On 7-Aug-07, at 11:31 AM, Bradley Lucier wrote:
Marc:
I've had a lot of experience now with the new compile options (and I'm not talking about --enable-gcc-opts) and I have to say that they just aren't worth it. You don't know which of them help the most in execution time, and you don't know which cost the most in compile time. (Hell, you don't even know which ones help *at all*; you could be running compiler passes that hurt run-time performance while eating up compile time.)
That's true.
You ran a genetic algorithm to guess which optimizations to run. That's fine to get an idea of what to try, but it's not sufficient to foist this pain on your users. Even on my Opteron server development is painful.
I feel the same pain on my MacBook Pro.
So pull back to the old
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno- strict-aliasing -fwrapv -fomit-frame-pointer
Done.
by default; even offer a configure optimization to add - D___OPTIMIZE_SPACE to the compile line. You have a development model that does whole-program compilation by default; it just can't support the default compiler options chosen at configure time.
Done. The configure option is "--enable-optimize-space".
On my 2GB 2GHz MacBook Pro using i686-apple-darwin8-gcc-4.0.1 I now get these times (for a build with "make -j 2", and for running "gsi tests/mix.scm") when using these configure options:
build gsi tests/mix.scm EOS 60s 8.41s <no options> 74s 8.52s ESH EOS 123s 4.38s ESH 147s 4.60s ESH EGO EOS 222s 4.19s ESH EGO 771s 4.33s
ESH = --enable-single-host EOS = --enable-optimize-space EGO = --enable-gcc-opts
It seems like using --enable-optimize-space gives a faster build *and* faster execution. So maybe I will probably make this the default if I observe the same thing on other benchmarks.
Marc