Currently, the market offers a variety of powerful x86 compatible servers and workstations, including modern 64-bit solutions based on AMD64 or Intel Xeon CPUs. To extract maximum performance from these new systems, you need to choose a proven optimizing compiler suitable for your platform. Then, by understanding how to use the compiler, you will be able to accelerate the performance of your applications.

Targeting the hardware

The x86 world has made a long journey from the first 8086 16-bit CPU to the current powerful x64 servers and workstations. While trying to make new systems backward compatible, enhancements were made to every architectural area along the way. This backward compatibility may create the incorrect perception that there is no performance difference in compiling an application for older hardware, rather than for a specific CPU or system. Still, almost every new generation of CPUs provides a new set of unique features to improve application performance. Some of the features work automatically. However, others need to be enabled explicitly in favor of backward compatibility.

Those changes include, but are not limited to, whole new instruction sets, such as the Streaming SIMD Extensions (SSE) that were introduced in Pentium III. A newer version, SSE2, became available in Pentium IV. SSE2 is also available in every AMD Opteron CPU (and in fact the whole AMD K8 family). Later on, SSE3 and the more recent SSE4 instruction sets were introduced. SSE(2-4) supports new integer and floating point registers; and with the advent of AMD64, a 64-bit architecture which extends the available addressable memory and provides access to 64-bit calculations.

A huge amount of work is done in every modern HPC-oriented compiler to allow your application to extract significant performance for a specific architecture. For instance, many compilers include a processor target option and a processor architecture option to obtain the best performance for a particular CPU. To optimize your 64-bit application, you usually need to specify these options during compilation.

Setting optimization levels

Several compiler optimization levels are usually available for the programmer. Use the highest optimization, unless it exposes some significant programming errors in your code.

Besides basic optimization levels, several additional optimization options are usually available, which are less safe or more resource consuming. Use of those options can further improve speed of your application. Many tools conveniently collect a number of powerful and relatively safe optimizations. This is a good first step for getting the best performance out of most applications.

Aliasing

Optimizing C/C++ code is more difficult with extensive use of pointers in your source code. By default, a compiler can only make few assumptions about program's data usage, thus inhibiting many optimizations. Often, an option to set assertions about aliasing (i.e., pointer usage) within the program allows the compiler to be more aggressive in its optimizations.

If you are confident that your program is written without pointer tricks, try to maximize aliasing assertions. Be careful though; the compiler will not warn you if the assumption is wrong. If your program follows the standard ANSI aliasing rules you may expect good result with no correctness problems.

Floating point calculations

If you use a lot of library calls in performance critical program sections, consider using optimized libraries. There are several possible sources of standard optimized code, such as compiler intrinsics or optimized libraries. In most cases, there is a trade-off between increased performance and the loss of both arithmetic exceptions information and errno variable values. For many applications, this is a reasonable trade-off.

If your program includes floating point calculations, you have additional options above and beyond using optimized libraries, such as relaxing floating point precision and runtime exceptions with floating point expressions. Again, in most cases this assumption is reasonable, allowing better optimization of floating point code. However, use of these options may result in some loss of standards conformance for floating-point operations and possible numerical differences.

SSE also includes Single Instruction Multiple Data (SIMD) instructions. These instructions allow the CPU to process several data values concurrently within one operation. Modern compilers are capable of generation SIMD operations by looking for suitable operations and vectorizing them whenever possible. Applications that benefit the most with SIMD instructions are those which perform a large number of floating point calculations.

Memory intensive programs

A lot of modern programs have to deal with large arrays. While CPUs continue to make significant performance leaps, the performance of memory has not kept the same pace. This creates a common problem; a CPU must wait for data from memory, reducing the performance of the application. Such programs are called memory bound (as opposed to CPU bound, where the CPU speed is the bottleneck). This situation is aggravated with SIMD which requires more data to process. Several solutions are available to mitigate against these circumstances.
 
First is prefetching. Memory accesses that fill high-speed cache memory can be done in parallel with computations. The heuristics used to fill the cache in advance are speculative and might not always fetch the data actually needed. In that case, prefetching can degrade performance by pushing needed data out of the cache. In most cases, you can enable the generation of prefetch instructions and regulate how aggressively the compiler generates prefetches through a setting option.

