🚀 go-pugleaf

"Jeffrey Cunningham" <jeffrey@cunningham.net> writes:

> I've re-run my simulation with the following flags, as suggested by Moritz
> Franosch:
> 
> -O3 offast-math -funroll-loops -march=i686
> 
> It made it slightly faster. So here's the summary:
> 
> 2.95 w/-O3: 0.17 minutes per iteration
> 3.2 w/-O3:  0.28 minutes per iteration

> 3.2 w/-MF:  0.24 minutes per iteration

Still much too slow. If gcc 3.2 performs 20% slower (even 40% in this
case) for a certain piece of code than gcc 2.95, I would consider this
as a performance bug. Gcc people should be interested in it, even more
so if you can identify the piece of code so that it is reasonably
short (and gcc people can look at the assembler output). If you don't
get your code much faster with the options below, I'd report it as a
performance bug.

> (MF=Moritz Franosch's flags). 
> 
> Better, but no cigar.I haven't tried either the -Ox or the
> -fstrict-aliasing yet. Later...

With -Ox I've meant -O, -O2 or -O3. Inline assembler math functions
are only enabled when using -ffast-math plus one of the -Ox.

I've just seen that -fstrict-aliasing ist turned on by -O2 in gcc 3.2
anyway (look at the info file).

You could also try these
-fomit-frame-pointer
-finline-functions
-fno-math-errno
-funsafe-math-optimizations
-fno-trapping-math
-fno-exceptions 

Some of them change program behavior, so you should check your results
and read the info file if you want to use these options in your
production code.


Moritz


-- 
Dipl.-Phys. Moritz Franosch
http://Franosch.org