OUTILS ET ENVIRONNEMENTS EXISTANTS

c’est-à-dire qu’une anomalie sonore dans une mélodie complexe est bien plus ai-sément perceptible qu’un changement dans une visualisation complexe. Il peut donc servir de support à la visualisation, celle-ci étant de toute manière obliga-toire pour voir ce qui se passe réellement dans l’application évaluée (LEBLANC

et al. 1990).

2.2 Outils et environnements existants

Il existe aujourd’hui un grand nombre d’outils et d’environnement pour l’éva-luation de performance à travers la visualisation. Ils couvrent un grand nombre de domaines et considèrent la visualisation sous différents angles et avec des pers-pectives variées.

Nous avons choisi de présenter ici quelques environnements et outils de visua-lisation qui sont représentatifs soit de ce qui est actuellement utilisé soit d’idées qui nous semblent caractéristiques de ce qui sera sans doute conservé dans les outils des prochaines années. Une présentation plus exhaustive ainsi qu’une clas-sification des outils disponibles pourra être trouvé dans les articles de KRAEMER

et STASKO (1993) ainsi que ROMAN et COX (1993) mais également dans les références données dans la bibliographie commentée présente à la fin dans ce do-cument.

2.2.1 ParaGraph

C’est l’outil ParaGraph (HEATH1990, HEATHet ETHERIDGE 1991a, HEATH

et ETHERIDGE1991b, HEATH1992) qui a popularisé l’utilisation de la visualisa-tion pour l’évaluavisualisa-tion des performances d’applicavisualisa-tions parallèles. Il fut le premier outil disponible publiquement et reste aujourd’hui encore l’un des plus utilisés.

ParaGraph utilise des traces produites par PICL (Portable Instrumented

Com-munication Library, GEIST et al. 1991), une bibliothèque de programmation

pa-rallèle par envoi de messages qui supporte la génération de traces d’exécution. Les applications écrites avec cette bibliothèque sont découpées en phases et s’exé-cutent à raison d’une tâche par processeur, aussi ParaGraph confont-il les deux. Si aujourd’hui PICL n’est pas la plus utilisée des bibliothèques de

programma-tion parallèle, ParaGraph reste néanmoins un outil très prisé et un grand nombre de traceurs logiciels sont accompagné d’un outil de conversion de leur format de trace vers le format de PICL.

Outre sa disponibilité, le plus grand attrait de ParaGraph est la diversité des vi-sualisations proposées (figure 2.3 page ci-contre). Il en existe actuellement plus de quarante, partagées entre vues instantanées et temporelles, représentations statis-tiques et spécifiques. ParaGraph les sépare en quatre catégories : les visualisations d’utilisation de la machine donnent des indications sur la manière dont les tâches exploitent les ressources à leur disposition, les visualisations de communication montrent le schéma de communication de l’application (que ce soit à travers un diagramme espace-temps, une animation du graphe d’état de l’application ou des matrices de communication), les visualisations des tâches indiquent l’activité de ces dernières et les visualisations diverses fournissent d’autres informations telles qu’une représentation textuelle de la trace, des statistiques ou encore une vue du chemin critique de l’application. Les visualisations des communications sont par-ticulièrement travaillées et il est possible par exemple de voir une animation des communications sur la plupart des topologies de réseaux d’interconnexion des machines actuelles.

ParaGraph est limité à la visualisation d’applications comportant au plus 128 tâches. Mais ses visualisations supportent très difficilement un aussi grand nombre d’objets et deviennent rapidement illisibles1. Il est même assez illusoire de vouloir observer des applications ayant plus de 32 tâches. Une grande partie des visuali-sations statistiques de ParaGraph est malheureusement boguéeet donne des résultats ininterprétables.

ParaGraph ne supporte qu’un modèle de programmation, celui de PICL. Pour l’adapter à un autre modèle, il faut réécrire une très grande partie de l’environ-nement ce qui représente une lourde tâche (GLENDINNING et al. 1992). Il est

possible d’ajouter une nouvelle visualisation à ParaGraph si on le désire. Mais cela est assez compliqué et, ParaGraph disposant d’un éventail de visualisations très large, ne se justifie que pour réaliser une visualisation spécifique à un type d’application, par exemple.

