An abstract event represents the occurrence of a set of execution events. The motivation for providing measurements at a higher level of abstraction than individual execution events is to decrease the amount of effort needed to understand the behavior of an application.
In predicate profiling [Crovella and LeBlanc1993], parallel overhead during execution is divided into categories that are semantically significant to users. These categories are defined by performance predicates. A performance predicate defines the parallel system state that characterizes the occurrence of the corresponding category. Examples of categories are load imbalance, insufficient parallelism, synchronization, communication, and contention. These categories provide a first level of explanation for performance problems. For example, if the programmer observes that an application is suffering from load imbalance, he can improve the application's performance by choosing a better work distribution strategy. One output of predicate profiling is the total time lost to each of the overhead categories across the execution. Although these measurements facilitate the understanding of parallel programs by dividing the overhead time into categories, they do not give any indication of the location of problems (i.e., source code) and do not isolate implementation decisions that are the causes of performance problems.
Normalized performance indices [Sarukkai et al. 1994] quantify the influence of parallelization overheads, such as communication, load imbalance, and resource utilization. These indices are generated from profile data and simulation. We can use them to locate functions, processors, and data structures that are affecting application performance. They differ from predicate profiling because they also give the location (i.e., source code, processor, and data structure) of the performance problems. Thus, these indices allow observation of performance phenomena at a finer grain than predicate profiling, but still lack support for identifying causes of phenomena.
The Performance Consultant of Paradyn [Miller et al.
1995] identifies and
characterizes performance phenomena automatically using the
Search Model, which tries to abstract the events that can affect the
performance of parallel programs. It addresses three questions: (1)
why is the application performing poorly, (2) where is the
performance problem, and (3) when does the problem occur. The why
question explores the performance phenomena space (e.g., blocked at a
barrier, waiting for a message). The where answer identifies
source-code segments, operations, or processors involved in performance
phenomena. The when answer identifies the execution ``phase'' of the
performance problem. The main difference between Paradyn and the
previous tools is the automated search for performance problems, which
means fewer user requirements in terms of both analysis effort and
system knowledge. Also, the facilities provided for augmenting the
search model make the system more portable and flexible. However, the
user is responsible for finding the reasons behind performance
phenomena, since the inference capabilities of Paradyn only identify
similarities among execution events and groups them in abstract
events.
Abstract events are a more intuitive description of the performance phenomena of parallel applications, which makes the performance understanding task easier. The identification of the exact location of performance phenomena is also helpful. However, these abstract events discard detailed dynamic information, which may be necessary to explain performance phenomena.