Using breezy, the execution of a pC++ program proceeds in steps. At breakpoint boundaries, the application relinquishes control to the breakpoint executive. The user then interacts with the breakpoint executive through the external breezy interface agent to access the program state. Once finished, the user instructs the executive to continue to the next breakpoint or to the end of the program. During an initial barrier, the executive connects to the interface agent via an Internet domain TCP/IP socket. This method of control allows a user to manipulate the program and its data from any machine that is accessible by the parallel host on which the pC++ application is actually executing.
The breezy interface agent offers a main panel (see Figure 4, left) for controlling program execution and listing currently active collections that are available to be accessed. From this panel, the user has control of when to stop and what data to examine. Currently, to control the program execution, the user can step from each breakpoint to the next, specify a number of breakpoints to skip before again pausing to examine the data, or continue or terminate the parallel application.
To access collection data from the main control panel, the user can specify a particular collection instance of interest by selecting a collection in the control panel where all collections are listed. Collection structure information comes from the program's AST and is access via Sage++. This functionality was easily implemented as a result of breezy's integration in the environment.
For each collection that the user selects, a new window appears, displaying the name of the collection element structure, each field name, the values of each field from the zero-th element of the collection, and the name of the collection (see Figure 4, right). The output is formatted to look like a C++ style declaration. Selecting the Auto Update toggle button causes the data values to be updated with current information at each breakpoint. The remaining two buttons are for viewing raw data and visualizing the data. These last two buttons work in concert with the display of the element structure. Any one of the fields of the displayed structure can be selected with the mouse. This selection specifies which field is to be viewed or visualized. Thus, until a selection is made, the two buttons are disabled.
The user can retrieve raw data from a structure as text, which is put into a scrollable window for viewing. This window contains the automatic update toggle button which works as described above.
The user can also visualize the parallel data retrieved. When a user chooses to visualize a field of a structure, a new window is created (see Figure 5). The user must specify the range of elements to retrieve from the collection instance. Also, the user must select a visualization from a menu of the provided (and user-defined) visualizations. Currently, a list of basic visualizations are supplied: triangle mesh, sphere mesh, color mesh, and cube mesh. After these user specifications, the visualization can be started. Separate processes are spawned from the interface to accomplish the visualizations, and then data is piped into them. The visualization performs the mapping of data to graphical objects, producing a visualization/animation of the collection data (see Figure 6). After starting a visualization, a small interface window remains behind, informing the user about the visualization, and again offering the automatic update toggle button. As in other windows, if this button is selected the visualization will be sent current information at each breakpoint, thus supplying the data for an animation during the execution of the program. Through the global features of , the user can also view the corresponding declarations (in fancy) or the access profiles (in racy) of collection classes that were selected for visualization (see Figure 2).
Figure 6a in Color
Figure 6b in Color
Several improvements will be implemented in the near future. The current prototype lets the user select a visualization from a predefined list. Future versions of breezy will allow a more flexible mapping through a (perhaps graphical) mapping specification. We also plan to enhance the breakpoint executive to allow access to the profile and trace data buffers, and automatically update the racy and easy displays during runtime, thus allowing for on-line performance analysis. We are also involved in another project which has developed a new visualization prototyping environment called POPEYE (Parallel prOgram and Performance displaY Environment). POPEYE is an external performance tool that interacts with through profile and trace data capable of creating sophisticated, multi-dimensional visualizations. Some example views are shown in Figure 7. We are working on reusing the POPEYE tools as visualization backends for breezy. More details about POPEYE can be found in .
Figure 7a in Color
Figure 7b in Color
Another enhancement we plan on soon implementing is allowing users to provide custom access functions in their parallel data structures, accessible through the breakpoint executive. In this way, the user can perform some preliminary analysis, grouping, and filtering of the data before it is sent over the socket connection, possibly saving costly network communication overhead. Another benefit of customizing data retrieval is the fact that it can be tailored for specific visualizations also provided by the user. Also, the customized access functions could modify the data itself, providing the basis for computational steering.