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

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.

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.

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

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