This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: egcs 1.1 performance report
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: egcs 1.1 performance report
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Mon, 24 Aug 98 23:04:11 +0200
- Cc: egcs at cygnus dot com
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <19980821042329.A642@dot.cygnus.com>
> Thought some folks would be interested in seeing how 1.1
> compares with 1.0 performance-wise. The following is
> the result of Spec95 run on my home machine, as described
> below.
> Executive summary is that we do a smidgen better, but
> nothing to brag about.
> In absolute terms, it is also nothing to brag about, as
> both SpecINT and SpecFP are about 60% of what they ought
> to be for my hardware.
BTW, do any of the SPECfp95 programs spend significant time doing
complex arithmetic ? I've been in a rather depressing dialog with
someone from South Korea who shows that for such code egcs/g77 can
easily be 2.5 times slower than Digital Fortran on the same
hardware.
The simple code put forward by Mr. Rowe in
http://www.cygnus.com/ml/egcs-bugs/1998-Apr/0117.html
and which I showed is twice as fast on my m68k when using
-fno-emulate-complex
http://www.cygnus.com/ml/egcs-bugs/1998-Apr/0245.html
gets a 1.5 x speedup on a 500 Mhz 21164A using that compilation flag.
The downside, of course, is that this only works by pure chance - a
lot of complex code doesn't compile correctly when using gcc's
SCmode and DCmode (which is what -fno-emulate-complex boils down
to).
Cheers,
Toon.
PS: My conclusion about the NEXT crashing running LAPACK's selftests
was completely wrong: Someone in the know pointed out to me that
the frame format error in the panic message was due to an unknown
stack frame encountered during a floating point emulation trap.
It seems that early 68040's do not always behave according to
the datasheets ....