What these pages are for

The importance, and difficulty, of this task is evidenced by the large, and growing, number of proposed solutions. As a field of study, parallel performance visualization has developed a huge vocabulary of display types, and tools which implement them. Inevitably, new methods are often described in terms of the old. An understanding of this common vocabulary is therefore important in using existing methods, or in developing new ones.

The breadth of the performance visualization vocabulary, and of the research literature which desribes it, can be a little daunting. So, we put together these pages to provide a convenient, accessable, contemporary introduction to the common language and experience base of parallel performance visualization. Our goals are twofold. First, we wanted this collection to be concise, but broad and detailed enough to be useful. Second, we have compiled a detailed, abstracted bibliography, that provides a rich set of directions for deeper study.

The difficulty arises from the enormous resource space (multiple processors, message pathways, shared memory, etc.) that concurrent systems offer programmers. In any given parallel environment, any computing problem can be solved a number of different ways, by using resources differently. The various solutions, however, will exhibit vastly different performance characteristics. Moreover, a solution that performs well on one architecture may not perform as well on another. Finally, performance may not be resource scalable; a program which runs efficiently on a few processors may perform terribly on a hundred.

These issues significantly complicate writing parallel software that is not only correct, but optimal. A programmer must choreograph a complicated, interactive ballet among resources, to collectively perform the computation in an efficient way.

For all but the simplest parallel programs, this is not an easy task. One way of tackling it is to use an empirical, iterative, tuning approach. A programmer starts with a working, nonoptimal program, and follows the following steps:

1. Run the program, collecting trace data on resource use.
2. Analyze the trace data to identify potential performance- enhancing code improvements.
3. Modify the program source code accordingly, and recompile.

Clearly, programmers want the above steps to be as intuitive and easy, and convergence as rapid, as possible. Achieving these goals is the central idea behind performance analysis and tuning tools.

Currently available tools have had some success. However, the need for better tuning methods is almost universally acknowledged as a significant obstacle to widespread use of parallel computing.

The essentially sequential nature of textual displays poorly suit them to this task. Consequently, most tools rely on visual representations of trace data--graphs, plots, etc. A well conceived visual display takes advantage of human shape- and pattern-recognition abilities to communicate anomalous behavior in a data set.

For performance data, however, finding an effective visualization scheme can be very difficult. To be useful, a visualization must not only indicate the existence of a problem; it must also indicate how to change code to improve performance. Moreover, a good display should be scalable. That is, a display scheme useful for one program should ideally be as useful for a similar program using more resources (longer execution time, greater parallelization).

We do provide brief descriptions of several tuning tools. However, the emphasis is on visualization methods, not particular implementations. We have included tools which, in our opinion, either:

• are widely available, and provide good illustrations of one or more traditional performance visualization methods;
• present some unique, interesting visualization; or
• have important historical significance.

How the documents are organized