Next: Using Jumpshot
More than ten years of experience with similar tools gave us a clear
set of requirements that our next-generation performance analysis tool should
- It is expected to have a long lifetime and to be the foundation for our
future research in performance analysis. It should therefore be implemented
in a stable and widely supported programming environment.
- The tool must be portable to all the types of workstations that parallel
programmers would want to use. Although the use of X made previous tools
portable within the Unix universe, portability to Microsoft-based
environments is now required.
- It must be able to deal with large logfiles in a scalable way. While
filtering of very large logfiles can be expected to take place
either within the application program itself or in an intermediate
preprocessing step, in order to be a practical tool, performance needs to
be maintained in the presence of many thousands of graphical objects being
displayed, zoomed, and scrolled.
- The display package (the Jumpshot part) must not be too tightly
integrated with the logging package (the CLOG part), for the sake of
flexibility within each.
- Support for nested and overlapping states is needed, although nested
states occur far more often than overlapping ones, because of the
natural nesting of subroutine calls in programs.
- Support for MPI concepts, such as communicators, is required. At the
same time, it is overly restrictive to tie the tool to the message-passing
model of parallel computation.
- It must be relatively easy to manipulate the display, turning specific
states on and off, changing colors, and so forth.
- The ability to create printable versions of displays is crucial, for
inclusion in documents.
- A desirable feature is to help the user find the ``interesting'' parts
of what might be a large and confusing display. This is a research topic we
are only beginning to explore.
- Multiple types of display are useful for looking at the behavior of a
program from many points of view:
- process timelines with zooming and scrolling
- histograms of state durations and message data
- ``mountain ranges'' for aggregating state data
- It must be possible for the user to define states that are meaningful in
the context of the application, not just the system.
- It must be possible to query specific states and events for details.
- The logfile format needs to be flexible, to account for unanticipated
types of events and states, summary data, and entirely new concepts.
- It is desirable that an event can be connected back to the source code
that generated it.
Jumpshot currently makes some compromises in attempting to meet these
requirements. These compromises are expected to be temporary.
Next: Using Jumpshot