Intel C/C++ Compiler Beats GCC

jfonseca writes: "An article from Open Magazine claims the new Intel C/C++ compiler's geometric mean performance on multiple kernels compiled through it reached 47% improvement over GCC. They also predict the end to the ubiquitous GNU compiler due to low performance. Many other compiler/platform combinations also compared. A bit pretentious, yet an interesting read."

Comments

Re:Performance is important

[Shiny Metal S.]

Sometime I analize assembler code produced by gcc-2.95.3 and I am dissapointed. Gcc can do so stupid things like inserting instruction inside - instead outside of loop.

Instead of being dissapointed, you should talk about it on GCC mailing lists or even submit a patch. This is how GCC evolve. If you are skilled enough (and I suppose you are, if you can read and understand optimized assembly), and if you suffer because of low performence, than you should act instead of just being dissapointed. Remember that GCC is a free software, you can improve it.

Re:Does this mean?

[wytcld]

GCC isn't the worlds best compiler
As a sysadmin who often compiles packages, but doesn't write them, all I care is that ./configure;make;make install produces the desired results. Since I'm always multitasking anyhow over several machines, what do I care if a different compiler would make a 5 minute compile 4 minutes, if the end result - as it is with gcc - is a program that runs and runs well.

Mozilla (the shining jewel of Open Source)
BS. Konqueror is better, and KDE and Gnome the shining jewels, after Apache of course. (Sendmail? Bind? Proftpd? PHP? - not jewels perhaps, but great workhorses.)

Loki ... listened to the Linux zealots and got screwed
So sad, Linux may never be primary platform for gaming. I could care. And my Toyota will never enter the Indy 500.

Slashdot ... dream is gone and good riddance.
If you don't like the moderation, set up your own board and invite in only folks you agree with. /. works for me - what gets modded up is generally what I end up agreeing is most worth reading.

Re:Good benchmarking, poor analysis

[rkit]

"No, what's great news is that Intel's compilers are available now on Linux."

I totally agree. Unix has always been popular in scientific computing and egineering, but I know of several people switching to WindowsNT because

a) intel systems are extremly cheap (compared to architecures optimized for number crunching like RS6K)

b) compilers available for NT produced MUCH faster code, e.g. Digital fortran. (Yes, I know ... but still a lot of excellent scientific computing software is written in fortran77, e.g. LAPACK)

When it comes to numerical simulation, run times in the order of weeks are not unusual, so a performance penalty of 50 percent is simply unacceptable.

So this may turn out to be a big win for linux in the scientific computing area.

Re:GNU is no longer the driving force behind free

[Ray Dassen]

What breakthroughs has there been in RMS-led projects in the last - say - 5 years? I can't think of any.

So? The GNU project does not have a mission statement that includes "produce major breakthrough every couple of years". The FSF's top level page has a couple of links that are essential when trying to evaluate its success: why we exist (as relevant as ever), what we provide and where we are going.

But of course, that's just my opinion, so flame me.

I rarely flame people for their opinions. I occasionally flame people who clearly haven't bothered to try to understand what they're talking about and who don't let facts get in the way of their opinions. You seem to fit that category nicely. In particular, your comment "I think we need a lot more non-GNU involvment for gcc (gcc-foundation?) to get some fresh blood into this project. And if RMS doesn't allow that, we need a fork." shows you to have little understanding of gcc's development process. Gcc's development process was broken open in 1999 (by the FSF effectively admitting the failure of its cathedral-style development model of gcc 2.8.x and embracing the bazaar-style development model of the EGCS fork) and has an effective foundation (in the form of the GCC steering committee), as anyone who has read the GCC FAQ or is familiar with gcc's history knows.

The new intel compiler used to be Kai C++

[Karma Star]

We use Kai (or KCC) at work, and it is truely a remarkable product. It's a two-stage compiler - it generates C code native to the platform your working on, then calls the compiler/linker for that platform to compile it. The idea here is that the native compilers for any given platform will be able to optimize for that platform. So Kai just optimizes what it can and dumps it out into C code, then calls the native compiler/linker with optimizations on to recompile that code into the executable. The Kai C++ compiler was ported to Windows, Solaris, Linux, IRIX, etc., so there was the added benefit that any code written with Kai in mind would compile easily across other machines.

Kai and GCC are very similar in concept, except that Kai was a bit of a "higher end" compiler. Think of GCC being the Toyota of compilers, and KCC being the Lexus of compilers. You may pay the extra bucks just for the optimization/cross-platform abilities that Kai has - but most normal folk don't need it.

Unfortunately, Kai got purchased by Intel, and (from what I see on their site) they seem to be dropping the other platforms to support only intel. Really, the Intel compiler is really the Kai compiler, but only for Intel. In fact, Kai (Kuck and Associates Inc.), is now part of Intel. Personally, I think this sucks, since Kai really is a superior product compared to any other C++ compiler out there, if you will to pay the extra $$$...

GCC can't generate 16-bit code

[yerricde]

Fortunantly, GCC just about compiles on everything with a CPU

"Unfortunantly," last time I checked, GCC doesn't generate code for 8086 or 80286 processors, only i386 and up, so you can't build an OS that's backwards-compatible with legacy 16-bit apps with GCC.