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?"

5 of 161 comments (clear)

  1. Re:What's the big deal? by Screaming+Lunatic · · Score: 4, Insightful
    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.

  2. Re:Question by AtrN · · Score: 4, Insightful
    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.

  3. Awfully tenuous argument by 0x0d0a · · Score: 3, Insightful

    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.

  4. Re:so, any source distributions able to use this? by cakoose · · Score: 4, Insightful
    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.

  5. Re:kernel by jarek · · Score: 5, Insightful

    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