Traces d’exécution

Même si la production de la trace d’exécution n’est pas du ressort de l’envi-ronnement d’évaluation de performances elle conditionne grandement le nombre et la qualité des informations que celui-ci sera à même de produire. Il est donc important, lorsqu’on analyse les performances d’une application, de connaître la manière dont les traces ont été produites afin de pouvoir comprendre la raison de certains résultats et pondérer son évaluation en fonction de ces connaissances. Nous présentons donc le mécanisme de la prise de traces avant d’évoquer le pro-blème de la lecture de traces par les outils d’analyse.

2.1. PRINCIPES 25 10 4 22 ²⁰ 28 31 32 33 29 30 36 38 39 37 40 35 18 12 1 5 15 26 2 9 13 23 3 8 19 11 6 14 24 21 17 7 34 27 16

FIG. 2.1. – Les événements sont générés aux instants des actions faisant

chan-ger l’application d’état. Dans cet exemple, où les barres verticales représentant les actions d’une tâche au cours du temps, nous avons marqué ces instants en donnant un numéro à chaque événement, ces numéros représentant l’ordre tem-porel entre les événements. Pour des raisons de lisibilité, seuls deux événements sont marqués pour chaque communication.

Prise de traces

Une trace d’exécution est une suite d’événements décrivant les actions réali-sées au cours de l’exécution d’une application. De tels événements correspondent par exemple aux instants où une tâche commence à s’exécuter ou se termine, ainsi qu’à l’appel des primitives de programmation parallèle du système sur lequel l’ap-plication fonctionne. Dans le cas d’un système à envoi de messages, par exem-ple, des événements correspondent aux communications entre tâches ou encore à l’appel de fonctions de synchronisation des différentes parties de l’application (figures 2.1 et 2.2 page suivante).

Les traces sont prises avec un traceur, qui est un outil spécialisé dans l’ob-servation d’une application parallèle : chaque fois que celle-ci effectue une action intéressante (c’est-à-dire entraînant un changement d’état) le traceur enregistre un

Fin d’envoi Début d’envoi Début de réception Fin de réception 1 3 4 2

FIG. 2.2. – On peut voir sur cette figure que suivant le modèle de programmation

utilisé (ici CSP) il peut y avoir bien plus de deux événements pour une seule communication point à point.

événement contenant des informations telles que la date à laquelle l’action est faite, l’identification de l’entité concernée et des données décrivant l’action elle-même (son type et des informations dépendant de ce dernier). Les événements sont la plupart du temps stockés pour une analyse post-mortem de la trace, celle-ci n’étant pas exploitable en temps réel.

Les traces prises pour l’évaluation de performance ont une caractéristique par-ticulière qui est celle de leur volume : les événements correspondant aux actions contiennent toutes les informations disponibles sur celles-ci, comme par exem-ple l’ensemble des paramètres d’une fonction d’envoi de message. Cela permet ensuite aux outils d’évaluation de performance de calculer n’importe quel indice de performance puisqu’il a la totalité des informations que l’on peut obtenir sur une exécution. En revanche la prise et le stockage des traces pose des problèmes à cause du volume d’informations généré par le traceur.

Nous distinguons trois types de traceurs : les traceurs matériels, les traceurs

hybrides et les traceurs logiciels. Tous fournissent des informations sur

l’exécu-tion d’une applical’exécu-tion parallèle, mais pas au même coût ou avec la même finesse. Les traceurs matériels observent l’application et le système sous-jacent au ni-veau du matériel, et acheminent les événements constituant la trace avec un ma-tériel qui leur est propre. Le plus grand avantage des traceurs de ce type est qu’ils sont invisibles pour l’application, et ne perturbent pas (ou très peu) son exécution. Ils sont également capables de tracer des événements au niveau de la machine

2.1. PRINCIPES

