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?"
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.
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.
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.
Human/Ranger/Zangband
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.
Do you even lift?
These aren't the 'roids you're looking for.
Who do you get to be an expert to tell you something's not obvious? The least insightful person you can find? -J Roberts
I don't know if this applies to the newest version, but info about a non-commercial license is at:l ers/c lin/noncom.htm
http://www.intel.com/software/products/compi
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.
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.
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.
That's a strange conclusion. The Gentoo comparision is a comparison of two -march settings on GCC. ICC is a whole different compiler.
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.
The next great MMORPG.
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.
Human/Ranger/Zangband