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

Re:Why does changing 0.1f to 0 slow down performance by 10x? by droithomme on Sunday March 11, 2012 @01:59PM (#3690817)

That code also serves as a good example of how assumptions about a theoretical "optimizing compiler" can lead people into trouble.

Something like:

  y[i] = y[i] + 0;

"Should" not take more time than:

  y[i] = y[i] + 0.1;

because "any decent optimizing compiler obviously would NOP the entire statement out".

I seldom see it is the case though where compilers optimize things that coders assume it is obvious the compiler will optimize.

[ Parent | on HN ]

Re:Why does changing 0.1f to 0 slow down performance by 10x? by tlb on Sunday March 11, 2012 @03:01PM (#3690970)

The semantics of floating point arithmetic in C do not allow the first line to be eliminated. It has non-trivial behavior in the case of signaling NaNs or denormals or -0.0.

[ Parent | on HN ]

Re:Why does changing 0.1f to 0 slow down performance by 10x? by stephencanon on Sunday March 11, 2012 @03:22PM (#3691017)

Adding zero (of either sign) has no effect on denormals in an IEEE-754 system. -0.0 and signaling NaNs are the only values which are effected.

[ Parent | on HN ]

Re:Why does changing 0.1f to 0 slow down performance by 10x? by tlb on Sunday March 11, 2012 @03:38PM (#3691056)

It can if you set the DAZ (denormals are zero) flag on the Pentium. I don't know if the C & IEEE-754 standards require the optimizer to preserve semantics in that case, but I can see why compiler writers would stay clear of such an optimization.

[ Parent | on HN ]

Re:Why does changing 0.1f to 0 slow down performance by 10x? by stephencanon on Sunday March 11, 2012 @05:31PM (#3691341)

Neither the C standard nor IEEE-754 specify anything about floating-point operations in non-standard modes like DAZ or FZ. (Nor do they require that support for signaling NaNs be implemented). The behavior of -0.0 suffices to block the optimization under strict fp modes, however.

[ Parent | on HN ]

Re:Why does changing 0.1f to 0 slow down performance by 10x? by mturmon on Sunday March 11, 2012 @08:10PM (#3691750)

I think you might have missed something in the OP.

I got the impression that the "+ 0.1" was enough to raise the value of the floating point number being operated on, so that it was not denormalized.

So, the "+ 0.1" version was faster because the numbers it generated were not denormalized. It had nothing to do with the special properties of 0 versus 0.1f (a float).

Neither of the two explanations on the SO post made any assumption about the "theoretical optimizing compiler" that you mention, right?

[ Parent | on HN ]