Hi Vlad, On Thu, May 20, 2010 at 9:17 PM, Vladimir Makarov wrote: >> For some time now, I've wanted to see where compile time goes in a >> typical GCC build, because nobody really seems to know what the >> compiler spends its time on. The impressions that get published about >> gcc usually indicate that there is at least a feeling that GCC is not >> getting faster, and that parts of the compiler are unreasonably slow. >> > > It is just a feeling. In fact, starting since 4.2, gcc becomes faster (if > we ignore LTO). My feeling is that LLVM becomes slower. The gap in > compilation speed between GCC4.5 and LLVM2.7 achieves less 10% on x86_64 > SPECInt2000 for -O2. > > Feeling that GCC becomes slower probably occurs for people who switched > recently from 3.x versions because in comparison with theses versions gcc > became slower achieving maximum slowdown 25 and 40% slowdown on gcc4.2 > correspondingly on SPECInt2000 and SPECFP2000 on x86_64 for -O2.
Yes, I agree with you on this point. But I think that doesn't mean the GCC community can ignore the feeling. It would be great if, for once, the release notes could say "this release is 15% faster than the previous release" or something like that. For PR if nothing else ;-) > RA and scheduling is usually the slowest part of optimizing compiler because > they solve NP-problems and widely used algorithms (list scheduling and graph > coloring) has worst quadratic complexity. Yes. Actually I'm more worried about things like the DF LR/LIVE problems, var-tracking, and expand. DF used to be better than this, so I think there is a regression somewhere. I guess I'll have to look at the file-by-file data to see if there is one file that triggers bad performance. For var-tracking, I'll confess I'm biased, but I think it's one of the the worst thing that happened to GCC in a long time: too invasive, perhaps I'm not looking in the right places but I don't see the benefit and the crowds cheering about better debug info, and on top of all that it's slow. But that's one battle lost... I do feel that this slowdown (see also bugzilla) was not properly addressed before the GCC 4.5 release. And finally: expand. This should be just a change of IR format, from GIMPLE to RTL. I have no idea why this pass always shows up in the top 10 of slowest parts of GCC. Lowering passes on e.g. WHIRL, or GENERIC lowering to GIMPLE, never show up in the compile time overviews. > For example, here is comparison > of how many time LLVM-2.7 passes and analogous GCC passes (although sometime > it is hard to find full correspondence) spent on > > LTO GCC4.6 > RA (linear scan RA + simple register coalescing) 7.2% IRA > 9% > Instruction Selection 10.7% combiner+reload > 9% > > The data are from compilation all_cp2k_gfortran.f90 (420Kline fortran with > hundreds functions) on x86_64 in -O3 mode. By the way on Core2 GCC4.6 spent > 235 user sec on compilation of this file vs 265 sec by LLVM. Interesting data, thanks! > I don't know is it big or not to have such time spend in RTL parts. But I > think that this RTL part could be decreased if RTL (magically :) would have > smaller footprint and contain less details. <checks pockets...> Bah, no wand... :-) Ciao! Steven
