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