mandrake.com;
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: [Cooker] RPM_OPT_FLAGS + BenchMark
>
>
> Thierry Vignaud wrote:
>
> >
> > Chmouel Boudjnah <[EMAIL PROTECTED]> writes:
> >
> > > Geoffrey Lee <[EMAIL PROTECTED]> writes:
> > >
> > > > i noticed that RPM_OPT_FLAGS have now got -ffast-math turned on. i
> > > > thought that breaks ANSI specifications just to get
> optimizations ? i
> > > > don't think that it is a good idea to pass to gcc...
> > >
> > > titi / guiseppe ?
> >
> > it doesn't really break ANSI spec, it just make some assumptions ...
> > (like non negative number for sqrt, ...)
>
are you sure??
taken from info gcc:
[...]
optimizations performed when this option is not used.
`-ffast-math'
This option allows GCC to violate some ANSI or IEEE rules and/or
specifications in the interest of optimizing code for speed. For
example, it allows the compiler to assume arguments to the `sqrt'
function are non-negative numbers and that no floating-point values
are NaNs.
This option should never be turned on by any `-O' option since it
can result in incorrect output for programs which depend on an
exact
[...]
i'm not saying that you shold not use -ffast-math , but only use it if there
is some significant optimization ...(mabye mesa, gimp ...)
i like Giuseppe's idea where you have CFLAGS="$RPM_OPT_FLAGS -ffast-math" or
CXXFLAGS="$RPM_OPT_FLAGS -ffast-math".
seems fair?
> Well, IMHO certainly is not a good idea to turn -ffast-math
> optimization on mathematical
> packages who generally don't make those assumptions (and the error
> code is important).
>
> IMHO it has sense to turn it on "on demand" using
> "CFLAGS="$RPM_OPT_FLAGS -ffast-math", on packages we have benchmarked a
> significative speed up (a 0.1% gain is not significative!), such as
> package doing floating point intensive (e.g. Mesa, gimp, etc.), and after
> we have tested no coredumps on it. For the rest of the packages
> speed up is
> totally negligible.
>
yep, exactly, turn it off!! and now!!
> > >
> > > > also is it possible to use -O3 instead of -O2, or will some
> code fail
> > > > toc ompile?
> > >
> > > we are back to -O3, -O2 was only there for gcc2.97.
> >
> > s/2.97/2.96/
>
> BTW, I think we should also do some benchmark. I found SSBENCH here
>
http://nastol.astro.lu.se/~stefans/bench.html
and several here:
http://devlinux.com/projects/reiserfs/bens.html
Who can do RPMS of SSBENCH?
BTW, is it true that on K7 -malign* and -m*boundary = 5 gives significative
increase of performance? Who can test on K7?
sorry not me, maybe send an [ANNOUNCE] message to cooker to look for guinea
pigs ? ;)
maybe we can look for some "benchmarking" c/c++ code (lots of those in
slashdot past stories) and do a test ...compile it under gcc and see what
happens, put some stress on the processor ...
Chmouel, can you turn the -ffast-math off now?
ther'es also one thing aobut RPM_OPT_FLAGS that iv'e mentioned to gc some
time before ...c++ code s0mtimes does not like -fno-exceptions (as c++ code
sometimes _need_ fexceptions) and will barf at one. what should we do about
that ?
one last thing: doesn't rpm now require bzip >= 1.0 to build, or am i wrong
about that ?
i once tried compiling 3.0.4 with bzip2 1pre, and it barfed...
