-ffast-math: Math critical applications?

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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,
    right?).
    * 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
      semi-transparent PNG.
    * 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
      obvious reasons.
    * 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
    anything risky.
    * 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
    mismatch reality.
    * 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

iQIVAwUBRSQM7gs1xW0HCTEFAQJ3DQ//Tw7FlEPmeE6Vuj7qZH5DfedcDGzH6MHw
JoIHQIIAtzVMtWbEZlTH8ouYHIJHwuTcFLMGIM9vQR0JNArTKSLbAT7O8X+2j7Dr
CBvs1FpVur6B35C5la09l6RAnqs0mjjk07TsCDihXm2LS8NJPVb7wCpCj382uwY5
zsHDDC9kGSD9Aurk8dUiIuNefOhC4bXBbRUZgFLdrGrmX+t5txFIfmeL1fabBExI
nfvubBDjCZ+VMF+M/CmE7NInLlZToQH8VO9mbnHHhT7R4k4PH3Bg8IiU0t/FyI8B
tapHGNuISuI5j3IL9ILmVTeIN00t/mI7NmRYRkbygQfSoi7gveypSp/p6CqIrbX6
4Zy7A9cOVDtX8zzzMVgumB4ueIbwFGfDOizzUUqGjuss2y2b/GN7PK0Q5Guvvrzg
xFS9CsY0E2sH80sLp6fTgcmK7xN+QOxEfaInORpmRAVyeQAVr061nDVRoAoVnBi4
aWjbQZo7muiAolpar0RoFEnJSH1k7w/yh3CdNjgeHGBgOxPljfsHDRtykElTihTs
lmsXPDxBUo2EaO2hw86RJWxzcrlUNR7o2wcGUTCMzXOVBkuh4EXnqSfM6E+eNBfO
WNYxmMSSmtuWdDuwmqo2jW6v+BKSXxz/1FxKt/iwXNSGFGjDGLxgsKdCRZJEV+Dj
GSDjfGk14OM=
=SSna
-----END PGP SIGNATURE-----