Rapport de stage de 2ème année. Filière Télécommunication

Institut Supérieur d'informatique, de Modélisation et de leurs Applications Complexe de Cézeaux BP 125 63173 Aubière Cedex www.isima.fr 1 rue de Provence BP 208-38432 Echirolles Cedex www.bull.com Rapport de stage de 2ème année Filière Télécommunication OUTIL DE VISUALISATION POUR MPI Présenté par : Cédric CABESSA cedric.cabessa.2007@anelis.isima.fr Responsable entreprise : Sylvain JEAUGEY sylvain.jeaugey@bull.net Responsable ISIMA : Christophe DUHAMEL christophe.duhamel@isima.fr Durée : 5 mois du 3 avril au 31 août 2006

Institut Supérieur d'informatique, de Modélisation et de leurs Applications Complexe de Cézeaux BP 125 63173 Aubière Cedex www.isima.fr 1 rue de Provence BP 208-38432 Echirolles Cedex www.bull.com Rapport de stage de 2ème année Filière Télécommunication OUTIL DE VISUALISATION POUR MPI Présenté par : Cédric CABESSA cedric.cabessa.2007@anelis.isima.fr Responsable entreprise : Sylvain JEAUGEY sylvain.jeaugey@bull.net Responsable ISIMA : Christophe DUHAMEL christophe.duhamel@isima.fr Durée : 5 mois du 3 avril au 31 août 2006

Remerciements Je tiens à remercier mon tuteur, Sylvain Jeaugey, pour son aide et ses conseils tout au long de ce stage. Je remercie également les membres du HPC Bull pour leur accueil chaleureux au sein de l'équipe.

Résumé L'objectif de ce stage est de développer une application permettant de visualiser en temps réel les performances d'un programme MPI. Ce travail a été réalisé dans les locaux de Bull Echirolles, dans l'équipe HPC (High Performance Computing). L'outil se présente en deux parties : Une bibliothèque statique permet la collecte des informations relatives à MPI avec la contrainte de ne pas impacter les performances. De plus nous utilisons les fonctions PMPI (surcharge de weak-symbols) ce qui permet d'être compatible avec toutes les versions de MPI. La bibliothèque se charge aussi d'envoyer les informations par le réseau à un serveur de visualisation. Le serveur permet l'observation en trois dimensions et en temps réel d'une application MPI en cours d'exécution. Il est réalisé avec la bibliothèque graphique FLTK et OpenGL. L'outil a été réalisé dans l'optique d'être le plus modulaire possible. C'est-à-dire qu'il est facile d'ajouter des modules afin de modifier le comportement du programme et observer un paramètre d'une application MPI en particulier. Mots clés : MPI, visualiser, temps réel, OpenGL, PMPI

Abstract The aim of this internship was to develop an application to monitor in real-time the performance of a MPI program. This work was done at Bull (Echirolles), in the HPC team (High Performance Computing) This tool is made of two parts: A static library collect data about MPI witout impacting performances. Moreover we use PMPI functions (overloading of weak-symbols) this allows us to be compatible with all MPI versions. The library is in charge of sending data through the network to the monitoring server. The server allows us to observe in 3D and real-time a running MPI application. It is made with the FLTK graphic library and OpenGL. This tool was designed to be modular. That mean it is easy to add modules to modify the program behavior and observe one parameters of an MPI application in particular. Keywords: MPI, to monitor, real-time, OpenGL, PMPI

Table des matières Remerciements Résumé Abstract Lexique Introduction...1 Présentation du cadre du stage...3 1) L'entreprise...3 2) L'environnement de travail...3 I. Analyse du problème...5 1) Présentation du HPC...5 2) MPI...5 3) Analyse du besoin...7 4) Le design de l'application...8 II. Conception de la solution...11 1) Bibliothèque PMPI...11 2) Le serveur de visualisation...16 III. Présentation du résultat et perspectives...21 1) Présentation...21 2) Analyse des résultats...24 Conclusion...27 Annexes Présentation de Tera10...i Exemple MPI...vii Planning réel...xi Exemple d'utilisation des weak symbols...15

Index des illustrations Illustration 1: Planning prévisionnel en semaines...8 Illustration 2: Fonctionnement de l'outil...9 Illustration 3: Diagramme de classe du serveur de visualisation...18 Illustration 4: Configuration d'un Novascale...iii Illustration 5: Une des 8 allées de Tera10...iv Illustration 6: Interconnexion des nœuds (Quadrics)...iv Illustration 7: Le système de climatisation...v Illustration 8: Planning réel...xiii

Lexique Cluster : (ou grappe) Ensemble d'ordinateurs reliés entre eux dans le but d'effectuer d'importants calculs. CVS : (Concurrent Versions System) Système de gestion des fichiers source d'un projet. CVS Permet à plusieurs personnes de travailler en même temps sur les mêmes fichiers. Le système gère les conflits et sauvegarde toutes les modifications. FLOPS : (Floating-point Operations Per Second). Nombre d'opérations à virgule flottante qu'un processeur peut réaliser en une seconde. Cette unité de mesure est souvent exprimée en GigaFLOPS (10 9 ) ou teraflops (10 12 ) FLTK : (Fast Light Toolkit, prononcez "fulltick"). Bibliothèque graphique multiplateformes écrite en C++ et permettant la réalisation d'interfaces graphiques. MPI : (Message Passing Interface) bibliothèque de fonctions, utilisable avec les langages C et Fortran. Devenu un standard dans le calcul parallèle. MPI est supporté par de nombreuses architectures. Chaque implémentation est optimisée pour un type de matériel. Noeud : Machine qui compose un cluster. Il en existe plusieurs types : les nœuds d'administrations, où un utilisateur peut se connecter pour gérer le cluster, les nœuds de calcul, c'est dans ces nœuds que les processus tournent et les nœuds de stockage qui servent à stocker les données sur disque. OpenGL : (Open Graphics Library) bibliothèque multi-plateformes pour la programmation d'applications 3D et 2D.

