Floating point vs fixed point calculations

[STuser2]

I need to perform lot of mathematical calculations and within a fixed time interval, the micro is STM32G474 my question is even if floating point calculator is available, do you recommend to use fixed point calcuations Q15 format etc. or I can go ahead with floating point calculations, will i get same performance? Please clarify.

[AScha.3]

If you get the needed precision by integer/fixed point calculation, it will always be faster than floating point, just because loading the floating point registers needs more time (32 or 64b) than having the value in 16b in the CPU registers and do one clock multiply.

Just do some simple test loops with the calculations you need and compare the time needed. I always do it, because this is 100% what you will get on this machine.

And always have optimizer on , -O2 is a fine setting, otherwise you see not the real performance of an arm CPU.

[STuser2]

Just one question related to above what is the benefit of CORDIC and FMAC modules? can i assume it is only in case i require more precision as per above explanation?  

[mfgkw]

CORDIC gives you not more precision. It is either q1.15 or q1.31.

It is just a bunch of algorithms, which can be implemented efficiently in hardware for trigionometric functions, logarithms and square roots (using add and shift to avoid multiplication).

It is a bit strange regarding the representaion, e.g. angles range from  -1 to +1 instead of -? to +?. 

[Andrew Neil]

Beware that the hardware FP unit in Cortex-M4 is only single precision:

https://mcuoneclipse.com/2019/03/29/be-aware-floating-point-operations-on-arm-cortex-m4f/

 

And floating point inherently has a number of issues:

What Every Computer Scientist Should Know About Floating-Point Arithmetic

 

There's an old computer science saying:

"If you think you need floating point to solve the problem, you don't understand the problem;

If you really do need floating point, then you have a problem you do not understand"

 

PS:

Previously, on this forum:

https://community.st.com/t5/stm32-mcus-products/stm32f446vet7-two-float-value-difference-problem/m-p/712815/highlight/true#M258906

 

[mfgkw]

I agree.

But another issue should be considered: with integral or fixed point arithmetic you need to be very clear about the range for your initial, intermediate and final values.

Floating point arithmetic is much more indulgent.

[STuser2]

Yes i really get confused with fixed point calculations, that is the concern i have. 

[Calculadora Alicia]

One practical approach is to benchmark both methods using the actual calculations required by your application. Fixed point can be efficient when the required range and precision are well defined, but scaling and intermediate values need careful handling. Floating point is generally easier when the calculation range varies. For the STM32G474, I would test the real workload and measure execution time rather than choosing only from theoretical performance.

[gregstm]

“… lot of mathematical calculations and within a fixed time interval ...” - that is pretty vague. Pity you couldn’t provide more detail about what you are trying to calculate. Here are my thoughts - 

get it working with floating point first - use test data, simulations, spreadsheets to make sure that everything is working well. If that isn’t fast enough, I would look at perhaps processing the data in blocks to increase efficiency, unwinding loops, or even assembly language. Only as a last resort would I try moving to fixed point. I’ve done a lot of that in the past and it is easy to stuff up the scaling etc.  and it often takes a lot of time and effort (and testing - use the test data from the working floating point version). Floating point is such a luxury - enjoy it.

[Alissia1240]

I agree that benchmarking the actual workload is the best way to compare integer and floating-point performance. Compiler optimization can make a big difference too, so testing with the same code and settings under -O2 or similar is a good approach. Real measurements are much more reliable than assuming one method will always be faster.