Document Actions
Outils d'analyse
Description pratique des outils de profilage des performances des codes
Introduction
Les outils d'analyse vous permettent d'étudier les performances de vos codes. On peut ainsi obtenir des statistiques sur les parties du code consommatrices du temps CPU : les sous-programmes les plus actifs, les boucles, ...Il est important de comprendre qu'une étude de profilage ne donne des informations que pour une exécution particulière du code : celle pour laquelle l'analyse est faite. Un même programme mais avec d'autres données peut produire une analyse très différente.
Une situation intéressante consiste en un code où le temps CPU consommée est concentré dans un petit nombre de sous-programmes. L'effort d'optimisation est alors limité à ces quelques routines.
L'environnement de développement IBM contient plusieurs outils suivants :
- prof : assez basique, pour le profilage ;
- gprof : version très améliorée de prof ;
- xprofiler : interface graphique pour visualiser les sorties de gprof ;
- hpmtoolkit : ensemble d'outils de comptage d'évènements (MFlops, cache misses, ...);
- PE Benchmarker (Parallel Environment Benchmarker) : ensemble d'outils et d'utilitaires.
prof
La commande prof fournit un compte-rendu de la consommation CPU pour chaque routine du code :C'est un outil peu intéressant ; il vaut bien mieux lui préférer gprof.
Par défaut, la commande prof considère le fichier objet a.out et le fichier de profilage (données collectées) mon.out. Il produit un compte-rendu envoyé vers la sortie standard qui peut être redirigé.
Pour utiliser la commande prof il faut compiler le programme C ou Fortran (ou Pascal ou Cobol) avec l'option de profilage -p.
A la fin de l'exécution, on obtient un fichier de données, mon.out, que prof peut analyser. On peut lui spécifier des options, les plus utiles sont :
Procédure :
- compilation et édition des liens avec l'option de profilage -p ;
- exécution classique ;
- analyse du fichiers de profilage.
Retour au début de la section .
gprof
La commande gprof produit un compte-rendu d'exécution pour les programmes C ou Fortran (ou Pascal ou Cobol), qu'ils soient séquentiels ou parallèles (MPI, OpenMP). gprof est bien plus complet que prof.Pour utiliser la commande gprof il faut compiler le programme avec l'option de profilage -pg.
A la fin de l'exécution, on obtient un fichier de données, gmon.out, que gprof peut analyser. On obtient alors deux compte-rendus :
Les options pratiques de gprof sont :
Procédure :
- compilation et édition des liens avec l'option de profilage -pg ;
- exécution classique ;
- analyse du fichier de profilage.
- Un classement décroissant (du temps cpu consommé) des fonctions appelées dans le programme : fonctions appartenant au programme et fonctions provenant de librairies du système. Par exemple l'extrait suivant :
- La répartition du temps cpu dans les appels aux fonctions peut être trouvée en analysant la hiérarchie des appels de fonction.
| % time |
cumulative seconds |
self seconds |
calls |
self ms/call |
total ms/call |
name |
|
|---|---|---|---|---|---|---|---|
| 36.9 | 92.23 | 92.23 | 87253 | 1.06 | 1.06 | .saxpy [4] | |
| 29.9 | 167.06 | 74.83 | 45751 | 1.64 | 1.64 | .pmv [5] | |
| 22.0 | 222.15 | 55.09 | 61502 | 0.90 | 0.90 | .prodscal [6] | |
| 6.1 | 237.48 | 15.33 | 10000 | 1.53 | 3.17 | .scdmb [7] | |
| 5.1 | 250.19 | 12.71 | 10000 | 1.27 | 21.85 | .gradconj [3] | |
| 0.0 | 250.22 | 0.03 | .__mcount [8] | ||||
| 0.0 | 250.25 | 0.03 | .qincrement [9] | ||||
| 0.0 | 250.27 | 0.02 | 1 | 20.00 | 20.00 | .fctfx [10] | |
| 0.0 | 250.28 | 0.01 | 6 | 1.67 | 1.67 | .nrmerr [11] | |
| 0.0 | 250.28 | 0.00 | 20000 | 0.00 | 0.00 | .fctft [12] | |
| 0.0 | 250.28 | 0.00 | 252 | 0.00 | 0.00 | ._sigsetmask [13] | |
| 0.0 | 250.28 | 0.00 | 170 | 0.00 | 0.00 | .pthread_mutex_lock [14] |
La colonne % time indique le pourcentage du temps cpu total consommé par la routine courante.
La colonne cumulative seconds représente la somme partielle des temps cpu du dhaut de la liste jusqu'à la routine courante.
La colonne self seconds représente le temps cpu de la routine courante.
La colonne calls indique le nombre d'appels de la routine courante.
La colonne self ms/call indique le temps cpu moyen (en milisecondes) consommé par appel à la routine courante, temps exclusif (ne contient pas la consommation des routines qu'elle appelle) uniquement.
La colonne total ms/call indique le temps total (inclusif + exclusif) consommé par appel à la routine courante.
| index |
% time |
self |
descendents |
called/total called+self called+total |
parents name index children |
|---|---|---|---|---|---|
| 0.00 | 250.22 | 1/1 | .__start [2] | ||
| [1] | 100.0 | 0.00 | 250.22 | 1 | .main [1] |
| 12.71 | 205.79 | 10000/10000 | .gradconj [3] | ||
| 15.33 | 16.36 | 10000/10000 | .scdmb [7] | ||
| 0.02 | 0.00 | 1/1 | .fctfx [10] | ||
| 0.01 | 0.00 | 6/6 | .nrmerr [11] | ||
| 0.00 | 0.00 | 1/1 | .domaine [88] | ||
| 16.36 | 0.00 | 10000/45751 | .scdmb [7] | ||
| 58.47 | 0.00 | 35751/45751 | .gradconj [3] | ||
| [5] | 29.9 | 74.83 | 0.00 | 45751 | .pmv [5] |
fonctions parents : celles placées au-dessus dans le tableau
fonctions de référence : celles qui ont un numéro dans la colonne index
fonctions children : celles placées en-dessous dans le tableau
Dans le cas de la fonction pmv, il y a 45751 appels mais la première partie du compte-rendu ne nous donne pas d'informations sur l'origine des appels ni la répartition du cpu consommé selon cette origine. Ces informations sont obtenues avec la seconde partie :
la routine pmv a ses 74.83 sec consommées suite à un appel de soit scdmb (pour 16.36 sec), soit gradconj (pour 58.47 sec) avec les nombres d'appels respectifs 10000 et 35751.
gprof peut aussi bien être employé sur un code séquentiel qu'une application parallèle (MPI, OpenMP). Dans le second cas, un fichier gmon.out.rang est crée pour chaque processus de l'application, selon le rang de celui-ci.
On peut alors appliquer gprof soit sur chacun d'eux, soit sur l'ensemble des fichiers, tous donnés comme argument :
- gprof gmon.out.2 pour analyser le profilage du processus 2 ;
- gprof gmon.out.0 gmon.out.1 gmon.out.3 ... pour analyser l'ensemble de l'application
On peut aussi visualiser graphiquement les fichiers de profilage gmon.out à l'aide de l'outil xprofiler. Pour utiliser pleinement ses possibilités, il est recommandé de compiler le code avec la séquence d'options -pg -qdbg -qfullpath au lieu de simplement -pg.
Retour au début de la section .
xprofiler
L'outil graphique xprofiler permet d'analyser graphiquement les sorties de gprof avec affichage du code source, arbre d'appels des routines, ....
Il est pratique car il donne une vision plus "dynamique" et interactive de l'analyse contrairement à gprof.
Lien vers la page dédiée à xprofiler.
Retour au début de la section .
hpm toolkit
L'ensemble hpm toolkit (Hardware Performance Monitoring Tool Kit) comprend des outils qui permettent de comptabiliser des évènements qui surviennent durant l'exécution du programme (séquentiel, MPI ou OpenMP). On obtients des comptes-rendus au format texte.
- l'utilitaire hpmcount démarre une application et fournit à la fin de l'exécution des informations comme le temps d'exécution, les informations sur les compteurs matériels, les statistiques dérivées et l'utilisation des ressources ;
- la bibliothèque d'instrumentation libhpm fournit les mêmes informations que l'utilitaire hpmcount pour chaque région du programme qui est instrumentée ;
- l'interface graphique hpmviz d'affichage des comptes-rendus n'est pas installée au CRIHAN ;
L'analyse peut être globale (tout le code est instrumenté) ou locale (une partie seulement, avec modification du code source)
Lien vers la page dédiée à HPM Tool Kit.
Retour au début de la section .
Parallel Environment Benchmarker Tool
Cet ensemble d'outils fait partie du Parallel Environment d'IBM (PE) qui contient notamment poe, la commande de lancement des applications parallèles MPI.Ces outils permet de collecter et d'analyser les traces d'évènements ou de performances. On y trouve :
- le Performance Collection Tool (PCT) pour collecter des traces MPI ou faire du profilage d'évènements liés au système d'exploitation ou du matériel ;
- un ensemble d'utilitaires pour convertir les enregistrements des traces fournies par PCT en un format qui peut être analysé par d'autres utilitaires (tiers ou provenant d'IBM) ;
- le Profile Visualization Tool (PVT) pour analyser les profilages des évènements liés au système d'exploitation ou au matériel, fournis par PCT.
Le Performance Collection Tool permet de collecter aussi bien des traces d'applications MPI ou séquentielles que de profilage d'évènements liés au système d'exploitation ou du matériel. Il repose sur l'instrumentation dynamique avec la Dynamic Probe Class Library (DPCL). Cette bibliothèque a l'avantage d'être moins intrusive pour l'instrumentation.
L'ensemble des utilitaires Unified Trace Environment (UTE) permettent de convertir un ou plusieurs fichiers de traces d'évènements AIX sous forme de fichiers au format UTE. Cette transformation permet d'inclure la durée d'un évèment au lieu de simplement l'instant où il survient. Cet ensemble comprend :
- l'utilitaire uteconvert qui convertit les fichiers de traces AIX en fichiers au format UTE ;
- l'utilitaire utemerge qui fusionne plusieurs fichiers au format UTE en un seul ;
- l'utilitaire utestat qui génère des tables de statistiques à partir de fichiers au format UTE ;
- l'utilitaire slogmerge qui convertit et fusionne plusieurs fichiers au format UTE en un seul fichier SLOG pour analyse avec le logiciel Jumpshot du Argonne National Laboratory.
Le Profile Visualization Tool permet de visualiser les fichiers de trace issus du profilage d'évènements liés au système d'exploitation ou au matériel qui sont sauvegarés au format netCDF (network Common Data Form).
La figure suivante illustre le processus de collecte et d'analyse des données à l'aide de PE Benchmarker.
La procédure commence avec PCT. On choisit le type de données que l'on veut collecter : traces d'évènements d'applications MPI ou séquentielles, évènements liés au système d'exploitation ou au matériel. On utilise PCT pour se connecter à des processus existants ou bien pour lancer les processus et s'y connecter. La connection aux processus signifie ici le contrôle de l'exécution et l'instrumentation de la collecte. Les fichiers d'informations collectées sont générés sur chaque machine qui exécute au moins un des processus instrumentés. Le format des fichiers générés dépend du type des données collectées.
- S'il s'agit de traces d'évènements d'applications MPI ou séquentielles, des fichiers de traces standard AIX sont générés. Il faut alors en premier lieu convertir ces fichiers au format UTE à l'aide de l'utilitaire uteconvert. On peut visualiser des statistiques sur les informations de ces fichiers avec l'utilitaire utestats. On peut aussi fusionner des fichiers au format UTE à l'aide de l'utilitaire utemerge avant de générer les statistiques avec utestats. On peut aussi visualiser graphiquement les informations contenues dans les fichiers UTE. Pour cela on les convertit au format SLOG, format lisible par le logiciel Jumpshot du Argonne National Laboratory. L'utilitaire slogmerge effecte cette conversion et génére un unique fichier SLOG à partir d'un unique fichier UTE ou d'un ensemble de tels fichiers.
- S'il s'agit de données sur les performances du matériel, les fichiers sont générés directement au format netCDF.
Les différents utilitaires et outils décrits ci-dessous possèdent des manpages, en plus d'une documentation au format pdf (Parallel Environment for AIX, Operation and Use, Volume 2) que l'on peut récupérer ici ou bien encore que l'on peut télécharger sur les sites IBM ; voir les liens proposés sur la page documentation IBM.
Lien vers la page dédiée à PCT.
Lien vers la page dédiée aux utilitaires UTE.
Lien vers la page dédiée à PVT.