Introduction Dans le cadre de son offre calcul haute performance, la société Bull a besoin d'outils pour comprendre et analyser le comportement d'une application MPI. Il existe déjà des méthodes pour obtenir ces résultats, mais la plupart sont dites «post-mortem» c'est-à-dire qu'elles donnent leurs résultats lorsque le programme est terminé. On voit donc l'intérêt de développer une solution qui permette l'observation d'une application au cours de son exécution. D'abord parce qu'elle permet un gain de temps par rapport à la solution post-mortem. De plus, un autre avantage de cette approche est d'obtenir une représentation graphique du programme. Ceci peut aider le développeur à comprendre où en est l'exécution (blocage, mauvaise répartition des processus, etc.) mais peut aussi être très utile lors d'une démonstration. En effet pour répondre à un appel d'offre, Bull doit faire une démonstration aux clients afin de montrer l'efficacité de ses machines. Or avec les outils classiques, la seule information disponible est un fichier que l'on récupère après l'exécution du programme et qui contient diverses statistiques. Dans le cadre d'une démonstration, il est intéressant d'avoir un résultat visuel, c'est à dire de voir toutes les machines qui constituent le cluster et leurs évolutions au cours de temps. Afin de présenter les résultats obtenus lors de ce stage, je commencerai par présenter l'entreprise d'accueil. L'étude débutera par une analyse générale du problème, nous verrons ensuite les étapes de développement de la solution, pour finir avec les résultats obtenus et les évolutions possibles. 1

Présentation du cadre du stage 1) L'entreprise Bull est une société dont la création remonte à 1931 à Paris. Elle s'est d'abord spécialisée dans la fabrication de cartes perforées et des premières machines à calculer. Puis dans les années cinquante, Bull entre dans le domaine de l'électronique et de l'informatique tout en s'ouvrant à l'international. Après des difficultés financières, le groupe est réorganisé en plusieurs entités. En 1988, Bull participe à la création de l'open Software Foundation. Aujourd'hui, Bull met l'accent sur l'intégration et les services, ceci dans le cadre de systèmes ouverts. En 2003, le groupe a renoué avec les bénéfices et en 2004, le CEA commande un super calculateur de 602 machines de type Novascale 6160 (voir annexe 1) Aujourd'hui Tera10 est classé 1 er en Europe et 5 ème au niveau mondial dans le classement des meilleurs clusters réalisé par le top500 1. Il développe une puissance de 50 tera-flops J'ai effectué mon stage dans l'entité HPC (High Performance Computing) situé dans les locaux d'echirolles près de Grenoble. Cette équipe est chargée de développer et d'intégrer des solutions hautes performances sur Linux pour des clients comme le CEA, l'onera (Office National d'etudes et de Recherches Aérospatiales) ou encore Dassault. Plus particulièrement, j'étais affecté à l'équipe «HPC Communications Infrastructure» chargé du développement de MPI et de Lustre (système de fichier distribué). 2) L'environnement de travail Toutes les personnes sur le site ont un PC à disposition, par défaut une distribution Debian (GNU/Linux) avec un environnement KDE est installée. Chacun est libre de configurer sa machine selon ses besoins. De plus un miroir Debian est disponible sur le réseau local. Cet ordinateur est principalement utilisé pour accéder aux machines de développement et pour l'accès à internet et aux mails. Le serveur sur lequel j'ai le plus travaillé est «nsadmin», c'est le noeud d'administration d'un cluster de 2 nœuds soit 8 cpu de type Intel Itanium2 ia64 (processeurs sur 64 bits). La distribution utilisée est basée sur RedHat mais a été largement modifiée par Bull. Ce serveur sert au développement d'application ainsi qu'à lancer des processus MPI sur le cluster. 1 http://top500.org 3

Les outils disponibles sont principalement Emacs et vim pour l'édition de code. La compilation des programmes se fait avec icc (compilateur intel optimisé pour ses processeurs) ou gcc (compilateur libre, standard sur les système Linux). Pour la partie OpenGL, j'ai développé sur un serveur équipé d'une carte graphique de type Nvidia GeForce Quadro De plus, j'ai aussi pu effectuer quelques tests sur Teratec, le centre de démonstration de Bull situé à Bruyère le Chatel à côté du CEA. Ce cluster est beaucoup plus grand que celui d'echirolles et m'a permis de voir comment se comportait mon programme dans des situations plus réaliste. Il comporte 20 nœuds à 16 processeurs par nœud. Les processeurs utilisés sont des Itanium2 type Madison, c'est la génération précédente des Montecito utilisée au CEA. Tout le développement s'est fait à l'aide de CVS ce qui permet un travail collaboratif et offre un système de sauvegarde de l'historique du code. 4

