4 ms·

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[

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.

tlb 15y ago
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.
- stephencanon 15y ago
  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.
  - tlb 15y ago
    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.
    - stephencanon 15y ago
      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.
mturmon 15y ago
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?

tlb 15y ago

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.

stephencanon 15y ago
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.
- tlb 15y ago
  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.
  - stephencanon 15y ago
    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.

mturmon 15y ago

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?