|C H A P T E R 7|
Once you have a correct, working OpenMP program, it is worth considering its overall performance. There are some general techniques that you can utilize to improve the efficiency and scalability of an OpenMP application, as well as techniques specific to the Sun platforms. These are discussed briefly here.
For additional information, see Techniques for Optimizing Applications: High Performance Computing, by Rajat Garg and Ilya Sharapov, which is available from http://www.sun.com/books/catalog/garg.xml
Also, visit the Sun Developer portal for occasional articles and case studies regarding performance analysis and optimization of OpenMP applications, at http://developers.sun.com/prodtech/cc/.
The following are some general techniques for improving performance of OpenMP applications.
Careless use of shared memory structures with OpenMP applications can result in poor performance and limited scalability. Multiple processors updating adjacent shared data in memory can result in excessive traffic on the multiprocessor interconnect and, in effect, cause serialization of computations.
Most high performance processors, such as UltraSPARC III, insert a cache buffer between slow memory and the high speed registers of the CPU. Accessing a memory location causes a slice of actual memory (a cache line) containing the memory location requested to be copied into the cache. Subsequent references to the same memory location or those around it can probably be satisfied out of the cache until the system determines it is necessary to maintain the coherency between cache and memory and restore the cache line back to memory.
However, simultaneous updates of individual elements in the same cache line coming from different processors invalidates entire cache lines, even though these updates are logically independent of each other. Each update of an individual element of a cache line marks the line as invalid. Other processors accessing a different element in the same line see the line marked as invalid. They are forced to fetch a fresh copy of the line from memory, even though the element accessed has not been modified. This is because cache coherency is maintained on a cache-line basis, and not for individual elements. As a result there will be an increase in interconnect traffic and overhead. Also, while the cache-line update is in progress, access to the elements in the line is inhibited.
This situation is called false sharing, and could be a significant cause of poor performance and scalability in OpenMP applications.
False sharing degrades performance when all of the following conditions occur.
Note that shared data that is read-only in a loop does not lead to false sharing.
Careful analysis of those parallel loops that play a major part in the execution of an application can reveal performance scalability problems caused by false sharing. In general, false sharing can be reduced by
Starting with the Solaris 9 release, the operating system provides scalability and high performance for the SunFire systems. New features introduced with Solaris 9 OS that improve the performance of OpenMP programs without hardware upgrades are Memory Placement Optimizations (MPO) and Multiple Page Size Support (MPSS), among others.
MPO allows the OS to allocate pages close to the processors that access those pages. SunFire 6800, SunFire 15K, and SunFire E25K systems have different memory latencies within the same UniBoard versus between different UniBoards. The default MPO policy, called first-touch, allocates memory on the UniBoard containing the processor that first touches the memory. The first-touch policy can greatly improve the performance of applications where data accesses are made mostly to the memory local to each processor with first-touch placement. Compared to a random memory placement policy where the memory is evenly distributed throughout the system, the memory latencies for applications can be lowered and the bandwidth increased, leading to higher performance.
MPSS allows a program to use different page sizes for different regions of virtual memory. The default page size for Solaris 9 OS is 8KB. With the 8KB page size, applications that use large memory can have a lot of TLB misses, since the number of TLB entries on UltraSPARC III Cu and UltraSPARC IV allow accesses to only a few megabytes of memory. UltraSPARC III Cu and UltraSPARC IV support four different page sizes: 8 KB, 64 KB, 512 KB, and 4MB. With MPSS, user processes can request one of these four page sizes. Thus MPSS can significantly reduce the number of TLB misses and lead to improved performance for applications that use a large amount of memory.