Anders Magnusson's BSD-licensed pcc compiler has been imported into NetBSD's pkgsrc and OpenBSD's src tree. Anders wrote to NetBSD's tech-toolchain list: "It is not yet bug-free, but it can compile the i386 userspace. The big benefit of it is that it is fast, 5-10 times faster than gcc, while still producing reasonable code. The only optimization added so far is a multiple-register-class graph-coloring register allocator, which may be one of the best register allocators today. Conversion to SSA format is also implemented, but not yet the phi function. Not too difficult though, after that strength reduction is high on the list."
To read all comments associated with this story, please click here.
Member since:2006-07-15
Member since:2005-11-11
Member since:2006-02-15
Member since:2005-10-13
portability has nothing to do with GCC's performance
Portability takes up developer resources, and I believe this is GCC's real problem, they just don't have enough people to go around. Also, it supports a ton of different languages while most compilers only focus on 1 or 2. This also takes more developer resources and stops them from making language specific hacks. I mean optimizations.
it's not yet bug-free and it does produce only reasonable code
No compiler is completely bug free, and it does produce reasonable code. It's definitely not as good as some more focused compilers, but it's one of those programs that does a lot and is good enough for most people. More competition in open source compilers is a good thing, but lashing out at how terrible GCC is isn't very productive IMHO.
Member since:2005-07-06
There's all sorts of reasons why GCC is slower, and only a few are really avoidable.
1) GCC is a heavily optimizing compiler. It doesn't just produce reasonable code, it produces excellent code: http://groups.google.com/group/comp.compilers/browse_thread/thread/...
Heavily optimizing compilers are slower than non-optimizing ones. Not only is there the cost of the optimization passes themselves, but the very structure of the compiler must be more well-abstracted and general in order to support the code complexity of an aggressive optimizer.
2) GCC's reusability forces it to use multiple intermediate representations. There is a compile-time cost to converting between language dependent trees, language specific trees, and RTL.
3) GCC"s retargetability forces it to use slower and more generic algorithms. All of the GCC back-end code has to deal with the complexity of all of GCC's supported targets. For example, the register allocator has to deal with all of the quirks of the embedded processors GCC supports*. RTL has to support all of the weird addressing modes of the processors supported by GCC, and the RTL expanders have to take the full complexity of RTL into account. Even if GCC implemented the same algorithms as PCC for these tasks, the GCC version would still be slower because it has to account for all of these cases. On top of that, GCC does instruction combining and instruction scheduling that PCC doesn't even try to do. GCC has a very sophisticated generic instruction scheduler that can generate processor-specific schedulers based on abstract machine descriptions. PCC doesn't even try to do this.
It is possible, but not easy, to make a compiler as aggressive and portable as GCC that's still fast pretty fast. LLVM, for example, is pretty near SOTA, but it is faster than GCC, though by a much smaller factor than PCC. However, LLVM goes to great lengths to achieve that speed. It uses a very memory efficient intermediate representation (three address code instead of trees). It almost exclusively uses sparse optimizations, without ever taking the IR out of SSA form. IMHO, it's a better, cleaner design than GCC, but then again, it has the luxury of being built from the ground-up, and doesn't have decades of legacy to support.
*) I'll give a simple example of this. In my compiler, I use a basic Briggs-style coloring allocator with preferencing to handle dedicated registers. For an AMD64 target, you don't need anything else. This is a grand total of a couple of hundred lines of Lisp code, maybe equivalent to 1,000 lines of C. When you think about supporting all the targets GCC supports (well!), though, the complexity explodes, even if you're still using the same basic algorithm. Suddenly you have to consider overlapping register classes, non orthogonal instruction sets (AMD64 is actually quite orthogonal), huge register files, tiny register files, instructions that use register pairs, etc. The same basic algorithm now has to support all sorts of extra features. GCC's register allocator is 25,000 lines of C, for these reasons. No wonder it's slower!
Edited 2007-09-16 01:51
Member since:
2006-01-03
"The big benefit of it is that it is fast, 5-10 times faster than gcc, while still producing reasonable code."
Well, if gcc dropped its extensive portability, was "not yet bug-fre" and produced only "reasonable code", it would be fast too.