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.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'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