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

Experiences?

[Anonymous Coward]

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

No, but I heard about it on this "nerd news" website that I frequent.

Re:Experiences?

[Anonymous Coward]

Can you post a link, because slashdot is getting boring.

Re:what about

[Anonymous Coward]

NO! IBM have a compiler for PPC, icc is for x86.

Linux is their benchmark then

[Nicolay77]

If that's true then for Intel is very important to have the compiler that can compile the fastest linux kernel, and to be able to link other software that runs on linux.

Very good way to show the world that linux is more mainstream every day.

I see no other reason to make the compiler binary-compatible with GCC. (Yes, BSD benefits too.)

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.

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.

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.

Re:Linux is their benchmark then

[ChocolateCheeseCake]

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

Not to sound negative about Linux and the developers who spend a good amount of time working on perfecting it, however, why isn't there a move by the coders to move away from using those extensions? I can understand the rational behind the whole use of it, however, I am sure that the speed penalty could be worked around eventually.

Is there someone here who can lay out what extensions are actually used and what those extensions do.

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.

Re:Linux is their benchmark then

[LoztInSpace]

Very good way to show the world that linux is more mainstream every day.

Sorry to rain on your parade, but not much of the world would consider a C++ compiler mainstream. (In fact I doubt most of the world know or care what it is).

Re:Linux is their benchmark then

[Old Wolf]

Examples?

Re:Linux is their benchmark then

[njchick]

Inline assembly with arguments. "printf" attribute.

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?

[Safrax]

Using the ebuilds posted on gentoo's bugzilla, I can NOT use icc 8 as a drop in replacement. Attempting to compile 2.6.0-test11 results in screens of errors after executing 'make bzImage'. If this was supposed to be able to compile the linux kernel or be a drop in replacement, it fails. Horribly.

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.

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

[ispeters]

I don't understand your post.

My point was that I attribute the snappiness of my Gentoo box to the lack of extra services that I have running, rather than the fact it's all been compiled from source. Since I don't think compiling from source (with gcc) has much to do with improved performance, I concluded that substituting another, possibly better compiler wouldn't make much of a difference, either.

Admittedly, my "conclusions" are not based on any real facts, so there's a pretty good chance I'm wrong, but even if I am, what does -march have to do with that?

Ian

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

[Anonymous Coward]

That's because you are, as they say, 'thick as a brick'

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

[cakoose]

what does -march have to do with that?

Stock binaries are usually compiled for i386. When you compile your own, they will be optimized for whatever processor you have. I assumed that your first conclusion was that there was no significant difference in speed between these settings.

Whether or not this is true, I thought you were only ruling out the impact of different -march settings on GCC. I didn't realize that you ruled out the possibility that a totally different compiler might improve performance.

As a side note, was your subjective judgement made on machines running the same version of the kernel? I'm not a kernel person, but I've read that the "snappiness" (i.e. response latency) varies a lot between kernel versions.

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

[AndrewRUK]

Most benchmark tests I've seen show icc producing faster code than gcc, which isn't surprising given that Intel's people presumably know preciesly what optimisations work best on their chips. Since icc produces faster code than gcc, compiling from course with icc will produce a faster system than compiling from source with gcc. Of course, there are fairly obvious downsides, too - using icc limits you in what platforms you can use, and (for those who care about such things) it's most definitely non-Free.

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

[ispeters]

In response to your side note: probably not. I was using Mandrake circa summer of 2002, and whatever kernel was shipping at the time. Gentoo's whole philosophy is 'the sooner the better', so once I put Gentoo on the machine, I was using the latest version of 2.4 that was available (2.4.18, or 2.4.19, I think).

You know, I'm beginning to regret opening my fat mouth in the first place. I've seen quite a few flame wars back and forth between Gentoo users and Gentoo detractors about the usefulness of from-source distros, and the benefits (or lack thereof) of machine-specific optimizations. I just wanted to put my two cents in and say that I'm a Gentoo user, but my reasons have nothing to do with any belief that my system is running millions of times faster than your average RH or Mandrake install--I just like the environment that Gentoo provides, and they have the best damn forum I've ever used. I think there's a possibility that compiling everything with -march=pentium3 -mmmx -Os -etc makes a small difference, but if you go get Mandrakes i686 binaries, are the differences measureable? When you're using bash, and it spends 99% of its time blocked on I/O, do you care that it's blocking as fast as possible? For your average home user, hard drive and memory latencies probably have more impact on the performance of your system than the optimization settings with which you compiled your kernel/shell/window manager/mp3 player, so whether you optimized pretty well with gcc, or as well as humanly possible with icc, what's the difference?

