Scott Robert Ladd has updated his GCC versus Intel C++ compiler benchmarks. This time round he includes updated results of the recently released GCC 3.1. The new version of GCC seems to be much better than its 3.0.4 predecessor, and GCC 3.1 even wins some benchmarks it lost previously over ICC. Overall, ICC remains a much faster C/C++ compiler, but GCC has successfully narrowed the gap. Read Scott’s interesting conclusion at the end of the article too.
GCC 3.1 Narrows Performance Gap Against ICC 6.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Having it improved is quite good, I hope that will be integrated in short time in the distributions
(Having gentoo I already have it ^^, next weekend I’ll try to emerge -e world an see if it break everthing or give some speed)
“Overall, ICC remains a much faster C/C++ compiler…” – not sure this is fair. The results seem very close. Its strange because Intel make the chips and have teams of dedicated programmers enhancing ICC performance. How on Earth do the gcc team even manage to stay in the same league let alone stay about level?
"Overall, ICC remains a much faster C/C++ compiler"
Really? I wasn’t aware that he looked into compilation times.
Not to mention that, overall, ICC remains a much less free compiler.
gcc – the most important of all the free projects because the others wouldn’t make sense without it.
Good to see that its so good that there’s no point in chucking Intel $400 to get their compiler.
>I wasn’t aware that he looked into compilation times.
We are not talking here about compilation times, but rather produced executable quality and speed.
this is a non-story. Of course Intel’s compiler is faster; it targets a single CPU family and it has the support of the very company that created the x86.
I am learning to program at home (in my spare time) but I will never use ICC because it is not free (as in freedom) software.
“We are not talking here about compilation times, but rather produced executable quality and speed.”
I’ve read the whole thing twice and it definitely indicates that gcc 3.1 is only slightly behind ICC.
Would you call a 850 mHz processor “much faster” than a 800 mHz processor? I bet most people would never notice the difference, and I suspect the same is true for code from ICC vs. GCC 3.1
I think that this article is far from a “non-story.” Having a detailed comparison of two top-notch compilers is critical to programmers in the field where execution time really does matter. Although a 10-15% difference in execution time may seem trivial, this is the kind of difference that can differentiate one 3D rendering program from another. When a 10-15% performance increase matters to a programmer, forking over $400 is going to be a trivial concern. My only concern in moving to icc, is how well the compiler optimizes for AMD chips vs. gcc. However, if your market is Intel-based, this doesn’t really matter either.
Eugenia, I was being tongue-in-cheek with my comment. The reason being the ambigious nature of your writing, and the fact that my reading of the benchmarks is that overall, ICC is but slightly faster.
He completely changed his conclusion based on significant improvements in just two benchmarks, Stepanov and Mazebench.
We know that at least one of these is very amenable to careful option tuning, and therefore could be won or lost by a compiler based on its assumptions about what optimisations are “healthy” for normal applications (Compilers have to make compromises and inlining is one of them, it can turn a few tight loops into a huge monster that smashes the cache if the compiler is over-enthusiastic)
Neither of these benchmarks does something genuinely useful (unlike the code fragments used in SPECint tests which are AFAIK mostly extracted from larger sources that serve a real purpose) so I’m dubious about the value of the exercise.
I still feel the same way I did on reading the original benchmarks, despite praise for ICC from a friend who writes high performance audio processing code. Vendor compilers are a good thing to try when you’ve spent a lot of money on the vendor’s hardware and you aren’t getting the expected performance. For most users AND developers they aren’t worth the extra hassle and cost over GNU’s suite.
If Intel daren’t donate their “go faster” optimisations for the Pentium family to GCC then maybe instead of buying Intel CPUs we ought to be trying to buy Intel compiler engineers – then we could shop around for the best price on hardware and still get all this lovely vectorisation
Yesterday I ported all my work code over to gcc 3.1 and got it running. It seems to be a ton ton slower. This morning I decided to run a race: a clean build on 2 almost identical machines (dual 1GHz P3’s with 1G+ ram), one with gcc-3.1 and gcc-2.96. I’m using QT 3.0.4 multi thread and some other libraries. Line count for code (*.h *.cc *.cpp) is 192543 with comments (mostly doxygen). Anyways, here are the times (wall clock time, the systems were idle)
gcc 2.96 – 19:22.77
gcc 3.1 – 25:17.92
Not exactly wonderful, it’s definitely enough for me to wonder if i should use 3.1 for doing debug and all. Btw, I was using flags:
-fno-exceptions -pedantic -Wall -finline-functions -Woverloaded-virtual -ffast-math
Somehow, it doesn’t seem all THAT surprising, because of all the stuff they added when they got to gcc 3.0, and now 3.1, like new and/or better optimizations, better standards compliance, etc.
Besides, supposedly, gcc 3.0.x is way slower than gcc 3.1, and far more resource intensive (kiss your ram and swap space goodbye). The gcc team seems to have given up on providing a FAST COMPILER a long time ago. They are way more focused on making a highly standards-compliant compiler that GENERATES FAST CODE (assuming you want it). In the future, when the 3.x series settles and cools, and there hopefully won’t be any major new revisions to the standards, they will go back and speed things up. According to the “Changes” page, they already have, at least when compared to 3.0.x.
OH yeah, there’s java too, and Ada is coming. No, Ada is not dead. It never died. The US government likes Ada.
–JM