Intel C/C++ Compiler 8.0 Released

Peorth writes "Intel has released version 8.0 of their Intel C/C++ compiler for both Windows and Linux. This release has been rumored for a long time to contain 100% GCC source and binary compatibility. It seems great strides have been made in advancement of that goal, as well as of its performance, but it may have a long way to go yet. Has anyone had experiences with it yet, either good or bad?"

Comments

so, any source distributions able to use this?

[gl4ss]

yes this is for you gentoo folk, does it work as just drop in replaced? benefits?

-

Re:so, any source distributions able to use this?

[ispeters]

I've not tried it, but there is a USE flag to use icc instead of gcc if you have it, so it's supposed to be drop-in-and-tweak-a-flag. As for benefits, who knows? I know my gentoo box feels snappier than the same box running Mandrake or RedHat, but I have a sneaking suspicion that it's only snappier 'cause it's running fewer deamons--I doubt that source-based distros really get you much more performance, but I have no numbers to back up either side of the argument--so if compiling from source with gcc doesn't give you any benefits, I doubt using icc would be any better.

Re:so, any source distributions able to use this?

[cakoose]

so if compiling from source with gcc doesn't give you any benefits, I doubt using icc would be any better

That's a strange conclusion. The Gentoo comparision is a comparison of two -march settings on GCC. ICC is a whole different compiler.

Because...

[DAldredge]

Because in some/most cases it makes faster code and saving 10% execution time is worth the sub 900 USD price of the Intel C compiler.

Re:Because...

[ciaran_o_riordan]

And as an added bonus, if you give a copy to a friend, you are a criminal! cool. or something.

Re:Linux is their benchmark then

[njchick]

The Linux kernel specifically requires gcc because it uses gcc extensions. But it should be possible to recompile the usermode code with the Intel's compiler. Even glibc may be worth trying (if you bought the compiler).

The really interesting part is that the Intel's compiler supports Itanium. It's very hard to optimize for Itanium because of its very long instruction codes. Those who run CPU-intensive tasks on Itanium may be interested in the Intel's compiler.

kernel

[portscan]

My first thought was, "does this mean it can finally compile the Linux kernel?" But the website says "with a few kernel modifications, [icc] can build the kernel." Since gcc can compile it without modifications, doesn't this mean they are not 100% compatible? Also, there is no link to these patches anywhere, just this article on icc 7. Do you have to figure out the problems and fix them yourself?

Obviously there is other software to compile besides the Linux kernel, but since the icc is so tuned to the Intel hardware, and Linux interacts so directly with the hardware, people believe that icc would give great benefits to the kernel. At the very least, nothing can claim 100% gcc compatibility unless it can compile Linux unmodified.

Re:kernel

[jarek]

To tell the truth, not even all gcc versions are compatible with the specific version of gcc that is currently supposed to compile the kernel. Gcc compatibility is a moving target and kernel developers do not switch to the latest gcc version as soon as it appears. Examples of this are kgcc vs gcc in some distributions. Unless icc becomes the official compiler for the linux kernel, I doubt it will ever compile the kernel in a predictable way (what ever predictable means in this case). /jarek

Here's my experience:

[ciaran_o_riordan]

> Has anyone had experiences with it yet, either good or bad?

I went to the website and was told that I wasn't allowed to have a copy unless I paid them money and promised to prevent others from copying my copy.

They've also denied my request for a copy of the source code. Appearently, I'm not allowed to know what my copy is doing when it's compiling my code.

