Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[dewar at gnat dot com]

I still see *no* quantitative data showing that the transformation most
discussed here (associative redistribution) is effective in improving
performance.

Linus seems to be getting a little emotional in this discussion but swearing
does not replace data.

My viewpoint, which I will repeat briefly is that we have to look at each
proposed transformation individually, and determine, by quantitative
measurement (many of these measurements are in the literature) how great
the gain is, and then the gain has to be traded off against the effect of
the transformation.

This seems such a reasonable position that I really have a heck of a time
understanding why Linus is so incensed by it.

Note that the requirement that there be a significant gain is a gate. If a
given transformation cannot be shown to be an effective contributor to
performance, then we don't need to discuss the effect of the transformation.
I suspect that in practice, many of the proposed transformations simply won't
get past this gate, and that thus a lot of hot air is expended uselessly 
arguing about the second stage.

In the case that a given transformation *is* effective, then we can discuss.

Let's take an example, which is multiplication by a reciprocal. This of
course does give "wrong" results. But division is often quite slow. On the
other hand, I can't imagine floating-point programmers, including those
doing game stuff, not knowing this, and thus writing the multiplication
in the first place. 

<<Oh, round-to-zero is definitely acceptable in the world of "who cares
about IEEE, we want fast math, and we'll use fixed arithmetic if the FP
code is too slow".
>>

That's probably a bad idea, on most modern machines, full IEEE floating-point
is faster than integer arithmetic (particularly in the case of multiplication)