Optimizing Open-Source Software for Intel Architectures

Results

The performance runs using the Intel Compiler on IA-32 systems running Linux confirmed a number of our expectations; however, a few results surprised us. The use of stronger inlining with -ip resulted in higher performance over the baseline (8.68 percent) and a larger code size (1.35 percent). Code size was measured as the total size returned by the size command of all executables in the client directory. Surprisingly, the use of -ipo did not result in as great a performance improvement (6.91 percent) than -ip, but did result in larger code size (1.46 percent). The biggest surprise was the combination of -ip and -prof_use, which resulted in less performance than the baseline (-3.31 percent). True to expectation, the combination of -ip and -prof_use resulted in a code size increase of 0.04 percent, which is an improvement over -ip alone. Table 2 summarizes the results of several different option sets on a Pentium 4 desktop system. The best performance was obtained by using -O3 -ip, so we chose to use these two options in our production build. If greater performance was desired, analysis of why -ipo and -prof_use did not increase performance would be the first priority.

Using both GCC and the Intel Compiler, we applied this process to a wider range of platforms, including IA-32. (The performance data has been provided by MySQL AB. The tests were performed using MySQL Version 4.1.12, Intel C++ Compiler 9.0 for Linux, and the GNU C Compiler 3.4.4. The operating system for the Pentium 4 processor-based system was SuSE Linux Enterprise Server 8.2, and hardware specifications were Pentium 4 processor 2.7 GHz, 1-GB RAM, 512-KB L3 cache, Hyper-Threading Technology switched OFF.) We also applied it to Itanium (MySQL version and compiler versions same as above. The operating system for the Itanium 2-based server was Red Hat Enterprise Linux AS 2.1, update 3, and hardware specifications were Itanium 2 processor 1.2 GHz, 1-GB RAM, 6-MB L3 cache.) Other systems included the Intel EM64T. (MySQL version and compiler versions same as above with the following exception, GNU C Compiler 3.2.3. The operating system for the 64-bit Intel Xeon processor-based server was Red Hat Enterprise Linux AS 3, Taroon Update 2, and hardware specifications were 2-way Intel Xeon processor 3.2 GHz, 4-GB RAM, 1-MB L2 cache, Hyper-Threading Technology switched ON.)

The aggressive optimization settings used in each run are summarized by architecture as follows:

• Intel C++ Compiler Aggressive Switches for Pentium 4 processor: -O3 -ip, GNU C Compiler 3.4.4 Aggressive Switches for Pentium 4 processor: -O3 -fomit-frame-pointer -felide-constructors -fno-rtti -fno-exception
• Intel C++ Compiler Aggressive Switches for Itanium 2 processor: -O1, GNU C Compiler 3.4.4 Aggressive Switches for Itanium 2 processor: -O3 -fomit-frame-pointer -felide-constructors -fno-rtti -fno-exception(i)
• Intel C++ Compiler Aggressive Switches for 64-bit Intel Xeon processor: -O3, GNU C Compiler 3.2.3 Aggressive Switches for 64-bit Intel Xeon processor: -O3 -fomit-frame-pointer -felide-constructors -fno-rtti -fno-exception

Figure 2 graphs the total execution time and relative performance gains comparing the various compilers to their default optimization levels. The results show appreciable performance gains over default optimization using the Intel Compiler on IA-32 (6 percent), the Intel Compiler on Itanium (2 percent), and GCC on Itanium (3 percent). Our expectation that greater optimization will lead to a performance increase was met in these cases. We did not go to the detail of extensively verifying that each performance gain was directly caused by a specific optimization. For example, with GCC, -O3 turns on several optimizations above -O2; we didn't try each optimization individually to see which specific optimization led to greater performance. In addition, some of the aggressive optimization settings did not result in significant performance increases, and in one case resulted in lower performance than the baseline optimization. We chose to share these numbers for a very important reason—stronger compiler optimizations do not guarantee better performance in all cases. This stresses the need to understand some level of detail in applying optimization to your application.

[Click image to view at full size]

Figure 2: Total execution time and relative performance gains comparing the various compilers to their default optimization levels.