login
Search
An anonymous reader reported that a CVS version of the yet to be released GCC 3.4 is reaching parity with ICC on floating point performance according to SPECFP2000. SPECINT still isn't as good however GCC is making big improvements there too. I hope that this is an indication of things to come. Congratulations to the GCC team are in order.
Observations about the benchmarks
It's worth noting that the ICC used there is not ICC 7. It's a prerelease compiler. In the main page for RH's SPEC2000 results, the ICC used is listed as "Intel(R) C++ Compiler for 32-bit applications, Version 7.0 Pre-Beta Build 020415Z".
It's also unsettling to see that the CINT2000 numbers for gcc are lower when you add the -mfpmath=sse flag. As far as I know, that option only affects floating-point code. Correct me if I'm wrong.
I also have doubts about SPEC2000. It seems to me like it's one of those microbenchmark suites, which aren't very useful.
still impressive
GCC continues to amaze me. Truely one of the finest free software projects, I'm really looking forward to gcc3.4.
Rock on.
I can see it affecting intege
I can see it affecting integer code in places where SSE instructions might be used for prefetching, etc. If GCC is doing dynamic run-time tests to see if SSE is available, that can add a minor slowdown. It sounds like GCC needs some tuning.
I doubt SPEC could be conside
I doubt SPEC could be considered a microbenchmark. Microbenchmarks, by definition, focus on measuring one specific feature of a system to the isolation of all others. An example might be "system call cost." The source code in SPEC contains a fairly large cut of programs, including a version of GCC itself, interestingly.
The -mfpmath=sse flag
My uneducated guess (I may be horribly mistaken...): pentium 4 performs integer operations in sse registers by default. The only exception up til now has been prescott. When gcc is optimizing for floating point usage, integer performance could suffer because of lack of registers of some scheduling problems (generally resource control blunders, analogous to smp kernels thinking they have 2 physical processors under hyperthreading and thus naively overusing the single core they do have). But on the other hand when there is no fp code in the benchmark this shouldn't have any effect.
ICC versus GCC
Although I respect gcc, I don't see it quite possible that gcc could ever match icc. Given that Intel knows more than anyone else about their processors and has very good (and well paid) team of engineers.
The fact that ICC achieves a certain level of performance is proof that GCC could reach the same level. While it is impossible to predict whether that will happen, I would certainly not be surprised. Many talented people hack on GCC.
Nit picking... Also, home-field compiler advantages
The fact that ICC reachs a certain level of performance indicates soley that that level of performance is achievable from a C compiler on that platform. It doesn't prove anything about GCC. It just says that level of performance is achievable.
With sufficient effort, GCC may be able to meet or exceed that performance level. While GCC may not have the legions of full time compiler staff that ICC has, it does attract a large number of talented hackers from many corners. As you note, it would be naive to ignore GCC's long term performance potential, at least on popular targets (such as x86).
Where GCC gets left behind is in the special-purpose embedded spaces, where mindshare is much smaller. DSPs and embedded CPUs are a good example. GCC provides a great starting point for many of these CPUs, but you're not going to see quite as broad a focus on improving the back-ends for most of these. Only the most common (eg. ARM, MIPS, PPC) are going to see broad efforts. The rest of the effort primarily comes from the vendor or a pocket of interested hackers that will make it Good Enough(TM) for their immediate needs. This is where a vendor-supplied compiler really has a home-turf advantage, should the vendor decide to roll their own, provided the vendor is willing to put a decent compiler team behind the tools.
ICC versus GCC
I really think too that gcc will have hard time to reach ICC performance, for they are not the same thing.
gcc is a portable, multi-architecture and even cross possible compiler. While ICC is the Intel C Compiler, so here, forget all about cross compiling, managing tenths of target architecture.
But, we can still hope that the wonderfull gcc team can enhance a lot performances, but I think it will always be 'slightly' less performant.
Rgds
processor knowledge
> Given that Intel knows more than anyone else about their processors
That's not a given at all. Intel publishes books about their assembly. If there was some question about the fastest way to write an assembly instruction you could write a benchmark and find the answer.
Even if you only considerred hardware knowledge that still is not a given. For example, AMD is able to take Intel chips and improve on them.
What about 3.3?
Hmm.. What now, are they skiping 3.3 or is right around the corner?
GCC 3.3 is in Stage 3 (enough 3s?)
According to the GCC home page, it looks like they're wrapping up GCC 3.3 (specifically: they are in Stage 3 of development).
Meanwhile, GCC 3.4 is in Stage 1, which is the early "experimental" stage of development.
gcc release schedule
Straight from http://gcc.gnu.org/develop.html (reformatted):
GCC 3.3 Stage 3 (ends Oct 15 2002)
v>
v>
V>
v>|: GCC 3.3 branch created (Dec 14 2002)
v>
v>
V>
v>|: GCC 3.3 release (Mar 1 2003)
v>
v>
v>
v>|: GCC 3.3.1 release (May 1 2003)
This is very interesting. IC
This is very interesting.
ICC is a very special compiler that is tuned for optimum performance, while GCC is a cross-platform compiler that focuses on reliability and correctness. Kind of like comparing a SUV to a sports car. Only that in this case the SUV is faster than the sports car in some cases....
Re: Reliability and correctness?
I don't buy it. ICC has -O2 on by default and likely has more QA and people testing it than I can imagine GCC does, which primarily relies on user feedback and the distros to do testing.
ICC also uses the EDG front-end, which is bar-none the best damn C and C++ front-end there is. Plus, they have scads and scads of PhDs working on the backend. I don't see how GCC can even be comparable for the x86 architecture.
That GCC can usually get fairly close performance wise reflects the maturity and understanding of compilers in general, IMO.
Re: Reliability and correctness?
GCC is moving towards new C and C++ parsers as well. A new C++ parser is already even checked in for 3.4. The people who wrote that also worked on/with the EDG front end so that sounds promising.
As for the backend, GCC is just lots of legacy code. ICC was designed from scratch, which allows them to use the latest and greatest algorithms. This is one of the reasons why the compile times for ICC are so much better.
GCC on the other hand is still stuck with algorithms from the Dragon book. Projects to change this are always ongoing, but it's just much harder to change an existing compiler that is so versatile. Or put differently, it's damn hard not to break it.
But that does not mean that the people working on GCC are all just talented amateurs. In fact there are quite a few PhDs working on GCC as well.
It would still be interesting to see how Intel does when you really push it to its limits (autovectorization, interprocedural optimization, etc...)
That simply isn't true
GCC is way beyond the Dragon Book. Read it and then have a look at the code. Unless there are some specific areas you want to mention? Some of the instruction scheduling and register scheduling stuff in GCC is pretty close to cutting edge. There are a lot more PhDs working on GCC as part of their grad research than there are working on the ICC source code.
Give it time. On x86 GCC will be THE compiler of choice. It's just a matter of time. The differences now are already reduced to inner loop conditions and specialized areas of code. The area where GCC will probably continue to lag is in RISC processors like PowerPC and SPARC. Generally for 95% of the code out there you can't notice a difference with it.
The GCC code is very well modularized too. They have been making steady improvments to make it better and easier to hack on also.
sounds like it hurts you
I'm just a lurker...not the same Anon you responded to. It looks to me like the hurt one is you, sorry.
Re: That simply isn't true
I thought that GCC hadn't have any interprocedural optimisation?
And it was because of some 'political concern', which I find disheartening.
Interprocedural
Recent GCC's don't do anything interprocedural. That has nothing to do with politics. The infrastructure simply wasn't there. Interprocedural optimizations on a pseudo-assembly language like GCC's RTL is virtually useless.
Beyond 3.4, with precompiled header support merged and abstract syntax tree SSA optimizers merged, the infrastructure *is* there. At least for intra-unit (e.g. per file) interprocedural optimizations, it shouldn't even be very hard to do. This is very promissing technology!
So no politics here, just old technology that is being replaced.
Re: made up bullshit
You must be one of those new sophisticated trolls who hangs out on these Linux/OS related sites and memorizes things you know nothing about, because just about everything you just said is not true.
For starters, the author of the new parser, Mark Mitchell, does not work "on/with" EDG. And it's not hard to tell who works for EDG, because it's a 3-man company.
GCC is also way-way beyond the "Dragon book". There isn't anything like DFA, SSA, IPO or anything else in there, or much about type based alias analysis which GCC has had for eons now.
Re: more made up bullshit
GCC is also way-way beyond the "Dragon book". There isn't anything like DFA, SSA, IPO or anything else in there, or much about type based alias analysis which GCC has had for eons now.
GCC doesn't do DFA, has a very broken SSA implementation and doesn't do IPO.
For starters, the author of the new parser, Mark Mitchell, does not work "on/with" EDG. And it's not hard to tell who works for EDG, because it's a 3-man company.
Mark Mitchell works with (owns?) CodeSourcery, which has in fact contributed to EDG. And you can hire CodeSourcery to hack on EDG for you.
Re: DFA/SSA/IPO
Never said it did. But it's not in the Dragon Book, and GCC has progressed beyond the state of the art of the 1980's, which is what that book covers.
erm, gcc also has a respectab
erm, gcc also has a respectably big testsuite. it's not like they throw something and wait for user to report bugs.
Re: testsuite
Yeah, and thats good. But it's no where near what companies like intel/borland/ms do, where snapshots are taken and put on a build farm and have to churn through millions of lines of real code constantly.
that's nonsense
Companies aren't magic. Mostly they consist of lazy old goats who can't wait for the weekend to come around.
I've worked with compiler source. I've had to deal with compiler bugs on multiple platforms. I can tell you that gcc is a good compiler. Compiling C++ wasn't very good back when I was working in C++ but I hear it is better now.
Re: Companies
Way to go. Always nice when someone intentionally misinterprets you just so they can construct a counterargument.
There was no claim about any "company" magic. It was about what they DO. Nor was there anything about how "good" GCC is. It IS good, but the bottom line is still: GCC does not DO that kind of testing.
Re: Companies
It IS good, but the bottom line is still: GCC does not DO that kind of testing.
FUD.
What do you think the distro builders do, say, every week, but probably more often?
Re: FUD
Fucktard.
Not that often, and not nearly as wide a coverage, with not nearly as many skilled people analyzing the results. The major metric for testing is whether changes to the tree pass a make check and bootstrap. This information is widely available.
Hmm?
What about companies like Cygnus or Red Hat, or the developers and users who live on the bleeding edge, recompiling their OS kernels and tools with the latest and greatest versions of gcc?
Are those real companies and real users, testing out millions of lines of real code? Or am I just imagining the whole thing...
Re: Hmm?
They are, and that counts for something. One thing to notice though is that the number of severe bugs hasn't risen dramatically until just recently, since many people skipped the 3.0.x series entirely and stuck with 2.95.x.
However relying on users to bungle over problems after releases are out is a rather passive way to test, and if GCC had some nice infrastructure in place like a build farm, regression tester, ABI suite, etc they could detect bugs much earlier, more often, and release sooner with more confidence in the system.
The number of bugs in GNATS now is becoming an eye sore. Just go take a stroll, and you'll notice that the vast majority of them are unassigned with apparantly no intent to fix them. I've personally got bugs in there that are a few years old. On the bright side, I've noticed a couple of gung-ho volunteers have gone through several thousand of the unanalyzed ones and confirmed or rejected invalid ones.
What did intel pay you for th
What did intel pay you for this comment? :)
--
schnee
Re: intel paying
You know, I think you might be replying to my comment, but there are so many goddamned nested comments now I can hardly tell. If so, the answer is NO. :)
I submitted this!
...though it seems to have been since slightly modified... what's the deal? (not that I really mind)
what happend
Hey,
You did submit this. I rewrote about half of the text in the article and since it was annon claimed effort for doing the work. If you had put a name on it I would have left your name on it.
--Nate
Yeah thats cool
Just curious.
Compiler flags
Hi,
Looks like the icc flags for SPECfp2K are: -Qipo -QxW -O3 +FDO
But we are comparing gcc 3.4 with icc's -O3 only.