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)

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.