Testing the Intel C++ Compiler

Version 7 does offer some performance gains, but the debugger is less than stellar.

Product Vendor: Intel CorporationURL: www.intel.comPrice: C++ Compiler for Linux - $399 (Free 30 day evaluation download)      Fortran Compiler for Linux - $699 (Free 30 day evaluation download)      VTune Performance Analyzer for Linux - $699 (Free 7 day evaluation download)

  • Performance gains of up to approximately 30% over gcc 3.2.

  • Optional Fortran compiler vs. g77, which translates into C and compiles with GCC.

  • GCC compatibility mode.

  • 64-bit support (Intel Itanium only).

  • Limited support for glibc (7.0 supports 2.2.4 or 2.2.5 only).

  • Requires RPM for install.

  • Debugger does not include a GUI, command line only.

  • Official support for Intel Pentium/Xeon or Intel Itanium processors only (no support for cross platform development).

  • GCC compatibility limited with open-source code tested.

Being an avid developer and tool junkie, my enthusiasm to try out Version 7 of the Intel C++ Compiler was high. I was most interested in using the debugger, as GDB has left me short of success on more than one occasion. I've put up with it and done the best I could, but I was looking forward to an alternative.

My first disappointment came in trying to get the tools installed, when I was forced to jump through some hoops simply to get the software on my computer. Reading the requirements, it seemed clear what was needed. The only piece that seemed to be a must-have was glibc 2.2.4 or 2.2.5. Taking some relief in knowing that my Debian woody has 2.2.5 installed on it, I believed all the requirements were met--until I discovered the Intel installer actually requires RPM to install. This is the type of requirement that really annoys me; luckily, I keep a partition installed with Red Hat for this very scenario. I typically find that I can tar up the software and move it easily over to Debian after it's installed.

Figure 1. The install is a simple command-line install. Unfortunately, it requires RPM as well as glibc 2.2.4 or glibc 2.2.5 to install properly. For Red Hat, this means 7.2 or 7.3 only.

The installation was not easy, because my Red Hat partition intentionally has been left at a variation of Red Hat 6.2. This is the last version of RH that VA Linux Systems distributed. I've always felt comfortable with VA's modifications to the stock Red Hat distribution. It gave me some comfort to know that people had done testing beyond what Red Hat does. Unfortunately, I came to find that glibc 2.1.3 was shipped with Red Hat 6.2.

Looking for life to start getting better, I decided to upgrade my system to Red Hat 7.3, which includes glibc 2.2.5. Aside from having to reinstall a newer Red Hat distribution to my partition, all I lost was time. After getting Red Hat 7.3 installed and setting up my login environment, I was able to tar up the software and move it to my Debian system, which already had glib 2.2.5.

The two systems I use for development are a dual 550MHz PIII Xeon box and a dual 1800+ Athlon MP box. Intel states that you need an Intel Pentium processor or higher to run the compiler, with Intel Pentium 4 or Intel Xeon processor recommended. Intel Itanium and Itanium 2 processors also are supported, and that in itself might make the compiler useful to the few folks who have those processors. A 64-bit version of GCC is available, however, and some folks might find its performance gains on Itanium and Itanium 2 processors to be a big incentive. I didn't have any Itanium processors to test with, unfortunately.

For the most part, I didn't notice any problems in using the Intel C++ Compiler on a non-Red Hat machine. It does bother me that vendors make installs specific to Red Hat, though. Even the fact that one of the machines I used for the review is not specifically supported--Debian running on an Athlon--is annoying because the programs ran fine on it.

Having navigated this far, I finally was ready to test the tools. I figured I could go back to my dual Xeon system, where Red Hat is installed, if all else failed. I didn't seen any problems, though, so people should be fine to use the Intel tools on an Athlon system for development/deployment. Just keep in mind this type of system is not officially supported.

