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.)
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.
So pull back to the old
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict- aliasing -fwrapv -fomit-frame-pointer
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.
Brad
Afficher les réponses par date
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
On Aug 7, 2007, at 1:42 PM, Marc Feeley wrote:
On 7-Aug-07, at 11:31 AM, Bradley Lucier wrote:
So pull back to the old
-O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno- strict-aliasing -fwrapv -fomit-frame-pointer
Done.
Thanks!
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".
Thanks again.
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.scmEOS 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's not clear to me what EGO includes---what was just the default in beta22, or the default in beta22 plus what you got with --enable-gcc- opts in beta22? Is there a way just to get the default set of options in beta-22?
It seems like using --enable-optimize-space gives a faster build *and* faster execution.
On one application, the interpreter.
So maybe I will probably make this the default if I observe the same thing on other benchmarks.
I suggested in
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2006-March/ 000662.html
an intermediate code expansion strategy somewhere between ___OPTIMIZE_SPACE and ___OPTIMIZE_TIME; this strategy would still remove about half the edges in the control-flow-graph of the generated C code, but would still be quite a bit faster than ___OPTIMIZE_SPACE.
Brad
-
Bradley Lucier -
Marc Feeley