This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Estimated SPEC2000 results for gcc+alpha
- To: rth at cygnus dot com (Richard Henderson)
- Subject: Re: Estimated SPEC2000 results for gcc+alpha
- From: Brad Lucier <lucier at math dot purdue dot edu>
- Date: Sat, 29 Jan 2000 13:19:07 -0500 (EST)
- Cc: lucier at math dot purdue dot edu (Brad Lucier), gcc at gcc dot gnu dot org, hosking at cs dot purdue dot edu
>
> You could hack gcc/f/g77spec.c and make sure -lcpml shows up before -lm...
>
> r~
It is not as easy as it seemed. I tried setting MATH_LIBRARY to "-lcpml -lm"
in gcc/f/g77spec.c and got the message:
popov-45% g77 -O3 -o testlm testlm.f
/export/u10/binutils-2.9.5.0.16/bin/ld: cannot find -lcpml -lm
collect2: ld returned 1 exit status
I then defined it in alpha.h and got the same message. The comments in
gcc/f/g77spec.c indicate that nothing should come between -lg2c and -lm.
So I figured out how to make libm.so a script to first include libcpml
and then libm, and this works for some small benchmarks I've tried (speeds
things up by a factor of 5-6), but it doesn't make any difference at all
to the CFP2000 benchmarks.
I find it hard to believe that the SPECFP2000 benchmark results compiled with
g77 are as bad as as I reported before in
http://gcc.gnu.org/ml/gcc/2000-01/msg00863.html
sixtrack is simply horrendous; I speculated that it was because I was
using slow math libraries, but I can't seem to get it to go any faster
with libcpml, and I'm finding it hard to figure out if I'm really using
cpml (although ldd reports cpml before lm). mgrid and apsi are
embarrassingly (sp?) bad and swim is not so great either.
Perhaps things would be better if I added -funroll-loops.
To make things more difficult, the g77 sources are getting increasingly
brittle; they won't build now with make -j on alpha linux (it bombs because
some files in gcc/f/ include the system system.h because the fixinclude'd
system.h is not ready yet) and is an increasing time sink for me.
For my codes I'm worried about gcc and g++ performance, and I'll continue
to concentrate on those compilers.
Brad