[2.0.x] Use 'float' instead of 'double' maths

[ejtagle]

1. Replace 'double' with 'float'. Under AVR both types map to the same (float). On 32bit CPUs, they don't. The extra precision double costs more time, and is unnecessary. (On FPU enabled 32bit-boards, double is not accelerated but float is.)
2. Remove Quake III fast inverse square root. Profiling shows it is faster to simply call sqrtf (because it's implemented in assembler). The same profiling showed that if multiplication is 1x, division is 2x, square root is 4x, so it makes sense to replace them.
3. Replace several divisions by multiplications by the reciprocal, when the divisor can be reused (in vector normalization).
4. Optimize Delta forward kinematics formulae (please, @thinkyhead , check if the optimizations are OK, just to be sure... I don't have a delta to test them)
5. Replace some sqrt by division.

[p3p]

A quick perusal shows there are still a fair few double literals in areas you modified, there are a lot everywhere else in Marlin but I thought I'd mention it as you updated those parts, I had the choice between disabling double literals in the compiler or going through Marlin and changing them all... I disabled double literals.

[ejtagle]

@p3p : I know there are still doubles. Specifically in the serial.print() routines. I didn´t remove them because that would break inheritance from the Stream class.

But, those functions aren´t used, so i hope the linker is able to remove them.

If there is consensus, i can also remove all those functions 👍

[p3p]

Sorry, I said constant I meant literal, there are many double literals everywhere in Marlin not sure why, well.. its probably because it didn't matter with AVR.

[ejtagle]

Yes, i agree. Codebase is full of double literal values. Technically, that could force promotion to double of some calculations...

[thinkyhead]

probably because it didn't matter with AVR.

Basically, and converting all the values to float by appending f is a lot of work.

Some MCUs might actually prefer double if that's the native type that they use in their FPUs. Maybe we need a decimal type which refers to the format preferred by the FPU, if there is one.

[thinkyhead]

Some of these changes look like they'd be worthwhile for bugfix-1.1.x too.

[ejtagle]

@thinkyhead : There is no embedded MPU supporting hardware double precision floating point (except STM CortexM7, but we don´t support those boards). The other exception would be Raspberry Pi or a PC

There are options to force GCC to use floats for everything, -fsingle-precision-constant . That would probably be the best choice, but Arduino does not allow to specify that compilation option...

What i am mostly interested in, is the optimizations to the Delta kinematics... Probably 10% faster o maybe more...

[thinkyhead]

Since M_PI is now defined with f on the end, casting it might be redundant.

[ejtagle]

Theoretically, yes

[thinkyhead]

RECIPROCAL is safer, but also a little slower. If we know the parameter won't ever be 0.0 then it's better to just use 1.0 / x.

[ejtagle]

You are right here. That is why a review is always welcome !! 👍

[thinkyhead]

Is LROUND actually better here, since the return type is float?

[ejtagle]

On AVR is does not matter. On ARM, round would force a conversion from double->float, and the parameter of round() is double, so it also forces a conversion from float->double

[thinkyhead]

Ah, I see. These would definitely be faster.

[ejtagle]

👍

[ejtagle]

(btw: the compilation is failing because the success variable is not defined ... 👍 🌊 ... )

[thinkyhead]

Marlin loves me.
Yes I know.
Travis CI
told me so.

[thinkyhead]

The delta optimizations seem good to me!

I've heard that it's more optimal on AVR to use const float & arguments to functions rather than passing a float because a pointer is smaller than a float on this architecture. Since this doesn't help with processors that have 32-bit addresses, maybe we should use const float & only AVR and simply float on others. Or maybe the compiler can be made to optimize these parameters automatically.

[ejtagle]

@thinkyhead : And they gave you good advice. On AVR pointers are 16bit, requiring 2 registers to be passed by reference. floats are 32bits, so passing them by reference uses 2 registers, and passing them by value uses 4 registers. So passing by reference is 2x faster...
But, dereferencing the pointer (or reference) to read the float value adds as much time as passing the float itself, so, it depends... If the function will be inlined, there is no difference... If a float will be passed several levels below, then passing them by reference is faster...