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?"
I've not tried it, but there is a USE flag to use icc instead of gcc if you have it, so it's supposed to be drop-in-and-tweak-a-flag. As for benefits, who knows? I know my gentoo box feels snappier than the same box running Mandrake or RedHat, but I have a sneaking suspicion that it's only snappier 'cause it's running fewer deamons--I doubt that source-based distros really get you much more performance, but I have no numbers to back up either side of the argument--so if compiling from source with gcc doesn't give you any benefits, I doubt using icc would be any better.
Because in some/most cases it makes faster code and saving 10% execution time is worth the sub 900 USD price of the Intel C compiler.
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.
Read the article. Previous to this version there was speculation that 100% compatability would be achieved. Clearly that is not the case, though great strides had been made.
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
Overall, it's probably not worth using unless you really need a compiler that generates fast code.
Human/Ranger/Zangband
According to the website the compiler for Windows is $399
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.
I'm not allowed to know what my copy is doing
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?
In a way, the idea of using a proprietary compiler is very similar to that of proprietary voting software.
Expert in software patents or patent law? Contribute to the ESP wiki!
Corrected link here
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.
And ignore the word "superior" in the last entry. That's just an internal note that I forgot to remove... has nothing to do with the timing test.
And for those who were wondering... the various tests comparing RH8 libraries (2.2.93 vs 2.3.2) were done because the 7.0 version of the Intel compiler did not support RedHat 9 (so we were forced to copy libraries over from a RedHat 8.0 box). I'm really looking forward to getting Intel's 8.0 compilers so we can stop doing that ugly hack!
Ok, I think that covers just about everything I left out. Now back to your regularly-scheduled programming....
i seem to remember that even non-open-source programs can still be run through a decompiler (albeit not necessarily legally, thanks to the shrink-wrap license.)
Sadly, there don't seem to be any good free (either speech or beer) general-purpose decompilers. There are several for Java, but Java is easier to decompile because programs carry extra information for verification purposes.
and sheesh, some C people can read assembly code just as easily as if it -were- C. it's practically the same thing.
Depends. C may be messed up but it's not nearly as messed up as, say, x86 assembly. And the compiler will reorder blocks, functions, and data, so things that were nearby in the source can be far away in the binary.
Human/Ranger/Zangband
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
Actually, just to note, there is (as there has been since 7.0 or so) a non-commercial version of the Linux compiler. You're not "allowed" to compile commercial stuff with it, but $0 is still cheaper than paying for 8.0 if you don't go for that sort of thing or just want to see how well it'll work with your libraries. (not to sound like an Intel saleswoman, gah)
I used the Windows version of the Intel compiler at work for quite a while, and it does produce some exceptionally fast code (and sometimes takes an exceptionally long time doing it).
The problem? Since version 6 came out any software we compiled with it exhibited crashes that did not occur when we used another compiler on the same code.
In the end we had to stop using it. Its a shame really because it was an excellent product (the only gripe being their Premier/Quad support website which was crap).
Steve.
See http://www.suri.co.jp/~ohkubo-k/linux/.
Because the extensions are good not just for speed. They improve code readability and make it easier to spot programming errors early. Also, they provide required functionality that is not standardized. Avoiding gcc extensions would mean rewriting some code in assembler for all architectures.
They won't since there's no compiler team at AMD. There are AMD engineers that work on the GCC project. That's as close as you're going to get.
I think ICC yields slightly better performance on AMD anyway.