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?

[psavo]

Sorry? Do you mean they're writing a compiler that'll compile things real fast? Why's that? -- compiling is 'cheap'.

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.)

Good for Intel!

[Komarosu]

Looks like Intel has woke up and smelt the coffee and actually listening to what the developers want, not what they think they want.

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?

[billcopc]

It's more that the kernel code has been extensively tweaked for GCC, which does a few things the Intel compiler doesn't, and vice versa. Something as complex as the linux kernel usually relies on sensitive features in the compiler, or makes up for them with add-on scripts that massage the resulting binary into compliance.

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

Re:Performance?

[Anonymous Coward]

Bah. That is a load of crap. The intel compiler blows GCC out of the water on just about everything I've used it on. Athlon -> Faster. PII -> Faster. P3 -> Faster. P4 -> Faster. Xeon -> Faster. Xeon w/ CPU Threads -> Faster.

In all cases we're talking >10%... On the Xeon, I had an increase of ~35% on the same code. I have a feeling if you didn't notice a significant speed increase you were having problems seeing past your gnu'ism. I have significant problems with the low speed low quality code generated by GCC. I would like a quality compiler that generates modern code, but I don't see that as long as zealots keep commercial help out of the compiler projects.

Re:Performance?

[Anonymous Coward]

Are you serious?

In the applications we have built with the intelcompiler we have typically had 30-50% faster code generated, even more under some circumstances.

Re:Performance?

[Anonymous Coward]

Same goes for GCC, most of all on non-intel platforms. We spent many many hours looking for bugs in our code that in the end didn't exists. This was for the StrongARM processor.

Re:Performance?

[gd23ka]

Right. Which is also why people using an Intel or other non-gcc compiler should first replicate bugs they find in their 3rd party compiler builds with a build produced by the official gcc compiler.

I'd rather see more work done on increasing the performance of the already excellent code that GCC produces on a wide variety of platforms (The Gnu Compiler Collection doesn't just generate IA32 machine code, btw, there's Alpha, ARM, M68K, AMD's version of IA-64 and a hell of a lot more...). I for my part don't want to use a proprietary compiler that makes use of secret, undocumented chip specific tweaks to eke out another 10% of performance on chips made by a specific manufacturer. I want a compiler that produces robust, dependable and fast code and that compiler is GCC.

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...

[morbid]

Itanium-specific optimizations?
Why bother?

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

This is nice, but...

[billcopc]

Let's harass AMD to give us an Athlon-optimized compiler for linux, eh ? These Intel tweaks don't do squat for my T-Bird. Or at least they could pitch in on GCC development.

Re:This is nice, but...

[Anonymous Coward]

I can't speak for Intel's C compiler, but moving to Intel's Fortran compiler on an Athlon Linux box bought my research group a 35% decrease in runtimes (for a simulation code that relies heavily on matrix factorization). We experimented a little with the compiler switches, but nothing heroic.

Re:This is nice, but...

[Anonymous Coward]

AMD uses the Intel compiler to submit their SPEC scores, so they do more than squat for a Athlon. Mainly because the design goal of the K7 was to run existing P6 code very fast.

For Hammer, however, it sounds like you'll have the choice between MSVC and GCC.

Re:This is nice, but...

[kermit6306]

That would be nice. Too bad AMD doesn't have a comiler team. Intel is a completely different company, they're about 6 times bigger.

Re:This is nice, but...

[billcopc]

Indeed, which explains why Intel cpus are 6 times more costly than the equivalent AMD chip. Still it would be nice to have some AMD-borne expertise working on GCC's code generator.

Re:This is nice, but...

[Anonymous Coward]

I agree with this post.
I also have seen about 35% improvement over g77
running a radiative transfer code. ifc also is
faster then portland, has the posix interface, and
has much, much better doc.s. With the non-com
license there's no reason to buy portrland.
Looking very bad for the g77 project, maybe they
can move on to something more relevant.

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...

Re:Pretty lame overall.

[Anonymous Coward]

GCC is a quite crappy compiler and this Intel compiler is quite good. A suggestion is to check out the evaluation version. We did and now I can't understand how we could put up with the bugs and crappy optimizations in GCC.

