> 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.