I. Analyse du problème Cette partie a pour but de montrer le problème dans son contexte. Nous présenterons d'abord de façon générale le HPC avant de se focaliser sur l'utilisation de MPI. Puis nous verrons les besoins qui nous ont amené à concevoir cet outil. Enfin nous présenterons une vue globale de l'application. 1) Présentation du HPC HPC signifie High Performance Computing, que l'on pourrait traduire par calcul à haute performance. Ce terme couvre l'ensemble de l'utilisation d'outils informatiques nécessaires pour effectuer des calculs mathématiques importants. Les utilisateurs de HPC sont le plus souvent des centres de recherches liés aux domaines de la défense ou de l'énergie. Pour effectuer de tels calculs, il est nécessaire de paralléliser le traitement des données. En effet créer un unique ordinateur n'est pas réalisable pour des raisons de limites techniques, mais aussi de coût. Une solution économique consiste à utiliser plusieurs machines de calcul, reliées entre elles, que l'on pourrait considérer de l'extérieur comme un seul grand ordinateur. Aujourd'hui les clusters de calcul contiennent des milliers de processeurs. Ces processeurs sont répartit dans des nœuds de calculs eux même reliés par un réseau à haute performance. Le stockage des informations se fait sur des nœuds dédiés, l'espace de stockage atteint plusieurs peta-octet (10 15 ) (voir annexe 1 pour un exemple avec la configuration de Tera10). Les systèmes d'exploitations utilisés sont de type Unix/Linux. 73% des 500 meilleurs clusters du monde tournent sous Linux 2 (19% sous Unix). Ceci est dû au fait que ces systèmes sont plus facilement modifiables et adaptables aux besoins particuliers de ces machines. En effet, chaque constructeur modifie les logiciels utilisés sur leurs clusters pour l'adapter aux spécificités de la machine. Les modifications vont du noyau du système aux applications en passant par les bibliothèques de calculs. 2) MPI Afin d'utiliser au mieux toute la puissance des processeurs disponibles, il est nécessaire de disposer d'un moyen pour écrire des programmes parallèles. Cette tâche consiste à trouver une façon de découper un problème en plusieurs parties qui seront traitées par une unité de calcul indépendante. C'est une tâche difficile à réaliser car les algorithmes ne sont jamais 2 http://www.top500.org/stats/27 5

totalement parallélisables. Il faut donc gérer les communications entre les unités de calcul. Et contrairement à une exécution séquentielle, l'ordre des opérations n'est pas assuré, ce qui complique la tâche du programmeur. Des points de synchronisation doivent être utilisés, mais ils ralentissent le traitement. Une autre contrainte est la répartition du travail entre les processeurs, pour un traitement efficace elle doit être le plus homogène possible. Pour répondre à cette problématique, la bibliothèque de fonction MPI a été conçue. Elle permet d'exploiter des ordinateurs distants ou multiprocesseurs par passage de messages. C'est devenu un standard dans le domaine du calcul distribué. MPI est utilisable avec les langages C et Fortran ainsi qu'avec de nombreux systèmes d'exploitations et architectures. La bibliothèque est écrite en C. La première version de MPI fut présentée en 1993 grâce aux efforts de 40 organisations. En 1997, le standard MPI-2 est défini mais il faudra attendre 2005 pour voir apparaître les premières implémentations. Pour l'utilisateur, MPI se présente comme une bibliothèque. Plusieurs fonctions permettent de savoir dans quel processus on se trouve, d'envoyer ou de recevoir des messages, d'attendre des processus, etc (voir annexe 2 pour un exemple). Différents types de communication existent : La communication dite point à point où un processus échange avec un autre. Divers modes sont disponibles : bloquant, non bloquant, synchrone, asynchrone. La communication collective où plusieurs processus sont engagés dans la communication. Cette dernière se fait en définissant des groupes de processus et des communicateurs. Pour exécuter un programme MPI un «lanceur» est nécessaire. Il permet de répartir les différents processus sur les processeurs disponibles. Diverses implémentations de MPI sont disponibles. Certaines sont libres comme OpenMpi ou MPICH. OpenMPI est développé par un groupe de sociétés (Cisco, Sun, Los Alamos National Lab,...) sous une licence BSD. MPICH est un projet du gouvernement américain mené par l'argonne National Laboratory de Chicago. MPICH est aussi distribué sous une licence open-source. L'objectif de Bull est d'utiliser MPICH pour l'optimiser et l'adapter aux machines qui seront ensuite vendues. Par exemple, Bull a développé une couche sous MPI qui permet de faire le choix entre la communication par le réseau (de type Quadrics) ou la communication directe par mémoire partagée. En effet, dans le cas de deux processus qui veulent communiquer mais sont sur des nœuds différents, il 6

faut utiliser le réseau. Alors que si les processus sont sur le même nœud, on peut utiliser la mémoire partagée. On peut aussi citer l'exemple de Cpuset qui permet de partitionner une machine multiprocesseur et de créer des zones d'exécutions. Cpuset a été intégré dans le noyau Linux. Cpuset permet, par exemple, d'avoir exactement un processus par processeur. En pratique c'est dans cette configuration que Cpuset est utilisé pour MPI. En effet ceci permet d'éviter les pertes de performance dues aux placements des processus en mémoire et à l'ordonnancement. C'est pourquoi nous ne ferrons pas vraiment la distinction entre un processeur et le processus MPI qui tourne dessus. 3) Analyse du besoin Les quinze premiers jours de mon stage furent passé à me familiariser avec MPI et les différents outils de Bull (les différents serveurs et le CVS en particulier). Dans le même temps avec mon tuteur, nous avons discuté des différents aspects du stage. L'objectif est de développer un outil permettant de visualiser les performances d'une application MPI. Il doit répondre à deux demandes : Rendre visuel quelque chose qui ne l'est pas : MPI est utilisé pour faire du calcul scientifique. L'utilisateur a peu d'informations sur l'exécution de son programme. Ce n'est qu'à la fin qu'il peut récupérer ses résultats sous la forme d'une grande quantité de données qu'il faudra ensuite analyser. Ceci rend très difficile les démonstrations car l'observateur (surtout s'il n'est pas expert) ne se rend pas compte de ce qui se passe réellement sur les machines. Aider à comprendre le fonctionnement d'une application : pour le développeur, il est intéressant de visualiser ce qu'il se passe. Par exemple, si plusieurs processus sont en attente d'un autre ou si les communications se font de manière homogène ou non. Or si les outils existants fournissent ces informations, c'est de façon post-mortem, c'est-à-dire que les résultats sont disponibles qu'à la fin de l'exécution du programme. On voit donc la nécessité d'un outil permettant de représenter en temps réel et de la façon la plus attractive possible l'exécution d'un programme MPI. A la fin de la deuxième semaine, nous avons organisé une réunion avec les différentes personnes qui pourrait être intéressées par ce projet. Le but de cette réunion a été de définir plus précisément les objectifs de l'outil et les différentes contraintes auxquelles il devra obéir, mais aussi de l'intégrer avec l'existant. En particulier avec un programme d'analyses post-mortem qui a été développé chez Bull. Ce programme appelé «Profilecomm» permet le calcul des matrices de communication, c'est-à-dire de connaître précisément les 7