Then there's the whole debate of whether it's worth your time compiling everything in the first place. I recently bought a new machine, so I'm not feeling the pain as much as I used to, but installing a binary is a hell of a lot faster than compiling a tarball. Given my doubts about speed improvements, I have to wonder if I'm just making the compile time back, amortized over the time that I use the software. On my PII 266MHz with 350 meg of RAM, it took over 20 hours to compile OpenOffice! Even if I use OpenOffice everyday for the rest of my life, and my magic compiler has squeezed every last ounce of performance out of OpenOffice, I doubt I'll ever make those 20 hours back. And you can forget about upgrading to version 1.1.

Ian, a happy, only slightly optimized, Gentoo user

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

[innosent]

That's why, unless you use a compiler farm with 4+ machines, "emerge openoffice-bin" is probably a better idea. You can change this with "emerge unmerge openoffice", then emerge the openoffice-bin package.

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

[ispeters]

Well, I have a 1.3 GHz Pentium-M laptop now, and OpenOffice only takes a couple of hours (2-3), so I don't mind waiting.

Actually, I might be using a compiler farm with 4+ machines--all the computers in the house are running Gentoo, distcc, and ccache! I forgot about that....

Ian

okay.

[/dev/trash]

But it's not free. Why would I want a compiler that isn't free?

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

[Anonymous Coward]

Sub 900 USD? icc is free (as in drinking wine from a paper-bag on a park bench) for non-commercial use. But it's not free as in 'freedom', just remember that intel support TCPA before using it to compile your sshd :-o

#include "tinfoil_hat.h"

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

[Anonymous Coward]

There is a simple fix: don't give your friend a copy! Do you really think the sort of person who can afford a $900USD compiler really cares if they can give it to a friend or not? No, they work for a company who thinks the $900USD investment is a good one, so the programmer doesn't even own it to begin with.

Re:Because...

[Anonymous Coward]

SSD would be a great application for TCPA -- no worry about your private keys getting stolen.

Oh wait, you are an idiot and a troll who doesn't even know what TCPA is.

Re:Because...

[/dev/trash]

I guess. For the average programmer, it's not worth it.

lol

[Sparr0]

so, if its 100% compatible with GCC source, and produces 100% compatible binaries... doesnt that make it GCC?

Re:lol

[Nasarius]

With Intel processor optimizations...

Re:lol

[makapuf]

It's ... a duck !

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

[Anonymous Coward]

Read the article. Previous to this version there was speculation that 100% compatability would be achieved. Clearly that is not the case, though great strides had been made.

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

Re:kernel

[Anonymous Coward]

It can compile the kernel since icc 7.0, see www.suri.co.jp/~ohkubo-k/linux/icclinux.pdf (in Japanese, but there are a few performance comparison charts). There is only a modest amount of performance gain in most areas, the major performance boost comes in file system (specifically file creations, which is 50% faster).

Re:kernel

[portscan]

Yes, I am aware of that. However, the GNU project does not claim "100% compatibility" between releases. In fact, the differences between releases are widely documented and prominently noted. Don't believe them? Check the source.

All I was saying is that claiming "100% compatibility" is a pretty bold statement. It was clearly written by the marketing department, not the developers. Granted they admit elsewhere that it's not actually 100% compatible, but maybe after rounding and a couple floating point errors, they got 100... who knows.

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:

[Unordained]

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.) and sheesh, some C people can read assembly code just as easily as if it -were- C. it's practically the same thing.

sure, it's not as easy or convenient. and modifying it to do what you like may be an pain. but ... a program is a program (and never a true black box.) you can always find out what it's doing, eventually.

besides, have you never seen people obfuscate source code? they could make it -harder- for you to find a trojan in the source code than in the assembly.

the fact that you can get your hands on the binaries themselves is arguably a step above the voting software, in that it's much more obviously accessible. with voting software, you probably have to deal with the voting hardware, the government agency owning/renting it, etc.

(and yes, intel could have made their chips obfuscate the assembly. maybe. you've got ways around that. and yes, hardware is just software in another, less modifiable, state. and therefore hackable. therefore, given enough time, any voting machine can be examined thoroughly.)

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:Here's my experience:

[marcovje]

man objdump

Re:Here's my experience:

[Lars T.]

So you volunteer to check a decompiled ICC-compiled kernel for a trapdoor that Intel may have hidden? ;-)

Re:Here's my experience:

[Anonymous Coward]

100% of GCC users got a binary compiler from someone to start out, and that binary compiler could have been trojaned. Since GCC is a much bigger target than ICC, I'd start decompiling that first.

Most of you dorks miss Ken Thompson's point, which is that you can only "trust" software that you wrote 100% of. Meaning, not GCC.

Re:Here's my experience:

[Haeleth]

Wait, though - you need to be certain that the disassembler wasn't compiled with ICC, since the hypothetical trojan code might be smart enough to recognise that it was compiling a disassembler, and insert code into it to make it strip out the trojan code if it ever disassembled ICC. Indeed, you can't be sure that the utility is safe if ICC ever compiled any tool which was used to build it, or if an Intel employee ever had access to the source of any of those tools.

