This is the mail archive of the
mailing list for the GCC project.
Re: The speed of the compiler, was: Re: Combine four insns
On Aug 9, 2010, at 10:28 AM, Toon Moene wrote:
> Diego Novillo wrote:
>> On 10-08-09 13:07 , Toon Moene wrote:
>>> Is this also true for C++ ? In that case it might be useful to curb
>>> Front End optimizations when -O0 is given ...
>> Not really, the amount of optimization is quite minimal to non-existent.
>> Much of the slowness is due to the inherent nature of C++ parsing. There is some performance to be gained by tweaking the various data structures and algorithms, but no order-of-magnitude opportunities seem to exist.
> Perhaps Chris can add something to this discussion - after all, LLVM is written mostly in C++, no ?
> Certainly, that must have provided him (and his team) with boatloads of performance data ....
I'm not sure what you mean here. The single biggest win I've got in my personal development was switching from llvm-g++ to clang++. It is substantially faster, uses much less memory and has better QoI than G++. I assume that's not the option that you're suggesting though. :-)
If you want to speed up GCC, I don't have any particular special sauce. I'd recommend the obvious approach:
1. Decide what you sort of builds you care about. Difference scenarios require completely different approaches to improve:
a. "Few core" laptops, "many core" workstations, massive distributed builds
b. -O0 -g or -O3 builds.
c. Memory constrained or memory unconstrained
d. C, ObjC, C++, other?
2. Measure and evaluate. You can see some of the (really old by now) measurements that we did for Clang here:
3. Act on something, depending on what you think is important and what deficiency is most impactful to that scenario. For example, we've found and tackled:
a. Memory use. On memory constrained systems (e.g. Apple just started shipping shiny new 24-thread machines that default to 6G of ram), this is the single biggest thing you can do to speed up builds.
b. Debug info: As others have pointed out, in the ELF world, this is a huge sink for link times. Apple defined this away long ago by changing the debug info model.
c. PCH: For Objective-C and C++ apps that were built for it, PCH is an amazing win. If you care about these use cases, it might be worthwhile to reevaluate GCC's PCH model, it "lacks optimality".
d. Integrated assembler: For C apps, we've got a 10-20% speedup at -O0 -g. The rest of GCC is probably not fast enough yet for this to start to matter much. See http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html
e. General speedups: Clang's preprocessor is roughly 2x faster than GCC's and the frontend is generally much faster. For example, it uses hash tables instead of lists where appropriate, so it doesn't get N^2 cases in silly situations as often. I don't what what else GCC is doing wrong, I haven't looked at its frontends much.
f. Optimizer/backend problems. LLVM was designed to not have many of the issues GCC has suffered from, but we've made substantial improvements to the memory use of debug info (within the compiler) for example. GCC seems to continue suffering from a host of historic issues with the RTL backend, and (my impression is) the GIMPLE optimizers are starting to slow down substantially as new stuff gets bolted in without a larger architectural view of the problem.
I'm also interested in looking at more aggressive techniques going forward, such as using a compiler server approach to get sharing across invocations of the compiler etc. This would speed up apps using PCH in particular.
At root, if you're interested in speeding up GCC, you need to decide whats important and stop the 1% performance regressions. It may not be obvious at first, but a continuous series of 1% slow-downs is actually an exponential regression.