Hacker News Reader

Comment by assbuttbuttass | Hacker News Reader

> To my surprise, there were no measurable differences outside of the standard deviation we already see when repeating tests multiple times.

This should be the main takeaway. Don't enable ffast-math if floating point calculations aren't a bottleneck, and especially not if you don't understand all the other optimizations it enables.

View on HN

Counter argument: Always enable fast-math unless your application has a demonstrable need for deterministically consistent floating point math. If you're just trying to get a "good enough" calculation (which is the vast majority of floating point work, physics and rendering calculations for 3D graphics), there's no reason to leave the performance on the floor.

> there's no reason to leave the performance on the floor.

As the article demonstrates, there is: with ffast-math, floating point subtly behaves in ways that don't match the ways you've been taught it behaves.

And my point is the majority of floating point applications, which is to say _not_ scientific computing, don't care about subtle rounding-error differences in results

You cannot even stop a NaN from propagating, I would think that affects a lot more than just scientific computing. Of course games probably don't check, I ran into having NaN money in at least one game I played.

> Always enable fast-math unless your application has a demonstrable need for deterministically consistent floating point math.

As far as I remember fast math also breaks things like NaN and infinity, which makes filtering out invalid values before they hit something important fun since they will obviously still exist and mess up your results but you can no longer check for them.

No tight rendering loop building a transform matrix to ship off to the a graphics card has an isnan() in it to begin with. If your code cares about isnan() or infinities, that would be an example of a demonstrable need to not use fast-math

If the compiler is going to assume that all FP values and calculations are finite, then you really need to be able to check for any non-finite input values, which you can’t do with -ffast-math because it silently breaks isnan and isinf. WTF.

Also, there are other uses of FP besides games..

This is the approach that I take! (Note: I write graphics and rendering code for a living. "Good enough" for me tends to mean quantizing to either identical pixels at the display bit depth or at least perceptually identical pixels. Also, I usually do see a measurable performance benefit to -Ofast over -O3 or -O2. YMMV.)

Just like cranking the warning levels as high as I can at the beginning of a project, I also like to build and test with -ffast-math (really -Ofast) from the very beginning. Keeping it warning-free and working under -ffast-math as I go is a lot easier than trying to do it all at once later!

And much like the warnings, I find that any new code that fails under -ffast-math tends to be a bit suspect. I've found stuff that tends to break under -ffast-math will also frequently break with a different compiler or on a different hardware architecture. So -ffast-math is a nice canary for that.

Unless you upgrade your compiler and now your climate model produces different results... I think "good enough" is actually pretty rare unless it's for games or something.

"Games or something" is the majority of floating point work. There are far more video games and 3D renderings and people working on these technologies than climate models or scientific computing.

[citation needed], at least for the "people working on them" part.

“There are far more people doing [thing that I personally do] than [thing that I do not personally do, and thus know fewer people who do it].” — everyone ever

Reply on news.ycombinator.com