The on-line documentation for the Intel C++ Compiler actually is pretty good. It is in HTML format and can be opened with any of the common desktop browsers, making it easy to navigate. A tree view of the categories is included that explains where help is provided, allows for searches and provides an alphabetized index.

Figure 2. On-line help is surprisingly easy to navigate with a nice HTML interface. A tree view inside the left frame makes it easy to navigate, view an alphabetized index or search.

The Intel C++ Compiler has a GCC compatibility mode that enables you to use the compiler with most code that compiles with GCC. Intel's C++ Compiler doesn't support all of the extensions that GCC implements to meet C language specifications, but it does accept most of them.

I found fair results in compiling quite a bit of the open-source code I was testing. About 50% of the code I tried to compile could compile with a simple reconfigure, but I felt there was enough code that didn't work straight away that I wouldn't call the Intel C++ Compiler a simple total replacement for GCC. Some examples of packages that were a simple GCC replacement are lame-3.92, mysql-3.23.52 and gnupg-1.2.1. Some examples of packages that weren't a direct replacement are emacs-21.1, liveice and gphoto-2. My experience showed that results were mixed on packages that could compiler straight up without changes. I think MySQL is a good example of GCC compatibility, because it is a fairly large project.

In many cases, the Intel C++ Compiler appears to produce code that is about 30% more optimized than GCC code. The performance of the Intel C++ Compiler, therefore, is good in comparison to GCC's performance. This may well be the best feature of the compiler for those using x86 architectures.

I won't go into performance testing in detail, mainly because several Web sites have detailed it much better than I could hope to do here. I am mainly concerned with using the tools and their ability to handle real world code. For performance numbers, go here and here.

My original interest was in writing about the Intel debugger. I have long felt that a decent debugger is worth its weight in gold to a developer. In cases where I have suffered by using GDB in the past, trying to debug shared libraries or multi-threaded applications, I gladly would have purchased a decent debugger.

Figure 3. The debugger is a basic-command line interface with no GUI. I found it comparable to GDB in functionality, but I couldn't get it working with the GNU Data Display Debugger (DDD). GDB is easy to set up with DDD; in addition, it supports cross-platform debugging.

As I used Intel's debugger, I realized it had many annoyances that made it less than suitable for my needs. First, there is no GUI for the Linux version. I've heard from a friend that there isn't a GUI for the Windows version either, but Windows uses the Visual Studio debugger for that integration. I do not know for certain how that combination works, as I do not run Windows on any of my machines. I have tried to get the GNU Data Display Debugger to use IDB but have not been successful to date.

I began by compiling a simple application with three threads and found that IDB was not nearly the debugger I was hoping it would be. The command-line interface was marginally acceptable, similar to GDB's. In addition, I see a disadvantage in that GDB works easily with DDD while IDB does not. IDB seems to handle threads better, but some of the basic commands to view threads didn't work as reported in the on-line documentation. Furthermore, a graphical debugger should be a basic part of any modern tool package these days.

I have heard of people getting DDD to work with the Intel Fortran compiler by using the --ladebug option, but I can't get this option to work with the C++ compiler. I tried reverting back to a stock Red Hat 7.3 installation in hopes that it might have been a Debian problem, but this wasn't the case--both systems failed. I could find no mention of using IDB with DDD on Linux in the documentation available.

Speaking of Fortran, Intel does include a true Fortran compiler that might be of use to people, because g77 translates the Fortran code into C code and then runs it through GCC. For those people looking for the last bit of performance they can get, however, this loop defeats the purpose of trying to optimize with Fortran in the first place. Intel's Fortran compiler would suit them better in that quest.

Even for C/C++ code, the Intel C++ Compiler seems to produce better optimized code than GCC. On average, it seems a 20-30% improvement in optimization can be achieved on most code. That in itself can be an incentive for people to invest in the Intel tools. Although people have different thoughts on the matter, my take is that if a tool can give you even 15% improvement in optimization, that can pay for the cost of the tools. However, for all practical purpose the debugger seemed to fall a bit short of what I thought it would offer. For people looking for performance gains on Linux, there certainly is some room for improvement.

