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

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?

-

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.

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.

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

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.