You might just about be safe examining the physical arrangement of bits on the hard disk, but you'd need to make certain first that your DNA wasn't compiled with ICC, otherwise they might have implanted a trojan in your brain that prevents you from recognising trojans in ICC binaries in any form.

And I sure hope you trust the guy who sold you the tinfoil for your hat... ;)

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

Re:What's the big deal?

[spitzak]

Where I work the SGI Irix C compiler has been real useful at detecting programming mistakes, it produces warnings that none of the others do.

We also use GCC on Linux, the Intel compiler (on Windows) and VC++ 6. I try to get all of them to produce no warnings, and this has detected a huge number of bugs that would not have been found if only one compiler had been used.

Re:What's the big deal?

[Peorth]

idb 'kinda works' if you don't use the debug flags, but the main difference between gcc and icc, and gdb and idb, is that idb generally doesn't pick anything up unless you compile with debug flags explicitly, while gdb can at least give you intelligible "debugging" even without explicitly using -g. Though using icc itself doesn't usually make debugging -impossible- either, using -fomit-frame-pointer with gcc will quite horribly ruin your day if you're trying to debug those cross icc/gcc glitches.

Re:What's the big deal?

[scrytch]

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

Actually, for a few projects I've done, I'd settle for a fast compiler, since the program is so I/O bound, I could have written it in perl if memory consumption wouldn't go through the roof if I did. Python+psyco looks intriguing, but I'd rather move to lisp ... assuming I could find a decent free CL compiler for windows (not clisp, that's cygwin, and it doesn't even handle proper tail recursion)

Re:What's the big deal?

[NateTech]

Oh someone just go benchmark the differences and then let people decide what they want to use. Sheesh.

Re:What's the big deal?

[LWATCDR]

For a lot of programs the extra speed really is not needed. How much faster to you need ls to list your files?
Of course faster is good but sometimes trading a little speed for smaller code is a valid trade off.
Speed is not everything sometime portability is of high value.
The best if of course small, fast, and portable.

I look forward to playing with icc. I really want to see if it can boost KDE and or the kernel. Okay gcc time to step up to the plate :)

$900?

[rudy_wayne]

According to the website the compiler for Windows is $399

Re:$900?

[DAldredge]

That would be sub 900, would it not? For some reason I was unable to pull up intels site at the time so I guessed high.

It is $378.99 at the following URL
http://www.programmersparadise.com/Product.pa sp?tx tCatalog=Paradise&txtCategory=&txtProductID=I23+0B 41

Oh, please, Mr. GNU/Troll

[jensend]

