How fast is a double floating point Square root function on a 48MHz Cortex M0 ?

[T J]

I made an integer Square root function:

   int integerSQRT, result,result2;

   for (integerSQRT = 0; integerSQRT < 100; integerSQRT++)

       if (integerSQRT*integerSQRT >= squaredResult) {           

           result = integerSQRT - 1;      // just larger than the sqroot -1 is just less than

           integerSQRT = 100;

       }

// easily adapted to cube root, quad root etc...

[Tesla DeLorean]

Jack Ganssle has published routines in several places over the years.

http://www.ganssle.com/approx-2.htm

The Cortex-M0 is going to do everything relatively slowly. You'd likely want to use the TIM or GPIO methods for benchmarking code execution speeds.

Worth noting however that a 48 MHz STM CM0 will not run twice as fast as a 24 MHz one. The flash wait state becomes pretty dominant.

[T J]

just mapping the touch sensors,

to adjust for heavy Vs light touch readings, I needed to use Sqrt(); quickly..

[john doe]

the standard math lib is pretty slow. try this:

https://www.quinapalus.com/qfplib.html

[henry.dick]

I think you have to show first that your approach works.

Then you have to make a fair comparison: integer to interger math.

From a distance, decrementing the result will be slow. I would halve it, or use a slope based approximation.

Benchmarking it is a piece of cake.​

[T J]

just a novel approach, 1000x faster than software Floating Point. as a guess.

[henry.dick]

" as a guess."

yeah. that's the right approach for sure.

[T J]

This integer SQRT works well enough for this problem.

I have 48 channels to transmit every mS or less.

it is only a F0 processor, so I didn't bother to try the double SQRT Math function..

my guess is that it would take at least 1mS in software floating point, that's 1 channel and I have 48 and no time to wait.

I don't need to test it, so I guess...

[henry.dick]

"so I didn't bother to try the double SQRT Math function.."

yet you still claim your algorithm is faster than it. plus, you are compariong integer math vs. double float math: anyone can write the most inefficient integer routines that can beat equivalent 1024-bit most efficient floating math routines.

that's rigorous.

quoting execution time without quoting how fast you run the mcu makes zero sense for an apple to apple comparison.

[henry.dick · Accepted solution]

by halving the initial guess (similar to the cordic approach), I got about 230 ticks (-O1 optimized) to 290 ticks (no optimization) to calculate the integer sqrt of 65535, on a CM0.

running at 48Mhz, that means 5 - 6us per calculation, inclusive of overhead.

see if your code can beat that.