Intel's C++ v5 Compilers for Linux and Windows smoke GNU C and MS Visual C++ in number crunching benchmarks.

Very few technologies excite the dyed-in-the-wool techie as much as a new compiler. There’s something very heady about the feeling that your code is driving the hardware to new heights. Add to that the thought of all that technological power behind the deceptively simple “build” button or “make” command. Whatever the motivation, there is no doubt that technology thrill seekers will marvel at the new Intel C/C++ compiler. And for serious old-line number crunching applications, Intel has a Fortran compiler which employs the same optimization techniques.

On a more prosaic plane, Linux ISVs whose software products are computationally intense, such as 3D graphics rendering, will garner an enormous efficiency boost in performance on both single and multiprocessor systems. Performance improvements of the order of 30% or more are naturally of a high order of importance. When they come with a simple recompile they can be a godsend.

The new Intel compiler suite answers a lot of our questions. For the highly technical Open Source development community it does raise a modest issue: This compiler itself is not Open Source. This compiler is the fruit of a great deal of work conducted at the Intel Microcomputer Software Labs, along with two prestigious companies recently acquired by Intel: Kuch and Associates. Nonetheless, the magnitude of the performance differential in numerically intense applications is such that only the most dramatic sort of improvement in the long-awaited version 3 of the GNU C/C++ compiler—a "beta" of v3 is included with the SuSE 7.3 distribution, but gcc v2.95 is installed by default—will stay the hammer that drives a stake through the fibrillating heart of the aging technology behind the GNU C compiler. May it rest in peace.

Target specific object code and executable file format notwithstanding, what really makes the Intel compiler so very interesting is the fact that it delivers the same instruction sequences on both Linux and Windows platforms. The differences in performance across the two operating system platforms are thus precisely that: differences in the operating systems. That includes, to some degree, the file formats, as well as the image activation, scheduling and interrupt interference of the individual operating systems. As a result, the new Intel compiler affords a unique opportunity to discover the baseline performance of the raw systems hardware with superbly optimized code, and to discover the relative performance differences between Linux and Windows in terms of the performance they can deliver from the same hardware.

In essence, the Intel compiler attempts to maximally exploit the 128-bit Streaming Single-Instruction-Multiple-Data (SIMD) extensions on packed integers and floating point numbers, which enable fine-grained code parallelization, found in the Pentium III and Pentium 4 CPUs. These instructions were introduced on Pentium III CPUs to provide floating point operations on 4 single-precision floating-point numbers and access to the 64-bit integer technology of MMX. This is extended in the he Pentium 4 with support for floating-point operations on two double-precision floating-point numbers and 128-bit integer technology in MMX.

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. What’s more, the majority of scientific, engineering, and multimedia applications easily take advantage of these streaming SIMD extensions. These programs are characterized by a control flow that is data independent, regular and re-occurring memory access patterns, and localized reoccurring operations performed on the data.

The Intel compilers magically do all of this work to exploit the implicit parallelism of any application’s source code in the background as they analyze the original source code, restructure the code, and finally translate the restructured code into SIMD instructions. In the program analysis phase, the compiler performs a series of progressively more complex tests to route out all data dependence problems. The restructuring phase then focuses on converting the input program through traditional techniques such as idiom recognition, loop interchange and loop distribution into a form that is more amenable to the Pentium III and Pentium 4 CPUs.

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 C++/Fortran compiler is to examine all the operations in the loop body and estimate the grain-size per-loop iteration on the targeted microarchitecture to estimate of the total workload of the loop and determine if the loop should be parallelized.

The alternative to all of this compiler wizardry is to explicitly exploit an application’s parallelism at the source code level, which is a cumbersome and error-prone task. More importantly, it is a very expensive task in that it greatly complicates program development and maintenance. Manually rolling your own parallel code requires the use of inline assembly to generate SIMD instructions, considerable understanding of thread libraries, and a considerable understanding of the application on a macro scale.

Once the compiler is installed, a juggle then ensues getting the script variables pointed at the correct directory for the binaries and the license data files. At this point, we encountered a bug in the Linux initialization script that was shipped with the compiler kit. Intel’s professional support identified the bug quickly and shipped a replacement script file in short order.

In order to have the compiler available at the command line for a user, one must manually edit the login scripts to define the script variables, and include the path to the compiler binaries. With that accomplished, there is almost parity between the icc—the Intel compiler is generally invoked with the ‘icc’ command—and the gcc compiler at the command line. A quick edit of the makefile yields the recompiled code after a ’clean’ of the application binary target directory and a new ‘make’.

At this point, it’s also important to note that the Intel compiler on both platforms is a little more pedantic than the default settings for either the GNU or the Microsoft compilers. Marginal error conditions that are dismissed by the other compilers are reported as warning level issues by the Intel compiler.

Having compiled and tested all four executables on our development system, we next distributed the four executables to our primary test bed: an HP Omnibook 6000 running Windows XP Professional, SuSE Linux 7.3. As with the installation of the compilers, program distribution is a bit more complex on Linux. Along with the Linux executables, you’ll need to distribute the Intel run-time library, which you are completely free to do under the Intel license. So before running the Intel-compiled benchmarks, we had to drop two library modules in the /lib directory.