Score-P
| Software | |
|---|---|
| Name: | Score-P
|
| Provider: | Score-P Development Team |
| License: | Open Source, BSD-like |
| Homepage: | https://score-p.org |
| E-Mail: | support@score-p.org |
| Concurrency: | parallel |
| Focus: | Performance |
| Programming Model: | MPI, SHMEM, OpenMP, Pthreads, CUDA, OpenCL |
| Programming Language: | C, C++, Fortran, Python |
Score-P is a performance measurement infrastructure for profiling, event tracing and online analysis of (parallel) HPC applications. It allows users to instrument and record the behavior of sequential, multi-process (MPI, SHMEM), thread-parallel (OpenMP, Pthreads) and accelerator-based (CUDA, OpenCL) applications as well as hybrid parallel applications.
General
Score-P supports a great variety of analysis tools and is open to new ones:
- Periscope
- Scalasca Trace Tools
- Vampir
- TAU
It uses the Open Trace Format Version 2 for event traces and the Cube4 profiling format for runtime summaries. OpenMP instrumentation is supported through the Opari2 instrumenter. Score-P is available under the New BSD Open Source license.
Instrumentation
Performing automatic instrumentation can simply be done by replacing your compiler command with the appropriate Score-P wrapper. The following example assumes your C compiler is given by the variable $CC:
$ scorep $CC <compile_flags>
Score-P also supports MPI applications. Again the corresponding MPI-compiler-wrapper for Score-P needs to be used to ensure correct linking of the MPI libraries. Assuming the MPI C compiler is referenced by the variable $MPICC this looks like:
$ scorep $MPICC <compile_flags>
Measurement
After compiling an instrumented binary it can just be executed and will generate measurement data during its execution.
Score-P offers several environment variables to control the behavior of the measurement facility within the binary. Some useful environment variables include:
- $SCOREP_ENABLE_PROFILING - enable profiling
- $SCOREP_ENABLE_TRACING - enable tracing
- $SCOREP_TOTAL_MEMORY - total memory in bytes for the measurement system
- $SCOREP_EXPERIMENT_DIRECTORY - name of the experiment directory
- $SCOREP_FILTERING_FILE - a file name which contain the filter rules
- $SCOREP_METRIC_PAPI - PAPI metric names to measure
- $SCOREP_METRIC_RUSAGE - resource usage metric names to measure
Note that tracing is disabled by default because it can cause substantial additional overhead and may produce lots of data, which will ultimately perturb your application runtime behavior during measurement. More environment variables can be found in the Score-P documentation (Appendix G - Score-P Measurement Configuration) or using the command:
$ scorep-info config-vars --full
Analysis
Score-P produces experiment results in different commonly used formats.
Call-path profiles are stored in the CUBE4 format and can be viewed using the Cube tool.
Event traces are stored in the Open Trace Format 2 and can be visualized using tools such as Vampir or automatically analyzed with tools such as Scalasca.
Score-P Plugins
Score-P provides two plugin interfaces: metrics, which allows integrating new metric sources, and substrates, which allows adding new event consumers besides profiling and tracing. You can also write your own plugins.
Site specific notes
RWTH
In order to use Score-P on the RWTH cluster you need to load the corresponding module.
$ module load Score-P
Depending on your currently loaded compiler and MPI implementation this will automatically load the correct version of Score-P for you. However, if you want to have an overview about all the available Score-P versions use the following command:
$ module avail Score-P
TU Dresden
In order to use Score-P on the Taurus cluster you need to load the corresponding module.
$ module load Score-P
Depending on the compiler tool chain you want to use, you can choose between different available Score-P versions. Use the following command to get a list of all available Score-P versions:
$ module avail Score-P