There were many other restrictions. Overall, a pretty bad experience :-(

Re:Here's my experience:

[ciaran_o_riordan]

I'm not allowed to know what my copy is doing

An AC above pointed out that Intel are part of the Trusted Computing group. This all reminds me of Ken Thompsons compiler trojan. (where he hacked a c compiler to add a backdoor whenever it is compiling "login".)

So, what might icc add to the security functions of glibc? to gnupg, sshd, lsh?

In a way, the idea of using a proprietary compiler is very similar to that of proprietary voting software.

Re:Here's my experience:

[RML]

i seem to remember that even non-open-source programs can still be run through a decompiler (albeit not necessarily legally, thanks to the shrink-wrap license.)

Sadly, there don't seem to be any good free (either speech or beer) general-purpose decompilers. There are several for Java, but Java is easier to decompile because programs carry extra information for verification purposes.

and sheesh, some C people can read assembly code just as easily as if it -were- C. it's practically the same thing.

Depends. C may be messed up but it's not nearly as messed up as, say, x86 assembly. And the compiler will reorder blocks, functions, and data, so things that were nearby in the source can be far away in the binary.

Re:Here's my experience:

[Peorth]

Actually, just to note, there is (as there has been since 7.0 or so) a non-commercial version of the Linux compiler. You're not "allowed" to compile commercial stuff with it, but $0 is still cheaper than paying for 8.0 if you don't go for that sort of thing or just want to see how well it'll work with your libraries. (not to sound like an Intel saleswoman, gah)

Re:Linux is their benchmark then

[RML]

The Linux kernel specifically requires gcc because it uses gcc extensions. But it should be possible to recompile the usermode code with the Intel's compiler. Even glibc may be worth trying (if you bought the compiler).

The Intel compiler has supported compiling the kernel with it for a few versions now, I believe. It may require a few kernel patches, but I think some of them have been accepted into the kernel tree. Intel has a web page about it.

What's the big deal?

[RML]

I'm looking at the feature summary and I don't understand the big deal.

• ICC supports two-pass compilation. So does GCC.
  
• ICC supports data prefetching. So does GCC.
  
• ICC can do code coverage testing. So can GCC.
  
• ICC can do interprocedural optimizations. Released GCC versions can't, but work is in progress.
  
• ICC can do automatic vectorization, GCC can't. Advantage ICC.
  
• ICC supports something called "processor dispatch". I'm not even sure what that is.
  
• ICC supports a number of optimizations that might be interesting if you happen to have an Itanium 2 sitting around.
  
• ICC supports parallel programming, GCC doesn't (not very well anyways). Advantage ICC.
  
• ICC's debugger supports "GDB syntax and a subset of GDB commands". Why not just use GDB?

Overall, it's probably not worth using unless you really need a compiler that generates fast code.

Re:What's the big deal?

[stevesliva]

Overall, it's probably not worth using unless you really need a compiler that generates fast code.

Yeah! Who needs fast code anyways?? Real C coders use only "#pragma I'll do it my goddamn self!" statements and asm{} blocks! Real men don't need any stinkin' optimizing compilers other than their own beautiful minds.

Re:What's the big deal?

[Screaming Lunatic]

Others have mentioned performance. But the more compilers that you put your source through, the more robust your code will become. Different compilers emit different warnings. Different compilers adhere to different parts of the standard. Putting your code through different compilers makes your code easier to port to other platforms.

At work we use both MSVC 7.0 and ICC 7.0. We'll probably also use MSVC 7.1 for our next product cycle. And maybe Comeau or GCC in the future. At home I use GCC and ICC.

Re:What's the big deal?

[Anonymous Coward]

Overall, it's probably not worth using unless you really need a compiler that generates fast code.

Yeah, totally. I mean ... the whole idea of compilers generating fast code is over-hyped anyway. :)

$900?

[rudy_wayne]

According to the website the compiler for Windows is $399

Re:Linux is their benchmark then

[larry bagina]

I see no other reason to make the compiler binary-compatible with GCC.

Actually, the gcc 3.0 series was changed to use Intel's C++ ABI, so gcc did the changing, not icc. Of course, icc did add support for some of gcc's extensions.

Non commercial license is free

[Anonymous Coward]

I don't know if this applies to the newest version, but info about a non-commercial license is at:
http://www.intel.com/software/products/compil ers/c lin/noncom.htm

I compile using both gcc 3.2 and icc 7.0. I do this because different compilers emit different warnings and this has helped me to improve my software's quality.

The fortran and c/c++ are both available, as long as you don't try to create a commercial product with it.

Re:Non commercial license is free

[ufnoise]

Corrected link here

Real Timings

[menscher]

Since this is Slashdot, this will quickly turn into a stupid bashing of Intel in favor of gcc, since everyone likes Free stuff and hates corporations. And everyone will talk out of their asses about how the Intel compilers couldn't possibly be faster than gcc. So, I figured I'd throw out some real numbers:

icc -static (Intel 5.2 compiler on RH7.2 box)
199.490u 0.000s 3:19.87 99.8% 0+0k 0+0io 48pf+0w

icc -static RH8.0-2.2.93 (Intel 7.0 compiler)
236.860u 0.010s 3:56.96 99.9% 0+0k 0+0io 53pf+0w

