Le traçage logiciel d applications parallèles : conception et ajustement de qualité Eric Maillet To cite this version: Eric Maillet. Le traçage logiciel d applications parallèles : conception et ajustement de qualité. Réseaux et télécommunications [cs.ni]. Institut National Polytechnique de Grenoble - INPG, 1996. Français. <tel-00005001> HAL Id: tel-00005001 https://tel.archives-ouvertes.fr/tel-00005001 Submitted on 23 Feb 2004 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Thçese prçesentçee par Eric MAILLET pour obtenir le grade de Docteur de l'institut National Polytechnique de Grenoble èarr^etçe ministçeriel du 30 Mars 1992è èspçecialitçe: Informatiqueè Le traçcage logiciel d'applications parallçeles : conception et ajustement de qualitçe Date de soutenance : 6 septembre 1996 Composition du jury Prçesident : Michel Adiba Examinateurs : Claude Jard èrapporteurè Brigitte Plateau èdirecteur de thçeseè Pierre Valiron Jan Van Campenhout èrapporteurè Jean-Marc Vincent Thçese prçeparçee au sein du Laboratoire de Modçelisation et Calcul í IMAG
ça Simone ça mes parents et ça tous mes amis
Remerciements Je tiens ça remercier Michel Adiba qui m'a fait l'honneur de prçesider ce jury de thçese. Je remercie çegalement Claude Jard et Jan Van Campenhout d'avoir acceptçe de rapporter sur ce travail de thçese. Je remercie Pierre Valiron qui a acceptçe de participer ça mon jury de thçese. Un grand merci çegalement ça mes directeurs de thçese Brigitte Plateau et Jean-Marc Vincent. Les nombreuses discussions qu'on a eu ensemble, que ce soit dans le cadre de l'çequipe Alpes ou en t^ete ça t^ete, çetaient pour moi d'une trçes grande valeur. Merci ça tous ceux qui ont lu le manuscrit de ma thçese, me faisant part de leurs commentaires et suggestions. Je pense bien çevidemment aux rapporteurs, Pierre, Brigitte et Jean-Marc, mais aussi ça Jacques Chassin, Florin Teodorescu, Pierre-Eric Bernard et Jo~ao Paulo Kitajima. Je tiens çegalement ça remercier mes collçegues de bureau Fred Guinand et Pierre-Eric qui, bien qu' èimperturbables è devant leurs çecrans èque ce soit au travail ou au jeu ;-è, çetaient toujours prçesents, pr^ets ça discuter èet pas que d'informatiqueè crçeant ainsi une ambiance de travail particuliçerement agrçeable que j'ai bien apprçeciçee lors de la rçedaction. Merci aussi ça tous les membres de notre ancienne çequipe du centre ville, au sein de laquelle j'ai commencçe mathçese : Brigitte, Jean-Marc, Jacques, Denis, Jean-Louis, Gilles, Joelle, Nathalie, Jo~ao Paulo, Alain, Pascal, Fred, Cçecile, Yves, Titou, Lolo, Phil, Xtof, Yannick, Michel C., Michel R., Alexandre, Luc, Evelyne et honte ça moi si j'ai oubliçe quelqu'un! Merci çegalement ça Alain, l' èautre Luxembourgeois è de Grenoble... Je remercie çegalement Laurent et Matthieu qui çetaient particuliçerement eæcace dans leur contribution au codage de TapeèPVM. Merci aussi ça tous les utilisateurs de TapeèPVM, en particulier ça Jo~ao Paulo, Wlodzimierz et Francesco, dont les remarques m'ont permis de corriger un grand nombre de èbugs è. Finalement, je tiens tout particuliçerement ça remercier mes parents qui qui m'ont toujours encouragçe ça faire des çetudes et si aujourd'hui, j'en suis arrivçe lça, je le dois beaucoup ça eux. Finalement j'exprime toute ma gratitude ça Simone pour sa prçesence, ses encouragements et sa bonne humeur durant
ces trois annçees de thçese ça Grenoble.
R ç ESUM ç E DE LA TH ç ESE vii Rçesumçe de la thçese En raison de leur faible co^ut, les traceurs logiciels sont aujourd'hui largement utilisçes pour mesurer les performances d'exçecutions d'applications parallçeles. A part leur caractçere çeconomique, ces traceurs sont de surcro^çt facilement portables, s'adaptent ça un nombre variable de processeurs è èscalabilitçe èè et fournissent des mesures dontlasçemantique est celle de l'application tracçee. Malgrçe ces atouts, le traceur logiciel ne peut pas fournir la m^eme qualitçe de mesures qu'un traceur matçeriel ou hybride. Ces derniers disposent en eæet d'une horloge globale de temps physique et de dispositifs dçediçes ça la gçençeration et ça l'çevacuation des informations tracçees. D'une part, cela leur permet de dater les actions rçeparties de façcon causalement cohçerente et d'autre part, l'instrumentation peut ^etre eæectuçee sans inæuencer le comportement de l'exçecution observçee. Cette thçese se concentre sur la notion de qualitçe reprçesentative des traces obtenues par voie logicielle sur des exçecutions de programmes parallçeles communiquant par messages. Nous proposons une sçerie de modçeles et de mçethodes permettant de rçeajuster la qualitçe d'une telle trace aæn d'approcher la qualitçe des mesures obtenues sur un systçeme de trace matçeriel. Dans la premiçere partie de la thçese, nous commençcons par une prçesentation gçençerale de la mesure et de l'analyse des performances de programmes parallçeles, et nous passons en revue quelques techniques et outils existants. Dans la deuxiçeme partie, nous çetudions en dçetail le problçeme de datation physique dans un environnement d'exçecution parallçele dçepourvu d'une horloge physique globale, mais çequipçe d'un ensemble d'horloges distinctes, une par processeur. En gçençeral, il y a un çecart non-nçegligeable entre les valeurs de ces horloges, çecart qui, en plus, est variable dans le temps èdçeriveè. C'est pourquoi, dans un tel environnement, la datation rçepartie des actions d'un calcul parallçele est diæcile. Aprçes avoir rappelçe le principe des mçethodes statistiques de calcul de temps global, nous proposons une technique qui permet de rçeduire considçerablement le temps d'çechantillonnage des horloges. Cette mçethode, appelçee SBA, a çetçe largement validçee par la pratique et a dçejça çetçe adoptçee dans diæçerents environnements de programmation parallçele,
viii R ç ESUM ç E DE LA TH ç ESE dont Athapascan èprojet APACHE ça l'imagè, Pom èprojet PAMPA ça l'irisaè ainsi que le projet europçeen Sepp èsoftware Engineering for Parallel Processingè. Elle oære un accçes suæsamment prçecis et confortable au temps global pour pouvoir rivaliser avec une solution matçerielle. Nous abordons ensuite le problçeme de l'eæet de sonde qui rçesulte du partage des ressources du systçeme entre l'outil d'instrumentation logiciel et l'application instrumentçee. Cet eæet se manifeste tout d'abord par une augmentation du temps d'exçecution, allant jusqu'ça 25è sur les systçemes qu'on a çetudiçes. Pour les applications non-dçeterministes, comme celles basçees sur une dçecomposition dynamique du travail, l'eæet de sonde peut en plus entra^çner un changement de comportement. L'analyse des mesures fournies par l'instrumentation peut donc mener ça des modiæcations ineæcaces de l'application qui n'amçeliorent en rien ses performances d'exçecution. Nous prçesentons diæçerents modçeles de correction des perturbations, permettant de compenser l'eæet de sonde par un traitement post-mortem des traces dans le but de retrouver la dynamique originale d'une exçecution non-instrumentçee. Nous discutons les conditions d'applicabilitçe de ces modçeles. Pour les applications ça comportement dçeterministe, comme les nombreuses applications numçeriques basçees sur une dçecomposition statique du travail, la correction permet de retrouver exactement la dynamique des exçecutions non-instrumentçees èaux perturbations indirectes prçesè. Sur ce type d'application, nos expçeriences montrent que la correction enlçeve de 70è ça 95è des perturbations du temps d'exçecution. Nous traitons ensuite plus en dçetail le cas des applications non-dçeterministes, comme celles basçees sur une dçecomposition dynamique du travail, et nous introduisons la notion d'approximation conservatrice : la trace dite approchçee, calculçee par le correcteur des perturbations, appartient ça la m^eme classe de comportement que la trace de dçepart. L'apport des techniques de rçeexçecution dçeterministe est çegalement discutçe. Dans la troisiçeme partie, on prçesente l'outil de trace TapeèPVM, dçeveloppçe dans le cadre de cette thçese. Les mçethodes de qualitçe de traces proposçees dans la deuxiçeme partie ont çetçe implantçees dans TapeèPVM : le traceur construit automatiquement une rçefçerence globale de temps pour la datation des çevçenements et inclut un outil de correction d'intrusion. Par ailleurs, les traces obtenues peuvent ^etre converties au format PICL ce qui permet leur exploitation avec l'outil de visualisation Paragraph. TapeèPVM propose çegalement un outil de prçediction de performances et un outil de test d'adçequation de modçeles des temps de communication sur des traces d'exçecutions rçeelles.
TABLE DES MATI ç ERES ix Table des matiçeres Rçesumçe de la thçese vii I Prçesentation 1 1 Introduction gçençerale 3 2 La mesure des performances 7 2.1 Introduction............................ 7 2.2 Les outils de mesure de performance.............. 9 2.2.1 Les mçetriques de performance.............. 9 2.2.2 La visualisation...................... 11 2.3 L'observation èin vivo è...................... 12 2.3.1 Les niveaux d'observation................ 12 2.3.2 Les mçethodes d'observation............... 15 2.3.3 Comparatif........................ 17 2.4 Les outils de traçcage existants.................. 18 2.4.1 Les techniques d'instrumentation des programmes... 18 2.4.2 L'environnement AIMS.................. 20 2.4.3 L'environnement ANNAI................. 21 2.4.4 Le traceur TapeèPVM.................. 24 2.5 Conclusion............................. 24 II La qualitçe reprçesentative des traces 27 3 La datation globale des çevçenements 29 3.1 Introduction............................ 29 3.2 Les mçethodes statistiques.................... 34 3.2.1 Le modçele d'horloge physique et le temps global.... 34 3.2.2 Les çechantillons...................... 35
x TABLE DES MATI ç ERES 3.2.3 L'estimation du temps global.............. 36 3.2.4 Quelques expçeriences prçeliminaires........... 41 3.3 Etude ç de l'erreur d'estimation.................. 43 3.3.1 Analyse expçerimentale dçetaillçee d'çechantillons..... 43 3.3.2 Modçelisation de l'erreur................. 48 3.3.3 La pertinence du modçele linçeaire............ 51 3.4 Implantation........................... 53 3.4.1 Contraintes dues au systçeme............... 54 3.4.2 Stratçegie SB : extrapolation du temps global...... 55 3.4.3 Stratçegie SBA : interpolation du temps global..... 57 3.4.4 SB et SBA par la pratique................ 60 3.5 Discussion de l'approche de IBM................ 65 3.6 Rçesumçe et conclusions...................... 67 4 La correction de l'eæet de sonde 71 4.1 Introduction............................ 71 4.2 Notations et hypothçeses..................... 75 4.2.1 La trace.......................... 75 4.2.2 Les perturbations directes et indirectes......... 77 4.3 Le modçele des æots sçequentiels indçependants.......... 80 4.3.1 Le modçele de correction des perturbations....... 80 4.3.2 Rçeæexions sur la base de temps............. 82 4.4 Le modçele du rendez-vous.................... 83 4.5 Le modçele de l'envoi asynchrone................. 85 4.5.1 Les deux schçemas de communication.......... 85 4.5.2 Un premier modçele de correction des perturbations.. 86 4.5.3 Le problçeme de l'çevçenement èarrivçee de message è... 87 4.5.4 L'approche de Sarukkai-Malony............. 89 4.5.5 Notre approche...................... 90 4.6 Comportement non-dçeterministe................. 92 4.6.1 Non-dçeterminisme et approximation conservatrice... 93 4.6.2 La qualitçe del'approximation conservatrice....... 96 4.6.3 Extensions de l'approximation conservatrice...... 98 4.6.4 L'apport de la rçeexçecution dçeterministe......... 102 4.7 Les rçesultats expçerimentaux................... 107 4.7.1 Jacobi : une premiçere application test.......... 107 4.7.2 Le jeu d'essais du NAS.................. 113 4.7.3 Discussion des rçesultats................. 114 4.8 Conclusions et perspectives.................... 115
TABLE DES MATI ç ERES xi III Le traceur TapeèPVM 119 5 La gçençeration de traces d'exçecution 121 5.1 L'environnement ALPES..................... 121 5.2 Travaux connexes......................... 123 5.3 Architecture de TapeèPVM................... 125 5.3.1 Instrumentation...................... 126 5.3.2 L'exçecutif du traceur................... 127 5.3.3 La bibliothçeque de lecture de traces........... 128 5.3.4 Les outils de post-traitement detraces......... 129 5.4 Conclusion............................. 130 6 Le post-traitement des traces 133 6.1 La datation globale des çevçenements............... 133 6.2 La correction de l'eæet de sonde................. 135 6.2.1 Rappel du principe de la correction de perturbations. 135 6.2.2 L'algorithme de parcours pour la correction...... 135 6.2.3 L'outil de correction de TapeèPVM........... 137 6.3 Le test de modçeles des temps de communication........ 139 6.3.1 Intçer^et du test de modçeles................ 139 6.3.2 Test statistique utilisçe.................. 139 6.3.3 Exemple d'utilisation du test.............. 141 6.4 La prçediction des performances................. 143 6.4.1 Intçer^et de la prçediction des performances........ 143 6.4.2 L'outil de prçediction de TapeèPVM........... 144 6.4.3 Expçeriences prçeliminaires................. 145 6.5 Conclusion et perspectives.................... 146 IV Conclusion 149 Bilan et perspectives 151
xii TABLE DES MATI ç ERES
TABLE DES FIGURES xiii Table des ægures 2.1 prof: exemple d'un proæl d'exçecution.............. 10 2.2 Le diagramme espace-temps de Paragraph : illustration visuelle d'un problçeme de dçesçequilibrage de charge............ 11 2.3 Diagramme des çetats observables et non-observables d'un processus................................ 14 2.4 Possibilitçes d'insertion du code d'instrumentation........ 19 2.5 Aæchage de la structure fonctionnelle d'un programme avec Annai : temps d'exçecution mesurçe et estimçe........... 23 3.1 La phase d'çechantillonnage pour le calcul du temps global.. 36 3.2 Transformation de l'çechantillon S j en R j............. 40 3.3 Tracçe del'çechantillon R j reprçesentant 50 minutes de temps de rçefçerence.............................. 44 3.4 Tracçe de l'çechantillon E j : erreurs des moindres carrçes..... 45 3.5 IBM-SP2 : çechantillon d'horloges et erreur des moindres carrçes. 47 3.6 IBM-SP2 : le modçele oscillatoire pour l'çechantillon des horloges. 52 3.7 Illustration de l'erreur d'extrapolation du temps global..... 55 3.8 Stratçegie SB : erreur d'approximation èmeganodeè........ 56 3.9 Illustration de l'erreur d'interpolation du temps global..... 57 3.10 Stratçegie SBA : erreur d'approximation èmeganodeè....... 59 3.11 Stratçegie SB : illustration de la mesure d'un dçelai nçegatif.... 59 3.12 IBM-SP2 : eæet du Network Time Protocol sur les horloges... 61 3.13 IBM-SP2 : le èbruit systçeme è................... 63 3.14 IBM-SP2 : illustration de la technique de synchronisation d'horloges proposçee par IBM...................... 66 4.1 Le modçele d'une perturbation directe.............. 77 4.2 Correction des perturbations sur un æot d'exçecution sçequentiel indçependant............................ 81 4.3 Synchronisation par rçeception bloquante : l'importance de la base de temps........................... 81
xiv TABLE DES FIGURES 4.4 Modçele de perturbation de l'çechange de message par rendezvous................................. 83 4.5 ç Emission non bloquante : les deux schçemas de communication possibles.............................. 85 4.6 Arbre de dçecision pour la correction du schçema de communication ça çemission asynchrone èmçethode qui minimise le nombre de recours au modçele de communicationè............. 91 4.7 Non-dçeterminisme : l'instrumentation peut induire un changement dans l'ordre de rçeception des messages........... 93 4.8 Le produit scalaire : exemple d'utilisation de l'opçeration de rçeduction globale de MPI..................... 98 4.9 Modçele de fonctionnement de l'opçeration de rçeduction globale èmpi reduceè............................ 100 4.10 Exçecution d'une application non-dçeterministe : illustration du changement d'ordre et de l'çechec du mçecanisme de correction par approximation conservatrice................. 104 4.11 Rçeexçecution dçeterministe selon l'ordre de rçefçerence de la ægure 4.10................................. 105 4.12 Algorithme de Jacobi èmeganodeè : comparaison visuelle d'une trace brute avec la trace corrigçee correspondante........ 110 4.13 Algorithme de Jacobi èibm-sp2è : temps d'exçecution instrumentçes, non-instrumentçes et corrigçes............... 112 5.1 ALPES: cha^çne de modçelisation et d'çevaluation......... 123 5.2 Architecture de TapeèPVM.................... 125 5.3 Structure de donnçees associçee ça l'çevçenement de rçeception de message èpvm recvè........................ 129 6.1 Fichier de statistiques du temps global de TapeèPVM..... 134 6.2 FFT-2D : bilan de la correction d'une exçecution brute..... 138 6.3 FFT2D: diagrammes espace-temps et de Gantt comparant deux exçecutions tracçees...................... 140 6.4 FFT-2D : bilan de la correction d'une exçecution perturbçee alçeatoirement defaçcon non symçetrique.............. 143
LISTE DES TABLEAUX xv Liste des tableaux 3.1 Erreurs relatives sur çecart et dçerive d'horloges obtenus par l'estimateur de Haddad et al. et par l'estimateur des temps de communication........................... 42 4.1 Algorithme de Sarukkai-Malony : nombre de recours au modçele de communication......................... 90 4.2 Nombre de recours au modçele de communication avec notre approche.............................. 92 4.3 Algorithme de Jacobi sur 16 processeurs èmeganodeè : statistiques sur les perturbations et la correction........... 109 4.4 Noyau CG du jeu d'essais NAS èibm-sp2è : statistiques sur les perturbations et la correction................. 113 4.5 Jacobi : eæet de l'instrumentation de la boucle de calcul.... 115 6.1 NAS-CG : diæçerentes prçedictions de performances ça partir d'une trace d'exçecution de la version PVM du noyau CG....... 145
xvi LISTE DES TABLEAUX
1 Premiçere partie Prçesentation
3 Chapitre 1 Introduction gçençerale Les demandes en puissance de calcul des applications scientiæques, sans cesse croissantes, ont contribuçe ça l'çevolution rapide du calcul parallçele et distribuçe durant la derniçere dçecennie. De plus en plus d'industries s'orientent vers cette solution. Citons par exemple la simulation numçerique en industrie açeronautique ou la simulation de dynamique molçeculaire en industrie pharmaceutique. En eæet, le calcul parallçele ça haute performance èhigh Performance Computing, en anglaisè joue un r^ole crucial dans l'innovation technique ; il permet de rçeduire le co^ut et d'augmenter la qualitçe d'un grand nombre de procçedçes industriels. D'autres domaines, comme le calcul symbolique ou la programmation logique tirent çegalement proæt de l'apparition des systçemes de calcul parallçeles. Ces systçemes permettent de traiter plus eæcacement des problçemes de taille de plus en plus grande. Dans le domaine du calcul parallçele haute performance, la tendance actuelle çevolue vers les machines parallçeles ça mçemoire distribuçee. Contrairement aux machines ça mçemoire partagçee, l'utilisation d'une mçemoire locale ça chaque processeur permet d'assembler un nombre de processeurs beaucoup plus çelevçe, pour s'approcher de ce qu'on appelle le parallçelisme massif. En m^eme temps, les progrçes enregistrçes dans les techniques de communication permettent l'çechange eæcace de donnçees entre un nombre çelevçe de processeurs ë76ë ; la distance entre processeurs communiquants, variable qui jouait un r^ole central dans les performances des communications sur les premiçeres machines, devient de plus en plus marginale sur les systçemes rçecents comme le T3D de CRAY ou le SP2 d'ibm ë89ë. Toutefois, ça cause de la complexitçe ça caractçeriser les performances d'une machine parallçele, il est trçes diæcile d'exploiter eæcacement l'extraordinaire puissance de calcul qu'elle oære. C'est pour cette m^eme raison que la prçediction a priori des performances d'une application donnçee sur une machine donnçee est une t^ache trçes diæcile í la dynamique d'une application ne peut
4 CHAPITRE 1. INTRODUCTION G ç EN ç ERALE ^etre connue prçecisçement qu'a posteriori, aprçes avoir expçerimentçe une exçecution eæective de cette application. La mise au point des performances d'une application sur une machine parallçele passe ainsi par une succession de rçevisions et d'observations expçerimentales de l'application. Durant ce cycle, le programmeur ajuste petit ça petit le grain de dçecoupage du travail et tente au mieux de recouvrir les communications par le calcul. Il devient clair que l'optimisation d'une application parallçele rev^et un caractçere expçerimental et empirique bien plus prononcçe que pour une application sçequentielle classique. Dans un environnement de programmation parallçele, la disponibilitçe d'outils de mesure des performances d'exçecution est donc cruciale. Les techniques classiques de comptage et d'çechantillonnage èproælingè sont insuæsantes pour dçecrire le comportement fonctionnel et les performances d'une application parallçele. La prise de traces d'çevçenements èeventdriven monitoringè s'est rçevçelçee la technique la mieux adaptçee ça la comprçehension et ça l'analyse de la dynamique des exçecutions d'une application parallçele sur un systçeme parallçele ou distribuçe ë51, 81ë. La prise de traces, dont l'implantation est loin d'^etre triviale, peut se faire au niveau matçeriel, logiciel systçeme ou applicatif. Cette thçese se concentre sur les traceurs logiciels destinçes aux dçeveloppeurs d'applications parallçeles communiquant par messages. Par traceur logiciel, on entend un mçecanisme de trace qui ne requiert pas de ressources matçerielles supplçementaires et qui partage les ressources du systçeme avec l'application observçee. En raison de leur faible co^ut, les traceurs logiciels sont aujourd'hui largement utilisçes pour mesurer les performances d'exçecutions d'applications parallçeles. A part leur caractçere çeconomique, ces traceurs sont de surcro^çt facilement portables, s'adaptent ça un nombre variable de processeurs è èscalabilitçe èè et fournissent des mesures dont la sçemantique est celle de l'application tracçee. Malgrçe ces atouts, les traceurs logiciels ne peuvent pas fournir la m^eme qualitçe de mesures que les traceurs matçeriels ou hybrides. Ces derniers disposent en eæet d'une horloge globale de temps physique et de dispositifs dçediçes ça la gçençeration et ça l'çevacuation des informations tracçees ë16, 51ë. D'une part, cela leur permet de dater les actions rçeparties de façcon causalement cohçerente et d'autre part, l'instrumentation peut ^etre eæectuçee sans inæuencer le comportement de l'exçecution observçee. Le but de ce travail de thçese est le dçeveloppement d'une mçethodologie de mise au point de la qualitçe des traces d'exçecution obtenues par voie logicielle et la validation de cette mçethodologie par l'expçerience. Nous proposons une sçerie d'algorithmes de correction de traces basçes sur un modçele exçecutif des applications et sur des modçeles de divers çelçements de l'architecture de la machine sous-jacente èhorloges physiques, communicationsè. Les outils de post-traitement de traces basçes sur cette mçethodologie permettent de rçeajuster
la qualitçe d'une trace aæn d'approcher la qualitçe des mesures obtenues avec un systçeme de trace matçeriel çequipçe d'une horloge physique globale et de sondes matçerielles non-intrusives. 5 Organisation de ce document Ce document est organisçe en quatre parties. La premiçere partie, èprçesentation è, comprend deux chapitres. Le chapitre 1, èintroduction gçençerale è, que vous ^etes en train de lire, a rapidement prçesentçe le contexte et la problçematique du traçcage logiciel de programmes parallçeles. Le chapitre 2, èla mesure des performances de programmes parallçeles è, se concentre plus en dçetail sur la mçethodologie et les techniques utilisçees et prçesente quelques environnements de mesure et d'analyse de performance existants. La deuxiçeme partie, èla qualitçe reprçesentative des traces è, introduit notre mçethodologie d'ajustement de la qualitçe des traces. Elle comprend deux chapitres qui peuvent ^etre lus indçependamment. Le chapitre 3, èla datation globale des çevçenements è, traite le problçeme de l'absence de rçefçerence globale de temps physique. Nous allons voir qu'il est possible d'obtenir une estimation suæsamment prçecise d'une rçefçerence globale de temps pour dater les çevçenements de façcon causalement cohçerente. Aprçes une analyse dçetaillçee de la nature de l'erreur d'estimation, nous proposons une mçethode de calcul du temps global par interpolation, qui permet d'obtenir une bonne prçecision, m^eme avec des pçeriodes d'çechantillonnage courtes. Le chapitre 4, èla correction de l'eæet de sonde è, propose un modçele des perturbations induites par le traceur logiciel. Nous montrons comment ces perturbations peuvent^etre caractçerisçees et enlevçees des traces d'exçecution d'applications parallçeles. Aprçes avoir dçecrit le problçeme du non-dçeterminisme de comportement de certaines applications, nous donnons une sçerie de rçesultats expçerimentaux sur des applications numçeriques. La troisiçeme partie de la thçese, èle traceur TapeèPVM è, dçecrit le traceur logiciel TapeèPVM dçeveloppçe dans le cadre de ce travail de thçese. Elle est organisçee en deux chapitres. Le chapitre 5, èla gçençeration de traces d'exçecution è, commence par la description de l'environnement ALPES, dont fait partie TapeèPVM, avant de prçesenter l'architecture gçençerale du traceur. Le chapitre 6, èle post-traitement des traces è, dçecrit nos mçethodes d'ajustement de qualitçe de traces, prçesentçees dans la deuxiçeme partie, telles qu'elles ont çetçe implantçees dans TapeèPVM. A part les outils de calcul d'un temps global physique et de correction des perturbations, TapeèPVM propose aussi
6 CHAPITRE 1. INTRODUCTION G ç EN ç ERALE des outils de tests de modçeles de communication et de prçediction de performances. La derniçere partie, èconclusion è, donne le bilan et les perspectives de ce travail de thçese.
7 Chapitre 2 La mesure des performances de programmes parallçeles Dans ce chapitre, nous proposons une introduction ça la mesure des performances de programmes parallçeles. Il s'agit de mettre en çevidence les diæçerences avec la programmation sçequentielle classique, de montrer sous quelle forme la performance d'une exçecution parallçele peut ^etre prçesentçee, de dçecrire les techniques d'instrumentation et la problçematique associçee. Nous ænirons par la prçesentation de deux environnements de mesure et d'çevaluation de performances rçecents et nous situerons TapeèPVM, outil de trace dçeveloppçe par l'auteur de la thçese, par rapport ça ces environnements. 2.1 Introduction La motivation principale pour le dçeveloppement d'une application scientiæque parallçele ou distribuçee est la vitesse d'exçecution : l'utilisation d'une architecture multi-processeur, que ce soit une machine parallçele ou un rçeseau de stations de travail 1, doit permettre non seulement d'augmenter la vitesse de traitement d'un travail mais aussi d'accro^çtre la complexitçe de ce travail. A ce propos, on peut donner l'exemple de la mçetçeorologie, oçu le parallçelisme permet d'eæectuer des simulations basçees sur des modçeles plus complexes des phçenomçenes atmosphçeriques. Une fois que les phases de vçeriæcation et de validation d'une application parallçele sont terminçees, le programmeur se concentre sur l'amçelioration des performances de cette application, i.e. sur la rçeduction de son temps d'exçecution. En eæet, les performances d'une premiçere implçementation sont gçençe- 1: Dans le cas de l'utilisation d'un rçeseau de stations de travail, on parle souvent de machine parallçele virtuelle ë29, 32ëetdecalcul distribuçe.
8 CHAPITRE 2. LA MESURE DES PERFORMANCES ralement dçecevantes au vu de ce que l'çetude de complexitçe de l'algorithme utilisçe et les donnçees techniques de la machine parallçele cible pourraient laisser croire ë64ë. Les performances applicatives, comme la vitesse d'exçecution ou le taux d'accçelçeration ècf. section 2.2è, sont en gçençeral instables sur une architecture parallçele ; de plus, on est incapable actuellement de prçedire les performances d'une application donnçee sur une architecture parallçele donnçee ë81ë. Les performances architecturales, èdonnçees techniquesè comme la performance de cr^ete 2 èen MIPS, MFLOPSè ou la frçequence d'horloge des processeurs, ne sont que des indicateurs trçes grossiers des performances applicatives. M^eme dans le domaine des machines sçequentielles, il devient de plus en plus hasardeux de se æer aux seules performances architecturales pour prçedire quelle machine sera la plus rapide dans l'exçecution d'un travail donnçe. Dans le domaine des machines parallçeles, le nombre de facteurs qui jouent sur la performance est encore bien plus çelevçe: non seulement elles renferment de multiples copies des ressources classiques ècpu, registres, caches, systçeme d'entrçee-sortieè mais elles disposent aussi d'çelçements spçeciæques comme les canaux de communication inter-processeur, par exemple. L'existence de copies multiples de ressources implique des couches matçerielles et logicielles supplçementaires implçementant les protocoles de cohçerence de cache èsystçeme fortement couplçeè ou de communication èsystçeme faiblement couplçeè, par exemple. Les jeux d'essais èbenchmarks, en anglaisè dont le but est de fournir une çevaluation quantitative de la puissance d'une machine çevoluent vers de vçeritables collections d'applicatifs d'un grand nombre de domaines du calcul scientiæque et de l'ingçenierie ë8, 35ë. Ces jeux d'essais mettent ça l'çepreuve la puissance de calcul et de communication des architectures parallçeles et fournissent des indicateurs de performances architecturales et applicatives pouvant servir ça comparer diæçerentes architectures. L'instabilitçe et la diæcultçedeprçediction des performances applicatives rçesultent des interactions complexes et gçençeralement non-dçeterministes entre le logiciel applicatif, le systçeme d'exploitation èincluant la gestion des ressources de communicationè et le matçeriel ë81ë. Aæn d'exploiter le plus eæcacement possible les ressources oæertes par une machine parallçele, le programmeur doit recourir ça des outils de mesure de performance ècf. section 2.2è qui lui permettent d'isoler expçerimentalement des phçenomçenes indicateurs de problçemes de performance qu'il est incapable de prçedire autrement. La mise au point des performances d'un programme parallçele passe ainsi par une sçerie de phases de mesures, d'çevaluation et d'optimisation attribuant 2: peak performance
2.2. LES OUTILS DE MESURE DE PERFORMANCE 9 ça la programmation parallçele un caractçere expçerimental plus prononcçe que pour la programmation sçequentielle classique. La rçepçetition de ces phases permet í d'adapter au mieux le code applicatif aux particularitçes de l'architecture multi-processeur utilisçee ; í d'avancer dans la comprçehension des interactions complexes entre l'application et l'architecture multi-processeur, ce qui pourra guider nos choix a priori lors de dçeveloppements ultçerieurs èle grain de dçecoupage, par exempleè. Du point de vue de l'ingçenierie du logiciel, il est indispensable de partager au mieux ces expçeriences au sein des çequipes de dçeveloppement. La rçedaction systçematique de rapports d'expçerience permet de gagner un temps prçecieux. Dans certains cas, l'adaptation de l'application aux caractçeristiques de l'architecture utilisçee va ça l'encontre de la portabilitçe de cette application. Toutefois, le protocole expçerimental sous-jacent, basçee sur des phases successives de mesure et d'analyse, reste valide dans la plupart des environnements parallçeles. 2.2 Les outils de mesure de performance Le but d'un outil de mesure de performance est de prçesenter au dçeveloppeur les çelçements qui lui permettent de remonter jusqu'ça l'origine du problçeme de performance qui pçenalise l'exçecution de son application. Nous distinguons deux catçegories d'outils selon que le rçesultat est prçesentçe sous forme d'une mçetrique de performance ou sous forme graphique. 2.2.1 Les mçetriques de performance Les mçetriques les plus simples sont scalaires et sont basçees sur le temps d'exçecution de l'application. Tel est le cas du rapport entre le temps sçequentiel et le temps parallçele, i.e. le taux d'accçelçeration èspeedup, en anglaisè. Il s'agit lça d'une mesure de succçes, car elle nous permet de nous situer par rapport au cas idçeal ë81ë, ça savoir l'accçelçeration linçeaire en fonction du nombre de processeurs. Cette mesure ne fournit cependant aucune indication sur la localisation d'un problçeme de performance. Les outils classiques comme prof ou gprof ë31ë, bien connus du dçeveloppeur de programmes sçequentiels, mesurent les performances sous la forme d'un proæl d'exçecution èexecution proæleè indiquant la proportion du temps
10 CHAPITRE 2. LA MESURE DES PERFORMANCES ètime Seconds Cumsecs ècalls msecècall Name 41.5 0.17 0.17 dot 24.4 0.10 0.27 5 20. _write 9.8 0.04 0.31 1 40. initmat 7.3 0.03 0.34 40200 0.0007 unf 4.9 0.02 0.36 _mcount 4.9 0.02 0.38 40200 0.0005 random 4.9 0.02 0.40 41000 0.0005 Abs 2.4 0.01 0.41 1 10. _profil Fig. 2.1 í prof: exemple d'un proæl d'une exçecution sçequentielle d'une rçesolution d'un systçeme linçeaire par la mçethode de Jacobi èmatrice de dimension 200è. La colonne èname è contient le nom des fonctions du programme classçees en fonction du pourcentage du temps d'exçecution total consommçe ècolonne èètime èè. La colonne èmsecècall è donne la durçee moyenne d'un appel de procçedure. Sur cet exemple, la fonction èdot è, qui calcule un produit scalaire, consomme le plus de temps CPU. On note çegalement la prçesence d'une fonction è proæl è reprçesentant le code d'instrumentation insçerçe par l'çediteur des liens : sur cet exemple, le sur-co^ut induit par l'observation est de 2,4è du temps d'exçecution. prof fonctionne par çechantillonnage. d'exçecution total par procçedure ècf. ægure 2.1è. Ces outils permettent au programmeur d'isoler les procçedures ça optimiser. Pour un programme parallçele, les proæls des diæçerents processus peuvent ^etre agrçegçees pour former un seul proæl. Cette mçetrique ne fournit qu'un bilan statistique sur les performances d'exçecution et ne permet pas de savoir ça quels moments prçecis de l'exçecution le problçeme de performance a lieu. En plus, en raison des dçependances entre les processus d'un programme parallçele, ce n'est pas nçecessairement la procçedure qui consomme le plus de temps CPU dont l'optimisation conduira en æn de compte ça une diminution du temps total d'exçecution ë37ë. La simple extension des mçetriques sçequentielles est clairement insuæsante pour le processus d'optimisation d'un programme parallçele. C'est pourquoi des mçetriques de performance spçeciæques ça l'exçecution d'un programme parallçele ont çetçe proposçees. Ces mçetriques sont basçees sur l'histoire de l'exçecution d'un programme, histoire qui peut ^etre reprçesentçee par un ensemble d'çevçenements signiæcatifs datçes èenvois et rçeceptions de messages, appels et retours de procçeduresè muni de l'ordre partiel de dçependance causale ègraphe d'activitçe du programmeè. Le proæl du chemin critique açetçe proposçe par Yang et Miller en 1988 ë97ë í les auteurs proposent de calculer un proæl des pro-
2.2. LES OUTILS DE MESURE DE PERFORMANCE 11 Fig. 2.2 í Le diagramme espace-temps de Paragraph : illustration visuelle d'un problçeme de dçesçequilibrage de charge. L'unitçe de temps est de 100ms. cçedures le long du chemin critique du graphe d'activitçe. D'autres mçetriques ont çetçe proposçees : le lecteur intçeressçe trouvera dans ë38ë un comparatif de plusieurs mçetriques et une analyse de leur qualitçe ça conduire ça une amçelioration eæective des programmes. Dans certains cas, ces mçetriques aboutissent ça des rçesultats contradictoires et la question d'une mçetrique idçeale reste un problçeme ouvert. Nçeanmoins, un environnement de mesure de performance se doit de proposer ça l'utilisateur une ou plusieurs de ces mçetriques. 2.2.2 La visualisation L'çevaluation d'une mçetrique fournit des rçesultats numçeriques, en gçençeral une statistique par procçedure, guidant l'utilisateur vers la partie de son programme susceptible de causer un problçeme de performance. Plut^ot que de rçesumer la dynamique d'une exçecution par de telles statistiques, la visualisation tente de reprçesenter cette dynamique sous forme graphique. Comme pour les mçetriques, il est trçes diæcile de choisir une visualisation idçeale, qui soit simple ça comprendre et qui permette d'isoler rapidement l'origine d'un problçeme de performance. Ainsi, l'outil de visualisation Paragraph ë34ë prçesente plus de 30 vues diæçerentes et permet ça l'utilisateur, moyennant un eæort de programmation, de rajouter ses propres vues. La pratique des systçemes faiblement couplçes communiquant par messages a montrçe que les vues reprçesentant l'historique d'une exçecution, comme le diagramme espace-temps èchronogrammeè et le diagramme de Gantt s'avçerent parmi les plus utiles pour comprendre une dynamique d'exçecution. Le diagramme espace-temps montre les çetats d'activitçe de chaque processus ainsi que les communications entre processus en fonction du temps. Le diagramme
12 CHAPITRE 2. LA MESURE DES PERFORMANCES de Gantt ne montre pas les communications inter-processus, mais illustre les transitions de chaque processus entre trois çetats : actif, bloquçe et systçeme. L'inspection de ces diagrammes permet d'isoler facilement des problçemes de dçesçequilibrage de charge rçesultantdecontraintes de dçependance entre les processus èblocage en attente de messagesè. La ægure 2.2 montre le diagramme espace-temps d'une partie de l'exçecution d'un programme parallçele de tri 3. L'exçecution totale prend 6 minutes ; l'extrait qui nous intçeresse ici reprçesente environ 1 minute. Lors de la premiçere itçeration, le processeur 3 est anormalement lent, sans doute ça cause d'activitçes concurrentes du systçeme d'exploitation et il ne s'agit pas ici d'un problçeme de performance au niveau applicatif. A partir de la deuxiçeme itçeration, le processeur 3 est en phase avec les autres. Nous n'allons pas dçecrire ici les aspects et la problçematique propres ça la visualisation et nous renvoyons le lecteur intçeressçe ça ë34, 3ë pour plus de dçetails. Il nous importe ici de remarquer que les outils de visualisation nçecessitent tout l'historique d'une exçecution èæchier de traceè dont la taille en termes d'espace de stockage est gçençeralement trçes importante. L'enregistrement eæcace et non-intrusif de ces informations est un des principaux problçemes de l'instrumentation. Il s'agit lça d'une diæçerence importante avec les mçetriques dont l'çevaluation peut souvent se faire ça la volçee. 2.3 L'observation èin vivo è L'çevaluation de la performance d'une exçecution, que ce soit graphiquement ou par le biais d'une mçetrique, implique l'enregistrement ou le calcul, in vivo, d'un certain nombre d'informations sur la dynamique de cette exçecution. Le programme exçecutable doit ^etre instrumentçe pour qu'il produise ou calcule ces informations lors de son exçecution. L'instrumentation consiste dans l'insertion de points de sonde dans le code applicatif : les techniques d'instrumentation sont abordçees en sous-section 2.4.1. Le terme d'observation est relatif aux aspects qualitatifs ènature et niveau d'abstractionè et quantitatifs ètemps physiqueè des informations produites par les points de sonde. 2.3.1 Les niveaux d'observation De façcon gçençerale, un systçeme informatique comprend une hiçerarchie de niveaux. On peut considçerer 4 niveaux potentiels d'instrumentation : le matçe- 3: Il s'agit du noyau IS du jeux d'essais du NAS ë91ë instrumentçe avec le traceur TapeèPVM ë63ë sur un IBM-SP2.
2.3. L'OBSERVATION èin VIVO è 13 riel, le logiciel systçeme, l'interface de programmation 4 èapiè et l'application. La nature et le volume des informations ça enregistrer, de m^eme que les techniques d'instrumentation associçees, dçependent fortement du niveau auquel on se place. Dans le cadre de cette thçese on s'intçeresse ça l'optimisation des performances de programmes parallçeles çecrits dans un langage de haut niveau èc, Fortranè utilisant une API èpvm ë29ë, MPI ë72ë, Athapascan-0 ë17ëè pour assurer la communication entre processus. Pour les programmes parallçeles, les problçemes de performance les plus dçelicats rçesident au niveau de la dçependance entre processus : temps de blocage sur un verrou, sur une rçeception de message ou ça une barriçere de synchronisation. Vu que la communication entre processus est eæectuçee par le biais de l'api, les dçependances inter-processus, ainsi que les çetats de blocage qui en rçesultent, sont directement conditionnçes par les appels des routines de l'api. Pour æxer les idçees, considçerons une API de programmation par çechange de messages sur une architecture ça mçemoire distribuçee et intçeressons-nous aux primitives d'envoi et de rçeception de messages. Comme le montre la ægure 2.3, on peut dçeænir diæçerents çetats pour un processus, suivant qu'il est actif, bloquçe ou en train d'eæectuer une entrçeeèsortie pour lire èrçeceptionè ou çecrire èenvoiè les donnçees vçehiculçees par un message. Les transitions entre ces çetats sont conditionnçees par les appels ça l'api et les informations dynamiques sur ces appels èdates de dçebut et de æn des appelsè sont essentielles pour l'çevaluation d'une mçetrique en termes de temps d'activitçe et de blocage èrapport calculècommunication, par exempleè ou pour reprçesenter graphiquement, en fonction du temps, les çetats des processus d'un programme parallçele ècf. le diagramme espace-temps et le diagramme de Gantt de Paragraph ë34ëè. Sans entrer dans les dçetails, on peut remarquer qu'au niveau applicatif on ne peut mesurer que les dates de dçebut et de æn des appels API èen les encadrant de points d'instrumentation dans le code sourceè. En particulier, pour la rçeception d'un message, il n'est pas possible de distinguer l'çetat bloquçe de l'çetat entrçeeèsortie, car la dçetection de la transition arrivçee message requiert l'observation du niveau d'abstraction sous-jacent, ça savoir celui de la couche API. L'instrumentation de cette couche n'est possible que si l'on dispose du code source de la couche de l'api. C'est le cas de la bibliothçeque de communication PVM, par exemple. De m^eme, on peut introduire un çetat supplçementaire en cas de faute de page èægure 2.3è : il y a alors une transition entre l'çetat actif et l'çetat chargement de page. Un dçefaut de page n'çetant pas directement visible au niveau applicatif, une observation ça ce niveau ne permet pas de distinguer le temps 4: Application Programming Interface
14 CHAPITRE 2. LA MESURE DES PERFORMANCES début(api_recv) actif début(api_send) fin(api_send) bloqué application fin lecture faute de page fin chargement entrée/sortie fin(api_recv) chargement de page arrivée message système API Fig. 2.3 í Diagramme des çetats observables et non-observables d'un processus. de calcul du temps consacrçe par le systçeme au remplacement de pages ègestion de la mçemoire virtuelleè. Bien que le systçeme d'exploitation enregistre des statistiques sur le nombre total de fautes de pages par processus, ces informations ne permettent pas de savoir quelle partie du code applicatif a provoquçe la faute de page èoçuè, ni ça quel moment cette faute de page s'est produite èquand è. M^eme si le code source du systçeme d'exploitation est disponible et que l'on parvienne ça dater les fautes de pages, il est diæcile en gçençeral de faire le lien entre un tel çevçenement systçeme et la partie concernçee du code applicatif. Dans ë39ë, Irvin et Miller proposent un modçele de caractçerisation des performances qui permet de faire la correspondance entre des informations de performance de bas niveau avec des entitçes du niveau applicatif. Ce modçele appelçe NV ènoun-verbè est basçe sur une modçelisation de chaque niveau d'abstraction en termes de noms èçelçements structuraux du programmeè et de verbes èactions sur les nomsè. La mçethodologie de qualitçe reprçesentative dçeveloppçee dans cette thçese concerne les mesures prises par voie logicielle et les niveaux d'instrumentation auxquels on s'intçeresse sont donc naturellement ceux de plus haut niveau, i.e. les niveaux applicatif et API.
2.3. L'OBSERVATION èin VIVO è 15 2.3.2 Les mçethodes d'observation Aprçes avoir dçecrit les niveaux potentiels d'observation en sous-section 2.3.1, nous dçecrivons dans cette sous-section les mçethodes d'observation couramment utilisçees : chronomçetrage, çechantillonnage et traçcage çevçenementiel. Le chronomçetrage ètiming è Le chronomçetrage de l'exçecution d'une application est sans doute une des premiçeres çetapes dans la mesure des performances. Toutefois, pour localiser plus prçecisçement la source d'un problçeme de performance, il faut chronomçetrer des parties du code applicatif. Ainsi, l'on pourra mesurer le temps total passçe dans une procçedure en encadrant cette procçedure de points d'instrumentation qui lisent l'horloge locale du processeur, eæectuant la diæçerence entre les deux estampilles et accumulant le dçelai rçesultant dans une variable prçevue ça cet eæet. En gçençeral, le chronomçetrage implçemente une observation au niveau applicatif. A condition que la rçesolution de l'horloge physique soit suæsamment prçecise pour mesurer le temps d'exçecution du composant fonctionnel çetudiçe, cette approche permet de construire le proæl exact d'une exçecution. En plus, elle ne requiert qu'un espace de fonctionnement restreint, gçençeralement un accumulateur par composant fonctionnel chronomçetrçe. Son dçesavantage est de provoquer l'exçecution de deux points d'instrumentation èdeux lectures d'horloge, une soustractionè ça chaque exçecution du composant fonctionnel çetudiçe, ce qui peut induire des perturbations importantes de l'exçecution. L'çechantillonnage L'çechantillonnage consiste ça observer pçeriodiquement l'çetat du systçeme et ça incrçementer un compteur associçe ça l'çetat observçe ë81ë. Les outils de mesure de performance basçes sur le calcul d'un proæl d'exçecution, comme gprof ë31ë par exemple, çechantillonnent le compteur ordinal ça intervalles de temps æxes et utilisent sa valeur comme pointeur vers une plage d'adresses pour incrçementer un compteur associçe ça cette plage. Aprçes l'exçecution du programme, la valeur de chaque compteur est proportionnelle au temps passçe ça exçecuter du code dans la plage d'adresses associçee. Des informations statiques connues au moment de la compilation permettent de faire le lien entre une plage d'adresses et les entitçees du code source correspondantes : les procçedures ou, ça un grain plus æn, m^eme les blocs çelçementaires. En plus de ces observations du niveau applicatif, l'çechantillonnage peut çegalement ^etre utilisçe pour obtenir des informations du niveau systçeme comme par exemple le
16 CHAPITRE 2. LA MESURE DES PERFORMANCES temps qu'un processus donnçe passe en mode utilisateur et en mode systçeme 5. Les implantations classiques des techniques d'çechantillonnage utilisent une pçeriode d'çechantillonnage entre 10 et 20 millisecondes. Les programmes dont le temps d'exçecution est court peuvent donc causer des erreurs d'çechantillonnage çelevçees. L'çechantillonnage est une technique trçes eæcace pour le calcul d'un proæl d'exçecution des procçedures : elle ne construit qu'une approximation du proæl exact calculçe par le chronomçetrage mais a le grand avantage de manipuler un volume modeste d'informations et d'^etre peu intrusive ècf. aussi la ægure 2.1è. Le traçcage d'çevçenements Le traçcage d'çevçenements consiste ça gçençerer une sçequence d'çevçenements. Chaque çevçenement correspond ça une action signiæcative, physique ou logique, qui modiæe l'çetat du systçeme, comme par exemple les appels et les retours de procçedures ou le dçebut et la æn de lecture de message. La connaissance de cette sçequence d'çevçenements, encore appelçee trace, qu'elle soit enregistrçee ou exploitçee ça la volçee, permet de reconstruire les çetats du systçeme, de les reprçesenter graphiquement, ou de calculer une mçetrique de performance. Les mçetriques prçesentçees dans ë38ë, dont celle du chemin critique, peuvent ^etre çevaluçees ça partir d'une trace d'çevçenements 6. Puisqu'il permet d'observer toute l'histoire d'une exçecution, le traçcage appara^çt donc comme bien plus gçençeral et æexible que l'çechantillonnage. Le traçcage consiste en gçençeral en une observation du niveau applicatif ou du niveau de l'api. Chaque enregistrement d'çevçenement contient les attributs suivants ë68, 81ë : í quelle action a eu lieu èi.e. un identiæcateur d'çevçenementè, dans quel processus et, le cas çechçeant, dans quel processus lçeger èthread, en anglaisè, í la date d'occurrence de l'çevçenement, í la rçefçerence vers le code applicatif qui a donnçe lieu ça l'occurrence de l'çevçenement, í des informations supplçementaires caractçeristiques de l'çevçenement èpar exemple, l'identiæcateur du ou des processus destinataires dans le cas d'une action d'envoi de messageè. 5: cf. l'appel systçeme UNIX getrusage 6: Notons toutefois que la disponibilitçe d'une trace dans son ensemble èenregistrçee sur disqueè n'est pas une condition nçecessaire pour calculer le proæl du chemin critique. Le lecteur intçeressçe peut se rçefçerer ça ë36ë oçu un algorithme de calcul du proæl ça la volçee est prçesentçe.