Table des matières

Jean Zay : SCALASCA

Description

SCALASCA est un outil graphique d'analyse de performances pour applications parallèles ; il a été développé par le JSC (Jülich Supercomputing Centre). Il permet d'analyser le comportement d'une application et d'en identifier facilement les parties critiques. Cet outil est particulierement adapté à l'étude d'exécutions massivement parallèles.

Versions installées

  • SCALASCA 2.4 avec le compilateur GCC 8.2.0
  • SCALASCA 2.4 avec le compilateur GCC 9.1.0
  • SCALASCA 2.4 avec le compilateur Intel 2019.4

Attention : SCALASCA est parfaitement adapté aux applications hybrides MPI et multithreads/OpenMP jusqu'au niveau MPI_THREAD_MULTIPLE pour un profil et jusqu'au niveau MPI_THREAD_FUNNELED pour une trace.

Utilisation

La commande module permet d'accéder à SCALASCA ; une utilisation appropriée de SCALASCA nécessite également de charger Score-P :

Avant de travailler avec cet outil, il faut donc exécuter les commandes : 

$ module load scalasca
$ module load scorep

L'utilisation de SCALASCA se fait en trois étapes :

  1. Instrumentation de l'application ;
  2. Exécution de l'application instrumentée ;
  3. Analyse/visualisation des résultats.

Instrumentation

SCALASCA fonctionne en modifiant votre application pour y insérer ses propres procédures de mesure lors de la compilation.

Toute application peut être instrumentée soit automatiquement, soit manuellement. Seule l'instrumentation automatique d'une application MPI “pure” (sans OpenMP) sera abordée dans ce document. Pour la procédure manuelle, référez vous au manuel PDF de SCALASCA.

Pour instrumenter automatiquement votre application, il suffit d'ajouter devant le nom du compilateur la commande skin (en laissant un blanc) : 

$ skin mpif90 my_code.f90

Attention :

  • l'usage de SCALASCA entraine des surcoûts en temps d'exécution, en occupation mémoire et en espace disque.
  • les performances sont mesurées entre les appels à MPI_Init et MPI_Finalize : toute opération effectuée en dehors de ces appels ne sera pas prise en compte.

Exécution

L'exécution se fait en ajoutant la commande scan juste avant la commande srun dans vos scripts Slurm.

Un profil est un résumé de l'exécution : par défaut, seul un profil est collecté.

Pour obtenir une trace complète des évènements et non plus un simple profil, il suffit d'utiliser l'option -t. Cette option est très utile car elle permet à SCALASCA d'identifier divers problèmes de performances qui seront mis en évidence lors de la visualisation.

Attention : cette option augmente fortement les besoins en espace disque d'une exécution.

A chaque exécution, SCALASCA écrit ses fichiers dans un répertoire dont le nom est généré de la manière suivante : 

scorep_NOMAPPLI_RANKSPERNODEpNPROCxNTHR_TYPE

avec

  • NOMAPPLI, le nom de l'exécutable,
  • RANKSPERNODE, le nombre de processus par nœud,
  • NPROC, le nombre total de processus,
  • NTHR, le nombre de threads par processus,
  • TYPE, sum pour un profil, trace pour une trace.

Attention : si le répertoire existe déjà, l'exécution échouera pour éviter d'écraser des résultats précédents. Il faut donc vous assurer avant qu'il n'existe pas.

Voici un exemple de job de soumission :

scalasca_mpi.slurm
#!/bin/bash
#SBATCH --job-name=scalasca_run    # nom du job
#SBATCH --ntasks=40                # Nombre total de processus MPI
#SBATCH --ntasks-per-node=40       # Nombre de processus MPI par noeud
# /!\ Attention, la ligne suivante est trompeuse mais dans le vocabulaire
# de Slurm "multithread" fait bien référence à l'hyperthreading.
#SBATCH --hint=nomultithread       # 1 thread par coeur physique (pas d'hyperthreading)
#SBATCH --time=01:00:00            # Temps d’exécution maximum demandé (HH:MM:SS)
#SBATCH --output=scalasca%j.out    # Nom du fichier de sortie
#SBATCH --error=scalasca%j.out     # Nom du fichier d'erreur (ici commun avec la sortie)
 
# on se place dans le répertoire de soumission
cd ${SLURM_SUBMIT_DIR}
 
# nettoyage des modules charges en interactif et hérites par défaut
module purge
 
# chargement des modules
module load ...
module load scalasca
module load scorep
 
# echo des commandes lancées
set -x
 
# exécution du code
scan srun ./my_appli my_args

Soumission de ce script via la commande sbatch : 

$ sbatch scalasca_mpi.slurm

Analyse/visualisation des résultats

L'analyse des résultats se fait à l'aide de l'interface graphique Cube. Pour la lancer, il suffit de taper, en interactif, les commandes suivantes : 

$ module load scalasca
$ module load scorep
$ module load cube
$ square repertoire_sortie_scalasca/profile.cubex

L'interface est divisée en trois volets. A gauche, les différentes mesures effectuées sont présentées. Au milieu, l'arbre des appels est donné et à droite, la topologie est affichée.

En développant ou en réduisant les différentes entrées du panneau de gauche, il est possible d'avoir une vue plus ou moins synthétique des performances. Les choix effectués dans ce volet sont répercutés dans les 2 autres et permettent ainsi d'identifier les points critiques de l'application. Si l'exécution a été faite en mode trace, SCALASCA peut identifier certains comportements responsables de pertes de performances (envois de messages dans le désordre, déséquilibrage de charge…).

La visualisation passant par une application graphique, il n'est pas toujours commode de l'utiliser directement à partir d'une frontale de Jean Zay. Pour contourner ce problème, il est possible d'installer l'outil de visualisation Cube (téléchargeable sur le site officiel de SCALASCA) sur un PC sous Linux, ou toute machine UNIX, pour l'y exécuter.

Documentation