V6 of Intel's C/C++ Compiler crushes MS .NET and KAPs it off by automatically generating parallel code.

This is the year when the pundits proclaim Java will surpass C as the most popular programming language. Perhaps. but in the meantime, Intel is making the performance issues between C and Java even more difficult to sidestep. With the release of version 6.0 of the Intel C/C++ compilers for Linux and Windows, C and C++ on Linux become a number-crunching forces which cannot be ignored. For IT managers still insisting that hefty license fees are a mark of software quality, the day of reckoning has arrived.

Back in January OpenBench Labs tested version 5.0 of Intel's C/C++ compilers for Linux and Windows. The results were nothing short of spectacular. On SuSE 7.3, the geometric mean performance for our 34 kernels soared by 47% over the version compiled with gcc 2.95. In particular, 30 kernels were dramatically faster when compiled with the Intel C/C++ compiler; 3 kernels were marginally slower; and only 1 of the 34 kernels was significantly slower with the Intel compiler. For ISVs whose software products are computationally intense, such as 3D graphics rendering, a performance improvement of the order of 30% or more is naturally of a high order of importance. When it comes with a simple recompile, then it's a godsend.

In the intervening months, the Intel compilers have begun to gather a lot of serious interest among developers. Microsoft has launched its .Net development tools. And the version 3 GNU C compiler has moved much closer to the mainstream, albeit SuSE version 8 still considers version 3.0.4 as "experimental."

With Intel's release of version 6.0 of their compilers this month, OpenBench Labs deemed it worth revisiting the performance issues among the three major C/C++ compilers: GNU, Intel and Microsoft.

Given the initial performance lead Intel demonstrated with v5, the goal for v6 was complete compatibility with GNU C. A perfect 10 for Intel was to enable the building of the Linux kernel with the Intel compiler. It looks like they scored about 9.2. Using some unpublished workarounds, Intel has been able to internally build a stable kernel. The rest of us will have to wait for the next release.

Nonetheless, v6 of the Intel C compiler has added substantial compatibility features with the GNU C compiler. These features include support for GNU inline assembly support on IA-32, GNU C language extensions, binary compatibility with GNU  C object files, and the use of the glibc library. Like the GNU C compiler, the Intel compiler supports the evolving C++ ABI. When fully implemented by all compiler vendors, this ABI should allow C++ objects files and libraries to be compatible across different compilers.

For the Intel C/C++ compiler the -O3 automatic optimization switch provides for loop unrolling similar to the -funroll-loops switch for gcc. Loop unrolling reduces the number of iterations in a loop by replicating the code within a loop. While creating a larger executable image, loop replication significantly reduces overhead with large numbers of iterations.

As a simple example, consider the initialization of an array of 1,000 numbers to a constant value. For a developer, the simple thing to do is repeat the assignment 1,000 times. Better for the computer is to assign the constant value to two numbers in the array for 500 times. Using just the -O3 switch on Intel gave us the exact same performance on Linux as Visual Studio .Net provided on Windows 2000 Server: a 36% performance improvement over gcc 3.0.4.

The next big jump in performance came from data prefetching, which is activated by the -O3 switch and vectorization, which for P-III processors is turned on by the -xK switch. Data prefetching reduces memory latency and improves application performance by intelligently putting data in cache before the program requires it. These instructions overlap memory accesses with other computations.

  Vectorization detects patterns of sequential data accesses by the same instruction, and transforms the code for Single Instruction Multiple Data (SIMD) execution. The Intel compiler attempts to maximally exploit the 128-bit SIMD extensions on packed integers and floating point numbers, which enable fine-grained code parallelization, found in the Pentium III and Pentium 4 CPUs.

To do this, the Intel compilers use a number of esoteric optimization technologies, such as alignment optimizations and advanced instruction selection in order to vectorize instruction loops that perform a single operation on multiple elements in a data set. The Intel compiler performs a series of progressively more complex tests to route out all data dependence problems during the analysis phase of compilation. It then restructures the code and translates the restructured code into SIMD instructions.

While these restructuring techniques have been around for some time, parallelizing a loop can result in slower execution if the overhead of dispatching threads, scheduling those threads, and sharing resources is significant compared to the total workload performed by the loop. As a result, the most important job of the Intel compiler is to examine all the operations in the loop body and estimate the grain-size per-loop iteration on the targeted CPU microarchitecture to estimate the total workload of the loop and determine if the loop should be parallelized.

The final step, which added about 7% more performance and brought our 600MHz workstation to a 162 LPI, was to introduce interprocedural optimization via the -ip switch. Interprocedural optimization improves performance in programs that frequently call small or medium-sized functions. It can be especially beneficial when those functions are called within loops. The idea is to reduce call overhead by "inlining" the functions code—i.e., directly adding the code at the location of the call and eliminating the call. This eliminates setting up parameters for a call as well as the branch itself.

Often such interprocedural optimization becomes quite complex, especially with large programs with a plethora of logic branches. Nonetheless, it is often the case that many of the logic branches are seldom if ever taken. Needless to say this discussion has little connection with benchmarks which are written to deliberately always execute in the exact same manner. For programs that are highly dependent on data to define how the logic executes, Intel provides a Profile-Guided Optimization (PGO). The PGO process involves two compilation steps separated by a learning period during which the program is executed several times to produce runtime profiles.

After generating a number of profiles the program is recompiled with the profiles used to give hints to the compiler about how to optimize the code. It came as no surprise to any of us when our invariant runtime profiles simply replicated the results of our manually directed optimization commands.

In our final set of tests, we moved our benchmark program onto an HP NetServer LP 1000r. This server has dual 1.26 GHz Tualatin P-III processors. These hot CPUs sport a .13-micron design core in contrast to the .18-micron Coppermine design and feature a 512KB Level 2 cache on the chip. Given the Tualatin's larger cache along with the compiler's microarchitecture-specific switches for exploiting parallelization and prefetching (-xK) at the chip level, we expected to see a performance level slightly greater than what the 2X that clock speed alone would project. We were not disappointed.