coriordan, please stop trying to convert the unwashed masses here at slashdot and lwn. Anybody who is at either site is well aware of GNU and their "philosophical" positions and has heard these regurgitated arguments before, and if we aren't members of the GNU/Cult it's because we've examined their positions and found Stallman and Co. to be frothing-at-the-mouth crazy. Your naive, ignorant, and overconfident opinions aren't the gospel you take them to be. Your sermons at LWN expounding the GPL and the GFDL to the non-believers are downright ludicrous (especially since you don't understand the actual natures of the licenses and software development models you discuss).

So intel releases a compiler. So you don't approve of its being protected by regular copyright law. Then a) refrain from buying it and b) sit down and shut up.

For those who have real interest in the compiler instead of fantasized complaints, Intel offers zero-cost downloads of both the c/c++ and fortran compilers for noncommercial use.

Why is this not modded up FUNNY?

[Inoshiro]

"What's the big deal? ...not worth using unless you really need a compiler that generates fast code."

Is this some sort of cruel joke? Do you like running slow code?

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.

Re:Why is this not modded up FUNNY?

[RML]

Is this some sort of cruel joke? Do you like running slow code?

The number of programs where a speedup of 5% or 10% makes a big difference is very small. Most programs are IO-bound or memory-bound anyways. For a huge number-crunching application that is going to be running for a week or two, though, a 10% speedup makes a big difference.

Re:Why is this not modded up FUNNY?

[sir_cello]

Garbage, you've never worked on a commercial enterprise scale product. 10% improvement in performance can make a significant difference to performance targets for an average software product, saving reasonable amount of development time, effort and cost.

Re:Why is this not modded up FUNNY?

[RML]

Garbage, you've never worked on a commercial enterprise scale product.

True enough, I've mainly done scientific programming. The project I work on is not performance-intensive, while the guy across the hall does heavy number crunching (and still uses gcc).

10% improvement in performance can make a significant difference to performance targets for an average software product, saving reasonable amount of development time, effort and cost.

Sorry, I've been thinking of compiling open-source and in-house software. I assume without saying that software developed for sale will use the compiler that makes the most economic sense.

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

[Anonymous Coward]

My apologies the link didn't post correctly. There should be no spaces in the url.

I think there may be a non-commercial version for windows, but it was difficult enough to search for the link on the intel website.

Re:Non commercial license is free

[ufnoise]

Corrected link here

Re:Non commercial license is free

[Anonymous Coward]

There is no non-commercial Windows version; the closest you can get is the 30-day evaluation license, after which you have to pay full whack.

Question

[JDWTopGuy]

#include

Hey, does anybody know how well it optimizes for the Athlon XP?

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.

Re:Question

[Haeleth]

$ gcc -c question.c
question.c:1:19: humor.h: No such file or directory

Damn, looks like I'll need to get a copy before I can find out.

Re:Question

[Anonymous Coward]

word, man. the java analog is the ubiquitous usage of javac over jikes. jikes is stricter about sticking to the JLS in many cases, and i have found several problems using it that would otherwise go undetected. the sad thing is that, at least here, no one cares: if it compiles with javac, it must be good. jikes is not perfect either, of course, and the reverse is true in some circumstances. just like with carbon-based life, a more varied environment typically produces hardier organisms; or, what doesn't kill you will make you stronger.

Re:Question

[JDWTopGuy]

So icc runs on Athlon XP? Sweet.

do try to keep up

[ciaran_o_riordan]

well aware of GNU and their "philosophical" positions
I mentioned neither "GNU" or any "philosophical positions".
Staying out of jail, and knowing what a compiler is doing, are *practical* arguments against using Intels compiler.

expounding the GPL and the GFDL
I denounce the GFDL.

So you don't approve of its being protected by regular copyright law
GPL uses regular copyright law.

sit down and shut up
Challenge, rebut, argue, but don't tell a person not to speak. (and I *am* sitting down.)

Re:do try to keep up

[jensend]

If someone has absolutely nothing worthwhile to say, it's worth telling him not to speak, at the very least as a service to him- helping get him to do better things with his time. The GFDL comment was just because I happened to see you defending Stallman and co regarding it on lwn once; I didn't read through everything you said in that discussion because I didn't have an vomit bag handy, and thus did not notice you denouncing the GFDL. I have no argument with the GPL and the way it utilizes copyright law (though I would maintain such usage doesn't qualify as regular but rather as exemption from regular restrictions by systematic copyright licensing)- though I would say the LGPL is generally better- but rather with inconsiderate, self-righteous, dictatorial, and uninformed GNU zealotry. As to your "practical" arguments, if you break the law every time you're given a chance to do so, you deserve to be in prison; and while some tasks would benefit from the transparency of GCC, for a very large number- probably the majority- of cases when people are compiling for Intel processors the Intel compiler's benefits would vastly outweigh any such considerations. In other words, "best tool for the job" rather than "whatever is preached from the GNU/Pulpit this week".

Re:do try to keep up

[cakoose]

Staying out of jail, and knowing what a compiler is doing, are *practical* arguments against using Intels compiler.

How is staying out of jail an argument against using Intel's compiler? It's only an argument against using ICC illegally. Same thing goes for distributing GCC under an incompatible license.

As for "knowing what your compiler is doing", you never made this argument in your original post. Even so, I assume you're getting at one of three things:

• You don't trust Intel enough to run their binaries on your machine
• You would like to know how the compiler works
• You don't trust that the compiler is even working if you can't examine the source code

The first point is the only remotely valid argument, but I'm sure most people trust Intel enough to use their compiler, so they really don't care.

If you want to learn how a compiler works, that's great. No, you can't learn from ICC. However, this isn't an argument against using it.

As for the third interpretation, I'm sure ICC works just fine. For compilers, it's probably more feasible to validate functionality through test suites (as opposed to a code audit).

Re:do try to keep up

[ciaran_o_riordan]

> How is staying out of jail an argument against using Intel's compiler?

If you have a copy of icc, and a friend or family member asks for a copy, what do you do?
You could say "No, I promised Intel that I wouldn't give a copy to you or anyone else". Or you could break the promise to Intel and help your friend. I think the latter is the lesser of two evils, but it's easier to simply avoid this dilema by not making that promise to Intel in the first place.

> As for "knowing what your compiler is doing"

This is a point I made in a post a little further down the page. My reason isn't really covered by your three options. I trust Intel to make a compiler, running the binary is probably not harmful on it's own, and I'm not really interested in reading the code. BUT:

My concern is over what the compiler might do to my code during compilation. Intel is part of the Trusted Computing Group. Will the compiler silently add a DRM signature? will a later version do so?

I'm not suggesting a tinfoil hat conspiracy, but if Trusted Computing became company policy, it could be added to the compiler as a mandatory feature. Maybe it's already in there. I don't like the idea of kernels, libc, gnupg, ssh, lsh, etc. being compiled by a black box.

Re:do try to keep up

[Anonymous Coward]

