After having fixed the -ffast-math issues, I had done some research
and experiments to see what good/bad having -ffast-math
enabled/disabled.
After discovering that -ffast-math depended on enable sse asm (via
gcc's flag: -msse), I decided to experiment with building the entire
system against -ffast-math. I believe I have made comments on this
before, and my results showed that no noticable gain was made having
-ffast-math enabled; However, there were noticable problems in
addition to having some projects specifcally complain about
-ffast-math being enabled.
So, I have been dwelling over why -ffast-math was enabled all over the
Mesa source. I performed a test to see what happens with glxgears
with -ffast-math enabled in ONLY the Mesa source, and then when
-ffast-math is disabled. As it turns out, that recursive degration of
framerate (having no better way to explain this performance loss) was
caused by having -ffast-math enabled while using the uClibc system.
My Via Unichrome Pro acceleration had numbers around the following:
| with -ffast-math | without-ffast-math |
Only glxgears moving | ~700 fps | ~700fps |
Moving an xterm | ~400 fps* | ~600fps |
* The framerate could reach 0fps if i continued to move the xterm and
the xterm would lag immensly behind the mouse movements making the
xterm look like it is moving on its own (independant of the mouse).
** Also, glxgears should be 1200fps to denote bare-minimal
3d-acceleration, but due to the current state of 3d-acceleration in
linux, most cards don't get past 800fps. (perhaps I should say "most
old cards" or most cards without proprietary acceleration)
As 3d-acceleration is math intensive, -ffast-math should create
performance problems with other math intensive applications. So
removing -ffast-math from the Mesa source and any other projects is
recommendable on any uClibc system.
-ffast-math seems to be a good hardware-deaccelerator under uClibc.
I have tested this on multiple complete recompilations.
1) with hardening enabled, with nls/gettext
2) with hardening enabled, without nls/gettext
3) with hardening disabled, with nls/gettext
4) with hardening disabled, without nls/gettext
Amazingly, I saw little performance gain or loss with basic hardening,
but I still have not confirmed that the ssp is fully working. The
only hardening I have yet to apply is -fpie, which is supposed to have
little performance overhead as it is.
Having NLS/gettext disabled did not show an increase/decrease in the
performance, but did show a decrease in disk-space usage (noticable,
but not immense).
The noted performance gains/losses were tested against 3d-acceleration/glxgears.
--
Kevin Day
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
