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: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000


> Paolo Bonzini wrote:
> >
> >Rather, we should seriously understand what caused the compilation time
> >jump in 4.2, and whether those are still a problem.  We made a good job
> >in 4.0 and 4.3 offsetting the slowdowns from infrastructure changes with
> >speedups from other changes; and 4.4 while slower than 4.3 at least
> >stays below 4.2.  But, 4.2 was a disaster for compilation time.
> >
> >  
> It was interesting for me that GCC4.4 is faster than GCC4.3 on Intel 
> Core I7.  This is  not true for most other processors (at least for P4, 
> Core2, Power4/5/6 etc).  Intel Core I7 has 3rd level big and fast cache 
> and memory controller on the chip.  I guess that slowdown in GCC is 
> mostly because of data and/or code locality.

Note that one of important reasons for slowdowns is the startup cost.
Binarry is bigger, we need more libraries and we do more initialization.
With per-function flags via attributes, we are now initializing all the
builtins and amount of builtins in i386 backend has grown to quite
extreme sizes.  In 4.3 timeframe I did some work on optimizing startup
costs that translated quite noticeably to kernel compilation time.  It
might be interesting to consider some scheme for initializing them
lazilly.

Honza
> 
> Fortunately, GCC4.5 will be 5% faster because of Richard Guenter's work 
> on improving aliasing (of course if it will be not eaten by a new 
> optimization).  People are complaining about GCC compilation speed and 
> of course we should work on its speedup.  But GCC is not so bad, for 
> example SUN Studio compiler is almost 2 times slower than GCC.  IMHO, 
> GCC performace is still #1 priority for us (although people working on 
> embedded processors could disagree with me).  I think that because in my 
> experience the performance improvement is much harder to achieve than 
> compilation speed and code size improvements.


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