You are worried that intel is going to trojan your code with their compiler? If you are using one of their processors, what is to stop them from putting in the special "ciaran o riordan detector" and have the hardware do it for them? In other words, you are paranoid. And for the record, how do you know someone hasn't written a compiler that will infect all binaries, then compiles gcc with it and distributes the infected gcc? If you are worried about intel doing it, when they have no reason to, why aren't you worried that someone may have done it to you (see debian server comprimise etc). Who was it that came up with that idea, I can't remember.

Re:do try to keep up

[Anonymous Coward]

If you have a copy of icc, and a friend or family member asks for a copy, what do you do?

AFAIK the compiler is available as a free download (for non-commercial use), so you would just send them the URL and let them worry about it.

Re:do try to keep up

[cakoose]

I think it was Brian Kernighan (one of the Unix guys).

Re:do try to keep up

[Anonymous Coward]

I would have to agree with what you have to say; I've encounterd ciaran a number of times, and not only were his statements zealous, but they were also quite GNU/Stupid.

He obviously needs more to do with his time, and I salute you for *attempting* to wake him up. :)

I know the Slashdot crowd won't mod you up, but they really should. Why Slashdot viewers relentlessly seem to reward ciaran for his karma whoring is beyond me.

Oh well. I'm just glad that the world doesn't think like Slashdot does.

Re:do try to keep up

[Anonymous Coward]

Actually, Denis Ritchie (the other one of the C guys)

I had a look.

[kyz]

There's no source code. So I'm not going to use it. Well, that was the easiest decision I made all year!

There was a time that I would put up with binary-only compilers. That was before gcc. Sure, both free and non-free compilers have bugs, but it's so much easier just to fix those compiler bugs yourself in the compiler's own source code, rather than have to craft a binary patch to fix the bug while you wait 6 months for the vendor to think about releasing the next version.

Re:I had a look.

[Peorth]

Actually, Intel seems decently smart about support. At least for their -paid- customers (I get an 'Access Forbidden' on their Premier support site, even though it says I should be able to get there with the free version too), there are pretty frequent minor patches that you don't notice if you just happen to check on the website once every few weeks.

It may be easy to some to patch their version of GCC for a bug they happen to hear about, but it's not a realistic expectation for most users. GCC is pretty "sluggish" on even bugfix updates, let alone noticing some of the bugs. gcc -march=athlon-tbird (and at least -march=athlon as well) can generate -really- grody incorrect code in even general situations, giving out really sub-par speed, even compared to -march=i686. The unfortunate thing being that this bug has been known about since circa 3.0.1, and hasn't been fixed by 3.3.2, and I've heard no mention of it being fixed in the 3.4 CVS branch (nor with my tests about five months ago).

Personally, I'm hoping an "alternative" compiler like TenDRA gets off the ground and can fill that void between overwhelming most-every-platform cross-compiler, and "beedy eyed" binary-only x86-optimized compiler, neither of which operates with any other particularly well.

Re:I had a look.

[Anonymous Coward]

"Well, that was the easiest decision I made all year!"

Easier than deciding not to poke out your eyes with a rusty fork?

Re:I had a look.

[Steve Cox]

> Actually, Intel seems decently smart about support.