Overall, I think the Intel C++ Compiler could offer some benefits to people needing extra performance. It offers a Fortran compiler for those needing such a tool, as well as a performance analyzer. The debugger, though, was a disappointment. Maybe Intel will improve the debugger in a future version.

Alan DuBoff is the president of Software Orchestration, Inc., an independent consultancy in Silicon Valley providing professional services for UNIX/Linux. He previously worked on the Kerbango Internet Radio, which used embedded Linux. He has programmed devices as small as a cell phone all the way up to enterprise servers, and he uses most modern programming languages. His hobbies include sailing and music.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

bisa minta compiler c++ 7 g

yolanda's picture

bisa minta compiler c++ 7 g ?

About VTune and Intel tools integration...

Anonymous's picture

I was expecting to see some information about the usefulness (or not) of VTune to track down bottlenecks and improve the overall performance of an application, it's a pity there's no such section in the article. I personnaly find VTune very useful and able to provide highly valuable information.

About the integration of the Intel tools, I'd like to think we will see something coming out of Intel joining the Eclipse consortium (http://www.intel.com/pressroom/archive/releases/20030730corp.htm).

The Linux Kernel 2.4.20 compiles with icc and boots :D

Anonymous's picture

the linux kernel 2.4.20 compiles with icc and boots, however not all modules compile, the xfs patch also doesn't compile (that part SUX a lot, because i use xfs) and newer versions of the kernel fail on one file at least, crc32.c. Linux 2.6.x does not compile at all. Gonna try some other packages, also want to try to compile gcc using icc.

Re: The Linux Kernel 2.4.20 compiles with icc and boots :D

Anonymous's picture

Does it seem any faster?

Re: Testing the Intel C++ Compiler

Anonymous's picture

Just a couple of comments on this article. First of all i have been using the Intel tools for Linux since version 4 and have never had any problem using the DDD interface, even before the debugger was called idb. I have always used SuSE Linux, where a simple
ddd --debugger idb
does. The debugger used to be called fdb as only Fortran was supported then.

Second, i wouldn't say ifc might simply be a replacement for g77 for two reasons. First on pure Fortran 77 source files, i have often found g77 to be more efficient. Second ifc is a Fortran 90/95 compatible compiler, where extensions such as dynamic allocation are available. For this very reason, it might be useful to scientists using Linux in their daily work. I have found however that ifc still suffers from a number of internal bugs, and is not yet quite on a par with other commercial F90 compilers for Linux.

Intel Debugger additional info

Anonymous's picture

Intel Debugger (IDB) supports 2 command languages: DBX (compatible with Ladebug from COMPAQ) and GDB (compatible with GNU GDB). The second one isn't fully implemented but the implementation improves form release to release.
To start IDB in GDB mode use:
$ idb -gdb
To switch between modes while working use:
(idb) set $cmdset="gdb"
(idb) set $cmdset="idb"
Both these modes could be used under DDD.
In the latest release manual describes how to run IDB under DDD.
In a word:

To use IDB in DBX mode with DDD the command line is:
$ ddd --ladebug --debugger /full/path/to/idb

To use IDB in GDB mode with DDD the command line is:
ddd --debugger "/full/path/to/idb -gdb"

Free unsupported, non-commercial versions

Anonymous's picture

Please note that you can download unsupported, non-commercial versions of
both the C++ and Fortran compilers for Linux: http://www.intel.com/software/products/global/eval.htm

Re: Testing the Intel C++ Compiler

Anonymous's picture

Why use redhat to do the rpm's ?

Debian has a very useful utility (alien) for converting rpms to debs. This would have saved you a lot of hassle:)

Re: Testing the Intel C++ Compiler

Anonymous's picture

