Intel Releases V6.0 Compiler Suite

Yokaze writes: "Intels C++ and Fortran compilers are now available for Windows and Linux. The compiler for Linux provides higher compatibility with the GNU C-compiler including compability to the upcoming GCC-3.1 C++-ABI (binary compability) and support for several GNUisms in the syntax (PDF). To quote Intel: 'The 6.0 release of the Intel C++ compiler has improved support for the GNU C language extensions and is now able to build the Linux kernel with minor work arounds for both the IA-32 and Itanium architectures.' Little reminder: Running such a kernel is, of course, not supported by the kernel developers. Evaluation copies are available for download, but requires previous registration."

Comments

Just a Preemptive strike here

[castlan]

Standing up for the FSF,

Compiling a Linux kernel for a GNU system without an Intel compiler does not mean that you are running Intel/Linux OS.

Although there is a pretty good chance that whoever reads this is running GNU/Linux Intel.

I love the smell of propaganda in the morning... It smells like sour grapes...

Adopt GCC extensions?

[babychess]

Interesting to see their compiler supports GNU C extensions. Usually it's the other way around, free software keeps implementing undocumented extensions. At least the GNU extensions are useful (like 0-sized arrays), and well documented.

It's also interesting that they wrote their own compiler, instead of patching GCC. GCC also works on Windows and 3.1 already has optimizations for different CPU extensions to x86.

They also wrote a new debugger (LDB) specially for Linux, although they claim it implements only a subset of GDB, so what is it for?

And to compile the kernel...who will do that? Is there some server vendor planning to sell Intel servers with such kernels on?

Re:Adopt GCC extensions?

[psavo]

It's also interesting that they wrote their own compiler, instead of patching GCC. GCC also works on Windows and 3.1 already has optimizations for different CPU extensions to x86.

Well, that's mostly sad. They cannot extend gcc, because gcc is under GPL -> they'd have to release the source -> many patented & licensed tricks would be exposed.

And to compile the kernel...who will do that? Is there some server vendor planning to sell Intel servers with such kernels on?

Kernel compiling is pretty much 'fire test'. If they can do that, they can do almost anything (save from mplayer ;). Also, kernel accounts for pretty much system overhead, so speeding kernel up speeds system. especially linux kernel SW RAID, sweet.

The area Intel compiler will shine is all computing -intensive tasks. Like Maya 4, povray, most math libs and stuff. So there is place and _demand_ for it.

I wonder how this code will perform on Athlon/Hammer-32..

Re:Adopt GCC extensions?

[QuantumG]

They cannot extend GCC because they're writing a high performance compiler, not an optimising compiler, it's a different architecture because it's solving a different problem.

Re:Adopt GCC extensions?

[Anonymous Coward]

Some people may find this interesting: GCC for IA64 Summit Talks about some of the optimization problems with GCC. Here's one juicy bit:

Suneel Jain: Is the goal of having a higher-level tree representation
to do inter-procedural optimizations from information written to
disk?

Mark Mitchell: This question comes up a lot. The sticky issue is that
the FSF is morally opposed to doing this. The aim of the FSF is not
to produce the best compiler, but to convince the world that all
software should be free. The concern is that writing out the
representation to disk would allow a vendor to use a GCC front end,
write the IL to disk, read it back in, and graft proprietary code
into GCC in a sneaky way to get around the GPL. This is a very
firmly held position in the FSF.

Re:Adopt GCC extensions?

[Anonymous Coward]

I had to read this twice... quite frankly, it's a pretty stupid reason to avoid those type of optimizations. First, if it's a real worry, add a clause to the gcc license that explicitly prohibits this hack. Second, there's nothing preventing someone from (essentially) doing this anyways - NuMega and Rational both have tools that are capable of injecting arbitrary code into a binary, and there are other projects that are exploring similar modifications (heck, disassemble the binary and run it through an optimizing assembler in order to generate proprietary code.)

Performance?

[4of12]

...able to build the Linux kernel...

So that begs the question: apart from issues of reliability, stability, do the Intel compilers make a Linux system perform better or worse than one built with gcc?

Re:Performance?

[spencerogden]

I think last time the Intel compiler was discussed it offered significant performance benefits ( read more than 10% ) on both Intel and AMD chips.

Re:Performance?

[Lars T.]

Again a word of warning: the Intel compilers can yield incorrect programs, if the more agressive optimizations (inter procedural optimization / -ipo) are used. At least this was the case for Version 5.5 (article in German).

Re:Performance?

[tjwhaynes]

So that begs the question: apart from issues of reliability, stability, do the Intel compilers make a Linux system perform better or worse than one built with gcc?

The correct answer to that question is: It depends

