Re: Floating point performance issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 23/12/11 21:02, Vincent Lefevre wrote:
On 2011-12-20 22:52:12 +0100, David Brown wrote:
I understand what you are saying here - and I agree that it's very important
that any such choice is made clear and explicit.  But that's why a program's
makefile is part of its source code - compiler flags are an essential part
of the source.

Very often there isn't a static makefile, for instance for all those
programs built via the autotools: the compiler options are provided
by the one who builds the program. Note that there has already been
complaints because some program gave incorrect results due to the
-ffast-math option provided by a 3rd-party (who didn't know that it
shouldn't have been used for this program).

BTW, I've found in my archives the following example I had posted:

float x = 30.0;
int main()
{
   if ( 90.0/x != 3.0)
     abort();
   return 0;
}

fails with -ffast-math (on x86).

Note that more generally, depending on the application, one may be
able to prove that the division is exact (e.g. when computing some
determinant on simple data), so that the != should be perfectly safe
in such a case.


<snip>

I have read the rest of your post (and the next one) with interest - I'm just snipping here to save space.

It's quite clear that we are seeing a very different range of programs using floating point, and a different range of problems or questions around them. You see a much wider range than me - it makes sense that default flags, settings and warnings on the compiler are picked to do a reasonable job for such programs.

I work on a more restricted type of program (mostly embedded programming) where the rules are stricter. For example, a makefile or other clear and unambiguous indication of compiler flags is a requirement. In my work, the code you wrote above is bad code - it doesn't matter if the floating-point comparison turns out to be consistent when used, it's still wrong. So to me, there are no "false positives" with something like -Wfloat-equal. I want to be warned on anything that even smells like it could be "dodgy" code.

And (regarding other examples in your posts) if floating-point code depends on things like the order of calculations, it is also wrong - thus "-ffast-math" will not affect the correctness of the program, but will sometimes greatly improve the speed.


I don't think I'm alone in wishing that more programmers used stricter coding practices - a great many bugs that cause software users grief could have been found if the authors used their compilers' warning flags, and fixed their code appropriately. It is true that this would sometimes mean changing code that is actually correct, but looks wrong to the compiler - that's part of the cost. In many such situations, the code would also look questionable to humans, and should be changed anyway.

But I know full well that this is not going to change. So the default settings of the compiler provide the safest possible code in the widest possible circumstances, and programmers like me can use the flags to get the features they want.


[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google