icc -static RH8.0-2.3.2 (Intel 7.0 compiler)
253.980u 0.050s 4:15.03 99.6% 0+0k 0+0io 53pf+0w
245.030u 0.020s 4:05.26 99.9% 0+0k 0+0io 53pf+0w

icc -static RH8.0-2.2.93 (Intel 7.0 compiler)
503.060u 0.770s 8:23.99 99.9% 0+0k 0+0io 58pf+0w

icc -static RH8.0-2.3.2 (Intel 7.0 compiler)
521.420u 0.020s 8:41.83 99.9% 0+0k 0+0io 58pf+0w

icc -static -O0 (Intel 5.2 compiler on RH7.2 box)
521.670u 0.000s 8:42.19 99.9% 0+0k 0+0io 53pf+0w

gcc -O3 -static (on RH9 box)
693.380u 0.010s 11:33.48 99.9% 0+0k 0+0io 46pf+0w

gcc -O3 -static RH8.0-2.3.2
728.680u 0.020s 12:09.57 99.8% 0+0k 0+0io 46pf+0w

gcc -O3 -static (RH 7.2 box)
731.560u 0.070s 12:12.17 99.9% 0+0k 0+0io 41pf+0w

superior gcc -static (RH 9 box)
856.170u 0.710s 14:18.18 99.8% 0+0k 0+0io 52pf+0w

The notations indicate the compile options. All binaries were then run on the same machine (dual Xeon running RH9) to gather timing information.

Now, you can take whatever you want outta that, but my view is that having your programs run three times faster just might be useful.

Disclaimer: these results are for a specific program (dealing with computational astrophysics). Obviously your application may see other speedups.

Re:Real Timings

[menscher]

I should have mentioned: the slow timings with icc (entries 4,5,6 in the table above) were done with -O0 (optimization turned off).

And ignore the word "superior" in the last entry. That's just an internal note that I forgot to remove... has nothing to do with the timing test.

And for those who were wondering... the various tests comparing RH8 libraries (2.2.93 vs 2.3.2) were done because the 7.0 version of the Intel compiler did not support RedHat 9 (so we were forced to copy libraries over from a RedHat 8.0 box). I'm really looking forward to getting Intel's 8.0 compilers so we can stop doing that ugly hack!

Ok, I think that covers just about everything I left out. Now back to your regularly-scheduled programming....

Re:Real Timings

[RML]

Since this is Slashdot, this will quickly turn into a stupid bashing of Intel in favor of gcc, since everyone likes Free stuff and hates corporations.

"Free stuff" and "corporations" are not mutually exclusive. Most of the work done on gcc is by people who are paid to work on it.

And everyone will talk out of their asses about how the Intel compilers couldn't possibly be faster than gcc.

There are still many interesting optimizations that gcc doesn't implement. A lot of work is being done on adding them to the tree-ssa branch, which hopefully will be merged into mainline gcc for 3.5.

So, I figured I'd throw out some real numbers:

It sounds like you're doing floating-point intensive number crunching code, which quite honestly is where icc should give the greatest benefit over gcc. On integer workloads they should be much closer. Number crunching gets a big boost from vectorization, and icc does automatic vectorization. GCC doesn't (though work is underway), and it won't use vector instructions at all unless you supply -mmmx, -msse, -msse2, and/or an -march option that specifies an appropriate CPU type. You can still get the advantage of vectorization if you're willing to code it explicitly.

Re:Real Timings

[Elwood P Dowd]

This might sound like a stupid question, but are you showing us executable running times or compilation times?

Re:Real Timings

[menscher]

This might sound like a stupid question, but are you showing us executable running times or compilation times?

Execute times. Sorry if that wasn't clear. The program was fairly small, so compile times were considered insignificant.

processor dispatch

[DAldredge]

Processor dispatch allows the compiler to generate multiple optimized code paths and dynamicaly select which optimized version of the routine to use based on the processor that the program is running on. This allows a single executiple to run with SSE/SSE2 support on the P4 and still run on processors that do not support SSE/SS2.

I do not know what happens when the app is ran on AMD processors that support SSE/SSE2.

Re:Question

[AtrN]

Actually, yes I do. A little while ago I was doing some micro-optimizations (i.e. not algorithmic), using gcc 3.3 and icc v7 on FreeBSD and testing the results on a number of processors available to me: Athlon XP, PIII and PIV Xeons.