I've made use of the new Intel compiler on some Linux projects. Initial results showed that it had about the same performance as gcc. But at this point we know a lot about the gcc compiler tuning and not a lot about the characteristics of the Intel compiler, so only time will tell how much performance can be (safetly) wrung out of the Intel compiler.

Cheers,

Toby Haynes

Interesting...

[pb]

It says it does profiling, and Itanium-specific optimizations, along with some more standard compiler tricks...

I'm sure it produces faster code on average than gcc, but it'd be interesting to see a gcc/Intel Athlon/P4 showdown. ;)

Re:Interesting...

[TheMatt]

Not quite what you want but look at this page. It compares many a chipset in re Gaussian 98. The benchmarks are in minutes so they are quite meaningful.

Re:Interesting...

[elfkicker]

Somewhat offtopic, but since you brought up AMD...

Ars has a story yesterday relating to Microsoft and AMD getting in bed together and Microsoft insisting that Intel incorporate AMD's x86 64-bit instructions over their own IA64 code. It may all be rumor, but it's intriguiging. Check it out.

You'll have to scroll down to "x86 64-bit support for Windows".

Re:Interesting...

[Lictor]

This hardly counts as a showdown, but, here are some statistically meaningless personal observations on my Athlon XP 1700+:

I tried compiling a program I've been working on with gcc-2.96 and version 6 of icc with some cut'n'paste "heavily optimize" flags*.

(The program generates all finite semigroups of a given order, and consists completely of integer operations).

To generate all finite semigroups of order 7 took (under constant system load; result is the average of the system time reported by /usr/bin/time over three attempts):

~672 seconds with the gcc executable
~553 seconds with the icc executable

Its not an Earth-shattering difference, but its certainly non-trivial.

Again, please don't mistake this for a fair comparison of any sort... its simply a test of both compilers in the only domain that matters a tinker's cuss to me: Will it generate faster exectuables for the program I'm working on at the moment with little to no extra work? Extrapolate at your own risk.

* flags for gcc were:
-O3 -fomit-frame-pointer -mcpu=pentiumpro -march=pentiumpro -malign-functions=4 -funroll-loops -fexpensive-optimizations -fschedule-insns2 -finline-functions -fstrict-aliasing

flags for icc were:
-O3 -tpp6 -xK -ipo -prof_use

(I compiled previously with -prof_gen and generated a profile running semigroups of order 6).

I hope they got it right this time.

[Utopia]

The Intel compiler has been known to ignore possible pointer-aliasing (variable accessed directly and also accessed via a pointer).
This is OK with Fortran or in Fortran converted to C because Fortran doesn't have aliasing.
This serious bug results in a lot of incorrect code.
It is prudent that you double check the results from the Intel compiler.

Re:I hope they got it right this time.

[tjwhaynes]

The Intel compiler has been known to ignore possible pointer-aliasing (variable accessed directly and also accessed via a pointer).

Its not the only compiler that has problems with pointer aliasing. Optimizing aliased pointers will give you trouble on lots of platforms - careful reading of the ANSI standard says quite a lot about valid C coding and avoiding aliasing situations.

Cheers,

Toby Haynes

Pretty lame overall.

[Ogerman]

Intel ought to stick with what they do best: designing fast microprocessors. If they could give the gcc folks some tips on improving performance, I think that'd go a lot further for their bottom line then wasting time writing proprietary compilers that only a few companies will use. Do they quite realize the market advantage of having the Open Source community on their side? Heck, I'd quit using AMD processors tomorrow if Intel could squeeze significantly more performance out of their chips in gcc. AMD take note: you guys could be the first to jump on this as well.

Re:Pretty lame overall.

[bstrahm]

Problem is that GCC's top goal isn't maximum performance, it is maximum portability. There are a lot of things you can do if you only have to target one architecture (and trust me Intel is only targetting one architecture) rather than the several dozen that GCC targets...

This said there is a need for both, ultimate portability and ultimate performance. The intel compilers have been delivering ultimate performance on their architecture for years, look at the difference 10 years ago between the MS compiler (internally developed) and the Watcom compiler (Intel License) guess who's compiler produced significantly faster executables...

BoundsChecker and Purify verus GPL?

[cpeterso]

You bring up a good point. Is it legal to debug a GPL program using NuMega BoundsChecker or Rational Purify? These programs are modifying (quasi-linking) the GPL binary..

Re:BoundsChecker and Purify verus GPL?

[Anonymous Coward]

You can link proprietary code with GPL all day long, just don't distribute any of it.

You can get a gratis, unsupported version...

[karmawarrior]

for Linux here. If you want support however, the supported version is a hair under $400 per licence (discounts for >9 licences)

Sadly there's no Windows version of the unsupported offer.