Why does changing 0.1f to 0 slow down performance by 10x?

I've been hit by nasty slow-downs with denormal numbers a couple of times. It's <i>much</i> easier to hit these problems with single-precision floating point, where near underflow happens much more quickly than with doubles.<p>As a folk-theorem of numerics goes though: such problems are often a symptom that you're not doing quite the right thing. Should your numbers <i>really</i> be that small? Often recasting the problem slightly avoids having to turn on low level flags or other hacking.

Exact same thing 4 weeks ago: <a href="http://news.ycombinator.com/item?id=3602388" rel="nofollow">http://news.ycombinator.com/item?id=3602388</a>

That code also serves as a good example of how assumptions about a theoretical "optimizing compiler" can lead people into trouble.<p>Something like:<p><pre><code> y[i] = y[i] + 0; </code></pre> "Should" not take more time than:<p><pre><code> y[i] = y[i] + 0.1; </code></pre> because "any decent optimizing compiler obviously would NOP the entire statement out".<p>I seldom see it is the case though where compilers optimize things that coders assume it is obvious the compiler will optimize.

This is a good opportunity for me to re-read <a href="http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html" rel="nofollow">http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.ht...</a>

Interesting discussion. Definitely something for the Lua programmers to keep in mind, as the default number implementation type is a C double. I did a quick test on my ancient MacBook, and the translation of the C++ code into Lua showed a slowdown for the denormalized case, although not as dramatic as the original problem (note: I changed the iteration count from 9,000,000 to 900,000 because the original count took way too long).

Wow, I wonder how many mysterious performance problems can be traced to things like this?

Yes, floating point is scary. I always try to stick with integers/fixed points if at all possible. Especially, if there is a loop with addition. That can eat 1 bit of precision per iteration if you're unlucky

I'm curious why no one has a good answer for the comments questioning why the compiler doesn't optimize out the +0/-0 instead of converting it to a floating-point, which triggers this issue.