With my problem/code the Intel compiler generated code ran faster on the Athlon XP than gcc 3.3's code using its XP switches and other "go fast" options. Using whole program optimization resulted in a program running considerably faster than the gcc 3.3 generated binary. icc is also stricter in some ways regarding syntax and C++ gets to use the EDG parser (if its still using it, can't see why not).

The various posts here from people going "why bother" show a great deal of naivety. There are good reasons you want to use multiple compilers other than just the fact that icc can generate better code than gcc (in many circumstances, other tests may show the opposite result, YMMV). For starters its going to pick up a different set of errors. Now gcc is pretty good at producing useful warnings, a whole bunch better than Visual C++ for instance, but it isn't perfect, adding icc into your toolkit helps you find problems in your code. A more important reason however is to avoid the mono-culture introduced with everyone using gcc. Years ago we called it "all the worlds a VAX", then it became "all the worlds a Sun", now its "all the world's Linux (with gcc)". A bit of variation (in implementation, not interface) is a good thing.

Awfully tenuous argument

[0x0d0a]

An AC above pointed out that Intel are part of the Trusted Computing group. This all reminds me of Ken Thompsons compiler trojan. (where he hacked a c compiler to add a backdoor whenever it is compiling "login".)

So, what might icc add to the security functions of glibc? to gnupg, sshd, lsh?

You're reaching pretty far with this argument. Intel is a damned large company with a lot of groups working on things and a lot of different opinions and people. They don't have to have a secret, nasty, ulterior motive, even if one group is working on something you don't like.

You want to be paranoid about Intel? Give up -- they control the CPU. They could trojan you much more easily via the proecessor -- no reason to dick around with the compiler.

Plus, look at the Trusted Computing Group membership list. Do you distrust all products from all of these companies?

Let's see:

* ARM is on there. You better avoid any embedded devices. They might be trojaned. Or using any devices in your system (drives, add-in cards) that have ARMs onboard.

* ATI and NVidia are on there. Video cards are clearly out -- there are numerous standards that will let video cards push code to the processor, plus cards tend to have pretty much unstopped access to memory.

* Fujitsu is on there. You want a trojan, a hard disk controller is a damned sweet place to put it.

* Philips is on there. I hope you don't rely on CDs for anything. Who knows what they put in their reference CD drive controller code?

* RSA is in there. A damned large number of companies license their prewritten libraries (and binary copies of the thing, as well). I hope you've never run Netscape Navigator 4.x, because if you did, RSA could be controlling your system, modifying binaries, etc.

* Phoenix is on there. Boy, I hope you don't trust your BIOS for anything. You *are* using LinuxBIOS on a *completely* open-spec'd motherboard, right?

Point is, trying to distrust huge companies because one small component of the company does something you dislike is simply a futile task. Maybe one day you can use all open-source and viewable software, but it isn't going to be in the next decade -- keep in mind all that controller hardware with unbounded privileges to all the goodies on your computer.

Don't get me wrong. I like open source. I write open source. However, being irrationally fanatical about it is both stupid and counterproductive, and doesn't do diddly for the open source movement.

Re:Why is this not modded up FUNNY?

[irc.goatse.cx troll]

Do you like paying $400 for a couple msecs? Hell, add it up over your programs lifespan and you might get a week or two if you're lucky.

Definitely going to try out this one

[sperling]

We've tested Intel's c++ compiler for linux at work, and it's cut the full distributed rebuild time of our gameserver software from about 9 mins to 3 mins. That alone is more than enough reason to switch IMO.
Performance-wise, it seems to have a slight edge over gcc, but this is subjective as I haven't really measured anything yet. Apart from the performance issues, I've found icc to be way more informative in its warnings and remarks than gcc. Unless you strictly believe in the GPL or are open-source only, I see no reason not to at least give it a try, it's a damned good piece of software.

Re: Supporting various hardware

[some guy I know]

The really interesting part is that the Intel's compiler supports Itanium.

Yes, but does it support the Opteron?

Re:lol

[makapuf]

It's ... a duck !

But Have They Fixed The Bugs?!

[Steve Cox]

I used the Windows version of the Intel compiler at work for quite a while, and it does produce some exceptionally fast code (and sometimes takes an exceptionally long time doing it).

The problem? Since version 6 came out any software we compiled with it exhibited crashes that did not occur when we used another compiler on the same code.

In the end we had to stop using it. Its a shame really because it was an excellent product (the only gripe being their Premier/Quad support website which was crap).

