We all know how tricky dealing with floating points can be - loss of precision, associativity violations, slowness compared to integer operations, and a lot of other fun aspects. But when we absolutely have to use floating point numbers, we shouldn’t care much about specific values, right? Well, let’s run a simple benchmark
It would be reasonable to expect all of them to take about the same time, except for maybe that weird ScaleDenormal one that is using std::numeric_limits<float>::denorm_min() factor. But the data are not very encouraging
Turns out even factor 0.3f results in the same 3.4X performance regression compared to 1.f! The explanation is bit involved and boils down to floating point representation and optimization for the common scenario.
When using perf you can use fp_assist.any event to see how often CPU had to switch to FP microcode handler and if you don’t care about precision use —ffast-math compiler flag or play with FTZ and DAZ flags.
It’s not like we haven’t already had enough reasons to avoid using floating point arithmetic, but I highly recommend considering alternatives - why use 0.3 dollars instead of 30 cents? Oftentimes it’s fairly easy to get rid of floating points by normalizing number range or changing their base - this makes computations much faster and avoids precision loss.