I guess no one here bothered to actually benchmark scalar (like unit type/conversion code) floats vs doubles on modern x86 hardware. It will perform identically

I guess no one here bothered to actually benchmark scalar (like unit type/conversion code) floats vs doubles on modern x86 hardware. It will perform identically. Heck, don't believe me, check Agner's x86 instruction tables [0]. Please default to doubles and optimize only when it's actually an issue. 99% of cases it's not, unless you're doing throughput computing. In that case floats provide up to 2x improvement. Keep in mind modern x86 CPUs can perform up to 16 double precision FLOPs (FMA) per cycle per core — do you really think it's going to be the bottleneck in your code? 32-bit floats expose you to nasty issues with even "simple" stuff like errors in naively computed sums. Issues that mostly just wouldn't matter if 64-bit doubles were used. See a proper floating point summation algorithm [1]. That said, even 64-bit doubles (or any arbitrarily long imprecise format) won't shield you from all of floating point weirdness. But it sure does help in common cases. With floats you'll get issues like this: https://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ https://randomascii.wordpress.com/2012/02/13/dont-store-that... [0]: https://www.agner.org/optimize/instruction_tables.pdf https://www.agner.org/optimize/instruction_tables.pdf [1]: https://en.wikipedia.org/wiki/Kahan_summation_algorithm https://en.wikipedia.org/wiki/Kahan_summation_algorithm