It would be interesting to see a comparison from the author between gcc 3.3 and the Intel compiler, as opposed to gcc 3.2 and the Intel C++ compiler. My tests showed that _for my software_ (which is scientific codes written in C++), gcc 3.3 and the icc 7.1 produce code that is of the same speed on Intel processors, but that the gcc 3.3 compiler produces code which is 30%-50% _faster_ on Athlon processors (compare this to gcc 3.2 which produced code identical in speed in most cases, but on one benchmark has about a 15% improvement on Athlon processors).

However, I did do some extra testing to find out certain related cases where icc could produce faster code than gcc (even on Athlon processors for some benchmarks)--but those kind of constructs just don't appear in my code.

Re: Testing the Intel C++ Compiler

Anonymous's picture

I've had good results using icc instead of gcc 3.2 for image
processing and graphics code, both of which have loads of
of floating point. Main reason is OpenMP, something which
hasn't been mentioned, but which gives almost painless
multi-threading and makes a dual Xeon machine scream.

Re: Testing the Intel C++ Compiler

Anonymous's picture


I'm looking for a floating C++ license for RedHat 8.0.
Can you tell me where to buy it??


Re: Testing the Intel C++ Compiler

Anonymous's picture

This is interesting. For my chess program, which manipulates 64bit integers, the Intel 7 compiler produces 30% faster code on Athlons - after profiling in both cases, which is a huge difference.

I wish the gcc guys would talk to the Intel compiler programmers.

(The difference is about the same for Intel 6 and 7 and gcc2.95 upwards.).

Re: Testing the Intel C++ Compiler

Anonymous's picture

There are some other interestings areas to compare: multithreaded STL code (I found icc's STL library produce much less context switches than g++-3.3); heavy template code (in the past I saw examples where g++ was much faster than icc on examples from Boost graph lib.); and finally (or should it be the first?) correctness of the compiler with high/reasonable/no optimisations. If compiler miscompiles for(i=0; i != n;++i), why would you worry about performance ? (well, one of them did under certain circumstances:), now fixed). Also, currently you have to use icc if you write multithreaded application which uses SSE[2] primitives, as gcc doesn't align stack properly (maybe there is a workaround, I don't know). Overall, I think both gcc and icc are excellent compilers and they're getting better every year.

g77 does not use gcc

Anonymous's picture

G77 uses the gcc backend to generate assembly code, it does not compile to C and then run gcc.


Re: g77 does not use gcc

Anonymous's picture

ditto, we have used g77 for years and it does not generate intermediate C code. f2c is a frontend that does do that for a limited subset of fortran.

Re: g77 does not use gcc

Anonymous's picture

However, g77 only does Fortran 77, which is a very limited subset
of Fortran 95

Re: Testing the Intel C++ Compiler

Anonymous's picture

You should check to see if the Intel compiler installs under Debian using the Debian alien and RPM packakages. You can also unpackage an rpm to a directory using the rpm tools and rewrite it as a Debian package or just follow the RPM install script/instructions to do a manual install.

Getting the Intel compiler to install on Debian may be as simple as unpackaging the RPM removing any external requirements from the RPM install script then repackaging the RPM and doing an rpm -i .

Re: Testing the Intel C++ Compiler

Anonymous's picture

The problem is that (last I checked) Intel wraps its RPMs inside of an executable program, in a foolish imitation of Windows installers. With some painful hacking, it is possible to extract the "raw" RPMs, convert them to .deb with alien, and install "natively" on a Debian machine.

I wish that Intel would get a clue, though.

Re: Testing the Intel C++ Compiler

Anonymous's picture

Why? RPM is used by 90% of people and the LSB states that a compliant distribution should alow the installation of RPM files.

Re: Testing the Intel C++ Compiler

Anonymous's picture

It's very easy to install icc on Debian/i386 (I run unstable). First install rpm package and run "rpm --initdb" (once). Then, during icc setup, it prompts you for extra options to rpm, just add "--nodeps" and it will install everything fine. Of course, I'd prefer they had native Debian install as well.