échanges entre chaque processus. Il a donc été décidé d'intégrer cet outil pour permettre à terme d'observer les échanges en temps réel. Cette réunion m'a permis de faire un planning prévisionnel Familiarisation avec MPI 2 Mise en place du client 6 Apprentissage Opengl 2 Mise en place du serveur 6 Intégration de Profilecomm 4 Illustration 1: Planning prévisionnel en semaines Vous trouverez en annexe le planning réel. 4) Le design de l'application Après avoir pris en compte les différentes contraintes et les objectifs que doit remplir l'application, j'ai pu écrire un «design» du projet. C'est-àdire un document qui présente l'application et donne des informations sur la façon dont elle sera implémentée. Le design fait aussi apparaître les problèmes qui devront être résolus au cours du projet. Il en ressort les points suivant : L'application doit être le moins intrusif possible : en effet MPI est utilisé dans des domaines ou la performance est primordial, il faut donc que l'utilisation des ressources soit le plus faible possible. Il faudrait que l'outil fonctionne avec toutes les versions et toutes les implémentations de MPI. Il existe deux versions majeurs de MPI (MPI-1 et MPI-2) et de nombreuses implémentations (libre et constructeur). Pour cela nous avons décidé de présenter l'outil comme une bibliothèque PMPI. (voir la partie II) La partie visualisation se fera avec OpenGL. Cette bibliothèque permet de créer des programmes en 3D et il existe des implémentations libres sous Linux. 8

Schématiquement, on peut présenter l'outil de la façon suivante : Illustration 2: Fonctionnement de l'outil Plusieurs processus MPI envoient leurs statistiques à un serveur de visualisation déporté. Le serveur réceptionne les données, les traite et en fait une représentation en trois dimensions pour l'utilisateur. L'utilisateur peut aussi agir sur l'interface graphique afin de sélectionner un paramètre particulier ou envoyer des ordres aux processus, comme par exemple l'intervalle de rafraîchissement 9

