Visualizing Concurrent Programs
Understanding parallel programs is hard, and parallel program visualization
often proves to be even more difficult. Many visualization systems provide
visually/aesthetically appealing views, but are often less useful. In his
paper, Miller presents a number of guidelines for alleviating these problems,
and making visualization an effective tool for program understanding and
presentation.
Why is visualization difficult?
It is often easier to draw a pretty picture than a useful one. A comment we
often hear is: ``that looks really neat, what does it mean?'' We must
strive to make visualizations more intuitive and easy to comprehend, rather
than spending a lot of effort on making complex but aesthetically
appealing visualizations. Creators of program visualizations are faced with
two major problems:
- In order to visualize a system, a good model of the system is required.
- Once a model has been constructed, means of visualizing the model need
to be invented.
Good models for programming constructs are hard to create, mainly because we
cannot appeal to the existence of real, physical models and concepts, but must
rather derive meaningful models from artificial constructs. Invariably,
mental models differ from person to person, and mappings from abstract to
concrete that are intuitive to one person, may have little or no meaning to
others.
Comment: This is a common problem that the user interface community
has thoroughly investigated. Concepts such as ``consistency,''
``affordances,'' and ``metaphors'' seem applicable in software
visualization as well.
Miller fails to point out why visualization of parallel programs is
innately a harder task than designing visualizations for sequential
programs. To remedy this, I here provide a list of reasons of my own (note
that this list is far from comprehensive):
- Complex interaction and behavior.
- It is often hard to replicate the execution order of a parallel
program.
- Visualization overhead.
- The visualization and/or information gathering may seriously
perturb the order of events in a parallel program.
- Difficulties in user interaction with parallel programs.
- On-line debugging requires the need to set breakpoints and single step
through a (potentially) heterogeneous environment. The visualization
must often be synchronized over several processes.
- Multiple and potentially inconsistent states, as well as
missing state information.
- In distributed memory architectures, several inconsistent copies of
the same data may reside in different memory modules. Interprocess
messages, constituting part of the system state, may in some
circumstances not be readily accessed.
- Diversity of programming and architectural paradigms.
- Examples include shared vs. distributed memory; concurrent vs.
parallel vs. distributed computing; underlying topology;
communication protocols, e.g. sockets, RPC, MPI, PVM, etc.;
levels of threading, e.g. user, kernel, and heavy weight processes.
- Increase in information volume, and scalability concerns.
- More information leads to less screen real-estate available.
Criteria for making good visualization
Miller lists the following guidelines for visualization design:
- Visualizations should guide, not rationalize.
- The visualization should convey information that is not already known,
without requiring the user to manipulate the model and the parameters
associated with the visualization.
Comment: Miller fails to distinguish between the visualization
tool and the image/animation associated with the visualization.
For example, the tool may be excellent, but the input data may
have no intrinsic value. Conversely, the tool may be very awkward
to use, but with enough interaction, a very informative view can
be produced. While the tool should promote informative views,
the ultimate merit of the visualization lies in the information
conveyed.
- Visualizations should be appropriate to your programming model.
- Visualize the high level constructs and operations that best describe
the interesting (and explicitly declared) parts of the program.
- Scalability is crucial.
- To the greatest extent possible, eliminate limitations on the amount
of information that can be presented, while providing the most
effective presentation of the given data with minimal user interaction.
- Color should inform, not entertain.
- Use colors sparingly, and only to: increase information density,
highlight important features, or aid in identification.
Guarantee color consistency between different views.
- A visualization should be interactive.
- Do not explore multiple dimensions in the same view. Rather, provide
several views, one for each dimension (spatial, level of detail,
type of performance data), that can be selected and manipulated by
the user.
- Visualizations should provide meaningful labels.
- Always provide access to labels for axes and data types.
- Default visualizations should provide useful information.
- Limit the complexity of the default views, while still providing
sufficient visual feedback for the user to extract useful information.
- Avoid the ``watchmaker's fascination''.
- Do not make visualizations overly complex and detailed. Unless
otherwise justified, visualize the high level aspects of the
program. To satisfy expert users without confusing novices, make
available--but hide--complex visualizations.
- Visualization controls should be simple.
- Use good interface design, and limit the number of parameters that
control a view. Eliminate parameter configurations that are not
useful.
Question: The title of the paper implies that the criteria for making
good visualizations are chiefly concerned with parallel programs.
However, few of these criteria are specific to parallel programs, and
do equally apply to serial programs. What concerns arise when
visualizing parallel programs that are not inherent in serial program
visualizations? Also, what sequential programming visualization concepts
are applicable in parallel program visualization?
Visualizing the Performance of Parallel Programs
Michael T. Heath and Jennifer A. Etheridge
In this paper, the authors describe the ``ParaGraph'' system--a
tool for displaying performance data gathered from executions of message
passing parallel programs. ParaGraph allows the user to visualize a large
number of important features ranging from load balancing and processor
utilization, interprocess communication performance and process/message
graphs, to task decomposition. For off-line collection of real-time
performance data, ParaGraph relies on the Portable Instrumented
Communication Library (PICL), which facilitates generation of trace
files without requiring the programmer to annotate the source code. The
software was developed by undergraduate students at Oak Ridge National
Laboratory.
ParaGraph design goals
The three primary design goals of ParaGraph are summarized below:
- Easy to understand.
- The views should be aesthetically appealing and self-evident. Use of
colors should aid in identification of objects, and should be
consistent across views.
- Easy to use.
- Use of menus and conventional GUI concepts should promote simplicity.
Little or no annotation of source code should be required.
- Portability.
- By basing ParaGraph on X windows and PICL, it should run on
virtually all Unix workstations. Support for monochrome displays
should be available to allow visualization on such devices, and
should also aid in producing hardcopy snapshots of the views.
Overview
One of the key features of ParaGraph is its (or rather PICL's) ability to
collect real-time data, and later allow the user to examine this data in depth
from several different perspectives. This is accomplished by telling PICL to
buffer all important execution events in memory, which are then written to a
trace file. In this way, profiling overhead is minimized so that serious
perturbations in the actual execution can be avoided. In addition to keeping
the overhead small, PICL goes to great lengths to ensure that the time stamped
events are synchronized across processors. The trace files are read by
ParaGraph, and the user is given the option to replay the execution off-line,
thereby ensuring that the order of events is the same each time the execution
is played back. The execution can be played back continuously, allowing the
user to pause and resume the animation, or the user may single step through
the execution one event at a time.
Comment: The lack of speed control for the animation, as well as long
response times when pausing the animation make ParaGraph cumbersome to use
at times. In addition, there is no provision for reverse execution which
could easily have been incorporated.
ParaGraph features nearly 30 different performance views, and allows the
user to link in customized views. The views are invoked from a set of menus
that are organized as follows:
- Utilization views.
- These views show instantaneous, cumulative, and time varying processor
utilization statistics. Some views display information for each
individual process(or), while others show the aggregate performance.
The time varying views scroll and let the user view the history of
the execution.
- Communication views.
- Network traffic, node-to-node connections, congestion and bottlenecks,
and message queue saturation can be derived from these views. Some
of these views graphically show the source and destination processes
of each message, while others are concerned with the load of messages
that are queued up and yet to be handled by the destination process.
Approximately 20 different predefined topologies can be visualized.
- Task views.
- By annotating the source code, the program can be broken down and
represented as a number of smaller tasks. The beginning and
completion of these tasks can be visualized, as well as their
distribution over the processor set.
- Miscellaneous views.
- Phase diagrams, critical paths, and application-specific views fall
in this category. The extensibility of ParaGraph allows the programmer
to add additional views.
Note that many of the views in ParaGraph are redundant and display the
same data from different perspectives. This allows the user to select a view
that most appropriately displays a certain characteristic of the execution.
Comment: While ParaGraph supports animation to some extent (whether its
dynamic views are ``animated'' is even debatable), it by no means supports
algorithm animation, contrary to the authors' claim. The trace files
simply contain no semantic information, and from watching the views, one
cannot infer what the algorithm associated with the performance data is.
Question: It is not immediately clear whether ParaGraph visualizes
performance data for each processor as opposed to each process.
Certain views as well as comments made in the paper suggest the former,
however. How could ParaGraph be extended to support both? It is certainly
conceivable to run a large number of message passing processes on a
uniprocessor machine, and the portable communication protocols of today
(e.g. MPI and PVM) allow process distribution decisions to be made rather
arbitrarily, as well as independent of the underlying architecture. A good
visualizer should handle arbitrary process mappings, as well as varying
process granularities (i.e. both light and heavy weight processes).