Steve.

Re:But Have They Fixed The Bugs?!

[p3d0]

You probably know this already, but the problem you describe could be because your code is not strictly ANSI-compliant (ie. it makes use of undefined behaviour). So it may not necessarily be the compiler's fault.

Re:But Have They Fixed The Bugs?!

[jjc2222]

Have you verified that you're actually seeing compiler bugs? It's quite possible that using a different compiler exposes bugs in the code itself - bugs that just happened to be treated differently with your original compiler. It may also be an issue of standards compliance. Either way, it seems that it would be worthwhile for you to explore _why_ you get the crashes you do. It may be enlightening.

Patches for compiling linux kernel

[rleeuk]

See http://www.suri.co.jp/~ohkubo-k/linux/.

Re:Linux is their benchmark then

[njchick]

Because the extensions are good not just for speed. They improve code readability and make it easier to spot programming errors early. Also, they provide required functionality that is not standardized. Avoiding gcc extensions would mean rewriting some code in assembler for all architectures.

10-20% increases using 7.1

[blackcoot]

i haven't played with 8.0 yet, but using 7.1 i managed to get substantial (>20% overall) speedups. of course, this was with ipo turned on for almost everything which generated several megabytes worth of files per source file. i'm looking at playing with their fortran compiler, partially because it's a good excuse for me to play with fortran and partly because i'm fairly certain that it will be able squeeze some extra speed out of key algorithms. that said, even if the executables' speeds weren't substantially different, icc has some other nice features, built in openmp stuff, etc. and, of course, it's always good to have a second compiler's opinions on things.

Re:Intel, great.. what about AMD ?

[kermit6306]

They won't since there's no compiler team at AMD. There are AMD engineers that work on the GCC project. That's as close as you're going to get.
I think ICC yields slightly better performance on AMD anyway.

AMD picked it as the best

[morcheeba]

AMD used version 7.0 to compile it's entries for SpecInt performance, and I'm guessing that they didn't just pick it because they thought it had a cute name.

Compiler:
Intel C++ 7.0 build 20021021Z
Microsoft Visual Studio .NET 7.0.9466 (libraries)
MicroQuill Smartheap Library 6.0

Re:Optimize or architect for performance?

[Haeleth]

The question I want to ask: why would you intentionally write source code whose object code can be significantly improved by optimizations?

Let's consider a very basic example:

{
int i, j[1000];
for (i = 0; i < 1000; i++)
j[i] = foo();
}

If you read old C textbooks, they'll actually tell you to write the above code as something like

/* Fill an array with the results of 1000 calls to foo() */
{
int *i, j[1000], *endptr;
i = &j;
endptr = i + 1000;
while (i < endptr)
*i++ = foo();
}

Why? Because this saves the program from having to calculate &j + i * sizeof(int) every iteration of the loop.

Now, a modern optimising compiler is probably going to automatically detect that i is only used to index j, and will therefore automatically generate code equivalent to the second example from the first example.

Do you see what I mean? Comments are no substitute for readable code. If an optimising compiler can make readable code run as fast as unreadable "optimised" code, then that is a thing worth having.

Vectorization is probably the key

[r6144]

For numeric C code, automatic vectorization will often double or quadruple (if you use SSE) performance with automatic (or manual) vectorization, as some other post has said. Other factors, such as inter-procedural optimization, gcc's lavish use of stacks and imperfect SSE register allocation, helps very little.

In one of my programs, icc7 actually produced slower code than gcc (at -march=pentium4, maximum optimization) because the most time-consuming loop was not automatically vectorized for some reason. The generated code for this loop (by both gcc and icc) are actually using x87 floating-point instructions (sse instructions are used in most other parts). gcc with -ffast-math generates reasonable code, while the icc-generated code have very long dependency chains, and is thus slower. The code in question is the sum of 9 products, so I think icc should be allowed to change the order of summation (anyway it defaults to non-strict floating-point), but it didn't do so automaticaly. Then I removed the dependency chain by hand by adding up partial results, and speed instantly doubled with icc (I didn't try gcc). Then I vectorized the code manually by using SSE intrinsics --- another 4x speedup (of course this would help gcc too, but I didn't try, either).

The moral of the story is that it is still unwise to trust the compiler too much to optimize your code. If most of the time is spent on very little code, some manual vectorization and formula rearrangement really pays off, whatever compiler is used.