This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 3.1 is still very slow, compared to 2.95.3


> On Fri, May 17, 2002 at 06:21:22PM +0200, Jan Hubicka wrote:
> > > Compiling the OpenBSD  kernel:
> > > 
> > > gcc 2.95.3 yields:
> > > make  229.16s user 20.34s system 89% cpu 4:38.64 total
> > > 
> > > gcc 3.1 yields:
> > > make CC=egcc  398.28s user 22.55s system 91% cpu 7:40.39 total
> 
> > I am sorry to say that according to the profiles, there is no single
> > place in GCC where we burn most of the CPU cycles.  The slowdown is commulative
> > result of many patches and it is clear that compile time performance has not
> > been thread seriously during GCC development (3.0 had number of other problems
> > that were addressed).  I personaly will care more the compile time performance
> > in next development and hope we will set up some periodic tester to check this
> > (this has proved to be effective at runtime perfomrance, where 3.1 is very well of).
> 
> > I would suggest using of -O1 for machines where is not enought CPU power to
> > compile in resonable times.  -O1 codes does not perform at all that bad
> > (Andreas Jaeger has measured 3% overall difference in performance at
> > http://www.suse.de/~aj/SPEC using 3.0.x compiler, currently the difference will
> > be probably bigger, but still acceptable) and compilation is considerably
> > faster.  It can be interesting to compare -O1 performance to -O2 performance
> > of gcc 2.95.  Since 3.1 is about 6% faster for SPECS, there is good chance that
> > -O1 3.1 code perofrms better than -O2 2.95 code.
> 
> There is something rotten in that kingdom.
> 
> -O1 results are worse than gcc 2.95.3 at -O2, still:
> make CC=egcc  275.17s user 20.71s system 82% cpu 5:57.44 total
> 
> if this isn't a significant regression, I don't know what is.

Another idea, is it possible for you to eassilly compare this on non-i386
architecture?  The i386 backend has been redesigned and the memory overhead is
now unfortunately considerably bigger, so getting 2.95 scores is dificult in
this area.  i386 is not dead architecture and in 4 years since 2.95 the CPUs
got significantly faster, so it may compensate the regression.

But I see your point about m68k and firends. I owe myself an m68k machine and I
gave up updating GCC there just because it became unusably slow even in egcs
development period.  Still hope that the scores may be better there.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]