Slashdot Mirror
Intel Releases Compiler Suite 7.0
Yokaze writes "Intel boosts its Pentium 4 and Itanium 2 and released Version 7 of its compiler suite. On the Windows side, there is the plugin compability to the .NET enviroment, on the Linux side better compability to the GNU compiler, including the Common C++ ABI.
As usual, there are 30-days evaluation copies and for Linux an unsupported non-commercial version after previous registration at the Intel Evaluation Centre. According to the comments published by Intel marketing, Dr. Fons Rademakers, CERN, claims high compability with GCC 3.2 and a performance increase of up to 30% on their code (The ROOT System)."
As usual, there are 30-days evaluation copies and for Linux an unsupported non-commercial version after previous registration at the Intel Evaluation Centre. According to the comments published by Intel marketing, Dr. Fons Rademakers, CERN, claims high compability with GCC 3.2 and a performance increase of up to 30% on their code (The ROOT System)."
gcc in some areas produces slower code than the native compilers.
The fact is that gcc is designed for cross platform compilation and the native compilers are not. The abstract tree approach to gcc's design is somewhat limiting for some arch specific operations, and certainly adds complexity to the compiler development process.
Also, Intel and Sun have spent many millions of dollars on their compilers over the years. You get what you pay for.
However, I would hesistate to use the intel or sun compiler for a project.
Using a platform specific compiler ties your project down to a single architecture, defeating one of the major purposes of C/C++.
A far better approach, if practical, is to isolate the real performance sucking areas (encryption, xor routines, float ops, etc), and write these sections in assembly. Those sections will become platform specific, but will smoke any compiler output.
Someone you trust is one of us.
I use the Intel compiler on Linux. The program I work on when compiled with it runs around 50% faster than gcc. But in general, use whatever suits your particular needs, and just make sure you use standard C/C++ and it'll still be compatible. If you're not sure, check occasionally that it still compiles with other compilers.
Personally theres no way I'd go near assembly. That pretty much guarantees unmaintainability, unreadability, platform-dependance. I don't know how many hours I've had to waste working out what someone else's assembly is doing, converting it to readable C, and then having understood what its doing, optimised the C algorithm to make it faster than the assembler ever was.
I've also used the Intel Compiler's Intrinsics to MMX-optimise my code without a line of assembler. I've tested the code to be just as fast as hand-coded assembly equivalents. I also always create an identical pure-C/C++ function, so its clear exactly what is being done, and can still be compiled on other compilers/platforms. This is necessary in any case so that the code will run on non-mmx (pre P-III) systems.
I'm looking forward to testing the version 7.0 Intel compiler - my experience with version 6.0 was that it made programs faster than gcc but still slower (and a lot bigger) than Visual Studio