The AMD CPUs implement special 3DNow! instruction extensions, including support for memory write prefetches. Generation of the code for an AMD-only architecture may allow a program to use store prefetches, while making your executable incompatible with non-AMD platforms.

In many situations, memory access performance depends on a program's memory layout. If you use the malloc function in your program, be aware that there are various versions, some which are perform better than others. Determining factors include the use non-thread safe libraries in a single threaded application and the balance of allocation speed, density and alignment (such as libbsdmalloc.so, which is available on Solaris for faster but less dense allocations).

With 64-bit architectures, applications can access more memory than ever and have additional hardware resources, such as more registers and additional instructions. While there are a lot of benefits with 64-bit applications, there are some downsides as well. For example, 64-bit applications are not always faster than 32-bit ones. In 64-bit mode, each pointer has a 64-bit address, even if your program is far from using 4GB of memory. This means your pointers are twice as wide as 32-bit ones. This is not usually a problem unless you have a lot of them, in which case, your program may become slower due to swapping and memory cache misses. If your program uses large arrays of pointers, 32-bit mode can be more efficient.

Flat-profile programs

If your program consists of many small functions, all called frequently (so called flat-profile programs), several optimizations can be done to improve its performance.

The cost of a function call becomes non-trivial in such conditions. Each function normally has a frame pointer, which is a special stack structure that helps to manage the function's data. Without frame pointers, debugging can become more difficult.  On the other hand, if you choose not to use frame pointers you free one general purpose register. Also a shorter prologue can be generated for a function, making its execution faster. Almost any compiler gives you a way not to use frame pointers.

Another way to optimize these types of programs is with the use of inlining and inter-procedural optimizations (IPO). While compilers do inlining by default, their ability to do it depends on function visibility. Optimizations can be much more effective if the compiler has access to the full project source, so it can inline a function called in one source file and define it in another. Function inlining removes time-consuming function calls, replacing them with the code segments within those functions. Thus, use of inter-procedural optimizations can lead to significant performance gains. Many compilers support inter-procedural optimizations.

However, it is not always beneficial to use inter-procedural optimization, since it will increase the code size, possibly creating problems with memory utilization.

Two-stage compilation

The optimization techniques discussed so far are selected by analyzing the source code. Two-stage compilation takes into account the actual program's data to help the compiler make further improvements. If the compiler knows the typical program's data, it can restructure the code to improve performance for default use cases. Some, but not all, modern compilers are able to use this kind of optimization. The possible performance benefits are high, but require additional effort.

To use this optimization you need to provide the compiler with representative data samples. It should be very similar to the actual data that will be used and small enough to keep compilation time reasonable.
For example, with Sun Microsystems’ Sun Studio 11 tool, you can generate a “compiler training run”, compile a program with the same options that you plan to use in production, adding -xprofile=collect:./feedback option. Then, you can run the executable using sample data to get the subdirectory ./feedback.profile. The data collected will be used later for optimization. Now recompile everything with the same options but replacing “collect” with “use”, as in -xprofile=use:./feedback. The compiler will use data from ./feedback.profile to direct its optimizations.

Conclusion

While applications will benefit by running on faster hardware, proper use of compiler technology will have a substantial impact on runtime performance. New instructions, additional registers, and cache characteristics of new architectures, such as AMD Opteron, can be exploited with a step-wise approach based on your application footprint. Understanding how modern compilers can be used will allow users to maximize the performance of your application.

—–

About The Author

Stanislav Mekhanoshin is the team lead of the Sun Studio Opteron Performance team. The team is based at the Sun Saint Petersburg Development Center in Russia. The main goal of the team is to improve the performance of code produced by the Sun Studio compilers for the x86 platform, and especially for Sun's Opteron based systems. Stanislav graduated from Saint-Petersburg State Technological University in 1995 with a masters degree in computer science. Prior to joining Sun, Stanislav worked on various software technologies in Russia — including database, speech recognition, and programming for mobile devices.