Re:Pretty lame overall.

[Hal-9001]

Actually, CPU houses have, AFAIK, always written compilers optimized for their chips, because a) they have a vested interest in the performance of their chips compared to competitors chips, b) a lot of CPU performance depends on the compiler and optimizing it for the chip, and c) if you're not the industry standard (like Intel currently is), then if you don't write a compiler for your chip, no one will, and then no one will use your chip. It's much more difficult to optimize a chip for a compiler, and the performance gains are less, than doing it the other way around.

Also, chip vendor compilers aren't necessarily for people to use, but also to show Microsoft or Watcom or Metrowerks or the GCC team how they can write compilers to take advantage of the chip's architecture.

You're missing the point

[Anonymous Coward]

The GCC people will not add many of the optimizations the Intel compiler does. Is a gcc fork going to make people happier than a separate compiler? And why stop using AMD if they do? The Intel compiler makes binaries that run faster than gcc on AMD processors as well.

> Do they quite realize the market advantage of having the Open Source community on their side?

Yeah, I think they realize exactly how much value that has...

Consider how slow GCC is on other platforms

[qurob]

GCC is a bit slower than the vendors compiler on most other platforms...any benchmarks for us to see?

I'm sure its optimised decently well for x86 however...

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.

what happened to pgcc?

[spectatorion]

i remember the pgcc project aimed to distribute a pentium optimized version of gcc. i believe that the stampede linux project (defunct, resurrected and defunct again) used pgcc to deliver an optimized complete linux distribution. looking at what appears to be pgcc's website, it appears that pgcc is inactive as well ("last change: 2000-12-27"). Does anyone know the actual status of this project or have any information? It's last release is gcc 2.95.2.1 so direct comparison is not quite possible, but how does pgcc compare against intel's cc performance-wise? the only value i can see in an intel cc is performance improvements. because intel obviously has all the specs on their processors, they can heavily optimize the compiler output. since they are not opening their source or specs completely, some people who are willing to pay can at least get the performance gains, but if something like pgcc can offer similar performance, there seems to be no point. any comments...

Check it out!

[Anonymous Coward]

We evaluated the intel-compiler and bought it. It's fantastic and gives huge performance improvments in some circumstances. Worth the money!

GCC doesn't generate good code and it's quite buggy. I'm glad to see intel releasing something as good as this.

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.

How can i compile gcc with this?

[Anonymous Coward]

I have been told that a quick way to speed up everything is to compile gcc 3.1 with the intel compiler and it will produce an instant 25% less of compilation time in any project. And gcc 3,1 itself can produce between 15% and 35% of overall code speed , so i want to know how to compile gcc with this thing. I tried but so far i need a flex license, i dont have a pentium so i dont have the serial, etc...

*BSD ?

[RinkSpringer]

Has Intel forgotten about the *BSD family, or do they just force us to use Linux 'emulation' ?

Re:*BSD ?

[Anonymous Coward]

Well, my understanding from cornering an Intel guy last week over beer was that FreeBSD was coming "at some point" in the next six months, largely due to internal pressure. The linux port happened in large part because of the enthusiasm of the linux folks internally over the last few years. The BSD folks, perhaps short on Geritol, did not make the same noise. OK, I added the Geritol part, but basically that was the deal. Now that the BSD-ers are getting crabby about it and doing the work you should be able to do a make World with the compiler by the end of the year. In all honesty, I think that the BSD market is far, far, far more likely to pay for the compiler and that this could be a real source of revenue for Intel, and that they are unlikely to ever see a dime out of the folks in my camp, so it will probably be well supported after the initial release. The people internally are testing on FreeBSD and some on OpenBSD and NetBSD, and no one is testing on BSDi, although that is planned.

Actually

[Anonymous Coward]

Intel is about 10 times the size of AMD, though AMD does have some odd off-balance sheet stuff (i.e. that Fujitsu thing?) and has been seen to speculate on economic indicies of which they are a part.

Intel is similarly far from squeaky clean, but their management has done a pretty outstanding job...

Whatever. Do your own due diligence :-).