Online Mode of Operation: Example 1

Table of Contents

• Example 1
  • Table of Contents
  • Simple example scenario 1 to show command usage
  • More detailed example scenario 1 to show command usage

Simple example scenario 1 to show command usage

• Simple list of the commands for the scenario that will load an executable on host1, create a pcsampling experiment for ranks 2 and 5 and start the experiment running:

• Now we want to stop the application and change the sampling rate

• Now stop the experiment and view the results

• Terminate the performance analysis session.

More detailed example scenario 1 to show command usage

This scenario is the same as the simple scenario 1 above but this one has more comments interspersed between the commands. It has a bit more information about what is going on under the hood.

#User launches Open|SpeedShop tool from a window. The CLI tool will come up first and then if the GUI option is not turned off the GUI will launch.
#The GUI will send low level commands such as:

# create an experiment to do pcsampling of the executable named a.out on host1

# expCreate will cause the initial default values of the specified experiment to be instantiated and the proper collector to be associated with the newly created experiment. The "1" below the command is the <expId> for the new pcsamp experiment.

# expCreate also will "under the hood" poll the Framework to give us a list of the ranks, processes, and threads associated with a.out that are currently known to the FrameWork. expCreate will create a thread group including all the ranks, processes, and/or threads from the Application Object and associate the new thread group with the experiment that has just been created.

# list -v pids will list the ranks, processes, and threads on the specified list of hosts.

# The GUI presents the user a panel from which he/she chooses which ranks, processes, and/or threads he/she wants included in the experiment. The GUI sends down expAttach commands to add them to the thread group or expDetach to subtract them from the thread group that will be operated on by the experiment. Naturally if the user wants to operate on all the ranks, processes, and/or threads no additional commands to select or deselect are necessary.

# In this example scenario we only want to look at ranks 2 and 5, so we can use the expDetach command to remove all the ranks in the thread group associated with this experiment.

# Now we use the expAttach command to add the ranks 2 and 5 into the thread group.

# An alternative would have been to specify the ranks on the original expCreate command:

# list -v params retrieves the list of parameters that may be changed by the user. The GUI and CLI tools need to display this to the user in order for the user to have the option of tuning the experiment to their specific needs.

# We assume the user did not change the parameters in this part of the scenario because no expSetParam command is created.

# list -v exp lists the active experiments to the screen

# expSetParam defines arguments for the specified experiment. Here the "-x 1"" indicates the experiment identifier, however we can omit this argument as the tool will have a concept of default experiment. The experiment identifier is created by expCreate. The identifier created becomes the default current experiment. So commands following the expCreate will default to using the current experiment identifier as their experiment.

# For the expSetParam the expId is optional because the default focused experiment was set to "-x 1" by the expCreate command.

# Run the application and the performance data collection utilities. experiment was created this command will also cause the instrumentation to be inserted into the application e.g. instruments the thread group. (the set of ranks, processes, and/or threads that are associated with the experiment). The experiment is starts the gathering of performance data as the application is started running.

• Now we want to stop the application and change the sampling rate

# We use the expPause command to halt/pause the performance data collection and the application.

# Here we use expSetParam to replace the existing sampling rate for experiment "-x 1" with the new value.

# We must do an expGo here to restart the application and to reengage the gathering of performance data.

# The list -v exp command is presented here, only to show the it can be used at any point in a sequence to give experiment data back to the GUI or the CLI tools.

• Now stop the experiment and view the results.

# We use the expPause command to stop the application. The focused experiemnt is "-x 1", so it does not need to specified in the command.

# The possible report types for this experiment are obtained. The GUI may want to present the user with a list of available views for this experiment (.e.g. in a menu item list. ).

# expView causes much processing behind the scenes. This command is asking for the data to create a top "n" display and will open a gui window to display the result.

• Terminate the performance analysis session.

# Close Open|SpeedShop. The data that was collected for the experiment is discarded, the executable modules that were attached to the experiment are terminated and all memory is reclaimed by the system.