A Quick Look At GCC 4.9 vs. LLVM Clang 3.5

[monohouse]

not a fair comparison

not a fair comparison, but not for the reasons mentioned so far, if you take a close look at GCC 4.9's changes, it shows it's colors at the LTO and at the LTO combined with PGO, and yes there were some changes to other optimizers but they do not appear to be the focus of GCC 4.9.

if you truly want to compare 4.9 to 4.8 or LLVM/Clang, you would enable LTO and PGO on all of them.
that being said, the opposite also applies (compare LLVM/Clang with the focus of this version of Clang to the same aspects of GCC 4.8 and 4.9).

[IsacDaavid]

Your logic is flawed.

``Here we have a test that can be compiled with or without OpenMP. One compiler supports, the other presently does not. We've decided to enable it to show how GCC kicks the crap out of LLVM who cannot leverage OpenMP. OpenMP is widely used, so it is a fair race.''

A fair comparison is to show the test with both compilers having disabled OpenMP support. We can determine from this just how dependent the test is on OpenMP versus the present state of compilers, but we feel this isn't fair to GCC who is already getting stomped too often.

So it is unfair for LLVM/Clang to be compared against a compiler with good multicore support but it isn't unfair when GCC lags behind in compilation time because of some techniques LLVM or its front-end implement but GCC doesn't. Nice logic.

Benchmarks should be carried at its maximum, squeezing the most and best of contenders, and that's how we know GCC still excels at making fast binaries, though slower at getting things done.