Slashdot Mirror
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?"
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.
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.
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.
May we never see th
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.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
That's a strange conclusion. The Gentoo comparision is a comparison of two -march settings on GCC. ICC is a whole different compiler.
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
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.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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.
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...
how long until
Let's consider a very basic example:If you read old C textbooks, they'll actually tell you to write the above code as something likeWhy? 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.