Skip to main content
T J
Senior III
July 30, 2018
Solved

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

  • July 30, 2018
  • 12 replies
  • 3545 views

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...

    This topic has been closed for replies.
    Best answer by henry.dick

    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.

    12 replies

    Tesla DeLorean
    Guru
    July 30, 2018

    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.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    T J
    T JAuthor
    Senior III
    July 30, 2018

    just mapping the touch sensors,

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

    john doe
    Senior III
    July 30, 2018

    the standard math lib is pretty slow. try this:

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

    henry.dick
    Associate II
    July 30, 2018

    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
    T JAuthor
    Senior III
    July 30, 2018

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

    henry.dick
    Associate II
    July 31, 2018

    " as a guess."

    yeah. that's the right approach for sure.

    T J
    T JAuthor
    Senior III
    July 31, 2018

    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
    Associate II
    July 31, 2018

    "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
    henry.dickBest answer
    Associate II
    July 31, 2018

    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.

    henry.dick
    Associate II
    July 31, 2018

    if you really want to know, double precision sqrt takes about 1000 ticks (-O1), and single precision sqrt 500 ticks (-O1), on the same chip, inclusive of overhead.

    you can get your code to a working order and then we can make a more fair comparison.