You actually liked their Premier support site? I could never find anything useful on it (I was a paid customer)! That and the tastful shade of blue (#0000ff) kindof made my eyes hurt. I also couldn't get on with the password that changed every 30 days with some pretty strict selection rules enforced - all for something that jsut game me patches for a product that was FlexLM licensed anyway. Ho hum. Until v6 came out, that website was my only gripe with the then excellent product.

Steve.

Re:I had a look.

[Anonymous Coward]

(I was a paid customer)!

This sounds like a very interesting program. Where do I sign up?

Re:I had a look.

[Anonymous Coward]

>I get an 'Access Forbidden' on their Premier support site
Reregister with a new e-mail addess and make sure you check off "sign up for premier support" or something to that effect.

Re:I had a look.

[Anonymous Coward]

most-every-platform cross-compiler

i assume you mean: almost-every-platform cross-compiler

Re:I had a look.

[Junks Jerzey]

There was a time that I would put up with binary-only compilers. That was before gcc. Sure, both free and non-free compilers have bugs, but it's so much easier just to fix those compiler bugs yourself in the compiler's own source code, rather than have to craft a binary patch to fix the bug while you wait 6 months for the vendor to think about releasing the next version.

So is this something you've actually done--fix errors in gcc--or something you're just spouting off about? What were the errors specifically? Did you do full regression testing on your changes? Did you update the test suite?

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

[HuguesT]

Hi, impressive numbers.

Did you turn -ffast-math on with GCC? icc does that by default. On some applications it makes a significant difference.

AFAIK gcc does not turn it on even with -O3 because it makes the application non-IEEE compliant as far as the FP math is concerned.

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

[RML]

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

I assume that with icc, -O0 doesn't really mean no optimization, it just means not to do any optimizations that take extra time. Some optimizations actually decrease compile time, or at least have no effect, because they decrease the amount of work later stages have to do.

GCC currently interprets -O0 as meaning no optimization at all, which makes comparing the speed of gcc -O0 to anything (even gcc at a higher -O option) silly. Intel's -O0 is probably closer to gcc's -O1.

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.

Re:Real Timings

[Anonymous Coward]

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.

Just to provide a partial counterexample, I personally have no problem with corporations in general, just evil ones, which there seem to be plenty of. As for ICC being faster than GCC: I'm not blind, I've seen the benchmarks, I just don't care. I don't use Free Software because it is technically superior, I use it because it gives me freedom. Fortunately, it is almost always technically superior as a result, but if it isn't, I don't care.

Re:Real Timings

[Anonymous Coward]

Apparently RMS was smoking crack again, while writing GCC.

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:processor dispatch

[RML]

Processor dispatch allows the compiler to generate multiple optimized code paths and dynamicaly select which optimized version of the routine to use ...

Interesting. I wonder how hard it would be to implement something like that for gcc.

Re:processor dispatch

[porksodas]

This allows a single executiple

What the hell is an executiple?

Re:processor dispatch

[DAldredge]

A new word. Please do not use it as I currently have a pending patent app on its use.

Re:processor dispatch

[swagr]

Interesting. I wonder how hard it would be to implement something like that for gcc.

Does it matter?. I'm sure it's patented.

How about version numbers?

[0x0d0a]

It'd be awfully nice to have version numbers on this 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:Awfully tenuous argument

[bhima]

Well to be honest, no I don't trust them, not at all. Being trustworthy has nothing to do with the main goals of being a company. Raising the stock price is what companies do, that's about it. Fortunately I'm too small of a fish, far, far away form the likes of them. I'm relatively cautious about my internet connection and what I install on my home PC. But I think all of this is beside the point. The parent was simply engaging in a mind game, the same as Ken Thompson was. These can be useful occasionally, it seems you may being irrationally fanatical in your response.

Re:Awfully tenuous argument

[Syberghost]

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.

What if you run an AMD?

Re:Awfully tenuous argument

[Anonymous Coward]

AMD is also a member of the trusted computer group. Therefore same arguement exists.

Re:Awfully tenuous argument

[Syberghost]

I can't believe I'm arguing for this ridiculous conspiracy theory, but what the hell.

No, the same argument DOESN'T exist. Intel can't very easily insert a trojan into AMD's processor designs, unless AMD collaborates. However, they do have an economic stake in designing a compiler that appears to function properly on AMD, but produces code that doesn't perform properly.

Follow the money.

Re:Awfully tenuous argument

[love2hateMS]

I was interested in your reply until I clicked on your sig...

You don't need a tin foil hat-- you need a tin foil body suit.

Great!

[wayne606]

It's great that this compiler is available. For the people who want to use open source and/or free software, there's gcc. For those who don't care about that and want good code, there's icc. And now that the gcc authors can pore over the output of icc and get some ideas on how to generate better code, we can hopefully expect future versions of gcc to close the gap a bit.

How fast on non intel machines ?

[bug1]

How bloated are the static binaries ICC produces ?

Code portability is important.

If you dont care about code portability and all you want speed write in assembler, not C or C++

ICC ay be usefull to a niche market, but it doesnt have a long term future.

Re:How fast on non intel machines ?

[menscher]

How bloated are the static binaries ICC produces ?

About the same size as the static binaries that gcc produced. I should mention that the reason I compiled with -static was because I was testing the speed on three different computers with different hardware (and different libraries) so I needed something widely compatible.

If you dont care about code portability and all you want speed write in assembler, not C or C++

Sorry, I didn't try running these on our Athlon boxes since they won't be running there anyway. I'd try it, but I don't feel like taking the hour or two to test that right now. Maybe you could try it. The Intel compilers are free for a 30-day evaluation.

Oh, and ROFL about coding in assembler. I think you're missing the point here. The code is portable. I really don't care if the binaries are.

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:Definitely going to try out this one

[Steveftoth]

Try using distcc, as that would reduce it even further when useing multiple computers.

Asuming that compile time is most important to you, if the code runs faster under icc then you should probably use that instead.

Re:Definitely going to try out this one

[sperling]

That's what we're using, compile usually runs on 5-6 2.5GHz+ cpus. distcc used to require a little tweaking to work with icc, but apparently the later versions handle it fine though.

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: Supporting various hardware

[njchick]

No, it doesn't. See System requirements:

IA-32: A system based on a 450 MHz Intel(R) Pentium(R) II processor or greater, Intel Pentium 4 recommended # 128 MB (256MB recommended).

IA-64: A system with an Intel Itanium(R) or Itanium 2 processor or greater

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.

Re:But Have They Fixed The Bugs?!

[Steve Cox]

With 4 years of development/support/enhancements, the program is getting quite large now so even though I have tried to keep my code standards compliant it could be a distinct possibility that some crap has crept in somewhere :) [note - I am using Windows, but the app is not using any MFC generated garbage/C++ extensions].

