GCC 4.6, LLVM/Clang 2.9, DragonEgg Five-System Benchmarks
Phoronix: GCC 4.6, LLVM/Clang 2.9, DragonEgg Five-System Benchmarks
Version 4.6 of GCC was released over the weekend with a multitude of improvements and version 2.9 of the Low-Level Virtual Machine is due out in early April with its share of improvements. How though do these two leading open-source compilers compare? In this article we are providing benchmarks of GCC 4.5.2, GCC 4.6.0, DragonEgg with LLVM 2.9, and Clang with LLVM 2.9 across five distinct AMD / Intel systems to see how the compiler performance compares.
So LLVM is great, but Clang isn't
My reading of this is that the LLVM's x86_64 backend is slightly better than GCCs x86_64 backend, but that the C(++) frontend (eg Clang) still sucks. Would be great to know if this holds for other frontends and/or backends available in both compilers as well.
Still, beating even parts of the long optimized GCC is a great step forward for LLVM. Here's hoping to Clang being brought into shape as well!
+ Other optimization options?
Another aspect of this enters here: GCC tends to not enable a lot of the more aggressive optimizations by default, even at -O3. This is because they aren't helpful in every case, aren't 100% safe on some code structures, do transformations on the code structure that may not be intended or violate standards, etc. I've recently been playing around with intel's compiler, which does enable many of these by default, and yeah, they break some code. Here, though, I'm curious how gcc does with -O3 and the following options, none of which are enabled by default (see option notes for the reasons): -march=native -funsafe-loop-optimizations -fgcse-sm -fgcse-las -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -ftree-loop-im -fivopts -fmodulo-sched -fmodulo-sched-allow-regmoves -ftracer -fvariable-expansion-in-unroller -ffast-math -funsafe-math-optimizations -ffinite-math-only. Again, note that these may not be optimal for all programs.
Originally Posted by BenderRodriguez
In general, it seems that gcc's philosophy is to generate predictable and standards-compliant code by default, allowing "unsafe" options only by specific choice. After fighting code breaks caused by intel's compiler and having to figure out which options to disable, I can appreciate this :-).