elle-même, autorisant l’obtention d’informations de très bas niveau, par exem-ple sur les actions de l’ordonnanceur d’un système multi-programmé ou encore sur la gestion des caches et des tampons systèmes. Malheureusement ces traceurs coûtent très cher et sont très difficiles à mettre au point. Ils sont de plus très étroi-tement liés avec l’architecture matérielle de la machine parallèle sur laquelle les traces sont prises et risquent de devenir inutilisables dès que celle-ci change un tant soit peu. Enfin si l’on souhaite comparer les performances d’une application exécutée sur deux machines différentes il faut construire entièrement deux tra-ceurs dédiés, et on ne pourra exploiter dans tous les cas que les informations qui peuvent être obtenues sur les deux machines, perdant ainsi une partie de l’avan-tage de la finesse de trace atteignable avec un traceur matériel. Ce sont les raisons pour lesquelles on ne trouve plus de traceurs de ce type actuellement.

Un moyen de diminuer le coût des traceurs matériels tout en leur conférant une certaine portabilité est de les changer en traceurs dits hybrides (KLAR1992). Les fonctions assurées par ces traceurs sont réparties entre une partie matérielle et une partie logicielle. La plupart du temps l’enregistrement des données propres aux événements (paramètres des fonctions tracées) est logicielle et la datation ainsi que le transport des événements sont matériels. L’avantage de la prise de trace logicielle est que, pour un système de programmation parallèle donné (langage ou bibliothèque de programmation), on ne réalise qu’un seul traceur qui est portable sur plusieurs machines. Ses inconvénients sont qu’une prise de trace logicielle est coûteuse et peut perturber l’exécution de l’application, et aussi que les traces sont prises à un niveau plus haut et que les informations disponibles sont moins pré-cises. La datation et le transport matériels, de leur côté, assurent d’une part qu’il est possible de produire si besoin est une date dans un référentiel de temps global, ce qui permet de classer les événements dans l’ordre exact où ils ont été produits, et d’autre part de ne pas perturber le réseau de communication de la machine sur laquelle l’application est tracée en y faisant circuler des événements, ceux-ci utilisant un réseau de transport indépendant. Ces traceurs sont néanmoins encore très coûteux et leur partie matérielle souffre du même problème de portabilité que les traceurs entièrement matériels, à savoir qu’il faut l’adapter à chaque machine, cette adaptation n’étant pas toujours possible en l’absence d’une connaissance très poussée de l’architecture de la machine utilisée.

La solution la plus utilisée actuellement est celle des traceurs logiciels (GEIST

et al. 1991, VAN RIEK 1991, VAN RIEK et TOURANCHEAU 1991, TOURAN

-CHEAU et VAN RIEK 1992, ARROUYE 1992, MAILLET 1995). De tels traceurs effectuent toutes leurs tâches, c’est-à-dire la prise de mesures et leur envoi, de

manière logicielle, par instrumentation du code de l’application ou de la biblio-thèque de programmation qu’elle utilise. Leur intérêt est leur grande portabilité puisqu’ils ne dépendent que des outils de programmation parallèles (langages ou bibliothèques de programmation) et absolument pas de la machine sur laquelle s’exécutent l’application. En revanche, ils posent un certain nombre de problèmes. Le premier d’entre eux est la perturbation de l’exécution liée à la prise des traces : chaque fois qu’un événement est générée, le traceur voledu temps à l’appli-cation et décale les événements suivants dans le temps. Cela peut finir par donner des traces incohérentes dans lesquelles l’ordre des événements indiqués n’est pas l’ordre des événements réels, ou représente une impossibilité (par exemple la ré-ception d’un message avant son envoi dans un système à passage de messages).

À la perturbation liée à la production de l’événement lui-même peut s’ajouter une plus grande perturbation due au transport des événements pour leur enregis-trement sur disque. Même si les événements sont gardés en mémoire autant que possible, il arrive un moment où l’espace nécessaire à ce stockage local est épuisé : il faut alors envoyer tous les événements enregistrés vers un site de stockage, ce qui produit une perturbation immense du fait du partage du réseau de communi-cation avec l’applicommuni-cation tracée et du temps de blocage de la tâche déclenchant ce transport. Outre la modification des dates des événements la perturbation due à la prise de trace peut également modifier l’ordre des événements, lequel peut varier à cause de l’indéterminisme des programmes parallèles. Enfin le dernier problème des traceurs logiciels pour les performances est que la plupart des ma-chines actuelles ne disposent pas d’une horloge globale permettant de dater sans ambiguïté les événements produits sur des processeurs différents. Si les traces ne sont pas construites avec précaution, par exemple en synchronisant les horloges de la machine avant l’exécution de l’application, ou en reconstituant un temps global après la prise de traces proprement dite (JÉZÉQUEL 1990, MAILLET et TRON1995), elles peuvent se révéler inutilisables.