1: Ce problème est d’autant plus gênant que ParaGraph ne supporte pas qu’une fenêtre en cache une autre, celles-ci n’étant pas rafraichies lorsqu’elles sont découvertes : il faut donc que toutes les visualisations utilisées soient placées côte à côte sur l’écran. L’utilisateur est ainsi souvent obligé de choisir entre la lisibilité des visualisations — impliquant de grandes fenêtres — et le nombre de visualisations différentes utilisées pour son évaluation.

2.2. OUTILS ET ENVIRONNEMENTS EXISTANTS

FIG. 2.3. – Visualisation de l’exécution d’une FFT bi-dimensionnelle sur IBM

SP2 avec ParaGraph.

Les visualisations de ParaGraph sont personnalisables de manière globale et cette configuration ne concerne que des attributs tels que les couleurs employées ou encore le placement des tâches dans les visualisations (ParaGraph pouvant les organiser par défaut par ordre croissant ou par ordre du code de Gray, sauf pour l’animation du graphe d’état de l’application qui propose plusieurs topologies lo-giques courantes). Elles ne sont absolument pas interactives et il est plutôt difficile de retrouver une information d’une visualisation à l’autre. Qui plus est les visua-lisations donnent une vue globale du fonctionnement d’une application mais ne permettent pas d’obtenir des indices de performances précis car seules les bornes des intervalles de valeurs sont présentées. Les seules données chiffrées exactes que l’on peut obtenir sont des valeurs globales fournies en fin de traitement de la trace par ParaGraph.

ParaGraph est néanmoins un outil très apprécié par la communauté d’évalua-tion de performance en parallélisme, que ce soit pour le nombre de ses visualisa-tions ou pour la très grande facilité avec laquelle on commence à l’utiliser, ce qui permet de voir très rapidement le comportement de ses applications. Même si de nombreux outils ont vu le jour après lui, aucun n’a encore atteint sa popularité.

2.2.2 XPVM

XPVM est un outil de visualisation de programmes parallèles écrits avec le système PVM. Son originalité réside dans le fait qu’il récupère chaque événement dès qu’il est généré par l’application et met immédiatement à jour ses visualisa-tions de l’exécution.

Le format de traces utilisé par XPVM est celui que la version 3.3 de PVM four-nit si on lui demande de tracer les tâches. Ce format est auto-descriptif et est donc facilement convertible en d’autres formats de traces adaptés au modèle de pro-grammation de PVM. Par contre XPVM n’exploite pas la partie auto-descriptive du format et se contente de lire directement les événements dont il connaît la syn-taxe et la sémantique.

XPVM est assez pauvre en visualisations puisqu’il n’en propose que cinq. Les deux plus utiles sont une animation de l’activité de la machine parallèle virtuelle sur laquelle fonctionne l’application et un diagramme espace-temps. La qualité de ces visualisations est néanmoins supérieure à ce qui est offert dans ParaGraph, et surtout le diagramme espace-temps est interactif, c’est-à-dire qu’il est possible de cliquer sur une information affichée et d’obtenir l’événement qui lui est associé. Les visualisations ne sont absolument pas personnalisables et XPVM ne fournit pas de support pour l’extension de l’environnement.

XPVM a surtout un grave inconvénient qui est le rapatriement direct des évé-nements : la perturbation induite par cette action est très importante et de plus la prise de trace prend beaucoup de temps puisqu’elle nécessite beaucoup de com-munications avec XPVM. C’est ce problème qui fait que XPVM est assez peu utilisé et n’a pas fait l’objet de gros efforts de développement depuis sa version initiale jusqu’en juillet 1995.

Mieux conçu que ParaGraph mais incapable de rivaliser avec lui pour l’ins-tant, XPVM se veut devenir à terme l’environnement simple de référence pour la

2.2. OUTILS ET ENVIRONNEMENTS EXISTANTS

FIG. 2.4. – Visualisation de l’exécution d’une FFT mono-dimensionnelle sur

