The only code that's being modified is the Linux kernel. It would be crazy to think they could get away with putting a back door in to that!!!

It's interesting that apparently just trying to compile something with Intel's compiler is a "project". I also tried compiling a piece of performance-critical code with Intel's compiler once. I gave up after a day or two--for me, there were just too many incompatibilities with the input flags and the output code. Instead of writing their own incompatible compiler, I'd really like to see Intel donate patches to gcc...

The monopoly = lack of progress = laziness argument is really weak for open-source projects like gcc.

These projects

So, the fact that you absolutely need competition to ensure progress is just bogus. Linux kernel (and even gcc) have been progressing fairly fast despite lack of serious competitors. If Linus criticized gcc it was probably due to *too many* performance features rather than too few. The kernel is being aggressively optimized already at source level, so its main requirement from the compiler is correctness, not optimizations.

ICC has become these days imho largely irrelevant, unless you are developing proprietary apps perhaps. The openness of gcc / llvm allows for optimizations in the "logical level" that icc
cannot even dream of. (I.e., you can hack the compiler to introduce extra optimization passes specific to your application)

The only field that is still largely open for competition is that of JIT/lifetime optimizations/
static & dynamic analysis etc where lots of problems remain unsolved and there is no "boxed"
open-source soft yet that solves them. LLVM is mainly interesting for going after this goal
but it still has a long way to go, especially in the front end area.

In the meantime gcc is getting support for plugins real soon now and it won't be too surprising
to see it become competent in the static analysis area pretty fast.

In closing, if ICC manages to optimize a few functions in a common codepath so that they run 40% (!!)
faster, then this imho should be considered a kernel bug and the *source* should be reworked
so that (large part of) this speedup is gained without need for any compiler help.

Good:
1) GCC=monopoly=slow progress=laziness. Even Linus Torvalds criticized gcc by saying he'd really love there to be a viable alternative to gcc.
2) When there's only one viable player people never get to see the whole picture - which is a breeding ground for fake and justified reasons against/in favor of GCC/ICC.
3) GCC is lucky because ICC is shooting itself in the foot by being closed source and non-free.

Bad:
1) Intel's reputation is questionable - it has been found guilty in the past by providing a compiler that spoils the code that targets AMD processors. Period.
2) A closed source and non-free compiler is much worse (intolerable!) than a 10% slower open source and free one.

I'm not an advanced computer scientist but i think Intel' compiler will make their own distro for Intel based arch. (e.g., Moblin) performs really good.

And i think it's better for Chinese (and other country known bad in computing) to join FOSS. It's good for them and us all if they put their skill on the place that it should rather than they're busy creating warez, cracks, and viruses.

I personally don't have a dog in the ICC vs. GCC fight. I'm not a kernel dev nor do I do a whole lot of coding these days. My main use for a compiler is the occasional download of a source tarball for something I want to build from source instead of using a pre-built package (I don't like the maintainer's compile-time options, I need to mod it, whatever) - and then I use gcc.

As a Linux/*NIX admin, however, I really don't understand the hostility or derision coming from some respondents.

If these guys can come up with a reasonable and repeatable recipe for using a compiler environment other than GCC to compile a Linux kernel, more power to them. It validates the reason that OSS is better than CSS - OSS can be adapted to an organization - any organization - rather than forcing an organization to adapt to the software (as CSS does).

We should be cheering these guys on, not throwing tomatoes.

If you don't like ICC, don't use it.

If you think someone should be helping improve GCC's optimization capabilities, go contribute to the GCC project.

But don't bash these guys for not putting their time into what you think they ought to contribute to, and don't throw stones at them for showing yet another reason open-source is better than closed-source.

icc is only faster than gcc if you don't use the parameter -fomit-frame-pointer. With the parameter -fomit-frame-pointer gcc is slightly faster on my project.

I am wondering why linux (and other open source) societies are not putting more effort to optimize GCC-compiler... Sounds pretty stupid that here we are using ridiculous amount of time optimizing every aspect of linux kernel when we could get 10% of more speed (on kernel level) with change of compiler. And we could say that if kernel level gives 10% more speed then higher runtime levels gives even more.

What we need is Univ. level projects to optimize GCC and implement perhaps new innovative optimizations to it. If GCC is now good it should be made better or even the best compiler.

Don't make me laugh, 2.6.22 is ancient, the thing is almost 2 years old.

Anyway, if your application is spending so much time in the kernel that a 40% speed-up is possible only by changing the kernel's compiler, there's something wrong with your app. Even if the improvement is in the 10% range, something fishy is going on---for instance, if your scientific app is 90% user 10% kernel, then icc has to eliminate 100% of all the kernel time to get a 10% speedup. Magic pixie dust, anyone?

My company uses it to compile its Linux products because our customers demand performance.

We use compiler settings requiring SSE2 (Pentium IV or greater). Performance is outstanding. GCC is not even close.