-ffast-math: Math critical applications?
John Richard Moser
nigelenki at comcast.net
Wed Oct 4 15:35:12 EDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
I am looking into gcc optimizations currently that either greatly
enhance code on the Geode GX or greatly harm it and are on by default.
So far I have found that -O2 enables -ftree-pre and that disabling this
causes a 34.8% reduction in the run time of POVRAY on POVBENCH. I get
similar results using -ffast-math, slightly better speed-up.
Currently of interest to me is applying -ffast-math generally. This
should not be a problem in most cases; -ffast-math only produces defects
in floating point calculations, and the defects are apparently often
minor enough to go unnoticed. Critical calculations like TCP/IP packet
size, byte offsets in files, and physical pixel locations are all
discrete anyway and thus will all be integer.
What I find interesting is that we know the FPU is crippled-- it's
single precision and basically uses a glorified emulator, because
doubles and anything higher are emulated by microcode that conveniently
can do single precision math by using a hardware FPU. A POVBENCH test
I'm doing looks to be ready to give better than 35%, but it won't finish
until 8am tomorrow. And the POVRAY guys confirmed for me that the
output when using -ffast-math is not visibly different in any way.
If the fuzz is only minor and/or only occurs rarely, then -ffast-math
can be applied in a number of places. Immediately of concern to me are
a number of things:
- Any media decoder code. Code to decode JPEG and PNG images, Ogg
Vorbis and FLAC, XviD and Theora.
* Any slight changes in random pixels will likely go unnoticed
anyway. Human perception is not great.
* We'll throw the results away when done, so we shouldn't care about
invisible damage to the calculations amounting to some inaccuracy
16 decimal places down the line.
* SIDE NOTE: Familiar for iPaq used an integer-math-only Ogg Vorbis
decoder. This could replace any Ogg Vorbis decoder on these
machines and avoid FPU overhead altogether.
- The entire rendering engine used for the Web browser (this is Gecko,
* Drawing Web pages is the same problem: We don't care what if a
single pixel has a single subpixel that's 0xAF instead of 0xAE
because the alpha blending code messed up on a single pixel in a
* Most of this is discrete anyway. Images that have opaque pixels
are opaque; areas of Web pages are defined by #rrggbb colors that
won't be floating point calculated.
There are three places I'm primarily worried about using -ffast-math with:
- Any sort of repeated calculation such as 3D rendering (Mesa) or
repeated image filtering, where an error in a single pixel of the
first calculation can be magnified by the next 3000 calculations
even if they're as accurate as normal.
* I don't forsee this being a potential use of the machine for
* POVRAY didn't care, users in #povray stated -ffast-math didn't
affect output on complex scenes they rendered.
- The compiler. It's a black box to me and I don't want to do
* I'm fairly certain the compiler is a discrete state machine anyway
and the worst it can output is working code with poorly calculated
floating point constants; however this propagates to any code it
builds that needs to be accurate.
- Spreadsheet and calculators. I don't want crappy results that
* This means -lm (mathlib) must be proper, not -ffast-math.
* It's doubtful anyone will notice; but I still would prefer these
tools to be as accurate as possible. Who is going to notice a
little extra run time in a spreadsheet application anyway?
Any comments? Thoughts on applications or libraries which rely
critically on IEEE standard float behavior? (Lossless compression like
gzip should be discrete; lossy should be floating point)
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Devel