IBM SP2 avec XPVM. La vue du haut représente l’état de la machine paral-lèle alors que celle du bas est un diagramme espace-temps (états des tâches et communications au cours du temps). On notera la ligne View Info en bas, donnant des informations sur la communication sélectionnée sur le diagramme espace-temps, laquelle apparaît sous forme de flèche épaissie.

visualisation de l’exécution d’applications PVM.

2.2.3 Upshot

Upshot (HERRARTE et LUSK 1992) est un outil de visualisation très simple mais assez intéressant. Il permet de construire rapidement une visualisation

per-FIG. 2.5. – Vue de la visualisation d’Upshot. On notera en bas les boutons

permettant de se déplacer d’une page  d’exécution à l’autre ainsi que la petite fenêtre d’inspection d’un événement.

sonnalisée pour l’application évaluée et supporte le déplacement vers un instant arbitraire de son exécution.

Le format de trace utilisé par Upshot est extrêmement simple et un utilitaire est fourni pour aider à la génération de fichiers dans le format voulu, facilitant la conversion de traces existantes. Upshot n’interprète pas toutes les données de la trace, en particulier il utilise tels quels les types d’événements qui lui sont fournis et conserve les informations utilisateur qui leur sont associées. Un fichier d’états

2.2. OUTILS ET ENVIRONNEMENTS EXISTANTS

peut être associé à un fichier de trace. Ce fichier décrit des états en donnant pour un numéro d’état donné un nom utilisé pour se référer à cet état, les types d’évé-nements correspondant au début et à la fin du passage dans cet état, et enfin une couleur pour la représentation de l’état lors de la visualisation.

L’outil ne dispose que d’une visualisation qui est une sorte de diagramme espace-temps (figure 2.5 page précédente). Lors de la lecture de la trace il place les événements sur les lignes correspondant aux tâches, et colorie les états. L’exé-cution est découpée enpageset il est possible de passer d’une page à une autre à tout moment. Les événements représentés sur le diagramme fourni par Upshot peuvent être interrogés pour obtenir les informations qui leur ont été associés.

Upshot est un outil simple mais suffisamment intéressant pour mériter d’être utilisé. Il est très utile en particulier pour visualiser des informations sur une ap-plication en l’absence de traceur, par exemple si l’on a découpé son programme en parties logiques et que l’on veut observer la manière dont il exécute ces parties au cours du temps. Le fait de pouvoir associer des informations aux événements puis de les récupérer lors de l’inspection d’un événement permet de faire rapidement de la mise au point pour les performances spécifique à une application.

La version actuelle d’Upshot étant tout de même assez limitée, une nouvelle version est en phase finale de développement. Celle-ci offre deux visualisations supplémentaires et permet aussi de représenter des interactions entre les tâches (comme un envoi de message) sur le diagramme espace-temps, ainsi que des états imbriqués (figure 2.6 page suivante).

2.2.4 Pablo

Pablo (REED 1991, REED et al. 1992) est un environnement d’évaluation de

performances général et complexe. Il a été conçu pour pouvoir traiter des traces de manière générique, pour pouvoir être facilement extensible et pour durer. Pablo n’est pas simplement un environnement de visualisation. Son but est de contrôler la totalité du processus d’évaluation de performance, de l’instrumentation du code à la visualisation de son exécution.

Les traces manipulées par Pablo sont stockées dans un format auto-descriptif, SDDF (pour Self-Describing Data Format). L’environnement étant générique, il n’a aucune connaissance de ce qu’il manipule et il conserve toutes les données de

FIG. 2.6. – La nouvelle visualisation espace-temps d’Upshot permet de

repré-senter des interactions entre tâches et des états imbriqués comme le montre cette visualisation de l’exécution d’un algorithme de FFT avec 16 tâches.

la trace et les indicateurs de performance qu’il calcule dans ce format.

