Re: [Bug-gnubg] compiling with optimization

[Jim Segrave]

On Wed 19 Nov 2003 (00:15 +0100), Holger wrote:
> At 22:09 18.11.2003, Achim Mueller wrote:
> >I just did a small test with different optimization flags.
> >
> >machine:toshiba satellite 2430-101, 512mb RAM, 2,5 ghz pentium4
> >os:     SuSE-Linux 9.0, glibc-2.3.2-88, gcc-3.3.1
> >
> >without opt:    CFLAGS=""
> >i686:           CFLAGS="-march=i686 -mcpu=i686"
> >i686-O2:        same + O2
> >i686-O3:        same + O3
> >pentium4:       CFLAGS="-march=pentium4 -mcpu=pentium4"
> >pentium4-O2:    same + O2
> >pentium4-O3:    same + O3
> >pentium4-all:   same + -pipe -fomit-frame-pointer -fforce-addr
> >                       -falign-functions=4 -ffast-math

-fomit-frame-pointer makes debugging very difficult.

> >Results (gnubg -t "calibrate"):
> >
> >without opt:    10954   12642
> >i686:           10985   11272
> >i686-O2:        22119   22125
> >i686-O3:        22386   22438
> >pentium4:       10996   11186
> >pentium4-O2:    23307   23255
> >pentium4-O3:    22849   22783
> >pentium4-all:   22815   22852
> >
> >Interesting: If you don't use "-O" you get only half of the maximum.
> >
> >Comments?
> 
> Same like we got in former tests. See e.g. 
> http://mail.gnu.org/archive/html/bug-gnubg/2003-01/msg00424.html . However 
> it's a bit strange that pentium4-O3 does worse than pentium4-O2. In my 
> experience it's most important to switch on -O2 (or -O3). All processor 
> specific features (like MMX or SSE) hardly make a difference.

I'm speculating a bit here, but O3 seems to try to inline more code
and appears (from trying to step through code with gdb) to do more
statement re-ordering. I suspect that the x86 architecture, with its
limited number of general purpose registers may make larger blocks of
code actually less favourable to optimise.

I'd also note that, while I've seen no ill-effects with O3 and gnubg,
the FreeBSD kernel does not function correctly with this level of
optimisation. The kernel developers maintain that this is a result of
gcc sometimes making incorrect optimisations. I have never pursued
this in depth, so I don't know of any sample code which can be used to
demonstrate that the optimised output is incorrect (or that the code
is non standard C).


-- 
Jim Segrave           address@hidden