CVS performance regression over 2.7.2 on SPECint95 on sparc
Dan Nicolaescu
dann@ics.uci.edu
Fri Dec 1 15:37:00 GMT 2000
Diego Novillo <dnovillo@redhat.com> writes:
> On Fri, 01 Dec 2000, Dan Nicolaescu wrote:
>
> > Diego Novillo <dnovillo@redhat.com> writes:
> >
> > > On Fri, 01 Dec 2000, Dan Nicolaescu wrote:
> > >
> > > > for both for gcc I get comparison errors.
> > > >
> > > > vortex compiled with gcc-CVS segfaults.
> > > >
> > > > Does anybody else see this?
> > > >
> > > I did see the vortex failures for yesterday's GCC (Nov30), but it
> > > ran fine today. I do not see the comparison errors for 126.gcc.
> > > I'm running on Linux 2.2.16.
> > >
> > > The failure on vortex I saw yesterday was a comparison error. It
> > > did not dump core.
> >
> > Sorry for not beeing clear enough, I was also referering to the
> > performance regressions.
> >
> Oh. Well, yes. It comes and goes. I didn't read the comparison
> table you posted. How much of a regression are you observing?
Here is an updated table, includes the scores for gcc-2.95.2 (compiled
with -O3 -mcpu=v8) and percentage increase in runtime compared to
gcc-2.7.2.3
% increase % increase
execution execution
for gcc-CVS for gcc-2.7.2.3 for gcc-2.95.2 time time
Base Base Base Base Base Base Base gcc-CVS vs gcc-2.95.2 vs
Benchmarks Ref Time Run Time Ratio Run Time Ratio Run Time Ratio gcc-2.7.2.3 gcc-2.7.2.3
------------ -------- -------- -------- -------- -------- -------- -------- ---------- -----------
099.go 4600 449 10.2 394 11.7 435 10.6 13.95% 10.40%
124.m88ksim 1900 234 8.12 244 7.80 289 6.58 -4.09% 18.44%
129.compress 1800 352 5.11 224 8.05 260 6.93 57.14% 16.07%
130.li 1900 254 7.48 256 7.42 264 7.21 -0.78% 3.12%
132.ijpeg 2400 252 9.53 246 9.77 266 9.04 2.43% 8.13%
134.perl 1900 207 9.17 202 9.40 193 9.83 2.47% -4.45%
147.vortex 2700 2.40 --X 323 8.36 314 8.61 N/A -2.78%
> Bear in mind that you're comparing to a really ancient version of
> gcc.
Isn't that an agravating factor?
> To my knowledge there has not been a systematic performance
> monitoring for GCC. Nothing public, anyway.
I will try to do some profiling and see if I can see anything
obviously wrong...
One obvious place where gcc is at disadvantage compared to other
compilers is compress, it has a function to read bytes from the
buffer to be compressed that just does:
return *buffer++;
That function's definition appears after it is used, so gcc cannot
inline it => on useless function call per byte read ...
--dan
More information about the Gcc
mailing list