I did search for the reason behind the crashes for a while, but after a while it came down to the usual time/money/performance trade off since we did not get any such crashes using MSVC6/7. It was kind of hard catching the crashes since the debugger missed them(!) and the printfs slowed it down so much that it could not process the data in time. Ho hum!

In the end I'll probably be giving icc 8 a go and will run it in parallel with the live system for a while - given the choice I have (on Windows) of MSVCC & icc, I much prefer the stricter parsing and better optimisiation of the Intel compiler. (That, and the fact that I find it hard to believe that MSVC compiler does very many optimisations at the speed at which it whizzes through things... good things come to those that wait!)

Steve.

Re:But Have They Fixed The Bugs?!

[jmv]

Just one thing: it's not because your program crashes with icc that the problem is necessarily in the compiler. It's often caused by errors or incorrect assumptions about the compiler. Just look at how every new gcc release breaks the kernel - not because of bugs in gcc but because of unclean things in the kernel.

Intel, great.. what about AMD ?

[billcopc]

When will AMD release an optimizing compiler ?

We've got the free software, why not tweak it for cheap fast processors ? My Dell P4 laptop is nice and speedy yes, but for the same money I could have bought an even nicer Mac G5, or five Athlon-based desktops of equivalent performance.

I want my 3DNOW, dammit! =)

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.

Patches for compiling linux kernel

[rleeuk]

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

Re:Patches for compiling linux kernel

[Anonymous Coward]

Thank you!

Try different architectures as well

[Zo0ok]

I was doing c/c++ development on the following platforms simultaneously:

- Mac OS X
- SGI Irix
- Solaris Sparc
- Linux x86
- Linux PPC

My experience was that you can get pretty much anything through the gcc x86 compiler and also run it successfully. When you move along to another platform you get Bus Error or Segmentation Faults all over the place, at runtime (the PPC is really picky).

Using different platforms simultaneously really helped improve code quality.

I usually code in linux/x86, but I do not consider my code tested and bugfree before it runs well on Mac OS X as well.

Optimize or architect for performance?

[aphor]

Theoretically, an optimizer would transform object code into something that always produces the same set of output for any given set of input, but it would do it faster than the un-optimized code. Since the direct correlation of objects in the object code and descriptions in the source code is broken, debuggers will often fail to work correctly on optimized code. Even if it worked perfectly all the time, there is no guarantee that optimized code will always be faster than unoptimized code. If the source code is architected with strict mathematical Ockham's Razor style, then the object code will be unoptimizable any further: reduced to its minimal terms.

