A Methodology to Characterize Critical Section Bottlenecks in DSM Multiprocessors

Abstract

Understanding and optimizing the synchronization operations of parallel programs in distributed shared memory multiprocessors (dsm), is one of the most important factors leading to significant reductions in execution time. This paper introduces a new methodology for tuning performance of parallel programs. We focus on the critical sections used to assure exclusive access to critical resources and data structures, proposing a specific dynamic characterization of every critical section in order to a) measure the lock contention, b) measure the degree of data sharing in consecutive executions, and c) break down the execution time, reflecting the different overheads that can appear. All the required measurements are taken using a multiprocessor simulator with a detailed timing model of the processor and memory system. We propose also a static classification of critical sections that takes into account how locks are associated with their protected data. The dynamic characterization and the static classification are correlated to identify key critical sections and infer code optimization opportunities (e.g. data layout), which when applied can lead to significant reductions in execution time (up to 33 % in the SPLASH-2 scientific benchmark suite). By using the simulator we can also evaluate whether the performance of the applied code optimizations is sensitive to common hardware optimizations or not.

Critical lock analysis: Diagnosing critical section bottlenecks in multithreaded applications

“…Previous methods [6,7,18,20,23,26] mainly use the metric of idleness caused by lock contention to analyze critical section bottlenecks. While quantifying idleness is generally useful, it fails to establish the impact of critical section bottlenecks on the overall performance.…”

“…6 we show the results in a 4-thread scenario. The second and third columns represent the results provided by our method and previous methods [6,7,18,20,23,26], respectively: CP Time means the fraction of the critical path time that the hot critical sections protected by a critical lock accounts for; Wait Time means the average fraction of time each thread spent on waiting for the lock. In other words, CP Time belongs to TYPE 1 and represents the total hold time of a critical lock on the critical path, whereas Wait Time belongs to TYPE 2 and represents the average wait time of all the invocations of a lock (including both critical lock and normal lock).…”

“…The first type of statistics (TYPE 1) is based on our critical lock analysis, which includes information for each critical lock such as the fraction of critical path time that a hot critical section accounts for, and the contention probability of a critical lock (along the critical path). The second type of statistics (TYPE 2) is provided for each lock (which can either be a critical lock or a normal lock) in the same way as used by previous approaches [6,7,18,20,23,26] which do not take the critical path into account. More specifically, it provides information such as wait time, hold time, and contention probability of each lock.…”

“…Previous critical section bottleneck analysis methods [6,7,18,20,23,26] mainly focus on quantifying the idleness caused by lock contention and do not take the critical path into account. For example, these methods would indicate L4 in Fig.1 as the most important critical section bottleneck since it introduces the longest idle time.…”

“…Approaches taken in these methods encompass quantifying the idleness caused by locks [6,7,23,26], exploiting the potential parallelism of critical sections [18] or characterizing data sharing inside critical sections [20]. While these approaches quantify the execution overhead of critical sections in isolation, they do not consider what impact critical sections have on the completion time of multithreaded applications by taking the critical execution path [14] into account.…”