Lecture de traces

La lecture de traces est l’opération qui permet d’extraire d’une trace la suc-cession des événements représentant les actions effectuées par une application au cours de son exécution. Ces événements sont fournis à l’environnement d’évalua-tion de performance dans un certain ordre, celui-ci étant normalement l’ordre des dates croissantes des événements puisqu’il permet de reconstituer la succession

2.1. PRINCIPES

des états de l’application par simulation.

Le problème principal des traces d’exécution actuellement disponibles est la multiplicité des formats de traces : on trouve presque un format de trace par envi-ronnement de programmation ou d’évaluation de performance (outre les formats des lecteurs évoqués précédemment citons notamment BEMMERLet al. 1990, BE

-GUELIN, DONGARRA, GEIST, MANCHEK et SUNDERAM 1991, KILPATRICK et SCHWAN1991,VANRIEK1991, ERLANGEN-NÜRNBERGUNIVERSITÄT1992a, HERRARTE et LUSK 1992) et certains environnements d’évaluation de perfor-mance utilisent même des formats différents pour un même système suivant la machine utilisée. La situation est d’autant plus compliquée que chaque format de trace fournit des informations dont non seulement la syntaxe mais aussi la séman-tique diffère des autres formats pour la simple raison que différents environne-ments supportent différents paradigmes de programmation pour lesquels on n’a pas besoin des mêmes informations.

Un format de trace a cependant joué un rôle particulier. C’est celui généré par la bibliothèque de communication PICL (Portable Instrumented Communication

Library, GEIST et al. 1991, WORLEY1992) qui a longtemps été le format le plus utilisé, principalement à cause de son exploitation par l’outil de visualisation Pa-raGraph (cf. § 2.2.1 page 33). Beaucoup de traceurs actuels sont accompagnés d’outils de conversion de leur format de traces en format PICL dans le seul but de permettre la relecture des traces par ParaGraph à des fins de visualisation.

Des essais de standardisation des formats de traces ont néanmoins été réali-sés en proposant des formats auto-descriptifs (HON1990, MALONY et NICHOLS

1991, ERLANGEN-NÜRNBERG UNIVERSITÄT1992a, REED et al. 1992) qui

ser-vent à produire des traces contenant d’une part les informations de trace habi-tuelles et d’autre part une description de haut-niveau de la syntaxe des événements contenus dans la trace. L’intérêt de cette approche est qu’il est possible de mani-puler ces traces avec des outils d’analyse génériques (ERLANGEN-NÜRNBERG

UNIVERSITÄT 1992b, ERLANGEN-NÜRNBERG UNIVERSITÄT 1992c) pour ef-fectuer des opérations simples (comme par exemple des statistiques sur un champ correspondant à la taille des messages échangés par les tâches). Ils ne résolvent par contre pas le problème du traitement des traces pour reconstituer la suite des états d’une application, cette reconstitution nécessitant une connaissance poussée du modèle de programmation utilisé pour l’application.

multi-tude de formats de traces différents qui doivent être traités spécifiquement par les environnements d’évaluation de performance. Il est parfois possible de convertir une trace d’un format vers un autre, mais à condition que les modèles de pro-grammation correspondent, sous peine de produire des traces non interprétables ou faussées.

2.1.2 Simulation

La simulation est le procédé par lequel un outil d’évaluation de performance reconstruit la succession des états de l’application au cours de son exécution. Cette reconstruction n’est pas obligatoire mais c’est elle qui permet de connaître certains indices de performance importants tels que le taux d’utilisation des processeurs, le temps pendant lequel une application est restée bloquée en attente de réception de données, etc. Aussi la plupart des environnements d’évaluation de performance actuels utilisent-ils un simulateur pour fournir ces indices.

Ces simulateurs dirigés par les traces sont dépendants de la sémantique des événements traités. Il faut donc, pour traiter plusieurs modèles de programmation, disposer d’un simulateur adapté à chacun de ces modèles.