The question I want to ask: why would you intentionally write source code whose object code can be significantly improved by optimizations? Platform neutrality (is that just modular compilation or optimization's role)? Source code readability (what about putting some effort into your comments and READMEs)? Laziness (what if your hour of programming effort will yield beyond what you would expect from optimization, many hours of saved work by running the program)?

Let's skip the polemic and get right to the meat of the question. WTF is the point of optimization? Can we do better?

Re:Optimize or architect for performance?

[Anonymous Coward]

Source code doesn't run in a theoretical vacuum. The job of every compiler is to output CPU-specific instructions. A vendor compiler like Intel's is much more likely to output optimal instructions for new CPUs, as well as exploit new processor features and so on.

Also, it's rare that you want to want to architect your source in "strict mathematical Ockham's Razor style", because it would be an unmaintainable spaghetti pile. Even simple constructs like functions and pointers have some overhead. An optimizing compiler removes some of that abstraction in the final binary, and the more you can remove, the faster it gets.

I recommend that you do less book-learnin' and more programmin'.

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.

Re:Optimize or architect for performance?

[aphor]

I'm not sure that this is necessarily an optimization like I'm referring to. I'm not exactly sure what gcc does for instance, but I would expect sizeof(int) to be calculated and stored for easy reference when the program block or function provifing scope is pushed onto the stack. I would consider recomputing sizeof(int) every iteration to be foolish. Is it even legal to change the type of a variable? What's the point of declaring a variable type before you use it if you need to do sizeof(type) every time you ++ it?

Maybe the meaning of optimizing compiler is changing and becoming more sophisticated. I was thinking more on the lines of unrolling loops and flattening scopes to avoid stack operations where it isn't strictly necessary.

Do I make any sense at all?

I really am not daunted by the pointer arithmetic. Maybe I was branded at an early age. I'm not sure this is a good readability example for me anyways. One is more abstract is all.

Re:Optimize or architect for performance?

[stevesliva]

The pointer arithmetic example just illuminates why there's a distinction between a high-level languages and assembly language. A high-level language should allow you to not have to pick out hidden operations and resequence instructions to use accumulators, registers, memory or cycles efficiently. A basic and correct compiler could do a load and a store to/from memory every time you do an i++ rather than keeping the loop variable in a register. But recognizing that a loop condition variable shouldn't have to be fetched from memory is so trivial it's not really considered much of an "optimization" to avoid it. However, the code is technically correct without. In fact, a load-store-load-etc. on the same address is so ugly that modern processors with ridiculous amounts of instructions in flight and out of order execution would basically ignore the explicit instructions but guarantee things look correct in the end. Intel's so fed up with making optimizing processors that they've decided to mandate hyper-intelligent EPIC compilers with IA64, guaranteeing that well-compiled assembly will bear no resemblence to elegant program code.

Re:Optimize or architect for performance?

[aphor]

I can't help but point out that the ridiculous amount of cache on processors these days can obviate concerns over the load-store-load thing, and processors (rather memory controller chipsets) will always optimize that sort of thing. Granted: fetching from cache is not as fast as direct operation on a register, but how many loops are tight enough to execute in less cycles than a fetch from (L1 or L2) cache? Now we're getting into "costing" operations where it pays to do architecture comparisons because of the drastic differences in pipeline depths, etc.

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.

redundant?

[Anonymous Coward]

how can the very first post for a story be modded 'redundant'? meta-mods, you know what to do here...

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: Supporting various hardware

[Anonymous Coward]

Here's a link you need to check out

Re: Supporting various hardware

[njchick]

Thanks. I should have replaced that stupid signature long ago.

Ok, people time to kill the confusion...

[JamesP]

Everybody is wondering why should I shell some money for something I could have for free (a C compiler for Linux and even for Windows)

The magic word is Optimization. Not 1% faster optimization, but Heavy Metal optimization...

For one, try to compile something to Itanium...

For other, try optimizing your code to use MMX/SSE/SSE2 stuff. ICC vectorizes your code automatically...

XVID is (usually) compiled with the ICC. Wonder why? Because it's top quality code...

Hope Scott Ladd will benchmark this soon

[haruchai]

As he has for previous versions of icc and gcc http://www.coyotegulch.com/reviews/index.html

Non-commercial use compiler and GPL?

[seva]

Here's a random question, if a compiler is licensed for non-commercial use, but the source code is GPL, does that mean that produced binary can not be used for commercial purposes?

But if it's GPL-ed souce, I don't think one can apply that kind of restriction to it.

Re:what about

[Anonymous Coward]

Mod parent funny.

It was a joke

[some guy I know]

See, the Opteron is made by AMD, a competitor of Intel's.

Re:It was a joke

[njchick]

It's a joke only for those who are indoctrinated by corporate culture. From the technical point of view, adding support for x86-64 is easier than IA-64 if the compiler supports IA-32 already. Even from the consumer perspective, it's reasonable to expect newly released propriery software to match features of the existing free software, including platform support.

Also, Opteron runs x86 code just fine, and there are good chances that the code compiled by the Intel compiler for IA-32 would run on Opteron.

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.

Re:Vectorization is probably the key

[menscher]

I appreciate your comments. And it touches on one of the reasons I did the benchmarking in the first place: we noticed our new machines were running as slowly as old machines. As you can see from my original post, icc7 ran 15% slower than icc5. The new machines were 15% faster (CPU) but had a slower compiler. I'm hoping that this was fixed in the recent release of the intel compilers, but haven't had time to benchmark them yet.

GCC compiled with ICC?

[Slur]

Well, ICC compiled with ICC ought to run pretty fast given its optimizations. Now, has anyone considered compiling gcc using ICC to see how much of a performance boost it gets?

20%+ penalty for using gcc rather than icc

[AHumbleOpinion]

Go look at the Dell SPEC numbers in Apple's G5 advertisements. Now go look at the official Dell SPEC numbers. IIRC the SPEC numbers dropped over 20% by moving from Intel to GCC. YMMV. Not a slam against GCC. Ubiquity is its goal not best performance on all platforms. GCC is also handicappd in that it can't use proprietary techniques Intel can easily afford to license.

Yeah

[kyz]

Some gcc 2.0 (I forget the version) would build 680x0 jump tables with unsigned shorts then jump as if they were signed. Thus it jumped to x-2 instead of x+fffe, if you see what I mean.

I didn't have the internet at the time, so no, I didn't update the test suite or even tell anyone.

I must admit that some closed source authors (e.g. Frank Wille when he was writing phxass) make a good effort to fix bugs immediately when they are told about them, but nothing's quite so satisfying as being able to say "there, found it, fixed it!" once you've spent 2 days finding out the bug, rather than "found it! now I have to mail the developers and wait a few weeks".

wrong again

[cakoose]

Looks like we were both wrong. It was the other Unix guy, Ken Thompson.