Pablo est le premier environnement de visualisation pour l’évaluation de per-formance qui a été diffusé avec un langage de programmation visuelle intégré. Ce langage permet de construire des graphes d’analyse et de visualisation en connec-tant des composants entre eux, ces composants pouvant être des filtres d’analyse de données ou des visualisations. Les données passent d’un composant à l’autre, chaque composant les transformant avant de les transmettre aux composants aux-quel il est connecté. Il permet également l’extension de l’environnement puisqu’il suffit de créer un nouveau composant pour qu’il soit intégrable à l’environne-ment ; cette intégration nécessite par contre une modification de l’environnel’environne-ment pour qu’il reconnaisse ce nouveau composant. Pablo est fourni avec un certain nombre de tels composants et il suffit de les connecter pour être prêt à mener une session d’évaluation de performance. Le système de programmation visuelle de

2.2. OUTILS ET ENVIRONNEMENTS EXISTANTS

FIG. 2.7. – L’environnement d’évaluation de performance Pablo. On notera la

fenêtre représentant le programme visuel décrivant le graphe d’analyse et de représentation utilisé pour la session d’évaluation de performance en cours.

Pablo utilise également SDDF pour la manipulation des données puisque c’est dans ce format que les données de la trace sont disponibles, et parce qu’il permet de réaliser des composants polymorphiques (c’est à dire acceptant par exemple des nombres sous forme d’entiers ou de réels et se chargeant des conversions né-cessaires).

Les visualisations de Pablo sont uniquement statistiques. En effet, l’environ-nement ne connaît aucun modèle de programmation et ne dispose pas de simu-lateur permettant de reconstruire la suite des états d’une application à partir des événements générés pendant son exécution. Les visualisations ne sont pas non plus interactives. En revanche Pablo est le seul environnement à disposer d’un ensemble de composants de sonorisation qui peuvent être utilisés en complément des visualisations.

FIG. 2.8. – Une visualisation expérimentale de Pablo. Les cubes représentent

des espaces de métriques et les sphères représentent les processeursflottant dans ces espaces tri-dimensionnels.

Pablo a voulu être un environnement capable de traiter n’importe quel type de trace et d’effectuer des analyses extrêmement variées. Pour cela ses concepteurs ont défini des mécanismes très généraux afin d’être à même de traiter tous les cas qui pourraient se présenter. Si cette intention est louable, le résultat actuel est que Pablo est très difficile à utiliser sans apprentissage : la configuration du schéma d’analyse de la programmation visuelle est une tâche extrêmement lourde et qui

2.2. OUTILS ET ENVIRONNEMENTS EXISTANTS

FIG. 2.9. – Immersion dans un espace de données (ici l’ensemble des projections

tri-dimensionnelles d’un jeu de données N-dimensionnelles) par utilisation de la réalité visuelle.

ne donne pas envie de recommencer2.

À notre connaissance l’utilisation de Pablo hors des milieux universitaires américains est toujours confidentielle trois ans après sa mise à disposition pu-blique. On notera cependant que Pablo Par contre le projet continue toujours et sert de cadre à un certain nombre d’essais de visualisations expérimentales, no-tamment multi-dimensionnelles (figure 2.8 page précédente) ou faisant appel à des accessoires de réalité virtuelle (figure 2.9) ; mais ces vues sont encore difficilement exploitables. D’autres expériences en cours concernent par exemple l’intégration de Pablo avec l’environnement Fortran D de la Rice University (HIRANANDANI

2: L’exemple le plus simple d’utilisation de Pablo dans son guide de l’utilisateur comprend huit pages de configuration du schéma d’analyse !

et al. 1992), la conduite d’une session d’évaluation de performance en temps réel

ou encore l’étude de méthodes statistiques de réduction de la taille des données à manipuler lors de l’évaluation d’applications importantes.

2.2.5 Paradyn

L’environnement Paradyn (MILLER, CALLAGHAN, CARGILLE, HOLLING

-SWORTH, IRVIN, KARAVANIC, KUNCHITHAPADAM et NEWHALL 1994, MIL

-LER, HOLLINGSWORTHet CALLAGHAN1994) est récent et plutôt novateur, met-tant en pratique un certain nombre d’idées inédites qui méritent de s’y intéresser. Il donne une bonne idée d’une des manières dont l’évaluation de performance des applications parallèles pourrait être conduite dans un futur proche.