II. Conception de la solution Dans cette partie nous allons montrer plus en détail comment est construite l'application. Nous commencerons d'abord par présenter la partie MPI puis la partie visualisation. 1) Bibliothèque PMPI PMPI Afin d'être compatible avec les différentes versions et les différentes implémentations de MPI, il est préférable de ne pas modifier le code de la bibliothèque. A la place, il faudrait créer une sur-couche de MPI qui aurait pour but de recueillir les statistiques d'utilisation et de les envoyer au serveur. Pour cela la norme MPI propose une solution en utilisant les «weak symbols»: Toutes les fonctions MPI_* sont définies weak (faible) par rapport aux fonctions PMPI_*. Notons MPI_fct une fonction MPI. Si à l'édition des liens d'un programme avec la bibliothèque MPI, la fonction MPI_fct est redéfinie (dans le code du programme ou dans une autre bibliothèque) alors l'appel se fera sur la dernière fonction définie. Le code «réel» MPI se trouve alors dans PMPI_fct que l'on pourra appeler de façon explicite. On peut donc ajouter du code qui permettra d'observer l'exécution du programme dans les fonctions MPI_*. (voir annexe 4 pour un exemple d'utilisation des weak symbols) Une bibliothèque de profiling pour MPI peut se présenter de la façon suivante : int MPI_Fonction(t1 arg1,...,tn argn) { } /* début profiling */ ret=pmpi_fonction(arg1,...,argn); /* fin profiling */ /* échange avec serveur */ return ret; A l'intérieur de chaque fonction, il faut donc écrire le code capable de calculer les données utiles et de les envoyer au serveur de visualisation. 11

Modularité Pour avoir une bibliothèque MPI complète, il faut écrire la couche de profiling pour toutes les fonctions MPI (soit près de 200 fonctions). De plus il faut être capable d'observer différents paramètres suivant la demande. Afin de pouvoir ajouter et enlever facilement des modules de calcul de statistiques sur MPI, nous avons décidé d'utiliser un système de script qui générera les fichiers de la bibliothèque. Sous la forme source de la bibliothèque, on aura un ensemble de fichiers avec un fichier par fonction MPI. Ces fichiers seront générés en utilisant un ensemble de règles et des sources réparties par module. Le script aura pour charge de compiler tous ces fichiers afin de générer une bibliothèque statique. Cette bibliothèque devra être liée avec les programmes MPI que l'on veut observer. Script Pour la réalisation du script, le choix c'est porté sur le langage Python. Ce langage est orienté objet et simple à prendre en main. Il dispose de nombreuses fonctions (traitement de chaînes de caractères, de fichiers, accès au réseau,...), d'un système de typage dynamique fort et une gestion de mémoire par ramasse-miettes. Le script a pour tâche de générer le code de la bibliothèque et les règles du Makefile qui serviront à la compiler. Comme l'objectif est de permettre d'écrire des modules facilement, il a fallu définir une syntaxe pour les créer. Celle ci est basée sur un principe d'arborescence de répertoires. Il y a un répertoire par module. Le nom des fichiers dans le répertoire précise la fonction MPI concernée. Un numéro permet de placer précisément le code par rapport aux autres modules. L'une des premières utilités du script a été de permettre l'intégration de Profilecomm. Ceci a amené une collaboration avec son auteur. En effet la définition du fonctionnement du script a été faite en commun. Et j'ai pu bénéficier de son retour d'expérience pour la correction des erreurs. 12

Génération Voici schématiquement comment se passe la création de la bibliothèque. Le script se nomme createlib.py, sur la ligne de commande il faut lui fournir un fichier contenant la liste de tous les prototypes de fonction MPI (prototypes.h) et le nom d'un répertoire de sortie. $ createlib.py prototypes.h lib C'est dans ce répertoire que seront créés les fichiers sources de la bibliothèque. Les modules doivent se trouver dans le dossier «modules». Il y a un dossier par module. Le script va placer le contenu des fichiers dans les fonctions MPI de la façon suivante: PMPI Si le fichier commence par E (end) il sera placé après l'appel PMPI Si le fichier commence par S (start) il sera placé avant l'appel Si le fichier commence par G (global) il sera placé avant la déclaration de la fonction. Ceci est utile pour les variables globales. Un numéro précise la positon relativement à tous les fichiers de tous les modules. Enfin, un suffixe de la forme _xxx.c ou xxx est le nom d'une fonction MPI (en minuscule) ou est égale à «all» si toutes les fonctions sont concernées. Si le fichier a l'extension «.h» alors il sera concaténé dans mpianalyser.h qui sera placé dans le dossier de sortie et inclus dans toutes les sources. 13

Pour résumé, un fichier module est soit un «point h» soit de la forme [G S E]nnn_fct.c /* G10_fct.c*/ Le script va générer un fichier de la forme suivante : int MPI_fct(type1 arg1,type2 arg2,...){ } int result; if(active_module1){ /* S00_fct.c */ } if(active_module2){ /* S10_fct.c */ } result=pmpi_fct(type1 arg1,type2 arg2,...); if(active_module3){ /* E05_all.c */ /* E20_fct.c */ } return result; Cette méthode permet d'insérer facilement du code dans les fonctions MPI. Les conditions sur les modules permettent de les activer ou désactiver depuis le serveur (un fichier de configuration permet aussi de les activer ou non à lors de la génération). Collecte de données En plus de ces modules que l'utilisateur peut créer, il existe un module particulier nommé «datacoll» qui est chargé de la collecte des données dans chaque module et de les envoyer par le réseau au serveur de visualisation. Pour cela, l'utilisateur doit fournir dans son module un fichier de la forme src/getdata_module.c. Ce fichier doit contenir la fonction : void getdata_module(void** ptr,size_t* size) Cette fonction renseigne l'adresse mémoire qui contient la donnée à envoyer et sa taille. (Pour être correctement reconnu par le serveur, les premiers octets du champ doivent contenir un identifiant, le rang de l'émetteur et la taille des données suivantes.) Sur le même principe il est possible de définir des fonctions pour recevoir des ordres depuis le serveur. Nous pouvons aussi signaler que le dossier src peut être utilisé pour définir toutes les fonctions que le programmeur du module juge utile. Elles 14

seront compilées et liées avec le reste de la bibliothèque, il suffit de fournir un Makefile. La communication avec le serveur s'effectue de trois façons différentes : L'inscription : dans la fonction MPI_Init (appelé au début de tout programme MPI) on crée une socket TCP. Cette socket envoie vers le serveur l'adresse IP de la machine sur laquelle s'exécute le programme MPI, un numéro de port utilisé pour les ordres et le numéro de rang MPI. Si le serveur ne peut être contacté alors l'inscription se fait dans un fichier. Ceci permettra au serveur de «récupérer» les processus déjà lancés quand il sera disponible. De la même façon une désinscription est faite lors de l'appel à MPI_Finalize. Les ordres : chaque processus MPI a une socket TCP en attente d'ordre venant du serveur. Les ordres reçus sont transmis à la fonction capable de les traiter en fonction de leurs en-têtes. Les données : une socket UDP est utilisé pour envoyer les données calculées par les modules vers le serveur de visualisation. Utilisation Après avoir créé les fichiers sources dans le répertoire de sortie, le script fournit le Makefile qui permettra de générer la bibliothèque. Les règles du Makefile sont fait de façon à compiler tous les fichiers du dossier de sortie (les fonction MPI), ainsi que tous les fichiers contenus dans les dossiers «src» de chaque module. Enfin tous ces fichiers objets sont rassemblés en une bibliothèque statique nommée libmpianalyser.a. Pour utiliser la partie client de l'outil, il suffit de lier cette bibliothèque avec un programme MPI existant. Enfin avant de lancer un programme MPI, il est nécessaire de préciser l'adresse IP et le port du serveur de visualisation sur lequel les processus MPI devront se connecter. Ceci ce fait grâce à des variables d'environnements. export MPIANALYSER_VISU_SERVER_IP=172.16.13.35 export MPIANALYSER_VISU_SERVER_PORT=12345 15

2) Le serveur de visualisation Généralités Le travail du serveur est de réceptionner les données en provenance des processus MPI et d'en faire une représentation en trois dimensions pour l'utilisateur. En plus d'afficher des informations, le serveur sert d'interface pour contrôler le déroulement de l'application. On peut envoyer des ordres aux programmes MPI pour, par exemple, contrôler la fréquences d'envoi des données ou sélectionner un module. Pour réaliser cette application, j'ai utilisé deux bibliothèques : OpenGL et FLTK. Je commencerai par présenter ces bibliothèques avant de montrer le fonctionnement du serveur. OpenGL Abréviation de Open Graphics Library. C'est une spécification qui définit un ensemble de fonctions permettant la programmation d'application 2D et 3D. Depuis sa création en 1992 par SGI, OpenGL est devenu un standard dans le domaine de la programmation d'application 3D (son principal concurrent est Direct 3D de Microsoft). OpenGL est disponible sur de nombreuses plateformes (Unix, Linux, Windows, MacOs,...) et est utilisable dans plusieurs langages (C, C++, Fortran, Python, Perl, Java,...). Plusieurs implémentations de la bibliothèque existent. Les constructeurs de cartes graphiques développent les leurs afin d'avoir les meilleures performances sur leurs matériels, mais il existe des implémentations libres. Par exemple Mesa qui est une implémentation logiciel d'opengl (pour des raison de licences, Mesa se dit très similaire à OpenGL...) La bibliothèque ne permet que de dessiner des primitives de base comme le point, la ligne et le polygone. Pour dessiner des objets plus complexes (comme une voiture, un arbre,...) on utilise d'autres bibliothèques qui fonctionnent au-dessus d'opengl. Par contre il est possible d'utiliser des textures, des effets de lumière ou de brouillard et des calculs de projections. OpenGL ne gère pas non plus de système de fenêtrage ni les événements clavier/souris. Ce choix permet d'avoir une bibliothèque plus portable car indépendante du gestionnaire de fenêtre mais impose l'utilisation d'une autre bibliothèque comme FLTK. FLTK FLTK est une bibliothèque qui permet la réalisation d'interfaces graphiques. Elle est utilisable en C++ et disponible sous Linux (X11), Windows et MacOS. Elle a pour objectif de fournir un moyen simple de créer des applications graphiques modernes. La bibliothèque est très légère (moins de 2Mo) et peut 16

être liée statiquement (ce qui permet de faciliter le déploiement de l'application). Elle est livrée avec un outil (FLUID) permettant de créer facilement son interface graphique par un système de «glisser-déposer». On peut ajouter des boutons des ascenseurs, des boites de dialogues, des zones de saisie, etc. De plus, il est possible d'ajouter une fenêtre OpenGL dans l'interface. Les événements clavier et souris sont gérés et peuvent être traités pour modifier le contenu de la fenêtre OpenGL. FLTK est livré sous la licence LGPL avec l'autorisation de lier statiquement la bibliothèque. Fonctionnement L'application de visualisation a été écrite en C++. Elle s'articule autour de cinq classes. Avant de présenter leurs fonctionnements, nous pouvons observer le diagramme de classe relatif à ce programme. 17

Illustration 3: Diagramme de classe du serveur de visualisation 18

Les classes Interfaces et Cluster. Elles représentent l'interface entre l'utilisateur et l'application. La classe Interface est générée automatiquement par l'outil FLUID fournit avec FLTK, elle fournit l'interface graphique à l'utilisateur. Cluster traite les événements clavier et souris. Cette classe dérive de Fl_Gl_Window qui est définie dans la bibliothèque FLTK et fournit des méthodes virtuelles pour l'affichage (draw) ou pour gérer les événements (handle). De plus, la classe Cluster est chargée d'assurer la cohérence entre l'interface et les variables qui la décrivent. C'est aussi dans cette classe que se trouve la boucle principale du programme. Celle-ci est réalisée grâce à la méthode statique add_timeout qui permet d'appeler une fonction particulière à intervalle régulier. Cette fonction a pour tâche principale d'aller chercher de nouvelles données sur le réseau. La classe Network. Dès le lancement du programme, une instance de Network est créée. Elle commence par créer deux sockets. Une socket TCP en attente de processus qui souhaite se connecter ou se déconnecter. Une socket UDP qui reçoit les données en provenance des programmes MPI. En plus des connexions réseaux, on vérifie aussi si des processus n'ont pas effectué leurs inscriptions dans un fichier (et non dans une socket). Ceci peut se produire si le serveur ne pouvait pas être contacté au moment du lancement de l'application MPI. Le plus souvent ceci signifie qu'il n'a pas été lancé. Cette option permet donc d'observer une application à tout moment. Comme cette classe se charge des inscriptions des processus, c'est elle qui est chargée de maintenir une liste des processus actifs. Cette liste est réutilisée par Cluster pour l'affichage. Un processus est actif à partir du moment ou il a effectué son inscription (MPI_Init). Il devient inactif s'il n'envoie plus de données et sa connexion TCP (ordre) est fermée. Dans ce cas il disparaît de la liste et n'est plus affiché. Un processus disparaît aussi lorsqu'il atteint MPI_Finalize. En plus des deux connexions citées, la classe Network gère une autre socket de type TCP pour envoyer des ordres vers les processus MPI. Ces ordres permettent d'activer ou de désactiver un module ou encore de configurer l'intervalle d'envoi des données. Elle est utilisée en particulier au lancement du serveur pour activer les modules. Enfin après avoir reçu les données, on les envoie à l'instance de Processor concerné. Chaque Processor se charge d'effectuer le traitement sur les données et d'en faire une représentation. 19

La classe Processor Elle a pour tâche de traiter les données fournies par Network et d'afficher le résultat sous la forme d'un cube coloré. Or le traitement de ces données dépend du paramètre que l'on souhaite observer. Celui-ci est choisi par l'utilisateur dans l'interface graphique. C'est pourquoi nous avons mis en place un système de module dynamique («plugin»), avec l'objectif de permettre de changer facilement la méthode d'affichage en fonction des choix de l'utilisateur. Voici comment ceci est réalisé. La classe Processeur contient une variable statique qui est un pointeur sur une instance de la classe Module. Module est une interface (méthodes virtuelles) qui définit le comportement de tous les modules. Ces méthodes permettent le traitement des données en provenance du réseau et de modifier la couleur d'un «processor». Elles doivent êtres fournies pour tous les nouveaux modules. Pour implémenter le chargement dynamique des modules, nous avons utilisé les fonctions de la famille dlopen de Linux. La classe Module contient deux méthodes statiques open_mod et close_mod. open_mod permet d'ouvrir une bibliothèque à partir du nom du module (qui correspond à un nom de fichier, utilisation de dlopen). Puis pour instancier le module on demande à dlsym de charger un symbole particulier qui correspond au constructeur de la classe. Ce symbole doit être défini comme extern ''C'' afin de dire au compilateur de ne pas modifier ce nom de symbole. En effet, au contraire des compilateurs C, les compilateurs C++ doivent modifier les noms de symboles à la compilation afin de prendre en compte, entre autres, le polymorphisme. De la même façon un appel à close_mod provoque l'appel au destructeur du module et ferme la bibliothèque dynamique (dlclose) Ce système permet de créer facilement des modules pour modifier le comportement de l'application suivant le type de données reçues. Ceci sans rien modifier à l'application de départ. Les différents modules disponibles sont automatiquement détectés et chargés sur demande de l'utilisateur. Il est inutile de recompiler l'application existante ni de refaire l'édition de liens. Utilisation De la même façon qu'avec le client MPI, il faut définir le numéro de port sur lequel le serveur va écouter. export MPIANALYSER_VISU_SERVER_PORT=12345 Remarque : Pour la réception de données et l'initialisation, on utilise le même numéro de port mais deux protocoles différents (UDP et TCP). C'est pourquoi, comme pour les clients MPI, il n'y a qu'un seul port à définir. 20

III. Présentation du résultat et perspectives. Dans cette partie nous allons décrire le fonctionnement de l'outil du point de vue d'un utilisateur, puis nous verrons ses limites et les perspectives qu'il peut offrir. 1) Présentation MPI Commençons par la partie MPI. En supposant que tout les modules sont correctement écrit, il faut commencer par choisir lesquels nous allons utiliser. Pour cela il faut éditer le fichier mod.conf. Ce fichier permet de choisir les modules qui seront compilés NB_MOD 4 GLOBAL 0 DATA_COLL 1 CALL 2 TIME 3 NB_MOD précise le nombre total de modules, les numéros suivant les noms sont utilisés pour les en-têtes qui vont déterminer à quel module appartiennent les données échangées (aussi bien les ordres que les données utiles). Il faut toujours compiler l'application avec les modules Global et Data_coll. Ce sont des modules de bases utilisés pour l'échange de données. En plus nous utilisons un module qui donne le nombre d'appels MPI (call) et un autre qui calcul le rapport entre le temps passé dans MPI et le temps total (time). Ensuite, nous générons puis compilons la bibliothèque: $createlib.py prototypes.h lib $make all Une fois que le fichier libmpianalyser.a est créé, il suffit de le lier avec un programme. $ mpicc -c test.c $ mpicc -o test test.o -lmpianalyser -L. Enfin on configure la connexion $ export MPIANALYSER_VISU_SERVER_IP=172.16.13.35 $ export MPIANALYSER_VISU_SERVER_PORT=12345 21

A partir de ce moment le programme MPI est prêt à être lancé. Si le serveur de visualisation est présent, il enverra sa demande de connexion directement, sinon il passera par un fichier. L'envoi des données se fera à la demande du serveur. Serveur Pour le serveur il suffit de donner le numéro de port à utiliser. $ export MPIANALYSER_VISU_SERVER_PORT=12345 Au démarrage, il recherche les applications déjà lancées puis les modules de visualisation qu'il peut charger. Enfin l'interface graphique est lancée. On voit ici l'application tourner sur un cluster de 16 machines, chacune avec 8 cpu. Cette capture est une simulation, en effet il m'était impossible de lancer autant de processus sur le cluster du site. Dans la fenêtre principale on voit les différents processeurs. Ils sont regroupés par machine, ici par groupe de 8. Cette sélection se fait d'après l'adresse ip. Les machines sont elle-même placées de façon homogène sur le plan. 22

Nous pouvons remarquer que chaque processeur est associé a une couleur, celle-ci traduit le taux d'activité du processeur. Ici le paramètres observé est le rapport temps total sur temps MPI (on vois sur la gauche dans le cadre «Display»). Une couleur rouge correspond a une forte activité MPI (presque tout le temps est passé dans du code MPI) alors qu'une couleur verte correspond à une faible activité. L'affichage est modifié à intervalle régulier. Celui-ci est réglable par la barre «speed», ici il est réglé à 500ms. Réduire cette fréquence peut être utile afin de ne pas saturer le réseau dans le cas d'un grand cluster. De plus une fréquences élevé impactera moins les performances MPI. L'utilisateur peut modifier la vue du cluster grâce à la souris ou le clavier. Il est possible de zoomer ou de faire tourner le plan sur deux axes. La partie gauche de la fenêtre fournie de nombreuses informations : Le nombre de processus affichés à cet instant (connected processes, ici 128) Le paramètre en cours d'observation (Display, ici Mod_time c'est-àdire le temps passé dans MPI par rapport au temps total). L'utilisateur peut cliquer sur la flèche afin de choisir le module qu'il veut visualiser. La vitesse de rafraîchissement (Speed, ici 500ms). La aussi l'utilisateur est libre de la modifier. Des informations sur le processus MPI sélectionné : on sélectionne le numéro de rang en modifiant la valeur «rank». A côté s'affiche l'adresse ip du nœud sur lequel tourne le processus. Enfin nous pouvons voir la valeur instantanée du paramètre observé (ici 54 c'est-à-dire que 54% du temps est passé dans MPI). Lorsqu'un processeur est sélectionné, il est affiché sans transparence ce qui permet de le retrouver facilement parmi les autres. Si besoin, il est possible d'augmenter la transparence de tous les autres processeurs grâce à la molette «transparency». Le cadre «active modules» permet de choisir les informations que les processus MPI envoient. Ici nous recevons les données relatives au temps passé et aux nombres d'appels. Enfin le bouton «origine» permet de retrouver la vue par défaut (zoom et rotation). La case «rotation» fait tourner le plan de façon continue. 23

2) Analyse des résultats Mise en œuvre Comme nous l'avons vu, cet outil permet de visualiser facilement l'exécution d'un programme MPI. Cette solution a l'avantage d'être simple à mettre en œuvre. En effet il suffit de lier la bibliothèque statique avec un programme existant. Pour la visualisation, le serveur a besoin d'assez peu de ressources. Les tests que j'ai pu effectuer sur mon PC ou sur le nœud nsadmin on été fait sans accélération graphique. Malgré un certain ralentissement, l'application reste utilisable. Mais il est plus confortable d'utiliser une machine équipée d'une carte graphique. Nous pouvons maintenant nous interroger à propos de l'impact sur les performances d'un programme MPI. Pour cela j'ai effectué plusieurs mesure. Le programme de test consiste à envoyer diverse donnée et à mesurer le temps de transfert. Il en ressort que lorsque la bibliothèque est liée mais sans modules actifs, la perte de performance est de l'ordre de 5%. Si on active les trois module (temps passé, nombre d'appels et Profilecomm, même si ce dernier n'envoie pas de données, il effectue tout de même un traitement) alors la perte monte à 45%. Ceci est principalement du au traitement de Profilecomm qui est assez lourd. Avec les module «call» et «time» nous avons une perte de 23%. Même si ces chiffres paraissent élevés, il faut voir que le programme de test traite le cas le plus défavorable (beaucoup d'appel MPI et envoi de message de petite taille). L'objectif des dernières semaines de stage sera de voir si il est possible d'optimiser le code pour obtenir de meilleurs résultats. Il faudra surtout s'intéresser au cas des modules inactifs. En effet si il est possible de liée la bibliothèque en impactant de façon négligeable les performances, alors il sera possible d'intégrer l'outil avec tout les programmes MPI et d'activer les modules suivant les besoins depuis le serveur. Dans ce cas même si les performances seront dégradé, l'utilisateur en est conscient et le fait pour observer le déroulement d'une application. Une fois l'observation terminée, les modules seront désactivé et l'exécution reprendra normalement. Modularité Cette méthode de visualisation est basée sur la création de divers modules, aussi bien au niveau client MPI que serveur de visualisation. Ce choix laisse une très grande liberté au développeur pour adapter l'outil à ses besoins. Par exemple, en utilisent le script python, il est très facile de créer un autre module pour compter le nombre de «barrière» dans un programme (les barrières sont des points de synchronisation, un processus dans une barrière 24

se bloque et attend ses voisins). L'outil Profilecomm a déjà été adapté pour être utilisé avec le générateur python. Une fois le module créé, il suffit d'hériter la classe Module pour transformer les données reçues en un résultat visible. On voit ici apparaître une première limite dans la conception du serveur de visualisation. En effet à l'heure actuelle le serveur ne sait afficher que des cubes de couleur. Même si cette représentation est adaptée aux paramètres liés à un seul processus (comme le temps passé, le nombre d'appel MPI,...), elle est n'est pas utilisable pour représenter les échanges entre processus. Or avec Profilecomm on souhaiterait observer les matrices de communications. Il faudra donc trouver un visuel adapté aux échanges. Limite Une autre limite évidente à cette application est qu'elle ne permet que l'observation de paramètres liés à MPI. Il est impossible par exemple d'obtenir la charge CPU des machines ou l'utilisation du réseau. Pour cela il faut utiliser des outils de surveillance de cluster comme Ganglia 3. Par contre il peut être intéressant de recouper les résultats globaux concernant tout le cluster fournis par Ganglia avec les résultats localisé sur MPI. Perspectives Le but premier de l'application était de fournir un moyen de visualiser en temps réel le fonctionnement d'une application MPI. Mais on peut très bien l'utiliser pour obtenir des résultat dit «post-mortem». Par exemple on pourrait demander au serveur d'écrire dans un fichier les résultats qu'il reçoit en plus de les afficher. Ceci pourrait aussi être fait du coté MPI si trop de données sont perdu lors de l'envoi (en effet les données sont envoyé par UDP, c'est un protocole dit non fiable, mais plus simple et donc plus «rapide») Si les données sont écrites dans un format facilement utilisable (comme le XML par exemple), il serait possible d'écrire des utilitaires pour tracer des courbes et faire des statistiques sur le comportement d'un programme. Nous pouvons même imaginer de renvoyer ces données au serveur de visualisation pour revoir le déroulement de l'application et s'arrêter ou ralentir à des moments précis. Utilisation Dans un premier temps il est probable que cet outil sera utilisé à des fin de démonstrations. Cela permettra à des personnes non spécialisées dans le domaine du calcul parallèle de prendre conscience du fonctionnement d'un programme (les échanges, la vitesse de calcul) et du matériel mis en jeu (nombre de processeurs en particulier). 3http://ganglia.info/ 25

Mais avec la création de nouveaux modules, nous pouvons penser que l'application sera utilisée par les développeurs. En effet elle permet de voir rapidement ce qu'il se passe dans un programme. Il est déjà possible de savoir si un processus est bloqué, s'il ne passe pas assez de temps dans MPI ou même s'il est détruit. L'intégration future de Profilecomm va aussi permettre de voir les échanges inter-processus et donc de savoir si un processus est surchargé de données ou au contraire s'il en reçoit très peu. 26

Conclusion L'objectif de ce stage était de réaliser un outil graphique pour l'observation en temps réel de programmes MPI. Même si de nombreuses améliorations sont encore nécessaire, l'outil tel qu'il est aujourd'hui, permet déjà d'observer le comportement d'un programme MPI en cours d'exécution. Grâce a une conception modulaire, il devrait être facile d'ajouter des fonctionnalités pour étendre les possibilités du programme suivant les besoins. Personnellement, ce stage m'a permis de mieux appréhender le monde de l'entreprise. J'ai aussi pu acquérir de nouvelles connaissances comme le langage Python et OpenGL (et plus généralement sur la conception d'interfaces graphiques). De plus, faire ce stage dans une grande société m'a permis d'assister à des conférences, une première sur les implémentations liées à MPI et une autre sur les futurs systèmes de fichiers sous Linux (ext4). 27

Annexes

Annexe 1 : Présentation de Tera10 i

Présentation Le cluster Tera10 est constitué de 544 NovaScales, chacun avec 8 processeurs Intel Itanium Dual-Core (appelé Montecito). Les serveurs sont reliés par un réseau Quadrics QsNet II. En tout, Tera 10 a une capacité de 4352 processeurs dual-core et 30 Tera octets de mémoire. 56 Novascales sont dédiés aux I/O gérant un péta octets d'espace disques et une bande passante de 100 Go/s. Illustration 4: Configuration d'un Novascale iii