Requirements for a New System

More than ten years of experience with similar tools gave us a clear set of requirements that our next-generation performance analysis tool should meet.

• 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.