C/C++ Users Journal February 2004
At first look, there's not even a question — GNU C/C++ rules on the Linux platform. Given that the kernel, libraries, and all of the tools are compiled with this compiler, and given that the compiler comes standard in every Linux distribution out there, it is easy to understand its dominance.
Still, there are other compilers available for Linux on the Intel architecture (IA32) platform. Why would you want to use them and what are their pros and cons?
One reason to use other C/C++ compilers is the quality of code generated. The Linux crowd tends to believe nothing can ever beat the GNU tools. It is indeed true that most of the GNU tools are far better than proprietary, commercial offerings. For example, there is little doubt that GNU's make is superior to those provided by development suites from HP, Sun, or IBM AIX. (One developer I know at Sun uses GNU tools, instead of Sun's, whenever he can.)
Nevertheless, compilers are indeed one of GNU's weakest spots. Why is that? One reason is certainly focus, or the lack thereof, when it comes to one platform or one architecture. A new GNU C/C++ release has to work — or is expected to — equally well on more than 20 platforms and architectures and combinations thereof. Making GNU C/C++ perform well on all these platform is, in some cases, a contrast in terms. This is especially true for the optimizer, which can't always keep up with aggressive new CPU optimizations such as branch predictions, pipelining, and prefetching. In this area, specialized, targeted compiler providers should have an advantage. In theory.
In the Linux space, not counting the ubiquitous GNU C/C++, the most widely used compiler suites are:
To test the performance of the different compilers, I used a Monte Carlo routine obtained from http://caboy.uchc.edu/sleipnir/Software/GSL/gsl-ref_14.html. I ran the test with the same data set and tuning parameters on a Pentium Xeon 2.4-GHz with 512K cache. Table 1 shows the results I obtained.
From Table 1, it looks like nothing can beat Intel's optimizer for number-crunching applications. After all, nobody knows the various Pentiums as well as Intel. In fact, working with commercial compilers for high-performance computing applications makes sense — especially if you also need clustering capabilities like OpenMP, which are built into the Portland compiler. The longer the jobs run — and in high-performance computing, some run for weeks or months — the better the effect of a good compiler.
Some time ago, Intel reported on the Internet that the Linux kernel, once compiled with Intel compilers, achieved speed-ups of up to 70 percent. How true is this claim? To answer this question, I began by compiling the kernel with the latest edition of Intel's compiler.
The Linux kernel is written specifically for the GNU C compiler, using some of its extensions. You'd expect that using the Intel compiler would generate many errors and warnings, though this is far from the truth. I did have minor issues with some drivers (especially e1000.h and ftape-bsm.h). However, some of the errors I encountered are due to wrongly coded typedef structures like this:
typedef struct bar_16 {
char xxx[3];
short yyy;
} bar_16_t __attribute__ ((aligned (16)));
Instead, you are supposed to write:
typedef struct bar_16 {
char xxx[3];
short yyy;
} __attribute__ ((aligned (16))) bar_16_t;
The attribute((packed)) is probably nonoperational anyway, as the structs are already packed according to the default rules, but you should fix them in any event. The core kernel compiles without problems but with some warnings that, after inspection, proved to be innocuous. The first indication of compiler quality is the size of the executable. With the GNU C compiler, the kernel configuration resulted in a kernel size of 1,523,441, whereas with the Intel compiler, the same configuration yielded a kernel size of only 1,398,289. That's an efficiency difference of 8.9 percent.
Table 2 presents some benchmark results of the same kernel compiled with GNU C compiler versions and the Intel Pro 7.0 C compiler. (The kernels built by GCC 3.2 were not stable on the Pentium 4, so I used GCC version 3.1.)
As a customary warning/notice for every benchmark I publish, be informed that the benchmark is neither scientific nor audited. You may achieve slightly different results in your environment. The results are an indication rather than an absolute judgment of the quality of any of the compilers used. As usual, your mileage may vary.
In the benchmark, I clocked several key kernel operations.
The benchmark was executed on a 2.4-GHz uniprocessor Pentium. All time measurements are in microseconds.
From Table 2, it is clear that there is indeed some performance advantage in using the Intel compiler. On the other hand, this advantage is nowhere near the 70 percent performance increase as rumored on various web sites. Moreover, the speed difference is too little to make a real impact on everyday tasks such as browsing, OpenOffice, and the like. Considering the admittedly minor problems in compiling the Linux kernel with the Intel compiler, it's probably not worth the effort.