La prise de traces dans Paradyn se fait en temps réel. Mais à la différence de XPVM, où cette prise de trace est très classique, Paradyn effectue celle-ci par une instrumentation dynamique du code de l’application au cours de son exécution. Cette instrumentation est dirigée par l’utilisateur, et l’application n’est effective-ment tracée que lorsque ce dernier en a besoin. La mise en place des points de trace est une opération délicate et qui est toujours susceptible de perturber l’exé-cution de l’application puisqu’il faut suspendre ses tâches puis les relancer après insertion des instructions de prise de traces. Par contre, le problème de la taille des traces est résolu puisqu’il n’y a plus de stockage des informations avant leur exploitation.

Les traces prises par Paradyn ne sont pas non plus des traces classiques. Alors que jusqu’à présent tous les outils de prise de traces pour l’évaluation de per-formance généraient des événements correspondant aux changements d’états de l’application tracée, Paradyn échantillonne à intervalles réguliers un jeu d’indica-teurs de performance spécifiés par l’utilisateur. Les traces sont plus petites que des traces classiques mais ne peuvent pas du tout servir à la reconstruction des états de l’application, par exemple.

Une session d’évaluation de performance sous Paradyn est contrôlée depuis une fenêtre contenant une représentation des différents modules de l’application évaluée, cette représentation indiquant quelle partie de l’application est en cours d’exécution (figure 2.10 page suivante).

2.2. OUTILS ET ENVIRONNEMENTS EXISTANTS PostCallBookwork UpdateBestColoring exhaustive.pd.pn{2} exhaustive.pd.pn{1} X_noncom_new.C MsgTag Barrier Process Procedure SyncObject

FIG. 2.10. – Vue de la fenêtre de contrôle de l’environnement d’évaluation de

performance Paradyn, présentant différents modules d’une application et indi-quant où l’on se trouve dans l’exécution de celle-ci.

la même qu’avec les autres environnements de visualisation. Alors que dans ces derniers on procède en observant l’exécution et en regardant si l’on peut voir une anomalie dans celle-ci, Paradyn cherche un problème de performance puis montre ce problème une fois qu’il l’a détecté (figures 2.11 page suivante et 2.12 page 47). Cette recherche de problèmes est automatisée par ce que les auteurs de Para-dyn appellent unconsultant en performance. Ce consultant utilise un modèle de caractérisation des problèmes de performances suivant trois axes, W3

(pour

Where, Why, When). Ces axes correspondent à la localisation du problème dans

l’application (axe Where), dans la séquence d’actions de celle-ci (axe Why) et dans le temps (axe When). Lorsqu’un indicateur de performance prend une valeur anor-male, le consultant cherche le point correspondant au problème dans l’espace de recherche du modèle W3

(en simplifiant, la date à laquelle l’anomalie est détectée fixe une coordonée sur l’axe When, l’instruction en cours d’exécution est liée à l’axe Where et l’axe Why correspond aux conditions ayant provoqué l’anomalie). Une fois le problème identifié Paradyn peut fournir une représentation graphique

exhaustive.p exhaustive.pd.pn{27} exhaustive.pd.pn{26} exhaustive.pd.pn{25} stive.pd.pn{24} exhaustive.pd.pn{0} mendota SpinLock Semaphore MsgTag Barrier UpdateBestColoring PreCallBookwork PostCallBookwork Exhaustive_Initiate tc Semaphore exhaustive_stack_new.h mendota lazy_array.h X_noncom_new.C X_m mendota X_noncom_new.C cpuBound vmBottlenec cpuBottleneck ioBottleneck root

FIG. 2.11. – Détection automatisée d’un problème avec Paradyn : le consul-tant en performance  intégré à l’environnement indique le type de problème rencontré et sa localisation dans l’application. De haut en bas on trouve suc-cessivement les différentes classes de problèmes de performance identifiées par le consultant puis les endroits considérés comme pouvant être la cause du pro-blème détecté. Le chemin dessiné en cyan définit le propro-blème et sa localisation dans l’application..

de l’évolution de l’indicateur concerné au cours du temps pour mettre en évidence l’anomalie.

Paradyn n’offre que deux visualisations non interactives, un tracé