Scalasca  (Scalasca 2.6, revision 748ac9e9)
Scalable Performance Analysis of Large-Scale Applications
Runtime measurement collection & analysis

While applications instrumented by Score-P can be executed directly with a measurement configuration defined via environment variables, the scalasca -analyze (or short scan) convenience command provided by Scalasca can be used to control certain aspects of the Score-P measurement environment during the execution of the target application. To produce a performance measurement using an instrumented executable, the target application execution command is prefixed with the scalasca -analyze (or short scan) command:

  $ scalasca -analyze [options] \
             [<launch_cmd> [<launch_flags>]] <target> [<target_args>]

For pure MPI or hybrid MPI+OpenMP/Pthreads applications, launch_cmd is typically the MPI execution command such as mpirun or mpiexec, with launch_flags being the corresponding command-line arguments as used for uninstrumented runs, for example, to specify the number of compute nodes or MPI ranks. For non-MPI (i.e., serial and pure multi-threaded) applications, the launch command and flags can usually be omitted.

In case of the example MPI application executable myapp introduced in the previous section, a measurement command starting the application with four MPI ranks could therefore be:

  $ scalasca -analyze  mpiexec -n 4 ./myapp
Attention
A unique directory is used for each measurement experiment, which (by default) must not already exist when measurement starts: otherwise measurement is aborted immediately.

A default name for the experiment directory is composed of the prefix "scorep_", the target application executable name, the run configuration (e.g., number of MPI ranks and/or OpenMP threads), and a few other parameters of the measurement configuration. For example, a measurement of the myapp application as outlined above will produce a measurement experiment directory named "scorep_myapp_4_sum".

Note
A number of settings regarding the measurement configuration can be specified in different ways. See the scan command reference in Section scan – Scalasca measurement collection and analysis nexus for details and available configuration options.

When measurement has completed, the measurement experiment directory contains various log files and one or more analysis reports. By default, runtime summarization is used to provide a summary report of the number of visits and time spent on each callpath by each process/thread, as well as hardware counter metrics (if configured). For MPI or hybrid MPI+OpenMP/Pthreads applications, MPI message statistics are also included.

Event trace data can also be collected as part of a measurement. This measurement mode can be enabled by passing the -t option to the scalasca -analyze command (or alternatively by setting the environment variable SCOREP_ENABLE_TRACING to either "1", "true", or "yes").

Note
Enabling event trace collection does not automatically turn off summarization mode (i.e., both a summary profile and event traces are collected). It has to be explicitly disabled when this behavior is undesired.

When collecting a trace measurement, experiment trace analysis is automatically initiated after measurement is complete to quantify wait states that cannot be detected with runtime summarization, to determine their root causes, and to identify the critical path of the application. In addition to examining the trace-analysis report, the generated event traces can also be visualized with a third-party graphical trace browser such as Vampir [9].

Warning
Traces can easily become extremely large and unwieldy, and uncoordinated intermediate trace buffer flushes may result in cascades of distortion, which renders such traces to be of little value. It is therefore extremely important to set up an adequate measurement configuration before initiating trace collection and analysis! Please see Section Optimizing the measurement configuration as well as the Score-P User Manual [17] for more details on how to set up a filtering file and adjust Score-P's internal memory management.


Scalasca    Copyright © 1998–2021 Forschungszentrum Jülich GmbH, Jülich Supercomputing Centre
Copyright © 2009–2015 German Research School for Simulation Sciences GmbH, Laboratory for Parallel Programming