Gestion dynamique d’une architecture cellulaire massivement parallèle Youssef Latrous To cite this version: Youssef Latrous. Gestion dynamique d’une architecture cellulaire massivement parallèle. Réseaux et télécommunications [cs.NI]. Institut National Polytechnique de Grenoble - INPG, 1995. Français. �tel-00005051� HAL Id: tel-00005051 https://tel.archives-ouvertes.fr/tel-00005051 Submitted on 24 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éSE PrŽsentŽe par Youssef LATROUS pour obtenir le titre de DOCTEUR de lÕINSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE (Arr•tŽ ministŽriel du 30 Mars 1992) (SpŽcialitŽ: Informatique) GESTION DYNAMIQUE DÕUNE ARCHITECTURE CELLULAIRE MASSIVEMENT PARALLéLE Date de soutenance : 12 Janvier 1995 Composition du jury: Messieurs Yves Guy Jean-Louis Jean-Luc Bernard CHIARAMELLA MAZARE ROCH BASILLE TOURSEL PrŽsident Examinateurs Rapporteurs Th•se prŽparŽe au sein du Laboratoire de GŽnie Informatique DŽdicaces Ë mon Žpouse Safia , =, Ë ma fille Meriem Ë mes parents et beaux-parents Ë mes fr•res et amis , , Ë la mŽmoire dÕun ami qui mÕest tr•s cher le Pr Djillali BELKHENCHIR. Remerciements Je tiens ˆ remercier Monsieur Yves CHIARAMELLA, Professeur ˆ lÕUJF et Directeur du LGI, pour lÕhonneur quÕil me fait en prŽsidant le jury de cette th•se. Je remercie Monsieur Guy MAZARE, Professeur ˆ lÕENSIMAG et Directeur de cette Ecole, pour la confiance quÕil mÕa tŽmoignŽe et les conseils quÕil mÕa prodiguŽs qui mÕont permis de mener ˆ terme ces travaux. Je remercie tr•s sinc•rement Monsieur Jean-Luc BASILLE, Professeur ˆ lENSEEIHT de lÕUniversitŽ de Toulouse 3 et responsable dÕŽquipe ˆ lÕIRIT, ainsi que Monsieur Bernard TOURSEL, Professeur ˆ lÕUniversitŽ de Lille 1 et responsable dÕŽquipe au LIFL, pour avoir acceptŽ dÕ•tre rapporteurs de cette th•se. M es remerciements vont Žgalement ˆ Monsieur Jean-LouisROCH, Ma”tre de ConfŽrence ˆ lÕENSIMAG, pour lÕintŽr•t quÕil a toujours portŽ ˆ mes travaux et pour lÕhonneur quÕil me fait en participant ˆ ce jury. Je tiens ˆ remercier tout particuli•rement Monsieur MichelDELAUNAY, pour le temps quÕil mÕa consacrŽ tout au long de cette th•se, aussi bien pour la mise en forme de ce manuscrit que pour son assistance aux pires moments de la programmation... Je nÕoublierai pas tous mes coll•gues du laboratoire, sans qui ce travail nÕaurait pas pu •tre rŽalisŽ dans dÕaussi bonnes conditions. QuÕils trouvent dans ces quelques lignes toute ma sympathie. RŽsumŽ Le mod•le dÕacteurs est un mod•le de calcul concurrent qui semble bien adaptŽ au mod•le dÕexŽcution des architectures massivement parall•les. Nous Žtudions son adŽquation ˆ une machine massivement parall•le ˆ grain fin ŽtudiŽe dans notre groupe; nous dŽgageons les mŽcanismes de base ˆ intŽgrer au niveau de lÕunitŽ de routage de cette machine. Pour des mod•les de programmation dynamiques de ce type, il est nŽcessaire dÕŽtablir une stratŽgie dÕallocation dynamique de processus. Nous proposons et Žvaluons une idŽe originale pour lÕallocation dynamique de processus dans une architecture massivement parall•le. Dans le cas dÕune machine ˆ grain fin comme la notre, il est primordial quÕune telle fonction nÕinduise quÕun minimum de charge supplŽmentaire en termes de communications. Nous prŽsentons une fonction intŽgrŽe de recherche de processeurs libres pour lÕexŽcution des processus dynamiques. LÕŽvaluation des principaux choix architecturaux a pu •tre menŽe gr‰ce ˆ un simulateur dŽveloppŽ dans le cadre de ce travail. Les rŽsultats obtenus, qui dŽmontrent lÕintŽr•t de lÕapproche, sont prŽsentŽs dans cette th•se. Mots clefs architecture massivement parall•le, parallŽlisme ˆ grain fin, syst•me intŽgrŽ, mod•le acteur, rŽgulation dynamique de charge, rŽseaudÕinterconnexion, gestion des ressources. Abstract The actor model which is a concurrent computing model that seems to be well suited to the massively parallel architecture execution model. We investigate its adequacy to a massively parallel fine grain machine; we derive the basic mechanisms to be integrated at the routing unit level of this machine. For dynamic programming models of this kind, it is necessary to establish a strategy for dynamic process allocation. We propose and evaluate an original approach for dynamic process allocation in a massively parallel architecture. In the case of a fine grain machine as ours, it is essential that such a function implies a minimum overhead in terms of communications. We introduce an integrated hardware function that takes in charge the search for free processors that will execute dynamic processes. The evaluation of the main architectural choices had been carried out with the help of a simulator developed as a part of this work. The results obtained in this thesis show the usefullness of this approach. Key words massively parallel architecture, fine grain parallelism, integrated system, actor model, dynamic load balancing, interconnectionnetwork, resources management. T ABLE DES M ATIéRES Introduction........................................................................................................... 3 1. Contexte de travail et objectifs...................................................... 9 1.1. Le projet ÒRŽseau Cellulaire Asynchrone IntŽgrŽÓ......................... 9 1.1.1. 1.2. Motivations et historique du projet...................................... 9 1.1.1.1.Classification des machines parall•les ................... 11 1.1.1.2.Les machines massivement parall•les .................... 11 1.1.1.2.1. Le GAPP......................................... 12 1.1.1.2.2. La Connection Machine 2....................... 13 1.1.1.2.3. La Machine MEGA .............................. 14 1.1.1.2.4. La CM5........................................... 15 1.1.1.2.5. La SP1............................................ 16 1.1.1.2.6. La Paragon ....................................... 17 1.1.1.3.Le projet R.C.A.I .......................................... 20 1.1.1.4.Processeur dŽdiŽ............................................ 21 1.1.1.5.Processeur programmable ................................. 22 1.1.2. Motivations pour une nouvelle approche.......................... 24 1.1.2.1.Mod•le statique ............................................. 24 1.1.2.2.Mod•le dynamique: allocation dynamique de ressources......... ...................................................... 25 PrŽsentation du projet R.C.A.I.......................................................... 28 1.2.1. Architecture du rŽseau......................................................... 28 1.2.2. La partie traitement............................................................. 29 1.2.3. 1.3. 2. La partie routage................................................................... 31 1.2.3.1.La stratŽgie de routage ..................................... 32 1.2.3.2.Interblocage et famine dans R.C.A.I..................... 33 Conclusion............................................................................................. 37 Mod•les de programmation et dÕexŽcution ...................... 41 2.1. DŽfinition dÕun mod•le dÕexŽcution ....................................................42 2.1.1. Mod•le physique.....................................................................43 2.2. Mod•les centrŽs objets........................................................................ 45 2.2.1. DŽfinition du mod•le objet.................................................... 46 2.2.1.1.DŽfinition dÕun objet ....................................... 46 2.2.1.2.Classes et instances ........................................ 46 2.2.1.3.HŽritage...................................................... 47 2.2.1.4.ActivitŽ dÕun objet .......................................... 48 2.2.1.5.Probl•mes liŽs au mod•le ........................... objet 49 2.2.1.5.1. Gestion de la mŽmoire .......................... 49 2.2.1.5.2. ParallŽlisme et synchronisation ................ 49 2.2.2. DŽfinition du mod•le acteur................................................. 50 2.2.2.1.DŽfinition dÕun acteur ...................................... 50 2.2.2.2.DŽlŽgation ................................................... 52 2.2.2.3.Continuation ................................................ 52 2.2.2.4.Instanciation................................................. 53 2.3. 2.2.2.5.SŽlection de mŽthodes ..................................... 53 2.2.2.6.ActivitŽ dÕun acteur......................................... 54 2.2.3. DŽfinition du mod•le dÕagents.............................................. 56 2.2.3.1.DŽfinition dÕun agent....................................... 56 2.2.3.2.DiffŽrents types dÕagents .................................. 57 2.2.3.3.Organisation des agents.................................... 57 2.2.3.4.Protocoles de communication entre .............. agents57 2.2.3.5.GranularitŽ et mod•le dÕagents............................ 57 2.2.4. Conclusion............................................................................... 59 Un mod•le dÕacteurs particulier: CANTOR ................................... 60 2.3.1. Les objets CANTOR............................................................. 60 2.3.2. Structures de contr™le et structures de donnŽes dans CANTOR ..................................................................................... 61 2.3.3. Structure dÕun programme CANTOR............................... 61 2.3.4. 2.4. 3. Les expressions de CANTOR.............................................. 62 2.3.4.1.DŽclaration de variables ........................... locales 62 2.3.4.2.Instruction conditionnelle.................................. 62 2.3.4.3.Affectation................................................... 63 2.3.4.4.Instruction de communication............................. 63 2.3.4.5.RŽpŽtition.................................................... 64 2.3.5. Un exemple de programme CANTOR............................... 65 Mise en Ïuvre du mod•le acteur dans R.C.A.I.............................. 66 2.4.1. Quelques caract•res implicites........................................... 66 2.4.1.1.Communication asynchrone............................... 66 2.4.1.2.IndŽterminisme ............................................. 67 2.4.1.3.FiabilitŽ des liens de communication ..................... 67 2.4.2. CaractŽristiques mises en Ïuvre ...................................... 67 2.4.2.1.Syst•me de tampons ....................................... 67 2.4.2.2.Gestion des rŽfŽrences (accointances) ................... 70 2.4.2.2.1. Reconfiguration dynamique dÕun rŽseau dÕacteurs ................................................ 70 2.4.2.2.2. Continuation...................................... 70 2.4.2.2.3. DŽlŽgation et Òpattern matchingÓ ............... 71 Allocation dynamique....................................................................... 75 3.1. RŽgulation de la charge dans les syst•mes massivement parall•les........................................................................................................... 75 3.1.1. Quelques dŽfinitions .............................................................. 76 3.1.1.1.RŽgulation de charge ....................................... 76 3.1.1.2.GranularitŽ .................................................. 76 3.1.1.3.Communication ............................................. 76 3.1.1.4.LocalitŽ...................................................... 76 3.1.2. Modes de rŽgulation de charge ............................................78 3.1.2.1.Mode centralisŽ ............................................. 78 3.1.2.2.Mode rŽparti................................................. 78 3.1.2.3.Mode mixte.................................................. 79 3.1.3. Modes de transfert de processus........................................ 80 3.1.4. Mode dÕŽchange dÕinformations ........................................... 81 3.1.5. 3.1.6. 3.1.7. 3.2. Crit•res pour lÕŽvaluation de lÕindice de charge................ 83 Distance et protocole de transfert de processus............. 84 StratŽgies de rŽgulation de charge..................................... 85 3.1.7.1.Allocation statique .......................................... 85 3.1.7.2.MŽthodes aveugles ......................................... 85 3.1.7.3.MŽthodes ˆ jetons .......................................... 85 3.1.7.4.Propagation du gradient ................................... 87 3.1.7.5.MŽthode des ench•res...................................... 88 3.1.7.6.MŽthode micro-Žconomique............................... 89 3.1.7.7.MŽthode stochastique ...................................... 90 3.1.8. De la prŽdiction de quelques param•tres.......................... 92 3.1.9. RŽgulation de la charge dans la machine R.C.A.I ........... 93 Mise en Ïuvre de lÕallocation dynamique........................................ 96 3.2.1. Allocation de ressources dans la machine R.C.A.I............ .......................................................................................96 3.2.1.1.Algorithme en colima•on .................................. 97 3.2.1.2.Algorithme de diffusion par ...................... ondes 101 3.2.1.2.1. Calcul des bornes des messages de rŽponses........................................................ 102 3.2.1.2.2. Protocole de rŽservation des......... cellules 103 3.2.1.3.Comparaison des deux mŽthodes de recherche de cellules libres ....................................................... 104 3.2.2. ImplŽmentation et intŽgration de la recherche par ondes....... ......................................................................................108 3.2.2.1.Structure des tampons .................................... 109 3.2.2.2.Structure du chemin de donnŽes ......................... 110 3.2.3. Une nouvelle proposition dÕalgorithme pour la rŽgulation de charge dans la machine R.C.A.I: lÕalgorithme CLIMB...........................................................................114 3.2.3.1.Principe de lÕalgorithme proposŽ ........................ 116 3.2.3.1.1. Un objet en descente ........................... 117 3.2.3.1.2. Un objet en montŽe ............................. 118 3.2.3.1.3. Etude des frottements .......................... 119 3.2.3.2.Application ˆ la rŽgulation de .................... charge 121 3.2.3.3.Cas de la machine R.C.A.I............................... 122 3.2.3.4.Quelques rŽsultats ......................................... 124 3.2.3.5.Conclusion ................................................. 136 3.3. Ramasse-miettes et gestion de la mŽmoire .................................138 3.3.1. NŽcessitŽ dÕun ramasse-miettes......................................138 3.3.2. Algorithme du compteur de rŽfŽrences ...........................139 3.3.3. Algorithme ÒMark & SweepÓ (RŽcupŽrer & Nettoyer).............................................................................................141 3.3.4. Algorithme ÒMark & CompactÓ (Marquer & Compacter).........................................................................................141 3.3.5. Algorithme ÒStop & CopyÓ (Arr•ter & Copier)..............142 3.3.6. 3.3.7. 3.3.8. 3.3.9. Algorithmes ÒgŽnŽrationnelsÓ ...........................................143 Un algorithme ÒgŽnŽrationnelÓ parall•le.........................145 Un algorithme parall•le non-bloquant.............................147 Conclusion.............................................................................150 3.3.10. Un algorithme distribuŽ pour la rŽcupŽration dÕacteurs......... .....................................................................................152 4. Autres probl•mes liŽs aux limitations de R.C.A.I.... ................................................................................................................159 4.1. Serveur de code ..................................................................................159 4.1.1. DŽfinition de lÕespace dÕadressage.....................................160 4.1.2. 4.2. 4.3. DiffŽrents types de copies de code....................................162 4.1.2.1.Duplication ................................................. 163 4.1.2.2.Copie distante .............................................. 163 4.1.2.3.Derni•re phase de la copie ...................... de code 165 4.1.3. Exemple de gestion dÕun espace dÕadressage..................165 Ramasse-miettes dans R.C.A.I......................................................167 Limitation de lÕespace dÕadressage de R.C.A.I..............................171 4.3.1. Limites physiques de la machine R.C.A.I.......................171 4.3.2. Notion de relais ....................................................................171 4.3.3. Introduction de relais pour lÕextension de l'adressage...........................................................................................174 4.3.3.1.Cas d'un relais physique ................................. 176 4.3.3.2.Cas d'un relais logique ................................... 178 4.3.3.3.DiffŽrence entre les deux types................ de relais 179 4.3.3.4.Relation entre relais et recherche de cellules libres.............. ...................................................... 181 5. ExpŽrimentation et Žvaluations .............................................187 5.1. 5.2. LÕenvironnement de simulation.......................................................188 5.1.1. Le simulateur.......................................................................190 5.1.1.1.Chargement du code ...................................... 190 5.1.1.2.Param•trage dÕune session ............................... 190 5.1.1.3.ExŽcution et extraction de mesures ...................... 190 Les benchmarks ................................................................................192 5.2.1. 5.2.2. 5.2.3. 5.3. Crible dÕErathost•ne...........................................................192 Tri dÕentiers...........................................................................194 Calcul de la suite de Fibonacci..........................................197 5.2.4. Comparaison des mod•les statique et dynamique...........................................................................................200 Quelques rŽsultats globaux sur des points dŽlicats ....................201 6. Conclusion et perspectives futures .......................................211 Bibliographie....................................................................................................217 ANNEXE I: Classification des machines parall•les ..........229 ANNEXEII: Environnement de simulation ...........................235 II.1. LÕassembleur ......................................................................................235 II.1.1. Commentaires .....................................................................236 II.1.2. Directives dÕassemblage.....................................................236 II.1.3. Instructions..........................................................................237 II.2. LÕŽditeur de liens.................................................................................240 INTR ODUC TI ON INTRODUCTION LÕorientation actuelle, de ce que lÕon pourrait appeler communŽment les Òsuper calculateursÓ, allant des calculateurs vectoriels aux machines massivement parall•les, tend ˆ favoriser lÕŽmergence des machines multiprocesseurs regroupant un certain nombre de processeurs classiques. CÕest ainsi quÕune des machines parall•les actuelles, la SP1 dÕIBM, est constituŽe dÕun rŽseau de processeurs RISC RS6000 du m•me constructeur, alors que ce processeur fut con•u ˆ lÕorigine pour la construction de stations de travail. A la base de cette tendance se trouve la conviction que lÕassemblage de processeurs ˆ haute performances pourrait supplanter les machines parall•les dont toute lÕapproche aura ŽtŽ pensŽe et rŽflŽchie autour de concepts purement parall•les (par exemple lÕiPSC dÕIntel) dont les processeurs ne peuvent, ˆ priori, •tre utilisŽs dÕune mani•re efficace que sur des architectures parall•les (contrairement aux prŽcŽdents). Cependant, de rŽcents travaux de [SCH…NAUER93] ont clairement montrŽ que les machines de la premi•re approche doivent intŽgrer des solutions aux probl•mes cruciaux soulevŽs par les architectures parall•les. En effet, lÕabsence dÕune unitŽ de routage indŽpendante par exemple, nŽcessiterait que le processeur soit interrompu pour chaque communication ˆ entreprendre - ce qui nÕest pas raisonnable. De m•me, les applications dÕingŽnierie, toujours selon ce m•me auteur, nŽcessitent dÕŽnormes calculs vectoriels. Le dŽfaut dÕune unitŽ vectorielle pŽnalise sŽrieusement ce genre dÕarchitectures. LÕapproche massivement parall•le semble •tre une meilleure alternative. La CM5 de Thinking Machine en est un bon exemple. Ces machines allient ˆ une conception relativement simple par rapport aux prŽcŽdentes, une puissance de calcul non nŽgligeable. Un de leurs atouts est la modularitŽ (lÕaugmentation de la puissance de ces machines est gŽnŽralement aisŽe). Les machines citŽes plus haut prŽsentent gŽnŽralement un nombre limitŽ de processeurs. Une des plus rŽcentes contributions au monde des machines massivement parall•les a ŽtŽ faite par CRAY Research. Il sÕagit du T3D b‰ti autour de processeurs RISC ALPHA de DEC. Cette 3 Introduction machine peut recevoir jusquÕˆ 1000 processeurs. Les concepteurs chez Kendall Square Research (KSR), quant ˆ eux, proposent la KSR2. CÕest une machine massivement parall•le ˆ mŽmoire partagŽe qui comprend de 32 ˆ5000 processeurs ÒmaisonÓ. Toutes ces propositions de machines massivement parall•les confirment la prochaine orientation des machines parall•les. Le souci actuel est dÕaffirmer leur adŽquation ˆ des domaines aussi peu investis par les machines parall•les que celui de la gestion (KSR2 supporte notamment les outils de gestion tels que COBOL ou ORACLE 7). Les machines massivement parall•les sont extensibles: leur structure est habituellement con•ue de telle fa•on ˆ ce que lÕajout de processeurs supplŽmentaires nÕentra”ne quÕun minimum de manipulations (cÕest le cas des Connections Machines qui sont organisŽes en ÒrackÓ). Ces machines adaptent la puissance de calcul aux besoins des applications en allouant le nombre nŽcessaire de processeurs. Notre projet sÕinscrit dans le cadre des machines massivement parall•les. JusquÕˆ ces derni•res annŽes, seul un parallŽlisme limitŽ Žtait exploitŽ (de lÕordre de 64 ˆ 128 processeurs). Le massivement parall•le concerne les machines qui int•grent 64K processeurs ou davantage. Cette approche Žtait rŽservŽe aux machines SIMD (Single Instruction Multiple Data), telle que laCM2. LÕoriginalitŽ du projet R.C.A.I1 (RŽseau Cellulaire Asynchrone IntŽgrŽ) a ŽtŽ dÕŽtudier une structure MIMD (Multiple Instruction Multiple Data) ˆ grain fin: le processeur ŽlŽmentaire est de taille tr•s limitŽe, dotŽ de peu de mŽmoire et associŽ ˆ une unitŽ de routage simple (10000 ˆ 20000 transistors en tout), pour rŽaliser des machines de 100000 processeurs ŽlŽmentaires. 1Le projet R.C.A.I (RŽseau Cellulaire Asynchrone IntŽgrŽ) a ŽtŽ soutenu par le Minist•re de lÕEnseignement supŽrieur et de la Recherche via le PRC-ANM (Programme de Recherche Commun en Architectures des Nouvelles Machines) et par le CNRS, via le GDR-ANM, dans le cadre des activitŽs de recherche en architecture de machines, entre 1989 et 1993. 4 Introduction Les machines massivement parall•les rendent nŽcessaire lÕŽlaboration dÕenvironnements qui en faciliteront lÕusage, et en tireront le meilleur parti. Lors du dŽveloppement dÕune application, lÕutilisateur doit sÕattaquer ˆ la difficile t‰che de rŽpartir celle-ci sur les processeurs. Le plus simple est une prŽparation statique: prŽparation, lors de la compilation, dÕun parallŽlisme statique; cependant cette approche correspond ˆ une classe de probl•mes limitŽe. Une autre approche, peut-•tre plus prometteuse, pour la rŽpartition du code serait lÕadoption du mod•le dÕexŽcution par acteurs [AGHA86a]: la rŽpartition du code revient ˆ lÕallocation des acteurs aux processeurs. Le but de nos travaux a ŽtŽ de proposer une mise en Ïuvre de la programmation suivant le mod•le dÕacteurs sur notre machine massivement parall•le R.C.A.I. LÕŽtude du mod•le dÕacteurs a permis de dŽgager un certain nombre de points: ¥ toutes les fonctionnalitŽs de ce mod•le ne doivent pas nŽcessairement avoir une projection directe au niveau de lÕarchitecture, ¥ le rŽseau de communication doit supporter dÕautres mod•les de communication que lÕactuel Žchange point-ˆ-point, ¥ le jeu dÕinstructions de la machine doit •tre Žtendu pour rŽaliser des fonctions de plus haut niveau. Dans cet ordre dÕidŽes, des notions telles que la dŽlŽgation ou la continuation peuvent aisŽment •tre traduites par un protocole dÕŽchange de messages entre les processus impliquŽs dans ces opŽrations. Par contre, la crŽation de nouveaux acteurs nŽcessite ˆ la fois: ¥ une mŽthode de diffusion (au niveau du rŽseau de communication) de la requ•te pour la recherche dÕune cellule libre, ¥ une instruction pour initier cette opŽration et rŽcupŽrer le rŽsultat de cette recherche. Parmi les probl•mes les plus importants soulevŽs par le mod•le dÕacteurs, nous pouvons citer: ¥ la nŽcessitŽ dÕŽlaborer un syst•me de rŽcupŽration dÕespace (garbage collecting), ¥ une politique pour la rŽgulation de la charge des processeurs (et Žventuellement un mŽcanisme de migration dÕobjets), ¥ un syst•me de dŽsignation (naming) des entitŽs pour les diffŽrencier. 5 Introduction Dans le premier chapitre de ce manuscrit, nous prŽsentons le contexte dans lequel sÕest inscrit cette th•se en en fixant les objectifs. Dans le second chapitre, nous passons en revue les mod•les centrŽs objets. Nous nous intŽressons ˆ un cas particulier des langages dÕacteurs, ˆ savoir le langage CANTOR. Nous exposons par la suite la mise en Ïuvre du mod•le acteur sur R.C.A.I. Dans le troisi•me chapitre, nous abordons le probl•me de lÕallocation et de la restitution dynamique de ressources dans un environnement massivement parall•le. Apr•s une prŽsentation de lÕŽtat de lÕart pour la rŽgulation de charge des processeurs, nous prŽsentons notre proposition pour rŽaliser cette opŽration: il sÕagit de lÕalgorithme CLIMB. Dans le chapitre suivant, nous nous attachons aux probl•mes relatifs aux limites physiques de la machine R.C.A.I. Pour rompre les limites dÕadressage des cellules, nous proposons une nouvelle notion, celle des relais logiques. Le cinqui•me chapitre est dŽdiŽ aux expŽrimentations et Žvaluations des mŽcanismes de gestion dynamique intŽgrŽs dans R.C.A.I. Nous terminons par une conclusion sur lÕintŽr•t de lÕapproche et quelques perspectives futures pour les travaux menŽs dans cette th•se. 6 C HAPITRE 1 C ONTEXTE DE T RAVAIL & OBJECTIFS 1. 1.1. CONTEXTE DE TRAVAIL ET OBJECTIFS Le projet ÒRŽseau Cellulaire Asynchrone IntŽgrŽÓ 1.1.1. Motivations et historique du projet Les machines massivement parall•les connaissent de plus en plus dÕengouement. Toutes les machines rŽcentes tendent ˆ conforter cette orientation: la CM5 de Thinking Machine, la KSR2 de Kendall Square Research ou encore INTEL avec sa toute derni•re machine la Paragon. La question essentielle est de conna”tre lÕopportunitŽ de ces machines. Le nombre peut-il remplacer la puissance individuelle? Construire dÕŽnormes machines avec de gros processeurs est difficilement envisageable ˆ grande Žchelle car trop cožteux... Cependant la rŽplication massive de processeurs ŽlŽmentaires ne dŽpend que de la possibilitŽ dÕen intŽgrer un nombre maximal. La technologie pour leur rŽalisation ne cesse de progresser, repoussant un peu plus loin ˆ chaque Žtape les limites dÕintŽgration sur le silicium (ou sur dÕautres supports). De ce fait, il est rŽaliste dÕespŽrer des machines intŽgrant plusieurs milliers de processeurs ÒrudimentairesÓ. Le probl•me soulevŽ alors par ce nombre dÕindividus est leur organisation et leur contr™le. Ce qui revient donc ˆ Žtablir entre eux des mŽcanismes de communications performants (dans tous les sens du terme) pour une meilleure circulation de lÕinformation. La gestion dÕune information cohŽrente est gage dÕune Žvolution ÒsaineÓ pour la rŽalisation dÕune Ïuvre commune. Les travaux menŽs au sein de notre Žquipe ont portŽ jusquÕˆ prŽsent sur la dŽfinition dÕune architecture simple, mais puissante, se contentant, ˆ la plus petite Žchelle, de rŽaliser des opŽrations ÒŽlŽmentairesÓ (essentiellement des opŽrations arithmŽtiques et des opŽrations de communication). CÕest la mise en Ïuvre dÕun nombre important de ces ŽlŽments de base et surtout leur coordination qui en font toute sa puissance. Cela nous a toujours fait penser ˆ une fourmili•re o• chaque individu, ˆ la base, poss•de une activitŽ rudimentaire. La coopŽration entre ces individus ÒŽlŽmentairesÓ en fait une 9 Chapitre 1 - Contexte de travail et objectifs sociŽtŽ organisŽe et cohŽrente, visant ˆ rŽaliser un but commun: la survie et la reproduction de lÕesp•ce! ReportŽe ˆ notre cas, cette image reste toujours valable. Les Žtudes menŽes par [RUBINI90] et [PAYAN91] ont montrŽ lÕefficacitŽ dÕune telle conception: la collaboration de t‰ches ŽlŽmentaires peut rŽaliser des fonctions de haut niveau. Historiquement, notre projet R.C.A.I (RŽseau Cellulaire Asynchrone IntŽgrŽ) a subi plusieurs phases: parti de machines dŽdiŽes ˆ des applications spŽcifiques, il a ensuite ŽvoluŽ vers une machine programmable, capable de sÕadapter ˆ plusieurs modes de programmation (comme nous le verrons par la suite). Le point commun entre ces versions successives sont: ¥ une architecture en une grille ouverte ˆ deux dimensions, ¥ un asynchronisme dÕexŽcution entre les processeurs ŽlŽmentaires, ¥ et une communication par messages comme unique moyen dÕŽchange. La tendance actuelle est, comme dans notre cas, vers le dŽveloppement dÕunitŽs de routage indŽpendantes. Nous retrouvons dans cette catŽgorie le projet MOSAIC de Caltech [ATHAS87b] [ATHAS88], le projet MEGA [GERMAIN89] avec lÕUGC (UnitŽ de Gestion des Communications), le Transputer T9000 avec son processeur de routage associŽ le C104 [MAY93] ou encore le DCM (Direct-Connect Routing Module) de lÕiPSC/2 [NUGENT88]. Le point commun entre tous ces routeurs est lÕutilisation de la technique dite du wormhole2 [SEITZ84] [DALLY87], qui semble devenir de plus en plus un standard de fait... Avant de voir en dŽtail lÕŽvolution de R.C.A.I vers une machine massivement parall•le MIMD ˆ allocation dynamique de ressources, nous introduisons dÕabord une classification des machines parall•les, puis nous prŽsentons quelques unes des machines (ˆ grain fin puis ˆ gros grain) existantes sur le marchŽ. Ces machines nous permettront de situer nos objectifs (cf. introduction). 2Se reporter ˆ la dŽfinition de cette stratŽgie au paragraphe 1.2.3.1. 10 Chapitre 1 - Contexte de travail et objectifs 1.1.1.1. Classification des machines parall•les La classification Žtablie par [FLYNN72] est maintenant un standard Žtabli. Afin de situer rapidement notre approche par rapport ˆ cette classification, nous en donnons un bref rappel ˆ ce niveau3 . Cette classification est basŽe sur le sŽquencement des donnŽes et des instructions au niveau des processeurs: ¥ Les architectures SISD (Single Instruction Single Data): cÕest la machine de Von Neumann traditionnelle; les instructions (lues ˆ partir dÕune mŽmoire vive) sont exŽcutŽes lÕune ˆ la suite de lÕautre. ¥ Les architectures SIMD (Single Instruction Multiple Data): plusieurs unitŽs de traitement sont supervisŽes par la m•me unitŽ de contr™le: mode dÕexŽcution synchrone. Les unitŽs de traitement exŽcutent la m•me instruction sur des donnŽes distinctes. ¥ Les architectures MIMD (Multiple Instruction Multiple Data): cette derni•re catŽgorie comprend lÕensembles des machines fortement couplŽes et communiquant par messages. La mŽmoire peut •tre soit partagŽe soit distribuŽe. LÕensemble des processeurs fonctionnent en mode asynchrone. La classe de machines qui nous intŽresse rel•ve du groupe des machines MIMD. Dans notre contexte, chaque processeur est dotŽ dÕune mŽmoire locale, il nÕexiste pas de mŽmoire commune. LÕoriginalitŽ de notre approche tient ˆ la petite taille du processeur ŽlŽmentaire et ˆ la finesse du grain de calcul. Pour mieux la situer, nous allons passer en revue les machines les plus proches. Nous en exposerons Žgalement dÕautres plus ŽloignŽes, mais qui rel•vent de la m•me classe de machines (MIMD). 1.1.1.2. Les machines massivement parall•les Il existe plusieurs machines parall•les sur le marchŽ. Ce nÕest plus un mythe. Une des premi•res machines qui a eu un succ•s retentissant est la CM2 de Thinking Machine. A la simplicitŽ de sa conception fut alliŽ un environnement de programmation riche. Ce qui explique en grande partie sa rŽputation. 3Nous invitons le lecteur ˆ se reporter ˆ lÕannexe I pour de plus amples informations. 11 Chapitre 1 - Contexte de travail et objectifs 1.1.1.2.1. Le GAPP Le processeur GAPP (Geometrical Arithmetic Parallel Processor) peut •tre considŽrŽ comme une machine cellulaire [SANSONNET91]. Un circuit (processeur) comporte 72 processeurs ŽlŽmentaires (1-bit), disposŽs en une matrice (grille) de 6 par 12 ŽlŽments. Chaque processeur ŽlŽmentaire peut donc communiquer avec ses quatre voisins immŽdiats par des liens sŽrie (figure1.2). (IN) Adresses 7 4 Lignes de communication UAL 1 bit 6 Lignes de 4 registres 1 bit 5 multiplexeurs (OUT) communication RAM 128 x 1 bit GO Horloge 13 Lignes de contr™le Fig.1.2. Le processeur GAPP. Chaque processeur ŽlŽmentaire est composŽ: ¥ dÕune unitŽ de calcul (UAL) un bit, ¥ ¥ ¥ ¥ dÕun registre 4 bits, dÕune mŽmoire vive de 128 bits, de 5 multiplexeurs, de 10 lignes de communication cardinales (entrŽes et sorties), ¥ et de 1 ligne de sortie globale (GO). Les circuits emploient un multiple de matrices de 6 par 12 processeurs ŽlŽmentaires. Les structures ainsi composŽes sont notamment bien adaptŽes au traitement de bas niveau dÕimages. 12 Chapitre 1 - Contexte de travail et objectifs 1.1.1.2.2. La Connection Machine 2 On peut voir la Connection Machine 2 (CM2) comme Žtant un ensemble dÕopŽrateurs du type GAPP. Cependant, la CM2 est ŽquipŽe dÕun rŽseau dÕinterconnexion, dÕune unitŽ micro-programmŽe avec un langage de microprogrammation et surtout dÕoutils logiciels. La CM2 est un super-ordinateur massivement parall•le SIMD [TUCKER88] [DELASALLE90] [TREW91] [SANSONNET91]. Il existe deux types de processeurs dans la CM2 (figure1.1): ¥ les processeurs 1-bit, qui rŽalisent les opŽrations logiques, mais Žgalement les opŽrations enti•res et en virgule flottante, ¥ et les processeurs 32-bits, utilisŽs comme des accŽlŽrateurs vectoriels de calcul. Les processeurs 1-bit sont groupŽs dans des ÒamasÓ (clusters) de 32 ŽlŽments, autour de chaque processeur vectoriel. Leur nombre est compris entre 8192 et 65536 processeurs ŽlŽmentaires. MŽmoire RAM Flags A ¥ ¥ ¥ B Contexte F C Fig.1.1. Le processeur ŽlŽmentaire de la CM2. Cet ensemble de processeurs est divisŽ en quatre partitions (de 16K processeurs chacune). On peut utiliser 1, 2 ou 4 de ces sous-ensembles (lorsque ceux-ci sont disponibles - libres). Comme la CM2 est une machine SIMD, il y a quatre processeurs de contr™le - appelŽs sŽquenceurs (sequencers). Un contr™leur est associŽ ˆ chaque partition, donc quatre programmes diffŽrents peuvent sÕexŽcuter simultanŽment sur une CM2. Cependant le contr™le global est rŽalisŽ sur un ordinateur frontal. Ce processeur frontal envoie des instructions parall•les aux sŽquenceurs, qui, ˆ leur tour, renvoient ces instructions aux processeurs 1-bit. 13 Chapitre 1 - Contexte de travail et objectifs De/Vers Les Contr™leurs Partitions Chaque groupe de 16 processeurs 1-bit est associŽ ˆ un routeur pour les communications distantes. 1.1.1.2.3. La Machine MEGA Avec la machine MEGA, nous changeons de classe de machines. Il sÕagit dÕune machine MIMD avec un processeur 16 bits et une taille de mŽmoire plus importante. La machine MEGA (Machine pour lÕExpŽrimentation des Grandes Architectures) est une machine massivement parall•le. Cette machine a ŽtŽ dŽveloppŽe par lÕŽquipe Architecture et conception des Circuits IntŽgrŽs du LRI, dirigŽe par le Professeur Jean-Paul Sansonnet. MEGA est une machine MIMD ˆ passage de messages [GERMAIN89]. Son architecture est un cube, une grille 3D (figure1.3). Le but visŽ par cette Žquipe est dÕarriver ˆ intŽgrer jusquÕˆ un million de processeurs ŽlŽmentaires (PE). Chaque PE int•gre une unitŽ centrale, une mŽmoire locale et une unitŽ de gestion des communications4. Cette machine a ŽtŽ con•ue pour la rŽsolution de probl•mes dÕintelligence artificielle. La contribution majeure de ce projet, de notre point de vue, est la dŽfinition dÕune stratŽgie de routage adaptative: le routage forcŽ. Cette technique dÕacheminement de messages permet une utilisation efficace des liens de communication [GERMAIN89]. 4A ce sujet, il existe une grande similitude entre les projets R.C.A.I et MEGA : le nombre visŽ de processeurs ˆ intŽgrer est du m•me ordre, ainsi que la sŽparation entre les unitŽs de calcul et de communication. 14 Chapitre 1 - Contexte de travail et objectifs y x z Fig.1.3. Structure du rŽseau tridimensionnel de MEGA. 1.1.1.2.4. La CM5 La CM5 est une machine MIMD ˆ mŽmoire distribuŽe dont le nombre de processeurs peut comprendre de 32 ˆ 2048 processeurs ŽlŽmentaires. Chaque processeur ŽlŽmentaire (dans sa version ÒHigh-Performance Arithmetic HardwareÓ) est b‰ti autour dÕun processeur Sparc (RISC), dotŽ dÕune mŽmoire de 32 Mo (divisŽe en quatre bancs indŽpendants de 8 Mo chacun) avec une taille de bus de 64 bits de donnŽes et 8 bits de protection de la mŽmoire (ÒECC codeÓ), et de quatre unitŽs de calcul en virgule flottante (figure1.4). LÕarchitecture de la CM5 est constituŽe de trois rŽseaux (figure1.4): ¥ le rŽseau de donnŽes (Data Network), qui g•re les communications pointˆ-point, ¥ le rŽseau de contr™le (Control Network), qui rŽalise les opŽrations globales, telles que la diffusion, la rŽduction ou les synchronisations, ¥ le rŽseau de diagnostic (Diagnostic Network), qui, non seulement permet de renseigner lÕadministrateur sur lÕŽtat du syst•me, mais Žgalement de rŽaliser la reconfiguration nŽcessaire des rŽseaux de communication (les deux prŽcŽdents) pour poursuivre le traitement en cas dÕerreur. Tout comme la machine de la m•me famille dŽcrite plus haut (la CM2), la logith•que de la CM5 est assez bien fournie. Outre les langages de programmation, tels que le CMFortran, le C* ou le *Lisp, une biblioth•que 15 Chapitre 1 - Contexte de travail et objectifs scientifique tr•s riche est proposŽe, avec des environnements de programmation (Prism) et dÕexŽcution (ˆ la Unix). Diagnostics Network Control Network Data Network P P P P PP P P PP P P P CP CP M M M M MM M M MM M M M M HIPPI or VME Interface M DataVault Graphics Output Fig.1.4. Architecture globale de la CM5. 1.1.1.2.5. La SP1 La SP1 (Scalable POWERparallel 1) est une machine parall•le dÕIBM constituŽe de 8 ˆ 64 processeurs [STUNKEL94] [CLAUSEL94]. Chaque processeur ŽlŽmentaire est un RS6000 du m•me constructeur (utilisŽ notamment dans les stations de travail). Dans le cas dÕune machine SP1 ˆ 64 processeurs, cet ensemble de processeurs est divisŽ en quatre groupes (clusters) avec deux Žtages de commutateurs (figure1.5). De chaque cluster sortent seize liens: douze vers le reste des clusters, et quatre vers des connexions externes (mŽmoire de masse ou autre). Chaque ŽlŽment du switch poss•de 8x 8 ports. Dans la figure1.5 les liens visualisŽs sont bidirectionnels; il faut donc multiplier par deux ce nombre. Le rŽseau de communication de la SP1 est synchrone. La technique de routage utilisŽe est le wormhole. Le paquet de base a une taille dÕun octet. Tous les messages doivent traverser quatre ŽlŽments du switch pour arriver ˆ destination. 16 Chapitre 1 - Contexte de travail et objectifs A titre dÕexemple, nous donnons quelques caractŽristiques de lÕIBM 9076 SP1 acquis par lÕIMAG. Cette machine est constituŽe de 32 nÏuds. Chaque nÏud poss•de une mŽmoire de 64 Mo et un disque dur de 1 Go. Il existe deux type de rŽseaux de communication: ¥ un rŽseau interne, le switch, ¥ et un rŽseau Ethernet standard pour les communications externes. Les processeurs de cette machine sont divisŽs en deux groupes de 16 nÏuds. Chacun de ces groupes est reliŽ directement ˆ un serveur de boot par le rŽseau Ethernet pour le chargement du syst•me au dŽmarrage. 1.1.1.2.6. La Paragon La structure de cette machine est une grille 2D. Elle dispose de 56 ˆ 4096 processeurs ŽlŽmentaires (PE) [PIERCE94]. Chaque nÏud de cette grille est formŽ (figure1.6): ¥ dÕun processeur de calcul (i860 XP), ¥ dÕune mŽmoire locale de 128 Mo, ¥ dÕun processeur de communication (i860), dont la t‰che est de prŽparer les messages et de les rŽceptionner, ¥ dÕun processeur de routage, le PMRC (Paragon Mesh Routing Chip), dont la stratŽgie dÕacheminement est le whormhole. Chaque PMRC est connectŽ physiquement ˆ ses quatre voisins. 17 Chapitre 1 - Contexte de travail et objectifs RS6000 ¥ ¥ ¥ ¥ Switch 4 ¥¥ ¥ ¥ ¥¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥¥ ¥ ¥ ¥¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ 4 4 4 ¥ ¥ ¥ ¥ ¥¥ ¥ ¥ ¥¥ ¥ ¥ ¥ ¥ ¥ ¥ 4 ¥¥ ¥ ¥ ¥¥ 4 ¥¥ ¥ ¥ PE PE PMRC PE PE PMRC PE PMRC PE PMRC PMRC PE PMRC PE PMRC PE PMRC ¥ ¥ ¥ ¥¥ ¥ Fig.1.5. Architecture globale de la SP1. PMRC Fig.1.6. Architecture globale de la Paragon. 18 ¥ ¥ Chapitre 1 - Contexte de travail et objectifs Cette prŽsentation ne prŽtend pas •tre exhaustive, loin de lˆ. Notre but est dÕexposer les machines les plus proches de la n™tre, pour mieux la situer. La CM2 ainsi que le GAPP semblent tr•s proches de notre conception au niveau de la taille et de la puissance de chaque processeur ŽlŽmentaire (du moins par rapport aux premi•res versions du projet R.C.A.I). Les deux premi•res machines que nous venons de voir sont toutes deux rŽgies en mode SIMD. Ce mode ne rŽpond pas ˆ la classe de probl•mes dits ÒirrŽguliersÓ, tels que les algorithmes rŽcursifs ou lÕintelligence artificielle. DÕune mani•re gŽnŽrale, lorsquÕon doit exŽcuter du code diffŽrent sur les processeurs, ce mode est incompatible5 (se reporter ˆ la dŽfinition de ce mode). DÕautre part, les machines MIMD sont toutes de tr•s grande capacitŽ (le bus de donnŽes) et nŽcessitent beaucoup dÕefforts, aussi bien humains que financiers, pour leur rŽalisation. Elles ne sont donc pas ˆ la portŽe des milieux universitaires. 5 Comme le signale [HILLIS_85], il est possible quÕune machine SIMD puisse simuler une autre machine MIMD en temps linŽaire, en utilisant un interprŽteur. Chaque processeur va interprŽter les donnŽes quÕil re•oit comme des instructions. Cette solution reste tout de m•me tr•s lourde et induit un overhead non nŽgligeable pour sa rŽalisation ! 19 Chapitre 1 - Contexte de travail et objectifs 1.1.1.3. Le projet R.C.A.I Le dŽveloppement du projet R.C.A.I a ŽtŽ suscitŽ par lÕŽlaboration dÕune machine parall•le qui, tout en gardant une conception relativement simple, ne nŽglige nullement le c™tŽ performances. LÕutilitŽ dÕune machine parall•le est dÕarriver ˆ rŽsoudre des probl•mes connus pour •tre gourmands en temps de calcul. La devise est alors de Òdiviser pour rŽsoudreÓ. Les structures en hypercube ou les grilles 3D prŽsentent, au niveau conceptuel, ŽnormŽment dÕintŽr•ts au niveau de leur rŽseau de communication. Cependant, le passage du mod•le architectural au silicium est dans la plupart des cas cožteux, voire impossible pour des structures intŽgrant plusieurs milliers de processeurs ŽlŽmentaires. Le nombre de lignes de communication ˆ rŽaliser est assez volumineux et surtout irrŽgulier (certaines lignes sont plus grandes que dÕautres). La projection la plus naturelle sur un plan de silicium est la grille 2D. Les lignes de communication entre ŽlŽments voisins sont toutes de m•me longueur. Elles prŽsentent donc les m•mes caractŽristiques Žlectriques (dŽlai de transmission, bande passante...). Certains processeurs parall•les, tel que le GAPP, prŽsentent lÕinconvŽnient majeur de ne rŽaliser que des communications fixes. Seuls les processeurs voisins (directement reliŽs) peuvent entrer en communication. Lors de la conception de la machine R.C.A.I, notre souci a toujours ŽtŽ dÕŽtablir des communications gŽnŽrales, o• chaque processeur peut communiquer avec nÕimporte quel autre processeur. Plusieurs tentatives ont ŽtŽ rŽalisŽes au cours du projet R.C.A.I [CORNU88] [OBJOIS88] [LATTARD89] [FAURE90] [PAYAN91] [RUBINI92] [KARABERNOU93]. Nous allons en retracer les plus importantes. 20 Chapitre 1 - Contexte de travail et objectifs 1.1.1.4. Processeur dŽdiŽ Les premi•res expŽriences du projet R.C.A.I ont dŽbouchŽ sur la conception de processeurs dŽdiŽs. Chaque processeur a ŽtŽ con•u pour la rŽalisation dÕune fonction spŽcifique. Les deux premi•res applications pour ce processeur ont ŽtŽ: ¥ la simulation logique de circuits intŽgrŽs [OBJOIS88], ¥ et la reconstruction dÕimages [LATTARD89]. A cet Žgard, ces processeurs peuvent aisŽment •tre considŽrŽs comme des co-processeurs de haut niveau. NORD Tampons de Communications Cellule E S T O U E S T SUD Fig.1.7. Structure en grille 2D de R.C.A.I. Le point commun entre ces diffŽrentes conceptions sont: ¥ une intŽgration massive de processeurs ŽlŽmentaires, ¥ une communication par messages entre ces derniers. D•s cette Žpoque, lÕarchitecture en une grille 2D fut adoptŽe pour les raisons ŽvoquŽes prŽcŽdemment (figure1.7). Cette structure prit le nom de rŽseau cellulaire. Chaque cellule peut communiquer (au plus) avec ses quatre voisines immŽdiates par le biais de tampons (buffers) de communications. Toutefois, lÕunitŽ de traitement du processeur ŽlŽmentaire est rŽduite ˆ sa plus simple expression: seules quelques opŽrations arithmŽtiques et logiques sont disponibles, augmentŽes dÕinstructions de communication primitives. 21 Chapitre 1 - Contexte de travail et objectifs 1.1.1.5. Processeur programmable Un besoin pressant fut ressenti par les possibilitŽs limitŽes du processeur de base. Une architecture programmable fut alors imaginŽe. Une machine h™te initialise le rŽseau et rŽcup•re ˆ la fin de lÕexŽcution les rŽsultats. Chaque cellule du rŽseau est composŽe [KARABERNOU93] par: ¥ une unitŽ de traitement du type MC6800, ¥ et dÕune unitŽ de routage indŽpendante. Cellules d'E/S H O T E Reset I N T Go E End R Inputs F A Outputs C E Cellule Source Cellule Destination Fig.1.8. Architecture de R.C.A.I. DÕune mani•re conceptuelle, nous disposons de deux rŽseaux (figure1.9): ¥ un rŽseau de calcul, constituŽ de lÕensemble des unitŽs de traitement, ¥ et un rŽseau de communication, dont la topologie est une grille 2D ouverte. RŽseau de communication Routeur RŽseau de calcul Processeur associŽ Fig.1.9. Niveau communication & Niveau calcul. LÕoriginalitŽ de cette approche est la sŽparation entre les deux rŽseaux. De cette mani•re, chaque niveau rŽalise la fonction quÕil sait le mieux faire. Le second trait est la parallŽlisation des routeurs: cinq communications peuvent •tre rŽalisŽes simultanŽment au niveau de chaque cellule. 22 Chapitre 1 - Contexte de travail et objectifs ¶ NORD · Cellule ¸ O U E S T E S T º ¹ SUD Fig.1.10. Cinq communication en parall•le. Le mode de programmation de cette machine [PAYAN91] [RUBINI92] est statique: apr•s avoir chargŽ le code au niveau de chaque cellule, celui-ci subsiste jusquÕˆ la fin dÕexŽcution du programme. Bien que ce mode rŽponde ˆ une grande classe de probl•mes6 [RUBINI92], nous pouvons cependant porter les remarques suivantes: ¥ le temps nŽcessaire pour le chargement du code dans lÕensemble du rŽseau est tr•s important comparŽ ˆ celui de son exŽcution sur cette architecture, ¥ une partie du code chargŽ risque dÕ•tre utilisŽe sporadiquement, dÕo• une sous-utilisation des ressources, ¥ toute une classe de probl•mes ne peut •tre abordŽe efficacement suivant cette approche: il sÕagit notamment de syst•mes dÕintelligence artificielle qui Žvoluent en cours dÕexŽcution [FERBER89] [HASSAS92]. Ces constatations nous ont donc amenŽs ˆ considŽrer une nouvelle approche pour la programmation de ce rŽseau. 6Des algorithmes de tri, de traitement dÕimages, de rŽseaux de neurones... 23 Chapitre 1 - Contexte de travail et objectifs 1.1.2. Motivations pour une nouvelle approche Devant ces limites, nous nous sommes demandŽs de quelle mani•re Žconomiser du temps lors du chargement du code? La rŽponse qui nous est venue ˆ lÕesprit est de ne charger quÕune copie de chaque Òbout de codeÓ. LÕensemble de ces morceaux de code constitue le programme formulŽ par lÕutilisateur. Par la suite, ces bouts de code se dupliqueront suivant lÕŽvolution du programme. Ce schŽma dÕexŽcution est donc tout ˆ fait dynamique. Nous allons revoir rapidement lÕapproche statique avant dÕentamer celle dont il est question au niveau de cette th•se, ˆ savoir lÕapproche dynamique. 1.1.2.1. Mod•le statique Plusieurs mod•les dÕexŽcutions se pr•tent tout ˆ fait aux architectures statiques. Le mod•le ˆ flot de donnŽes (DATA FLOW) en constitue un exemple typique [PAYAN91]. Dans ce mod•le, on commence par extraire les opŽrateurs, puis ˆ les affecter aux diffŽrents processeurs du rŽseau (figure1.11). Par la suite, les donnŽes circulent suivant un diagramme Žtabli ˆ la compilation durant toute lÕexŽcution du programme correspondant (schŽma statique). in3 c2 in2 * - s1 < > * - if c1 s2 + in1 c3 * + outpu Fig. 1.11. Exemple du mod•le ˆ flot de donnŽes. De m•me, dans le mod•le fonctionnel, le nombre des fonctions est Žtabli au dŽpart et reste identique jusquÕˆ la fin de lÕexŽcution. Les donnŽes (param•tres) sont fournies aux fonctions qui dŽlivrent en retour des rŽsultats ˆ dÕautres fonctions (figure1.12). Il nÕy a pas de gŽnŽration de nouvelle fonction en cours dÕexŽcution. 24 Chapitre 1 - Contexte de travail et objectifs Data 2 Data 1 Fct 1 Fct 6 Fct 2 Fct 7 Output Fct 3 Output 1 Fct 4 Fct 8 Output Fct 5 Fig. 1.12. Exemple du mod•le fonctionnel. 1.1.2.2. Mod•le dynamique: allocation dynamique de ressources DÕun autre c™tŽ, il existe un tout autre mod•le dÕexŽcution qui sÕadapte dÕune mani•re naturelle aux architectures parall•les. Il sÕagit du mod•le ˆ base dÕacteurs [LATROUS95] [AKTOUF93]. Tr•s bri•vement, il sÕagit dÕentitŽs autonomes (aussi appelŽes agents) et qui coop•rent par Žchange de messages. Le comportement dÕun acteur est indŽterministe: il est fonction de son Žtat courant et des messages en entrŽe. Le mod•le dÕacteurs peut reproduire pratiquement tous les mod•les dÕexŽcution connus [AGHA86b]: cela va du mod•le sŽquentiel, au mod•le fonctionnel, en passant par le mod•le ˆ flots de donnŽes ou les mod•les de lÕintelligence artificielle ˆ base de r•gles [HASSAS92]. Cependant, de par sa nature m•me, le mod•le dÕacteurs ne peut •tre exploitŽ efficacement sur une architecture statique. Le schŽma dÕexŽcution du mod•le dÕacteur est Žminemment dynamique. Tout au long de lÕŽvolution dÕun tel schŽma, il y a crŽation et destruction dÕacteurs. De m•me, de nouvelles compositions dÕacteurs ou des changements des liens (de communication) entres ceux-ci peuvent intervenir. Ces opŽrations ne peuvent •tre intŽgrŽes statiquement, ˆ moins de recourir ˆ des artifices incompatibles avec le mod•le statique. LÕintŽgration de mŽcanismes dynamiques suppose une allocation dynamique des ressources. Les mŽthodes dÕallocation statique (dites aussi 25 Chapitre 1 - Contexte de travail et objectifs mŽthodes de placement) sur un rŽseau de processeurs parall•les fournissent de tr•s bons rŽsultats [TALBI93]. Les techniques issues de celles utilisŽes jadis dans les circuits intŽgrŽs - Žchanges de paires, placement constructif ou itŽratif [LATROUS88], ou encore le recuit simulŽ [BOKHARI81] ou de mŽthodes plus rŽcentes, telles que les mŽthodes gŽnŽtiques [TALBI93] - ont toujours gardŽ leur attrait lors de leur adaptation pour le placement de t‰ches sur les architectures parall•les [CHEN90] [BAIARDI89] [GHOSH89] [KRAVITZ87]... Le point commun entre ces diffŽrentes approches est lÕhypoth•se dÕune connaissance, partielle ou totale, de param•tres qualificatifs et/ou quantitatifs de lÕapplication cible. Ces param•tres, qui entrent dans lÕŽvaluation dÕune fonction de cožt, peuvent comprendre: ¥ la taille du rŽseau des entitŽs ˆ placer, ¥ le cožt des communications sur les liens les reliant, ¥ la mŽmoire susceptible dÕ•tre utilisŽe, ainsi que dÕautres facteurs jugŽs critiques7 pour lÕŽvaluation de cette fonction de cožt. Cette derni•re caractŽrise un placement en lui affectant une valeur. Les diffŽrentes valeurs ainsi dŽgagŽes permettent de comparer une sŽrie de placements pour une m•me application afin dÕen choisir le (ou les) meilleur(s). Dans les syst•mes dynamiques, cette connaissance ˆ priori est difficilement extractible ˆ partir des ŽlŽments du syst•me (voire impossible ˆ Žtablir). Le nombre dÕentitŽs ˆ gŽnŽrer ne peut pas •tre connu ˆ lÕavance. De m•me, il est pratiquement impossible dÕassocier prŽalablement un cožt aux communications. Les communications dŽpendent: ¥ de la distance qui sŽpare les entitŽs en relation; celle-ci est conditionnŽe par lÕaffectation des entitŽs mises en jeu dans cette communication aux ressources disponibles au moment de leur gŽnŽration, ¥ de la charge des liens de communication; cÕest-ˆ-dire, le nombre total de messages en cours de transit dans le rŽseau ˆ lÕinstant o• cette opŽration prend effet. Ces remarques nous ont tout naturellement conduit ˆ considŽrer lÕallocation dynamique de ressources: ˆ la demande et suivant la disponibilitŽ de celles-ci. Ceci ne signifie nullement (comme nous le verrons par la suite) 7Tels que des crit•res de regroupement de nÏuds, la distance maximale autorisŽe entre certains nÏuds, les entrŽes/sorties... 26 Chapitre 1 - Contexte de travail et objectifs quÕil nÕy a pas lieu de tenter dÕoptimiser cette allocation. Par exemple, la distance sŽparant des acteurs reliŽs (par des liens de communications ou des rŽfŽrences croisŽes) constitue un facteur important ˆ minimiser. Contrairement aux travaux menŽs par [DALLY84] [DALLY87], notre but nÕest pas de proposer une machine dŽdiŽe. Les travaux de DALLY et de son Žquipe ont conduit ˆ lÕŽlaboration dÕune machine-langage centrŽe objets8: le MDP (Message Driven Processor). Son objectif est la rŽduction du temps requis pour la gestion des messages dans le rŽseau. Pour cela, une unitŽ spŽcialisŽe a ŽtŽ dŽveloppŽe pour lÕinterprŽtation des messages (figure1.13). A partir du rŽseau File T•te Queue RŽcepteur SŽlecteur Reply To Arg 1 Arg 2 Arg 3 Arg 4 Arg Ptr Buffer de messages en mŽmoire Registre de rŽception Fig.1.13. RŽception dÕun message dans le MDP. LÕinconvŽnient dÕune telle machine est, ˆ lÕŽvidence, un mod•le dÕexŽcution figŽ. Toute modification de celui-ci entra”ne inŽvitablement celle de lÕunitŽ correspondante. De plus, cette unitŽ est tr•s onŽreuse en silicium (de lÕordre de 1/3 de la surface totale, sans compter le syst•me de routage attenant). Nous allons Žtudier, dans les sections suivantes, dÕune mani•re plus dŽtaillŽe, nos mod•les dynamiques dÕexŽcution et de programmation pour une machine de ce type. 8cf.¤2.2 pour la dŽfinition de la notion de langages ˆ objets. 27 Chapitre 1 - Contexte de travail et objectifs 1.2. PrŽsentation du projet R.C.A.I Pour situer la cadre dans lequel est mis en Ïuvre ce mod•le, il est utile de rappeler le projet R.C.A.I jusquÕau point o• il a ŽtŽ menŽ avant le dŽbut de nos travaux: il sÕagit de lÕapproche statique. 1.2.1. Architecture du rŽseau La machine cellulaire R.C.A.I se prŽsente sous forme dÕune grille 2D ouverte o• chaque cellule est reliŽe ˆ ses quatre voisines immŽdiates (figure1.14). Fig.1.14. RŽseau d'interconnexion. Chaque cellule du rŽseau a ŽtŽ con•ue en deux parties: ¥ la partie traitement (un processeur de calcul dotŽ dÕune mŽmoire locale), ¥ la partie routage (bloc de transmission et de rŽception de messages). Cellule Nord Buffers de communication Cellule Ouest Processeur + mŽmoire Cellule Est Aiguilleur Cellule Cellule Sud Fig.1.15. Structure d'une cellule. 28 Chapitre 1 - Contexte de travail et objectifs 1.2.2. La partie traitement La partie traitement est ˆ base d'un microprocesseur 8 bits du type MC6800, associŽe ˆ une mŽmoire locale de 256 octets: il nÕy a pas de mŽmoire globale. Les modes dÕadressage prŽvus dans la machine R.C.A.I sont issus en grande partie des modes classiques du MC6800. Il sÕagit notamment des modes: ¥ dÕadressage inhŽrent, ¥ dÕadressage immŽdiat, ¥ dÕadressage indexŽ, et ¥ dÕadressage indexŽ post-incrŽmentŽ. Un autre mode, dit mode dÕadressage court, a ŽtŽ introduit pour rŽduire le nombre de cycles pour les acc•s mŽmoire, et pour optimiser le code des programmes [RUBINI92]. Dans ce mode, chaque instruction est composŽe de deux champs de 4 bits chacun: ¥ les premiers 4 bits dŽfinissent le code opŽration, ¥ les 4 bits restants dŽterminent le dŽplacement par rapport ˆ la premi•re page de la mŽmoire ($0) dans le cas des instructions LDA et STA et par rapport ˆ la derni•re page de la mŽmoire ($F) dans le cas des instructions de communications PUT, GET et TRY. 29 Chapitre 1 - Contexte de travail et objectifs Le jeu dÕinstructions est Žgalement inspirŽ de celui du processeur MC6800. En rŽsumŽ, nous donnons la classification suivante9: Accumulateur : ArithmŽtiques : ADD SUB ADC SBC CMP INC DEC TST CLR MUL addition soustratction addition avec retenue soustraction / retenue comparaison incrŽmentation dŽcremententation comparaison avec 0 Mise ˆ 0 multiplication LDA STA chargement accumulateur stockage accumulateur Communication : GET attente du message et lecture PUT envoie message interne TRY test arrivŽe message SEND envoie message Branchements : Bcc branchements conditionnels OpŽrations logiques : XOR OR AND NOT OpŽrations registres : ou exclusif ou logique et logique negation LDI CLC SEC DŽcalage & Rotation : ROL rotation gauche ROR rotation droite ASR dŽcalage arithm droite ASL dŽcalage arithm gauche chargement du registre index mise ˆ 0 de la retenue mise ˆ 1 de la retenue OpŽrations Registre ˆ Registres : TAPC transfert A ˆ PC TPCA transfert PC ˆ A TIA transfert I ˆ A TAI transfert A ˆ I D'autre part, nous disposons de quelques instructions 16-bit: Instructions 16-bit : LDAW STAW ADCW SBCW chargement accumulateur Žtendu stockage accumulateur Žtendu addition 16-bit /C substraction 16-bit / C 9Pour plus de prŽcisions en ce qui concerne le jeu dÕinstructions de la machine R.C.A.I., nous conseillons au lecteur de se reporter aux travaux de [RUBINI_92] et de [KARABERNOU_93]. 30 Chapitre 1 - Contexte de travail et objectifs La machine R.C.A.I a ŽtŽ dotŽe, dans sa version prŽcŽdente, de quatre instructions de communication: Instructions de communication : SEND <msg> envoi d'un message <msg> 1.2.3. GET <addr> attente d'un message ˆ <addr> ensuite le retirer du rŽseau de communication PUT <addr> gŽnŽration d'un message ˆ <addr> pour une synchronisation locale TRY <addr> teste la prŽsence d'un message ˆ <addr>, recommencer sinon La partie routage Le syst•me de communication a ŽtŽ con•u autour de deux parties: ¥ le rŽcepteur et ¥ l'Žmetteur (arbitre). Les cellules communiquent entre elles par passage de messages. La structure du message inclut quatre champs (figure1.16): ¥ l'adresse relative (Dx, Dy), mise ˆ jour ˆ chaque transition d'une cellule ˆ une autre par dŽcrŽmentation (un message dont l'adresse relative est nulle signifie qu'il est arrivŽ ˆ destination, et passe ainsi de la partie routage ˆ la mŽmoire locale de la cellule), ¥ l'Žtiquette (TAG) qui correspond ˆ une adresse dans la mŽmoire locale du processeur o• la donnŽe doit •tre rangŽe et ¥ la donnŽe ˆ Žchanger (DATA) . 31 Chapitre 1 - Contexte de travail et objectifs Adresse Relative Dx Dy TYPE TAG DATA 0 1 2 3 4 1 1 O 2 Le 9i•me bi Dy 3 4 Dx Fig.1.16. Structure d'un message. Remarque: Le type du message fait partie de la derni•re version de la machine R.C.A.I. Il sera explicitŽ le moment venu. 1.2.3.1. La stratŽgie de routage Il existe principalement deux modes de routage dans le cas gŽnŽral: ¥ le routage adaptatif (ou semi-adaptatif), et ¥ le routage dŽterministe. Le premier mode prŽsente lÕavantage de tenir compte de lÕengorgement du rŽseau de communication. LorsquÕil nÕy a aucune restriction sur les liens de sortie ˆ partir dÕun nÏud nous parlons dÕun routage adaptatif. Autrement, lorsque le nombre de liens de sortie autorisŽs est restreint, le routage est dit semi-adaptatif. A lÕopposŽ, le routage dŽterministe dŽfinit, dÕune mani•re fixe, les liens de communication entre les diffŽrents processeurs, comme son nom lÕindique. La diffŽrence entre ces deux modes est la complexitŽ engendrŽe par le maintien de lÕŽtat du rŽseau dans la premi•re approche. De ce fait, son intŽgration (au niveau silicium) demande davantage de surface que la mŽthode retenue dans la machine R.C.A.I. Dans le cas dÕune machine massivement parall•le, la partie routage doit consommer le moins possible de silicium (de lÕordre de 20 ˆ 30% de la surface totale). 32 Chapitre 1 - Contexte de travail et objectifs La stratŽgie de routage adoptŽe dans R.C.A.I est dŽterministe. Il sÕagit de la technique dite du wormhole [SEITZ84] [DALLY87]. Sommairement, cette mŽthode consiste ˆ diviser un message en plusieurs paquets avant de les introduire dans le rŽseau de communication: commutation de paquets. La t•te du message creuse un ÒtunnelÓ pour le reste des paquets. Ce passage est refermŽ par la queue pour libŽrer les liens de communication aux prochains messages. De cette fa•on, il y a un recouvrement entre les diffŽrents paquets. Chaque message est rŽparti sur plusieurs cellules successives (suivant le nombre de paquets qui le composent). Cette stratŽgie de routage a ŽtŽ implantŽe au niveau de lÕaiguilleur dans la machine R.C.A.I (figure1.15). 1.2.3.2. Interblocage et famine dans R.C.A.I Nous prŽsentons les r•gles suivantes, inhŽrentes au rŽseau de cellules R.C.A.I: ¬ Les tampons dÕentrŽe au niveau dÕune m•me cellule sont inspectŽs successivement en vue dÕ•tre lus, toujours dans le m•me ordre. - Un message qui transite dans un sens au niveau dÕune cellule ne peut en bloquer dÕautres qui transiteraient dans les autres sens (mais bloquent toutes les communications dans ce m•me sens). ® Un message est toujours acheminŽ dÕabord selon son dŽplacement en abscisse (dx), puis en ordonnŽe (dy). ¯ Un message arrivŽ ˆ destination est immŽdiatement retirŽ du rŽseau (rangŽ en mŽmoire). ° Les messages prŽsentent le m•me nombre de paquets (m•me longueur). ± Les paquets qui constituent un message empruntent tous le m•me chemin au travers des cellules. ² LorsquÕun message a ŽtŽ sŽlectionnŽ pour •tre acheminŽ vers sa prochaine destination, il doit •tre traitŽ en entier avant de passer au suivant (sÕil y en a un en attente). Ces r•gles nous permettent de dŽgager deux caractŽristiques de notre rŽseau: ¥ la premi•re est lÕabsence de famine; en effet, la r•gle (1) assure quÕau bout dÕun temps fini, chaque entrŽe, au niveau dÕune m•me cellule, sera prise 33 Chapitre 1 - Contexte de travail et objectifs en compte, et ˆ condition que la seconde caractŽristique (r•gle 2) soit vŽrifiŽe (comme nous le montrerons par la suite), ¥ la seconde caractŽristique est lÕabsence dÕinterblocage ; pour cela, dŽfinissons dÕabord cette notion. Nous dirons quÕil y a interblocage lorsquÕun groupe ou lÕensemble des cellules nÕarrivent plus ˆ acheminer les messages sur leur entrŽe vers les cellules voisines. En gŽnŽral, ceci revient ˆ dire quÕil existe un circuit dans le rŽseau. Avant de montrer lÕinexistence dÕun tel cycle, nous allons considŽrer quelques dŽfinitions. Soit G (C, L) un graphe orientŽ dont lÕensemble des sommets C correspond ˆ lÕensemble des cellules: C = {c i } | i ∈ [0 , ( n− 1)2] n2 Žtant le nombre de cellules du rŽseau (de nxn cellules). L est lÕensemble des arcs, tel que: L = {ldi,j1,d2,[,d3] | (i, j) ∈ [0,( n-1)] et (d1,d2,d3) ∈ {N,S,W,E}, d1 ≠ d2 ≠ d3} 2 N:nord, E:est, W:ouest, S:sud Nous dirons quÕil existe un lien d ,d ,d 2 3 li,j1 entre deux cellules ci et cj , lorsquÕun message au dŽpart de la cellule ci (ou seulement de passage au niveau de celle-ci), selon une direction (d1, d2) arrivant ˆ la cellule cj doit changer de direction en d3. d ,d2 ,d 3 l i,j1 cj ci Remarquons que la direction d3 peut •tre Žventuellement vide lorsquÕune des deux directions dx ou dy du dŽplacement est nulle (ou que lÕon ne change pas de direction). 34 Chapitre 1 - Contexte de travail et objectifs cj d2 ci d1 d3 Les directions d1, d2, et d3 refl•tent donc les dŽplacements en abscisse et en ordonnŽe, comme par exemple: d(d1,d2) = dx & d(d2,d3) = dy Le choix dÕun tel mod•le est justifiŽ par le fait que, dans le cas qui nous concerne, une communication est dŽcrite par un couple de dŽplacements (dx,d y). Trois nÏuds importants interviennent donc dans cette description: ¥ le nÏud de dŽpart du message, ¥ le nÏud dÕarrivŽe, ¥ et surtout le nÏud au niveau duquel sÕop•re le changement de direction (dx en dy ou dy en dx). De plus, la r•gle(2) spŽcifie que deux communications distinctes dans deux sens diffŽrents ne peuvent interfŽrer. Par consŽquent, pour mettre en Žvidence un cas de conflit, il faudrait choisir un mod•le qui refl•te la concurrence pour lÕacc•s ˆ une ressource critique par deux ou plusieurs nÏuds ˆ la fois: ˆ savoir les tampons dÕentrŽe/sortie des cellules en question. 35 Chapitre 1 - Contexte de travail et objectifs Un circuit typique serait donc: W,E,S Cell 1 N Cell 0 E W S c0 c1 S,N,W N,S,W l 1,2 Cell 3 Cell 2 l 0,1 l 3,0 c2 E,W,N l 2,3 c3 Ce cycle peut •tre traduit dans notre mod•le par la suite dÕarcs: cycle = (l W,E,S 0,1 , E,W,N N,S,W l1S,N,W , l2,3 , l3,0 ,2 ) Un tel cas ne peut se produire dans notre rŽseau eu Žgard aux r•gles(2) et (3). En effet, un cycle de ce type signifie que lÕon proc•de ˆ un moment donnŽ ˆ un dŽplacement (dy, dx). Or ce genre de dŽplacement ne peut avoir N,S,W et l3,0 ne sont pas lŽgaux lieu dÕapr•s la r•gle (3). Les deux ŽlŽments l1S,N,W ,2 car les changements de direction (S,N) et (N,S) ne sont pas permis dÕapr•s cette m•me r•gle. Par consŽquent, notre rŽseau, comme tous les rŽseaux qui rŽalisent un routage incrŽmental, suivant une dimension toujours croissante, est exempt de cas dÕinterblocage. De plus, notre rŽseau garantit lÕabsence de famine gr‰ce ˆ la premi•re r•gle. 36 Chapitre 1 - Contexte de travail et objectifs 1.3. Conclusion Rappelons bri•vement les motivations qui ont prŽsidŽ ˆ ces travaux ainsi que les objectifs que nous nous sommes fixŽs. Parmi les motivations, citons les plus importantes: ¥ tout dÕabord, Žconomiser le temps de chargement du code sur une machine massivement parall•le, ¥ traiter la classe des probl•mes dits irrŽguliers (telle que lÕIA), ¥ gŽrer efficacement les ressources du syst•me (par le biais de lÕallocation et de la restitution dynamiques des ressources). Dans le cadre du projet R.C.A.I, les objectifs que nous nous sommes assignŽs peuvent •tre rŽsumŽs dans les points suivants: ¥ la spŽcification dÕun mod•le de programmation: le mod•le acteur; ce mod•le, par les concepts sous-jacents, sÕadapte tout naturellement ˆ la programmation de notre rŽseau, ¥ la mise en Ïuvre de ce mod•le au niveau de la machine (qui correspond au mod•le dÕexŽcution), ¥ lÕallocation dynamique de ressources, ainsi que leur rŽcupŽration, ¥ et finalement apporter une solution ˆ quelques limites hŽritŽes de la version statique de R.C.A.I. 37 C HAPITRE 2 M ODéLES DE PROGRAMMATION & D ÕEXƒCUTION 2. MODéLES DE PROGRAMMATION ET DÕEXƒCUTION Le projet R.C.A.I. nous a lŽguŽ un certain nombre de contraintes, sur lesquelles est construite notre solution, ainsi: ¥ lÕarchitecture du rŽseau est une grille 2D ouverte, ¥ les processeurs sont asynchrones, ¥ il nÕexiste pas de rŽfŽrences globales entre les processeurs; les distances sont relatives et exprimŽes par des dŽplacements en abscisse et en ordonnŽe, ¥ il nÕy a quÕun seul moyen de communication: le passage de messages, ¥ la durŽe de transmission est imprŽvisible, ¥ le grain de programmation est fin. En prenant en compte toutes ces spŽcificitŽs, nous allons passer en revue les mod•les qui peuvent sÕadapter ˆ une gestion dynamique de ce rŽseau. Avant dÕentamer cette Žtude, nous dŽfinissons la notion de mod•le dÕexŽcution et le mod•le physique de R.C.A.I. Le mod•le logique est prŽsentŽ en plusieurs parties (ˆ travers les diffŽrents chapitres de ce manuscrit). DÕabord en dŽfinissant le mod•le de programmation correspondant; puis en traitant les aspects dynamiques dÕallocation et de restitution dÕobjets. En ce qui concerne le mod•le logique, le point le plus important est la dŽfinition de lÕespace dÕadressage dÕun acteur dans notre contexte. Il sÕagit de ce que nous dŽsignons par serveur de code (cf.¤4.1). 41 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.1. DŽfinition dÕun mod•le dÕexŽcution Un mod•le dÕexŽcution consiste en un ensemble dÕabstractions qui fournit une vue simplifiŽe dÕune machine. Une machine doit comporter un minimum de mŽcanismes qui permettent de supporter un ou plusieurs mod•les dÕexŽcution. Il existe des mŽcanismes capables de supporter divers mod•les dÕexŽcution parall•le. Ces derniers nŽcessitent, de fa•on globale, des mŽcanismes efficaces pour: ¥ la communication, ¥ la synchronisation, ¥ ainsi que la dŽsignation. Un autre mŽcanisme prend de plus en plus dÕampleur dans la spŽcification de divers syst•mes, et semble sÕimposer en tant quÕŽlŽment de base ˆ fournir dans tout syst•me pour faciliter la programmation au niveau le plus haut. Il sÕagit du mŽcanisme de Òramasse-miettesÓ connu sous le nom de garbage collector. Un mŽcanisme est dit universel lorsquÕil peut •tre utilisŽ pour supporter la majoritŽ des mod•les dÕexŽcution existants. De m•me, un mŽcanisme est dit primitif lorsquÕil peut •tre implŽmentŽ dÕune mani•re efficace au niveau physique [DALLY89]. Ces mŽcanismes permettent de ne pas sÕattacher aux aspects physiques de la machine lors de la spŽcification du mod•le dÕexŽcution de plus haut niveau. Dans le cas qui nous concerne, lÕensemble de ces mŽcanismes doit •tre mis en Ïuvre dans un contexte de machine parall•le. LÕinterface de machine parall•le (IMP) discutŽe dans [DALLY89] correspond ˆ un ensemble de mŽcanismes universels reliant les syst•mes de programmation aux machines (figure2.1). LÕIMP facilite la portabilitŽ des syst•mes de programmation parall•les. Cette interface sŽpare ainsi les probl•mes liŽs ˆ la machine (implŽmentation des mŽcanismes primitifs) de ceux liŽs aux mod•les de programmation (niveau logiciel). 42 Chapitre 2 - Mod•les de programmation et dÕexŽcution Data Flow Acteurs Fonctionnel Niveau Logique Interface de Machine Parall•le RAP J-Machine Caltech-Machine Niveau Physique Fig.2.1. LÕInterface de Machine Parall•le (IMP). Nous prŽsentons maintenant le mod•le physique relatif ˆ notre machine R.CA.I. 2.1.1. Mod•le physique Ce mod•le inclut un ensemble de mŽcanismes suffisants pour supporter les mod•les dÕexŽcution les plus connus (mod•le acteur, mod•le dataflow, mod•le fonctionnel...): ¥ la machine abstraite est composŽe dÕun ensemble N de nÏuds; un nÏud i de cet ensemble est notŽ N[i], ¥ chaque nÏud contient une mŽmoire locale M ; cette mŽmoire est constituŽe dÕun ensemble de mots M[0],...,M[k-1] (k est donc la taille de cette mŽmoire), ¥ un mot mŽmoire peut contenir une valeur, une rŽfŽrence (pointeur adresse) ou une valeur particuli•re ^ (nil). La valeur ^ signifie Òvaleur indŽfinie ou mot mŽmoire en attente de donnŽeÓ. Nous reflŽtons cette opŽration au niveau de R.C.A.I en associant ˆ chaque mot mŽmoire un neuvi•me bit de validitŽ [KARABERNOU93] [RUBINI92]. Si ce bit est positionnŽ ˆ 0, la valeur de ce mot mŽmoire correspond ˆ ^. SÕil est positionnŽ ˆ la valeur 1, la case mŽmoire correspondante contient la derni•re valeur re•ue (figure1.16). 43 Chapitre 2 - Mod•les de programmation et dÕexŽcution Ainsi, nous Žcrivons: M[k].valid ¬ 0, pour suspendre une t‰che et la mettre en attente dÕune donnŽe, M[k].valid ¬ 1, pour reprendre la t‰che en question, ¥ une t‰che sur un nÏud N[i] peut: ¥¥ modifier le contenu de sa zone mŽmoire, ¥¥ envoyer un message ˆ un autre nÏud, ¥¥ se mettre en attente dÕun ou de plusieurs messages (attente active). ¥ si une t‰che tente de lire la valeur ^, elle suspend son traitement, et se met en attente de lÕarrivŽe dÕune donnŽe dans cette zone. 44 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2. Mod•les centrŽs objets Nous reprenons ˆ ce niveau lÕŽtude de mod•les de programmation potentiels pour la gestion dynamique de R.C.A.I. Les langages ˆ objets peuvent •tre classŽs suivant la dŽfinition attribuŽe ˆ la notion dÕobjet [FERBER87] [MASINI89]: ¥ La perspective structurelle: dans cette famille, lÕobjet est considŽrŽ comme Žtant un type de donnŽes qui dŽfinit un mod•le pour la structure de ses reprŽsentants ÒphysiquesÓ et des opŽrations applicables ˆ cette structure. Les langages qui appartiennent ˆ ce premier groupe sont appelŽs langages de classes. La classe sÕapparente ˆ un type abstrait de donnŽes et dŽcrit un ensemble dÕobjets qui partagent la m•me structure et le m•me comportement. Elle sert de moule pour gŽnŽrer ses reprŽsentants physiques (dits instances). ¥ La perspective conceptuelle: lÕobjet est une unitŽ de connaissance qui reprŽsente le prototype dÕun concept. Les langages appartenant ˆ cette famille sont appelŽs langages de frames. Un frame est un prototype qui dŽcrit une situation ou un objet standard. LÕensemble des frames est organisŽ en une hiŽrarchie dÕhŽritage o•, ˆ la diffŽrence des classes, tout objet est ˆ la fois un reprŽsentant des frames dont il est issu et un gŽnŽrateur de frames plus spŽcialisŽs. Les langages de cette catŽgorie sont essentiellement utilisŽs pour la reprŽsentation de connaissances [MINSKY75]. ¥ La perspective acteur10: dans cette derni•re catŽgorie, lÕobjet est une entitŽ autonome et active. Cette famille regroupe tous les langages dits dÕacteurs, issus des travaux menŽs au M.I.T par C.HEWITT [HEWITT77]. Un acteur est un objet actif qui communique avec les autres acteurs par envois de messages asynchrones (contrairement aux deux prŽcŽdentes classes). 10Le mod•le agent est une extension du mod•le acteur comme nous le verrons au ¤2.2.3. 45 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.1. DŽfinition du mod•le objet 2.2.1.1. DŽfinition dÕun objet Le terme de programmation orientŽe objets (Òobject-oriented programmingÓ) dŽsigne un mode de conception de logiciel caractŽrisŽ par: ¥ une organisation en entitŽs relativement autonomes (les ÒobjetsÓ) qui utilisent une forme particuli•re dÕinteraction mutuelle (les ÒmessagesÓ), ¥ un mŽcanisme de spŽcification et de gŽnŽration des objets au moyen de mod•les gŽnŽriques qui dŽcrivent leur structure et leur comportement (les ÒclassesÓ). 2.2.1.2. Classes et instances Les objets qui prŽsentent les m•mes spŽcifications sont rangŽs dans une m•me reprŽsentation: la classe. La structuration en classes est une reprŽsentation dÕun type abstrait. CÕest ˆ partir de ce moule que nous gŽnŽrons des exemplaires. Ces exemplaires sont appelŽs instances. LÕopŽration de gŽnŽration est appelŽe instanciation dÕobjets. Toutes les instances dÕune classe peuvent prŽsenter les m•mes caractŽristiques dŽfinies par cette classe. Il existe deux types dÕinstanciation: ¥ la mŽthode classique: construction dÕun objet ˆ partir des spŽcifications de sa propre classe (figure2.2), Classe des chiens F Un chien _ Boby F Un chien _ MŽdor Fig.2.2. Instanciation. 46 Chapitre 2 - Mod•les de programmation et dÕexŽcution ¥ la construction dÕun objet terminal par copie ˆ partir dÕun prototype en changeant Žventuellement la valeur de champs, dÕo• le nom de copie diffŽrentielle. Tout objet est considŽrŽ comme une classe dans cette approche (figure2.3). F Chien Mod•le F MŽdor Fig.2.3. Copie diffŽrentielle. 2.2.1.3. HŽritage La spŽcialisation des classes dŽfinit la notion dÕhŽritage (en rŽalisant une hiŽrarchie en classe et sous-classe). Plusieurs sous-classes peuvent hŽriter des mŽthodes (et des attributs) des classes supŽrieures. Chacune de ces sous-classes peut ajouter ˆ son tour de nouvelles mŽthodes (ou de nouveaux attributs) qui lui sont propres ou redŽfinir celles (ou ceux) dont elle a hŽritŽ. [BAILLY87] donne la dŽfinition suivante de lÕhŽritage: Ò...les deux notions dÕhŽritage et dÕinstanciation sont parfois confondues en un m•me mŽcanisme...il convient toutefois de les diffŽrencier car ils nÕont pas la m•me signification. Une relation classeinstance est assimilable ˆ un lien dÕappartenance ŽlŽment-ensemble. LÕhŽritage doit plut™t •tre considŽrŽ comme reprŽsentant une inclusion entre un ensemble et un sous-ensemble.Ó 47 Chapitre 2 - Mod•les de programmation et dÕexŽcution Navire Bateau de Plaisance B‰teau ˆ Moteur Navire de Commerce B‰timent de Guerre Voilier Fig.2.4. Notion de classe/sous-classe et dÕhŽritage. Il existe deux types de recherche de mŽthodes hŽritŽes: ¥ recherche statique: chaque classe contient un dictionnaire complet de toutes les mŽthodes (locales ou hŽritŽes); chaque entrŽe dans le dictionnaire pointe directement le code de la mŽthode correspondante, ¥ recherche dynamique: la recherche de la mŽthode hŽritŽe se fait par exploration de lÕarbre dÕhŽritage des classes (en remontant dans la branche jusquÕˆ trouver lÕinformation sollicitŽe). 2.2.1.4. ActivitŽ dÕun objet Les seules opŽrations permises sur un objet sont: ¥ le changement de lÕŽtat de lÕobjet, ¥ l'envoi de messages, ¥ et la crŽation de nouveaux objets. Les objets sont normalement au repos, en attente de lÕarrivŽe dÕun message, d'o• la notion de passivitŽ des objets. Un objet ne peut traiter quÕun message ˆ la fois. Le nombre de messages envoyŽs ainsi que le nombre dÕobjets crŽŽs en rŽponse ˆ la rŽception dÕun seul message est fini. 48 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.1.5. Probl•mes liŽs au mod•le objet La mise en Ïuvre de la programmation par objets pose divers probl•mes qui sont encore largement ouverts: 2.2.1.5.1. Gestion de la mŽmoire Les probl•mes de gestion de la mŽmoire sont ceux de tout syst•me comportant des entitŽs crŽŽes et dŽtruites dynamiquement (gestion dÕun tas, ramasse-miettes). Ils sont compliquŽs par la possibilitŽ de partage dÕobjets ou de parties dÕobjets (notamment les descriptions de classes) et par la nŽcessitŽ de liaison dynamique inhŽrente au mode dÕexŽcution spŽcifiŽ, qui am•ne ˆ conserver des informations de liaison jusquÕau moment de lÕexŽcution. Ce probl•me nÕest pas spŽcifique au mod•le ˆ objets. Il est commun aux trois mod•les dŽcrits dans cette section. 2.2.1.5.2. ParallŽlisme et synchronisation Le mod•le gŽnŽral ci-dessus ne fournit pas dÕexplications quant au parallŽlisme dÕexŽcution entre les objets, bien que la terminologie (en particulier le terme ÒmessageÓ) puisse suggŽrer une exŽcution parall•le. La plupart des langages dŽveloppŽs jusquÕici utilisent en fait un mod•le 1 1 , ou Flavors sŽquentiel : Smalltalk [GOLDGBERG 83], Ada [WEINREB80]... Le parallŽlisme nÕa ŽtŽ effectivement abordŽ quÕˆ partir du mod•le dÕacteurs. 11Ada nÕest pas un langage ˆ objets ˆ proprement parler. Certains auteurs le consid•rent comme tel eu Žgard ˆ ses propriŽtŽs dÕencapsulation, en regroupant dans une m•me entitŽ (package) les donnŽes et les procŽdures qui les manipulent. Ceci nÕest toutefois pas une r•gle, seulement une possibilitŽ dans ce langage. 49 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.2. DŽfinition du mod•le acteur Les techniques de programmation Žvoluent, et se tournent de plus en plus vers la rŽalisation de syst•mes concurrents. Les langages dÕacteurs, formŽs de petites entitŽs autonomes qui communiquent par envois de messages, offrent alors un cadre simple et pratique pour dŽvelopper des applications. La programmation qui en dŽcoule transforme radicalement notre vision de lÕinformatique en ne concevant plus les programmes comme des monstres monolithiques mais comme des communautŽs de petits spŽcialistes qui, par interaction et dialogues, aboutissent au rŽsultat souhaitŽ. B A D C E Fig.2.5. Structure dÕacteurs. 2.2.2.1. DŽfinition dÕun acteur Le terme dÕacteur est utilisŽ par certains auteurs comme synonyme dÕobjet. Il exprime une notion dÕaction alors que le mot objet est passif. La thŽorie des acteurs a ŽtŽ dŽveloppŽe au M.I.T par C.HEWITT [HEWITT77]. Son but est de modŽliser une communautŽ dÕexperts indŽpendants et autonomes. Ces experts (les acteurs) sont des entitŽs cohŽrentes qui poss•dent leur propre environnement et qui communiquent par message. Les acteurs se reproduisent par duplication dÕeux-m•mes (copie identique) ou par copie diffŽrentielle (copie originale enrichie par de nouvelles caractŽristiques). Ce mod•le introduit des concepts nouveaux par rapport aux autres syst•mes dÕobjets dans le domaine de lÕhŽritage, de lÕinstanciation et du passage de message (dŽlŽgation, continuation...). 50 Chapitre 2 - Mod•les de programmation et dÕexŽcution Un acteur est dÕune fa•on gŽnŽrale composŽ: ¥ des donnŽes locales, appelŽes accointances, qui correspondent aux acteurs que celui-ci conna”t explicitement, ¥ dÕun comportement (script), qui dŽfinit les actions que lÕacteur entreprend au cours de son existence, en fonction des ŽvŽnements qui surviennent. Contrairement ˆ une classe, le comportement nÕest pas dŽfini par des mŽthodes mais par un script, unique, qui filtre les messages re•us par lÕacteur et active la partie appropriŽe du comportement. Les capacitŽs dÕun acteur sont limitŽes. Il est incapable de rŽsoudre des probl•mes importants ˆ lui seul. Toute la puissance des syst•mes dÕacteurs tient plus aux capacitŽs de communication entre acteurs quÕˆ des performances intrins•ques liŽes ˆ chacun dÕentre eux. En fait, un acteur ne sait presque rien faire, si ce nÕest rŽpondre ˆ des messages par dÕautres messages ou en donnant naissance ˆ dÕautres acteurs. LÕobjectif de cette famille de langages est de proposer un langage de programmation dÕordinateur multiprocesseur. Il est tr•s orientŽ vers lÕaspect multit‰ches et parallŽlisme. ACCOINTANCES SCRIPT ACCOINTANCES B.A.L SCRIPT ACCOINTANCES SCRIPT B.A.L ACCOINTANCES Bo”te aux lettres B.A.L SCRIPT B.A.L Fig.2.6. Mod•le acteur. 51 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.2.2. DŽlŽgation Les acteurs sont caractŽrisŽs par un mandataire. Le mandataire est lÕacteur auquel on renvoie tous les messages incompris. ACCOINTANCES SCRIPT MANDATAIRE B.A.L ACCOINTANCES ACCOINTANCES SCRIPT SCRIPT MANDATAIRE MANDATAIRE ACCOINTANCES SCRIPT MANDATAIRE DŽlŽgation B.A.L B.A.L B.A.L Fig.2.7. Notion de dŽlŽgation. Cette caractŽristique permet de rŽaliser la notion dÕhŽritage dans le mod•le dÕacteurs. Le mandataire (appelŽ Žgalement proxy) correspond dans la hiŽrarchie dÕhŽritage au p•re de lÕacteur en question. CÕest un hŽritage dynamique. Ce nÕest quÕau moment de lÕexŽcution quÕil y a passage de message du ÒfilsÓ vers le Òp•reÓ, pour la prise en charge dÕun message incompris. Il nÕexiste pas de notion de dictionnaire de mŽthodes, construit statiquement ˆ la compilation. 2.2.2.3. Continuation Une premi•re idŽe introduite par C.HEWITT est la continuation: la rŽponse ˆ un message nÕest pas (forcŽment) retournŽe ˆ lÕenvoyeur mais ˆ un tiers (une accointance), spŽcifiŽ par le message lui m•me. Ce mod•le se rapproche de lÕidŽe de processus, et sÕadapte parfaitement ˆ la programmation multit‰che ou multiprocesseur. 52 Chapitre 2 - Mod•les de programmation et dÕexŽcution A Message pour E B D C E Fig.2.8. OpŽration de continuation. Un autre aspect marquant vient de lÕuniformitŽ des concepts. Instances, classes, mŽtaclasses sont remplacŽs par un unique concept: lÕacteur. Les messages eux-m•mes sont des acteurs. Les mŽcanismes dÕinstanciation et dÕhŽritage sont diffŽrents. 2.2.2.4. Instanciation LÕinstanciation est en fait une recopie dÕun acteur prototype (copie stricte ou diffŽrentielle). La notion dÕhŽritage, comme nous lÕavons Žcrit plus haut, nÕexiste pas dans le mod•le acteur. Elle y est remplacŽe par le mŽcanisme de dŽlŽgation. CÕest un moyen diffŽrent de partager la connaissance entre plusieurs acteurs: lÕhŽritage classique (ˆ la Smalltalk [GOLDBERG85]) est un mŽcanisme c‰blŽ dans le langage alors que la dŽlŽgation est un passage de message. 2.2.2.5. SŽlection de mŽthodes La derni•re originalitŽ de ce mod•le est la gŽnŽralisation des sŽlecteurs. Les messages ne sont pas reconnus dÕapr•s un mot clŽ (sŽlecteur) mais par filtrage (Òpattern matchingÓ). Ainsi, contrairement au mod•le ˆ objets, ce nÕest plus le sŽlecteur qui dŽclenche la mŽthode appropriŽ. ConsidŽrons par exemple les deux mŽthodes suivantes: <Concatener x y> & <Concatener x y z> La seconde mŽthode nÕest dŽclenchŽe que sÕil y a correspondance entre le message en entrŽe et le ÒprototypeÓ qui la dŽfinit. Le message suivant <Concatener Òcha”ne1Ó Òcha”ne2Ó Òcha”ne3Ó> dŽclenche donc la mŽthode <Concatener x y z>. LÕinterface dÕun acteur, appelŽe intention, dŽfinit le contrat que lÕacteur a passŽ avec le monde extŽrieur. LÕacteur est seul responsable de la 53 Chapitre 2 - Mod•les de programmation et dÕexŽcution mani•re dont il remplit son contrat. Il ne conna”t que lÕintention de ses accointances, qui peuvent •tre considŽrŽes comme une abstraction de sa reprŽsentation physique. Nous retrouvons donc la notion classique dÕabstraction de donnŽes: un acteur est dŽfini par son comportement et non par sa reprŽsentation physique. 2.2.2.6. ActivitŽ dÕun acteur La structure des acteurs peut •tre Žtendue ˆ la dŽcomposition suivante en trois sections: ¥ la premi•re (DonnŽes) contient les donnŽes locales qui dŽfinissent son Žtat, ¥ la seconde (Comportement) dŽcrit son comportement de base, ce quÕil ne cesse de faire, ¥ et la troisi•me (MŽthodes) caractŽrise ses rŽactions ˆ la rŽception de messages. Cette derni•re dŽfinition sÕŽloigne de celle proposŽe par C.HEWITT, mais semble se rapprocher davantage du mod•le de classe, enrichie par la notion dÕactivitŽ des acteurs. Un acteur qui nÕa pas de comportement propre est dit passif: sa seule prŽoccupation est de rŽpondre ˆ des messages qui lui sont envoyŽs. Les acteurs, dit actifs, agissent indŽpendamment des communications quÕils entretiennent avec dÕautres acteurs. Les mŽthodes peuvent •tre considŽrŽes comme de petites procŽdures locales ˆ lÕentitŽ et dŽclenchŽes lors de la rŽception dÕun message. LÕeffet de ces mŽthodes est soit de modifier les valeurs des donnŽes locales, soit dÕenvoyer dÕautres messages. Quelle que soit la structure adoptŽe pour dŽcrire un acteur (en deux ou trois sections), la valeur dÕune accointance nÕest jamais modifiŽe par une affectation, mais gr‰ce ˆ un changement dÕŽtat (en r•gle gŽnŽrale, lÕinstruction become). Pour conclure ce mod•le, nous dirons que lÕensemble des notions prŽsentŽes dans ce paragraphe augmente considŽrablement la souplesse de la programmation. Mais il faut •tre conscient que, dans bien des cas, cette 54 Chapitre 2 - Mod•les de programmation et dÕexŽcution souplesse nŽcessite de la part du programmeur une grande rigueur. Il nÕest guidŽ, en effet par aucune mŽthodologie. DÕautre part, la souplesse se paie souvent en temps de calcul. Le mod•le dÕacteurs est suffisant pour aborder une large classe dÕapplications (syst•me dÕintelligence artificielle, simulation de syst•mes complexes...). Cependant, dÕautres types dÕapplications, tels que les syst•mes complexes dÕintelligence artificielle, nŽcessitent un enrichissement de ce mod•le par la notion de connaissance: cÕest le mod•le dÕagents. 55 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.3. DŽfinition du mod•le dÕagents Les travaux que [KORNFELD79] a menŽ en collaboration avec C.HEWITT [KORNFELD80] ont dŽgagŽ de nouvelles bases quant ˆ lÕapproche de la rŽsolution distribuŽe de probl•mes. Elle est fondŽe sur la mŽtaphore de la communautŽ scientifique. La rŽsolution dÕun probl•me est basŽe sur la notion de Òproposition/rŽfutationÓ. Elle est le rŽsultat dÕune nŽgociation entre plusieurs individus : proposition, objection, contre-proposition, approbation... Chacun des individus qui intervient dans cette dŽmarche est appelŽ agent. LÕensemble des agents en coopŽration constituent alors un syst•me Òmulti-agentsÓ. 2.2.3.1. DŽfinition dÕun agent [FERBER89] donne la dŽfinition suivante dÕun agent: ÒOn appelle agent, une entitŽ rŽelle ou abstraite qui est capable dÕagir sur elle-m•me et son environnement, qui dispose dÕune reprŽsentation partielle de cet environnement, qui, dans un univers multiagents, peut communiquer avec dÕautres agents, et dont le comportement est la consŽquence de ses observations, de sa connaissance et des interactions avec les autres agentsÓ. La diffŽrence fondamentale entre le mod•le dÕagent et le mod•le dÕacteurs est que, dans le premier, il existe une connaissance (expertise), qui est absente dans le second mod•le. Certains auteurs ajoutent la notion de responsabilitŽ et dÕengagement [COHEN90] [BURMEISTER91]. Un agent qui sÕengage pour la rŽalisation dÕune fonction, suivant un contrat, a la responsabilitŽ de la mener ˆ terme. Pour cela, il peut coopŽrer avec dÕautres agents. Dans ce contrat, nous pouvons spŽcifier des conditions dÕengagement (prŽ-conditions) ainsi que des clauses portant sur les conditions que vŽrifie le rŽsultat une fois que cet engagement est honorŽ (post-conditions). 56 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.3.2. DiffŽrents types dÕagents DÕapr•s la dŽfinition prŽcŽdente, nous pouvons distinguer deux types dÕagents [RUSSEL89] [KNIGHT9?]: ¥ les agents dŽlibŽratifs, les objectifs ˆ atteindre sont explicites et font lÕobjet dÕun raisonnement, ¥ les agents rŽactifs, dans ce cas, les objectifs sont implicites et dŽfinis par les Žchanges entre les agents. 2.2.3.3. Organisation des agents [FERBER89] distingue deux types dÕorganisations dÕagents: ¥ lÕapproche sociale: les agents sont supposŽs douŽs dÕune ÒintelligenceÓ et capables dÕavoir une perception de leur environnement; chacun des agents a un but quÕil cherche ˆ satisfaire (en tenant compte de la connaissance que dÕautres agents lui communiquent), ¥ lÕapproche biologique: dans cette conception, il nÕy a pas de prŽsomption quant ˆ lÕintelligence des agents. Comme le souligne [FERBER89], ÒlÕintelligence Žmerge de lÕinteraction dÕun grand nombre dÕagents qui individuellement ne disposent dÕaucune intelligenceÓ. LÕŽchange de donnŽes entre les diffŽrents agents dŽtermine la progression dans la rŽsolution dÕun probl•me. GŽnŽralement, tous les agents ont une structure et un mŽcanisme de rŽsolution identiques. Ce sont donc des syst•mes primaires o• la coopŽration est le seul lien dÕorganisation. 2.2.3.4. Protocoles de communication entre agents La structuration dÕun ensemble dÕagents en sociŽtŽ ou en une organisation primaire, nŽcessite la dŽfinition dÕun protocole de communication et dÕinteraction. Les interactions entre les agents peuvent relever: ¥ soit dÕun protocole de rŽsolution, qui correspond ˆ lÕensemble des interactions qui contribuent ˆ la progression dans la rŽsolution dÕun probl•me; ce sont tous les mŽcanismes qui portent sur les donnŽes; ¥ soit dÕun protocole dÕorganisation, constituŽ des interactions mises en Ïuvre pour la structuration des agents en vue de rŽsoudre des conflits internes dÕorganisation. Ceci correspond aux attitudes (dŽcisions) des diffŽrents agents face ˆ un probl•me. Par la suite, le protocole de rŽsolution adŽquat est appliquŽ pour la rŽsolution du probl•me. 2.2.3.5. GranularitŽ et mod•le dÕagents 57 Chapitre 2 - Mod•les de programmation et dÕexŽcution On peut dire que lÕapproche sociale correspond ˆ une structuration ˆ gros grain. Chaque agent exhibe dÕimportantes capacitŽs: il est capable de prendre des dŽcisions (suivant ses propres intentions) sans manifestation dÕŽvŽnements dans son environnement. A lÕopposŽ, lÕapproche biologique se rapproche davantage du mod•le connexionniste (rŽseaux de neurones). Les agents sont de petite taille (grain fin), et gŽnŽralement en grand nombre [FERBER91]. La relation des agents avec leur environnement est essentielle. Elle dŽtermine, suivant un comportement prŽdŽfini, la progression de la rŽsolution dÕun probl•me. 58 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.2.4. Conclusion Il existe une certaine similitude entre les mod•le dÕacteurs et dÕagents. Tous deux prŽsentent une autonomie et un syst•me dÕŽchange par messages. La dichotomie entre acteurs actifs et acteurs passifs a une projection dans le mod•le dÕagents par la division des agents en agents dŽlibŽratifs et agents rŽactifs, respectivement. Mod•le Agents D E P E N D A N C E Mod•le Acteurs Mod•le Objets C O N N A I S S A N C E Fig.2.9. HiŽrarchie au niveau concepts des mod•les orientŽs objets. On peut dire que le mod•le dÕagents est une extension du mod•le dÕacteurs. Il reprend toutes les caractŽristiques du premier et lui additionne des facultŽs de plus haut niveau. DÕailleurs, historiquement, le mod•le dÕagents a dŽcoulŽ des travaux concernant les acteurs [KORNFELD80]. En ce qui nous concerne, il existe une bonne adŽquation entre le mod•le dÕacteurs et les spŽcifications faisant partie du cahier des charges (cf.introduction). Nous nous limiterons donc, dans notre Žtude, ˆ ce mod•le. CÕest dans ce contexte que nous allons dŽvelopper un mod•le dÕacteurs particulier: le langage CANTOR. CÕest ce langage que nous avons sŽlectionnŽ pour illustrer nos propos. Par la suite, nous explicitons la mise en Ïuvre du mod•le acteur dans lÕarchitecture R.C.A.I. 59 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.3. Un mod•le dÕacteurs particulier: CANTOR CANTOR est un langage qui peut •tre dŽfini comme une variante (adaptation) du mod•le dÕacteurs. CÕest autour de ce langage quÕa ŽtŽ dŽveloppŽ le projet MOSAIC de Caltech [ATHAS86]. Un des rŽsultats de ce projet est lÕŽlaboration du MDP (Message Driven Processor). Cette unitŽ interpr•te directement les messages et rŽalise une recherche rapide des mŽthodes spŽcifiŽes dans les diffŽrents messages. Les objets CANTOR sont des ÒagentsÓ (unitŽs) de calcul indŽpendants. Ces objets ne communiquent que par passage de messages. Ce langage a ŽtŽ ŽlaborŽ dans le but de dŽcrire des traitements concurrents. 2.3.1. Les objets CANTOR Un objet CANTOR est composŽ: ¥ dÕun ensemble dÕaccointances (variables locales - privŽes), ¥ dÕune bo”te ˆ lettres pour le stockage des messages, et ¥ dÕun script (comportement) activŽ en fonction des messages re•us. Les objets sont normalement au repos, en attente dÕun ŽvŽnement pour les activer. Toutefois, les objets dans ce syst•me ne sont pas ÒŽternelsÓ. Apr•s avoir traitŽ un message, chaque objet doit: ¥ ou se positionner dans un nouvel Žtat qui lui permet de recevoir dÕautres messages, ¥ ou sÕauto-dŽtruire, et quitter de la sorte le syst•me. La rŽaction ˆ la rŽception dÕun message est standard. Ces actions incluent: ¥ lÕenvoi de nouveaux messages, ¥ la crŽation de nouveaux objets, ¥ le dŽclenchement dÕopŽrations de base: opŽrations arithmŽtiques, affectations... La communication entre les objets est asynchrone. CANTOR Žtablit une sŽparation temporelle entre le nom dÕun objet et son instance. Une rŽfŽrence ˆ un objet peut avoir lieu avant m•me sa crŽation effective. Cependant, pour quÕun objet puisse accepter un message, lÕobjet doit avoir ŽtŽ instanciŽ auparavant. 60 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.3.2. Structures de contr™le et structures de donnŽes dans CANTOR CANTOR ne fournit aucune structure de donnŽes de haut niveau. Les tableaux, structures (RECORD) ou piles, par exemple, sont inexistantes dans ce langage. Ces donnŽes doivent donc •tre construites explicitement ˆ partir dÕobjets de CANTOR. De m•me, les structures de contr™le sont compl•tement absentes dans ce langage. Les structures de boucle (telle que lÕexpression while) doivent •tre construites par des opŽrations de passation de messages. 2.3.3. Structure dÕun programme CANTOR La structure gŽnŽrale dÕun programme CANTOR peut prendre lÕune des deux formes suivantes12: <Nom_Objet> (<Liste_de_Param•tres>) * [ <Corps_Progamme_Persistant> :: ] <Nom_Objet> (<Liste_de_Param•tres>) [ <Corps_Progamme_Temporaire> :: ] La diffŽrence entre les deux structures est la longŽvitŽ des objets quÕelles dŽfinissent. Dans la premi•re, lÕobjet persiste tout au long de lÕexŽcution du programme. Dans lÕautre, lÕobjet sÕauto-dŽtruit apr•s exŽcution de la derni•re instruction dans le corps de lÕobjet. La liste des param•tres, dont la portŽe est locale, peut •tre vide. 12Les crochets [ et ] ainsi que le symbole * font partie de la syntaxe de ce langage. 61 Chapitre 2 - Mod•les de programmation et dÕexŽcution Le corps dÕun programme est gŽnŽralement constituŽ dÕune suite de blocs de la forme suivante : <DŽbut_Corps_Programme> ( <Variable_Communication> { , <Variable_Communication>}* ) <Reste_Corps_Programme> Les variables de communication sont les variables attendues pour engager le traitement qui suit cette expression. Ces variables, ainsi que les param•tres, sont considŽrŽs comme des variables globales ˆ la dŽfinition en cours (corps du programme). Le reste du corps dÕun programme (respectivement dÕun objet), est composŽ des diffŽrentes expressions dŽveloppŽes dans le paragraphe qui suit. 2.3.4. Les expressions de CANTOR 2.3.4.1. DŽclaration de variables locales LÕexpression suivante permet de rŽserver un emplacement pour recevoir la valeur dÕune expression. Ces variables sont locales au bloc en cours (dŽlimitŽ par les deux symboles [ et ]). let <Nom_Variable> = <Expression> Il faut rappeler que les variables CANTOR sont typŽes dynamiquement, au moment de leur crŽation. 2.3.4.2. Instruction conditionnelle La conditionnelle se prŽsente sous la forme classique13: if <Expression_BoolŽenne> then <Expression>+ [else <Expression>+] fi 13Les crochets qui entourent lÕexpression else signifient que celle-ci est facultative. 62 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.3.4.3. Affectation LÕaffectation ne peut avoir lieu que dans des variables rŽservŽes au moyen de lÕinstruction let, ou faisant partie de la liste des param•tres ou de la liste des variables de communication. <Nom_Variable> := <Expression> 2.3.4.4. Instruction de communication Il nÕexiste quÕune seule forme dÕinstruction pour la communication. Elle est structurŽe de la mani•re suivante: send ( <Expression_1> ) to <Expression_2> La valeur de lÕexpression qui dŽtermine la destination (Expression_2) doit correspondre ˆ une rŽfŽrence. La valeur particuli•re self pour cette expression dŽnote une rŽfŽrence ˆ soi-m•me. La premi•re expression est une liste de constantes, variables ou rŽfŽrences ˆ dÕautres objets. Cette liste peut •tre vide (cas dÕun signal). Les rŽfŽrences ˆ des objets peuvent donc •tre communiquŽs entre les acteurs, Žtablissant par la m•me occasion des liens dynamiques (ˆ lÕexŽcution). 63 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.3.4.5. RŽpŽtition LÕitŽration peut •tre obtenue au moyen de deux styles de programmation: ¥ en recourant ˆ lÕinstruction conditionnelle: repeat_relay (where, what) [ (i) if i > 0 then s e n d (what) to s e n d (i - 1) t o fi ] [ (console) s e n d (5) t o ] :: where repeat_relay repeat_relay (where, what) (console, ÒHello WorldÓ) ¥ en utilisant lÕinstruction repeat: repeat_relay (where, what) [ (i) if i > 0 then s e n d (what) to s e n d (i - 1) t o repeat fi ] [ (console) s e n d (5) t o ] :: where self repeat_relay (console, ÒHello WorldÓ) ¥ en utilisant les objets persistants, combinŽs avec lÕinstruction exit: repeat_relay (where, what) * [ (i) if i > 0 then s e n d (what) to s e n d (i - 1) t o else exit fi ] [ (console) s e n d (5) t o ] :: where self repeat_relay (console, ÒHello WorldÓ) Dans ces trois Žcritures [ATHAS86], il sÕagit dÕŽcrire la m•me cha”ne de caract•res (en lÕoccurrence ÒHello WorldÓ) cinq fois de suite. 64 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.3.5. Un exemple de programme CANTOR Nous considŽrons ˆ ce niveau un exemple de programme CANTOR qui a ŽtŽ traduit en assembleur et implantŽ sur R.C.A.I. Il sÕagit du crible dÕErathost•ne pour la dŽtermination des nombres premiers, dont nous reparlerons au chapitre des Žvaluations. ; Programme principal [ (console) ; Attente de la variable “console” send (2000) to Generator (console, NULL, 3) ] G e n e r a t o r (console, Cell, next) ; Générateur de nombres [ (limite) [ if ( next then if < limite ) ( cell == NULL ) then ; Rechercher une cellule libre, ; puis lui affecter le code de Eratos, ; pramètres :console & le nbr premier 2 cell = Eratos (console, 2) fi send (next) to cell () let next = next + 2 repeat ; Répeter le bloc le plus interne fi ] ] Eratos (console, sieve) ; [ let Cell = NULL [ (prime) if ( prime < 0 ) then if ( cell then send fi send (sieve) else let advance let unknowm let Accu let Accu let Accu if ( Accu then if then fi send fi repeat fi ] ] Code du crible d’Erathostene != NULL (-1) to ) cell to console = prime = prime = prime / sieve = Accu * sieve = Accu - advance != 0 ) ( cell == NULL ) cell = Eratos (console, unknown) (advance) to cell () 65 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.4. Mise en Ïuvre du mod•le acteur dans R.C.A.I Pour les besoins de cette th•se, nous nous sommes limitŽs dans notre choix ˆ un langage dÕacteurs simple, du type CANTOR [ATHAS86]. Comme nous lÕavons vu prŽcŽdemment, ce langage allie les avantages de la programmation par acteurs ˆ la simplicitŽ des moyens mis en Ïuvre pour sa dŽfinition. Ce qui nous importe le plus dans nos travaux, cÕest davantage la mise en avant de mŽcanismes de base pour une implantation efficace des langages dÕacteurs, que lÕŽlaboration dÕun langage ˆ proprement parler qui serait dotŽ de toutes les nouvelles spŽcifications qui augmentent la puissance de ce mod•le [AGHA93]. 2.4.1. Quelques caract•res implicites Certaines caractŽristiques des langages dÕacteurs se retrouvent implicitement dans notre machine, ˆ commencer par une exŽcution parall•le, rŽelle, des diffŽrentes entitŽs. Les autres traits sont ŽnoncŽs dans ce qui suit. 2.4.1.1. Communication asynchrone Les communications dans la machine R.C.A.I sont, par dŽfinition, asynchrones [KARABERNOU93]. LÕŽmetteur et le rŽcepteur ne sont pas tenus de se synchroniser pour Žtablir une communication. Source Destination RŽseau de Communication Tout message transfŽrŽ au rŽseau de communication est acheminŽ de proche en proche, suivant la disponibilitŽ des tampons intermŽdiaires, jusquÕˆ sa destination. Le message est ensuite rangŽ en mŽmoire sans intervention du processeur de calcul. 66 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.4.1.2. IndŽterminisme LÕŽchange dÕinformation entre deux nÏuds du rŽseau, m•me voisins, peut prendre des dŽlais variables. Les flux de donnŽes circulant sur les liens de communication qui relient ces nÏuds ont une incidence directe sur les dŽlais de propagation. Par consŽquent, un m•me programme peut fournir des rŽsultats diffŽrents suivant lÕordre dÕarrivŽe des messages aux diffŽrents acteurs. De tels syst•mes sont donc indŽterministes. 2.4.1.3. FiabilitŽ des liens de communication Le mod•le dÕacteurs nŽcessite un rŽseau de communication fiable [AGHA86b]. Tous les messages Žmis doivent •tre dŽlivrŽs ˆ leur destination. Aucune perte de message nÕest tolŽrŽe. Dans lÕŽtat actuel de notre machine, nous sommes dans lÕobligation dÕassumer lÕhypoth•se suivante: Hypoth•se Tous les messages introduits dans le rŽseau de communication sont dŽlivrŽs ˆ leur destination, sans perte ni erreur. 2.4.2. CaractŽristiques mises en Ïuvre 2.4.2.1. Syst•me de tampons Le mod•le dÕacteurs est basŽ sur la notion de bo”te ˆ lettres. Les messages destinŽs ˆ un acteur sont rangŽs dans une file, suivant leur ordre dÕarrivŽe. LÕacteur puise dans cette structure les messages avant de leur appliquer lÕopŽration de Òpattern matchingÓ. Dans notre cas, nous avons conservŽ le syst•me de communication de la version statique de notre machine. Dans cette version, chaque message int•gre dans sa description lÕadresse mŽmoire o• il est rangŽ une fois parvenu ˆ destination. Une position mŽmoire de ce type est assimilŽe ˆ un lien de communication virtuel, Žtabli entre les deux acteurs. 67 Chapitre 2 - Mod•les de programmation et dÕexŽcution MŽmoire i MŽmoire j Canal de communication Les canaux de communication sont dŽterminŽs ˆ la compilation de lÕinstruction de haut niveau ÒSENDÓ: * ö æ ìConstante 1ü é ì Constante i üù çï ïê ï ïú ÷ SENDç í Variable 1 ý ê, í Variable i ýú ÷ ïê ï ïú ÷ ç ïîRŽfŽrence 1þ ë îRŽfŽrence i þû ø è TO Nom_Acteur, SŽlecteur Cette instruction est traduite par la sŽquence dÕinstructions de bas niveau de la figure2.11. Remarque: LÕŽditeur de liens se charge de rŽsoudre les rŽfŽrences croisŽes. En adoptant cette stratŽgie nous avons rŽduit la notion de bo”te ˆ lettres ˆ sa plus simple expression: sa taille correspond ˆ lÕensemble de ce que nous avons appelŽs les variables de communication. Toutefois, le rŽseau de communication est sollicitŽ pour Žtendre la notion de bo”te ˆ lettres. En effet, les communications sont compl•tement asynchrones. Il nÕy a pas dÕattente entre deux communications adressŽes sur un m•me canal. Le rŽseau de communication sert de tampon temporaire pour stocker les messages non encore traitŽs au niveaux des acteurs. Il faut rappeler, quÕˆ lÕarrivŽe dÕun message, celui-ci ne peut •tre rangŽ en mŽmoire que si la case mŽmoire correspondante est libre. CÕest-ˆ-dire, en se rŽfŽrant ˆ notre mod•le physique dŽveloppŽ prŽcŽdemment, nous devons avoir: Mémoire éTagjù.valid ¹ ^ ëê ûú Sachant que Tagj est lÕadresse en mŽmoire du canal de communication. 68 Chapitre 2 - Mod•les de programmation et dÕexŽcution ; Acteur Récepteur ORG 0 ; Déclarations système Tag_1: DS 1 ... Tag_i: DS 1 ; Reste du code GET Tag_1 GET Tag_i ... ... END ; Acteur Emetteur ORG 0 ; Déclarations système Var_1: DC adr_1 DC Tag_1 DC val_1 ... Var_i: DC adr_i DC Tag_i DC val_i ; Reste du code SEND Var_1 SEND Var_i ... ... END Fig.2.10. Traduction dÕune instruction de communication de haut niveau en assembleur. 69 Chapitre 2 - Mod•les de programmation et dÕexŽcution 2.4.2.2. Gestion des rŽfŽrences (accointances) 2.4.2.2.1. Reconfiguration dynamique dÕun rŽseau dÕacteurs Les syst•mes ˆ base dÕacteurs sont dynamiques. Chaque crŽation de nouvelles entitŽs engendre une structure diffŽrente. Cependant, les liens crŽŽs dynamiquement peuvent Žgalement •tre modifiŽs dynamiquement. Acteur B Acteur B Acteur A Acteur A Acteur C Acteur C Acteur E Acteur D Acteur E Acteur D Pour rŽaliser cette opŽration, lÕacteur doit envoyer un message ˆ lÕacteur concernŽ, sur un canal de communication. Ce canal rŽgit une rŽfŽrence ˆ un acteur tiers. A la rŽception de ce message, lÕinterface du routeur de la cellule Žcrase la rŽfŽrence prŽcŽdante en faveur de la nouvelle. La mise en Ïuvre de la reconfiguration dynamique est donc assez triviale dans notre syst•me. Toutefois, dÕautres considŽrations nous ont contraint ˆ abandonner pour le moment cette facultŽ. En effet, le ramasse-miettes actuel est basŽ sur un compteur de rŽfŽrences. Par consŽquent, nous ne pouvons pas modifier la structure du rŽseau dÕacteur sans mettre ˆ jour le compteur de rŽfŽrences correspondant. LÕintŽgration dÕun tel mŽcanisme nŽcessite de revoir en profondeur la procŽdure du ramasse-miettes. 2.4.2.2.2. Continuation Un trait particulier des langages dÕacteurs est la notion de continuitŽ (figure2.12). Le rŽsultat ˆ un message nÕest (nŽcessairement) pas renvoyŽ ˆ lÕŽmetteur, mais ˆ un autre acteur spŽcifiŽ dans le message lui-m•me. Les acteurs impliquŽs dans cette opŽration ne sont pas pour autant interrompus. Chacun des acteurs progresse individuellement en fonction des messages et requ•tes quÕil re•oit. Tout comme au niveau du point prŽcŽdent, il suffit de recourir ˆ un message, adressŽ ˆ un emplacement particulier de la zone syst•me (associŽe ˆ chaque acteur dans le rŽseau). En Žcrasant lÕancien contenu de cette zone, nous dŽsignons ainsi lÕacteur ˆ qui remettre la rŽponse. 70 Chapitre 2 - Mod•les de programmation et dÕexŽcution Acteur A Acteur B Acteur C Message (Reply To C) Message (Continuation) Fig.2.11. Notion de continuitŽ. 2.4.2.2.3. DŽlŽgation et Òpattern matchingÓ Le principe de la dŽlŽgation est de renvoyer tous les messages incompris ˆ lÕacteur mandataire. Dans le cas de langages dÕacteurs ÒrŽduitsÓ, tel que CANTOR, la notion de Òpattern matchingÓ nÕexiste pas. Dans ces conditions, la sŽlection de mŽthode se fait par le biais dÕun sŽlecteur (et non plus par pattern matching). De ce fait, il nÕy a pas lieu dÕintŽgrer cette notion dans notre contexte. Notre but, il faut le rappeler, nÕest pas de proposer un langage dÕacteurs en soi, mais dÕŽtudier lÕallocation dynamique de ressources dans un environnement massivement parall•le, nŽcessaire pour ce mod•le. 71 C HAPITRE 3 A LLOCATION DYNAMIQUE 3. ALLOCATION DYNAMIQUE 3.1. RŽgulation de la charge dans les syst•mes massivement parall•les Il a ŽtŽ clair, d•s lÕav•nement des machines massivement parall•les, quÕun mŽcanisme (adaptatif) pour la rŽgulation de charge Žtait nŽcessaire pour lÕallocation de ressources ˆ ces syst•mes dynamiques. Dans la littŽrature, de nombreux auteurs se sont longtemps posŽ la question du choix entre la rŽgulation de charge (Òload balancingÒ) et le partage de charge (Òload sharingÓ) [KRUEGER87b]. Alors que la premi•re approche tente de maintenir une charge Žgale sur lÕensemble du rŽseau, la seconde a pour mission de tout simplement prŽvenir lÕinactivitŽ ÒsuperflueÓ des processeurs, en assurant quÕil nÕy a pas de processeurs inactifs (ou sousutilisŽs) lorsquÕil y a des processus en attente dÕexŽcution. LÕutilisation de lÕune ou lÕautre technique dŽpend de la connaissance (ou de la prŽdiction dans certains cas) des param•tres caractŽrisant le syst•me cible. Un syst•me global de rŽgulation de charge doit •tre en mesure dÕestimer, dÕune quelconque fa•on, la charge moyenne courante du syst•me (ou une approximation dans un futur proche), pour pouvoir acquŽrir ou se dŽcharger dÕune ou plusieurs t‰ches afin de se maintenir ˆ la charge moyenne du syst•me. 75 Chapitre 3 - Allocation dynamique 3.1.1. Quelques dŽfinitions 3.1.1.1. RŽgulation de charge Pour une utilisation efficace dÕun rŽseau de processeurs, il est nŽcessaire de distribuer uniformŽment le travail sur lÕensemble des processeurs. En r•gle gŽnŽrale, cette opŽration peut •tre rŽalisŽe dÕune mani•re statique ou dynamique, par un syst•me c‰blŽ ou programmŽ. LÕŽquilibrage de la charge dÕun syst•me est dŽsignŽ sous le nom de ÒrŽgulation de la chargeÓ. 3.1.1.2. GranularitŽ La granularitŽ peut •tre dŽfinie comme Žtant la taille des unitŽs de travail allouŽes aux processeurs. Les rŽseaux de processeurs conventionnels sont dits ˆ gros grain; le travail y est allouŽ par programme entier. Il existe des machines dites ˆ grain fin (CM2, Manchester DataFlow Machine MDM, R.C.A.I ...) qui allouent de tr•s petites unitŽs de traitement de quelques instructions seulement, voire dÕune seule instruction machine dans le cas de la MDM. Bien que les machines ˆ gros grain traitent de mani•re plus efficace de grandes sŽquences dÕinstructions, elles nÕexploitent pas cependant tout le parallŽlisme potentiel dans un programme, comme cÕest gŽnŽralement le cas dans les machines ˆ grain fin. 3.1.1.3. Communication Il est maintenant communŽment admis que les communications sont souvent le facteur limitant dans les syst•mes parall•les. Ces limites peuvent •tre liŽes ˆ la bande passante qui est le dŽbit maximal dÕun canal de communication, et ˆ la latence, qui constitue le temps total pour quÕune communication parte de sa source et arrive ˆ sa destination. Ces limites peuvent causer lÕinactivitŽ du processeur ou provoquer un cožt supplŽmentaire (overhead) lors de changements de contexte de processus. Nous dirons quÕune machine est ÒtolŽrante ˆ la latenceÓ si son architecture permet une poursuite dÕexŽcution ÒnaturelleÓ en attendant une communication (cÕest le cas de la machine R.C.A.I). 3.1.1.4. LocalitŽ 76 Chapitre 3 - Allocation dynamique Pour rŽduire le cožt de communication, il est nŽcessaire dÕexploiter la localitŽ en regroupant ensemble les entitŽs reliŽes par des liens de communication. Trois approches ont ŽtŽ adoptŽes dans ce sens [SARGEANT86]: ¥ localitŽ nulle ; cette catŽgorie ignore compl•tement cette notion en partant du fait que cette propriŽtŽ est trop difficile ˆ exploiter, donc, autant lÕignorer en assurant plut™t une meilleure fonction de communication (telle que le projet Manchester DataFlow Machine), ¥ localitŽ partielle ; dans cette approche la notion de localitŽ est Žtendue ˆ lÕarchitecture des machines. LÕobjectif dans cette catŽgorie est de tenter de regrouper les unitŽs de mŽmoire et les processeurs ÒphysiquementÓ par des liens de communication fortement couplŽs. Le but final est de rŽduire le temps nŽcessaire aux ÇswitchsÈ pour Žtablir les connexions. Les machines visŽes ˆ ce niveau sont celles possŽdant un rŽseau de communication ÒdenseÓ (tel le Transputer ou la FlagShip), ¥ localitŽ totale ; ˆ ce niveau, les processeurs et les mŽmoires sont considŽrŽes fortement liŽes et le rŽseau dÕinterconnexion ÒsoupleÓ, telle une grille par exemple. Dans ce cas, il est primordial dÕexploiter les liens de voisinage des diffŽrents processeurs pour tirer parti de la notion de localitŽ. 77 Chapitre 3 - Allocation dynamique 3.1.2. Modes de rŽgulation de charge14 3.1.2.1. Mode centralisŽ Comme dans tous les syst•mes centralisŽs, cÕest un processeur particulier, dit processeur ma”tre, qui sÕoccupe du maintien de lÕŽtat global du syst•me pour lÕallocation de processus aux autres processeurs, dits processeurs esclaves, suivant leur Žtat de charge. La simplicitŽ de tels algorithmes ne rŽsout pas lÕŽternel probl•me du goulot dÕŽtranglement que constitue le processeur central. Un autre probl•me est celui de la tolŽrance aux pannes: un tel syst•me serait en compl•te paralysie suite ˆ une panne du processeur ma”tre. Par similitude avec le probl•me de la rŽgŽnŽration du jeton dans un syst•me rŽparti, un rem•de pour la tolŽrance aux pannes serait de dupliquer le processeur central sur plusieurs autres nÏuds. NŽanmoins le nombre de messages nŽcessaires pour la mise ˆ jour de lÕŽtat du syst•me sera multipliŽ par autant de fois quÕil y a de copies du processeur ma”tre. De plus, ce rem•de nŽcessitera inŽvitablement un mŽcanisme complexe de diffusion sŽlective (Òone to manyÓ) pour plus de performance. 3.1.2.2. Mode rŽparti Dans cette catŽgorie, un m•me algorithme est exŽcutŽ sur lÕensemble des processeurs. Un rŽseau composŽ de ce type de processeurs sera beaucoup plus rŽsistant aux pannes par reconfiguration du syst•me. LÕextension de ce dernier peut •tre facilement apprŽhendŽe dans cette approche. Le probl•me majeur que pose la rŽpartition dÕune information est le maintien de sa cohŽrence. 14On pourra trouver une tr•s bonne classification de la rŽgulation de charge dans [XU93] et [GOSCINSKI91]. Nous en proposons une autre ˆ ce niveau. 78 Chapitre 3 - Allocation dynamique 3.1.2.3. Mode mixte Une solution intermŽdiaire consiste ˆ hiŽrarchiser le syst•me. Chaque groupe dispose de son propre processeur ma”tre. Cette hiŽrarchie peut •tre rŽalisŽe de deux mani•res: ¥ hiŽrarchie ˆ plusieurs niveaux, ou structure de compŽtition; dans ce cas chaque niveau est responsable des niveaux infŽrieur. En cas dÕincapacitŽ ˆ satisfaire une demande de service par un niveau infŽrieur, il y a transfert de celle-ci au niveau supŽrieur immŽdiat. On aboutit ainsi ˆ une gestion arborescente de demandes dÕallocation de processeurs. ¥ hiŽrarchie ˆ un niveau, ou structure de coopŽration. Dans ce cas, le syst•me sera divisŽ en plusieurs partitions. Chaque partition est indŽpendante des autres. En cas dÕŽchec pour lÕallocation dÕune ressource, une demande de coopŽration sera diffusŽe vers les ma”tres des autres partitions. Lorsque la profondeur de lÕarborescence dans le premier cas, ou le nombre de partitions dans le second cas, augmente, la duplication des nÏuds de maintien de lÕŽtat des processeurs de chaque niveau ou partition devient un sŽrieux probl•me pour la tolŽrance aux pannes. Toutefois lorsque le nombre de ces entitŽs augmente, la taille de lÕinformation ˆ maintenir diminuant, leur duplication sera toujours possible. En effet, nous pourrons supposer que ces algorithmes pourront cohabiter avec des processus esclaves. Ils ne monopolisent plus les processeurs. De surcro”t, plus le nombre de partitions ou niveaux augmente, plus le nombre de copies de processeurs ma”tres nŽcessaire pour la tolŽrance aux pannes diminue. 79 Chapitre 3 - Allocation dynamique 3.1.3. Modes de transfert de processus La rŽgulation de charge peut agir de deux mani•res: ¥ en opŽrant sous le mode non prŽemptif, ˆ ce moment on rŽalise un placement 15 de processus. La dŽcision de transfert nÕest prise quÕˆ la naissance du processus, suivant lÕŽtat de charge du processeur qui le supporte. Dans ce cas, une fois allouŽ ˆ un processeur, le processus ne pourra plus migrer ailleurs, assurant ainsi une certaine stabilitŽ du syst•me. ¥ en opŽrant sous le mode prŽemptif, et on parle alors de migration de processus. La dŽcision de transfŽrer un processus peut affecter m•me un processus en cours dÕexŽcution. La migration est beaucoup plus cožteuse que le placement, puisque le contexte du processus, qui doit lÕaccompagner vers le processeur cible, devient beaucoup plus complexe apr•s le dŽbut dÕexŽcution. Ceci ajoute donc un volume dÕinformations supplŽmentaires qui doivent accompagner le processus. LÕopŽration de migration doit rester transparente vis ˆ vis des processus qui communiquent avec ce dernier (nous ne devons pas redŽfinir lÕespace dÕadressage de ceux-ci). Dans la cas contraire, il faudra prŽvoir un mŽcanisme de rŽ-acheminement des messages adressŽs ˆ ce processus, tel le mŽcanisme de relais que nous proposons dans la machine R.C.A.I (se reporter au paragraphe4.3). La question posŽe ˆ ce niveau est de savoir [KRUEGER88], vu les cožts de gestion occasionnŽs par la complexitŽ du mŽcanisme de migration de processus, si le placement ˆ lui seul ne peut pas rŽguler la charge du syst•me? La rŽponse a ŽtŽ que la migration ne peut apporter de meilleures performances que dans le cas o• le syst•me comporte beaucoup plus de processus que de nÏuds. 15 Dans le sens o• un processus est allouŽ une fois pour toutes ˆ un site. Le mode prŽemptif rŽalise Žgalement un placement de processus. Il sÕagit juste de faire la diffŽrence entre les deux modes. 80 Chapitre 3 - Allocation dynamique 3.1.4. Mode dÕŽchange dÕinformations Le maintien de la cohŽrence des donnŽes dÕun algorithme de rŽgulation de charge repose sur le type dÕŽchange dÕinformations entre les diffŽrents processeurs [EAGER86]. Cet Žchange peut •tre (cf.les diagrammes3.1 et 3.2): ¥ actif :dans ce cas, lorsquÕun processeur dŽsire prendre une dŽcision de placement de processus, il va interroger les processeurs concernŽs sur leur propre Žtat (sender-initiated), ¥ passif : ˆ ce moment, lorsquÕun changement intervient au niveau dÕun processeur, celui-ci le communique automatiquement aux processeurs concernŽs (receiver-initiated). Ces deux modes dÕŽchange dÕinformation induisent un Žchange de donnŽes trop frŽquent, pas toujours nŽcessaire pour prendre une dŽcision. Une solution intermŽdiaire serait de rŽaliser un Žchange pŽriodique. Ce mode dÕŽchange nÕest valable que dans le cas du mode passif, puisque laissŽ ˆ lÕinitiative du processeur o• sÕop•re le changement dÕŽtat. Dans cette variante on ne communiquera un nouvel Žtat que lorsque celui-ci a changŽ dÕune mani•re significative, eu Žgard ˆ une fonction dŽfinie (taux relatif, suite exponentielle... [KUCHEN91]). Dans le diagramme 3.2, le voisinage dÕun nÏud peut •tre dŽfini soit par lÕensemble des nÏuds qui lui sont connectŽs physiquement, soit par un crit•re de proximitŽ logique (tous les nÏuds de distance infŽrieure ou Žgale ˆ deux, par exemple). En ce qui concerne la migration de processus, toujours dans le m•me diagramme, il faut sÕassurer de la stabilitŽ du syst•me. En effet, il faut Žviter quÕun processus ne migre perpŽtuellement dÕun nÏud vers un autre. Une politique de dŽsignation de candidats ˆ lÕimmigration doit donc •tre Žtablie. Elle peut reposer simplement sur lÕutilisation dÕun compteur qui limite le nombre de dŽplacements dÕun processus. 81 Chapitre 3 - Allocation dynamique DŽbut d'un processus sur i Nbre de processus locaux >= Seuil Oui Choisir le prochain processeur j suivant la politique de localisation Non ExŽcuter localement le processus sur i Non Processeur dŽterminŽ ? Oui Envoyer une offre d'exŽcution d'un processus ˆ j TransfŽrer le processus sur j Oui RŽponse du processeur localisŽ j positive ? Non Diagramme 3.1. StratŽgie Òsender initiatedÓ Fin d'un processus sur i Nbre de processus Oui locaux < Seuil Oui Non Envoyer une offre au prochain processeur j dŽfini dans le voisinage de i Tout le voisinage de i consultŽ ? Non Attendre la prochaine fin d'un processus Syst•me avec migration Non Oui Nbre de processus sur j >= Seuil Non TransfŽrer un processus de j vers i Non Nbre de processus locaux < Seuil Oui Diagramme 3.2. StratŽgie Òreceiver initiatedÓ 82 Chapitre 3 - Allocation dynamique 3.1.5. Crit•res pour lÕŽvaluation de lÕindice de charge LÕŽvaluation de lÕindice de charge doit choisir entre, calculer une valeur exacte en se basant sur un maximum de crit•res, ou rŽaliser une approximation non optimale, mais satisfaisante pour une prise de dŽcision rapide en se basant cette fois-ci uniquement sur quelques crit•res jugŽs significatifs. Parmi les crit•res dÕŽvaluation de lÕindice de charge, nous pouvons citer entre autres: ¥ la taille de la file dÕattente pour lÕunitŽ de calcul (CPU), ¥ la taille de la file dÕattente des messages ˆ traiter (MESS), ¥ la taille de la file dÕattente des entrŽes/sorties (E/S), ¥ la taille de la mŽmoire dynamique utilisŽe (m•me si cet indicateur nÕest pas exhaustif en ce qui concerne le temps dÕexŽcution dÕun processus)... Une corrŽlation doit •tre trouvŽe entre certains de ces crit•res pour constituer une approximation significative de lÕindice de charge dÕun processeur. Dans la pratique, tout dŽpend en fait du type dÕapplications visŽes: si celles-ci demandent beaucoup de temps de calcul, la taille de la file dÕattente CPU peut constituer un bon indicateur pour lÕŽvaluation de lÕindice de charge; par contre, lorsquÕil sÕagit dÕapplications qui effectuent ŽnormŽment dÕentrŽes/sorties, tout porte ˆ privilŽgier la taille de la file dÕattente E/S pour dŽterminer lÕindice de charge du processeur. De m•me, le taux de communication gŽnŽrŽ par lÕapplication peut apporter un ŽlŽment supplŽmentaire pour lÕŽvaluation de lÕindice de charge. En effet, suivant que la communication est continue ou sporadique, la prise en compte de la taille de la file des messages en attente peut sÕavŽrer judicieuse ou dŽsu•te. 83 Chapitre 3 - Allocation dynamique 3.1.6. Distance et protocole de transfert de processus Le grain de parallŽlisme a un impact direct sur ce point. Plus le grain est gros, plus le volume dÕinformation ˆ transfŽrer est important. DÕun autre c™tŽ, plus le grain est fin, plus le rŽseau de communication est sollicitŽ par tous les messages de synchronisation et dÕŽchange dÕinformation. De ce fait, cette derni•re approche contribue ˆ un accroissement de la charge du rŽseau de communication. Intuitivement, nous pouvons penser que dans le cas dÕun grain fin, nous avons tout intŽr•t ˆ donner une importance particuli•re au crit•re de la localitŽ (distance). Deux idŽes concourent ˆ ce niveau: ¥ les rŽseaux dits ˆ topologie fixe (CM5, Parsytec, R.C.A.I...), ¥ les rŽseaux ˆ reconfiguration dynamique (tel le Transputer). Dans le premier cas, cÕest ˆ la charge de lÕalgorithme dÕallocation de dŽterminer le processeur le moins chargŽ, et le plus proche possible (nous reviendrons sur ce point par la suite). En revanche, dans le second cas, la reconfiguration du rŽseau de communication va permettre de minimiser au plus la distance entre les diffŽrents processeurs qui souhaitent opŽrer un transfert de processus des uns vers les autres. Pour cela, il faut disposer dÕun processeur ma”tre (contr™leur) qui, au vu des diffŽrentes commandes de placement, restructure instantanŽment le rŽseau de mani•re ˆ mettre en liaison directe un maximum de couples de processeurs esclaves (workers) impliquŽs dans cette opŽration. NŽanmoins les rŽseaux ˆ reconfiguration dynamique (Transputers) nÕautorisent que des structures de faible dimension [WAILLE91] et ne sont donc pas adaptŽs aux architectures massivement parall•les. Le passage ˆ des architectures de plusieurs milliers de processeurs rend impossible un rŽarrangement fiable (non bloquant) du rŽseau de commutation. De m•me, le fait dÕavoir ˆ rŽarranger ce rŽseau ˆ chaque communication entra”ne inŽvitablement une sŽrialisation des communications, dÕo• perte de parallŽlisme effectif! 84 Chapitre 3 - Allocation dynamique 3.1.7. StratŽgies de rŽgulation de charge 3.1.7.1. Allocation statique La mani•re la plus triviale pour rŽaliser une rŽgulation de charge est dÕallouer statiquement les diffŽrentes entitŽs aux processeurs. Cette opŽration peut •tre rŽalisŽe soit de mani•re automatique, transparente ˆ lÕutilisateur, soit au contraire en lÕassistant dans cette dŽmarche, ou pire en la laissant ˆ la charge de ce dernier. LÕallocation statique suppose tout de m•me une certaine adŽquation entre le probl•me ˆ traiter et lÕarchitecture cible. En exemple, nous pouvons considŽrer le traitement dÕune image par un rŽseau de processeurs organisŽs en une grille o• chacun dÕeux serait responsable dÕun pixel de lÕimage. Toutefois, ce type de projection ne peut pas •tre trouvŽ systŽmatiquement dans les programmes gŽnŽraux. CÕest le cas des programmes logiques. Nous ne pouvons faire dÕa priori sur les buts ˆ Žvaluer. Dans ce cas, une rŽgulation de charge dynamique est nŽcessaire. 3.1.7.2. MŽthodes aveugles Ces mŽthodes ne reposent gŽnŽralement sur aucune connaissance de la charge des autres processeurs. Pour cette raison, elles nÕaugmentent pas la charge du rŽseau de communication. Une approche serait de sŽlectionner alŽatoirement une distribution de processeurs destination ˆ partir dÕun ensemble de candidats [EAGER86b] [WANG85] [YUM81]... Dans la rŽgulation alŽatoire globale, tous les nÏuds du syst•mes sont Žligibles. Dans la rŽgulation alŽatoire locale, seuls les nÏuds topo-logiquement adjacents peuvent •tre candidats. Cependant, ces mŽthodes ne semblent pas avoir un large consensus bien quÕelles soient tr•s simples ˆ implŽmenter [SARGEANT86]: en effet, des simulations ont montrŽ leur inefficacitŽ, tant au niveau des machines ˆ gros grain, quÕau niveau des machines ˆ grain fin. Ceci est du principalement au fait quÕelles ne prennent pas en compte lÕŽtat de charge du syst•me lors de lÕŽtablissement de la liste des candidats. 3.1.7.3. MŽthodes ˆ jetons Dans cette mŽthode, un Òcontr™leur du rŽseauÓ rŽcup•re les annonces dÕaptitude ˆ recevoir du travail, Žmises par lÕensemble des processeurs. 85 Chapitre 3 - Allocation dynamique LorsquÕun processeur est en mesure de fournir du travail en parall•le, il adresse une demande dÕallocation au contr™leur. En retour, le contr™leur lui attribue un jeton rŽfŽren•ant le processeur pr•t ˆ recevoir ce processus. Le processus y est alors transfŽrŽ avec tout son contexte. Cependant, en cas dÕindisponibilitŽ de jetons, le processeur demandeur rŽalise le traitement en sŽquentiel, assurant par la m•me occasion un contr™le automatique du parallŽlisme. NŽanmoins, cette mŽthode nÕa ŽtŽ appliquŽe que dans le cas dÕune machine ˆ gros grain KABU-WAKE [SOHMA85], o• chaque processeur ne peut traiter quÕun processus ˆ la fois. Une variante de cette mŽthode a ŽtŽ appliquŽe ˆ la machine PIM-D [ITO86]. Chaque processeur poss•de une file de jetons des autres processeurs. LorsquÕil dispose dÕun processus ˆ allouer, il puise dans la file le premier jeton. Le processus est exŽcutŽ sur le processeur correspondant ˆ ce jeton. A la terminaison du processus, le jeton est restituŽ ˆ la fin de la queue. La rŽgulation de charge y est effectuŽe implicitement: un processeur occupŽ rendra tardivement le jeton ˆ sa source. De plus, la notion de localitŽ (distance) peut y •tre introduite en favorisant les processeurs voisins: initialement, on fournit dans la file locale davantage de jetons pour les processeurs voisins que pour ceux distants. NŽanmoins, cette technique, ainsi que sa variante, prŽsentent le gros inconvŽnient de ne pas dŽsigner explicitement les processeurs inactifs. 86 Chapitre 3 - Allocation dynamique 3.1.7.4. Propagation du gradient Les mŽthodes prŽcŽdentes ont soulevŽ la nŽcessitŽ dÕune connaissance de lÕŽtat de charge des autres processeurs pour •tre en mesure de rŽaliser une ÒbonneÓ rŽgulation de la charge du syst•me. Cette connaissance suppose donc un Žchange dÕinformation entre les diffŽrents processeurs. Une des mŽthodes pour rŽaliser cette fonction dÕŽchange dÕinformation est la propagation du gradient de pression ˆ ses voisins. Cette mŽthode a dÕabord ŽtŽ appliquŽe ˆ une grille [LIN87]. Chaque processeur est au courant de lÕŽtat de charge de ses quatre voisins immŽdiats. Ainsi, ˆ chaque Žtape, un processus sera orientŽ vers le voisin le moins chargŽ, et graduellement diffusera au travers du rŽseau (par analogie avec les pressions de gaz). Pour Žviter de se bloquer dans des minima locaux, [LIN87] propose de propager son gradient affectŽ par les pressions des voisins immŽdiats. La pression pi propagŽe dÕun processeur i est dŽfinie comme suit: { { }} pi = mingi ,1+ minp j |di, j = 1 sachant que di,j est la distance entre les processeurs i et j. Le gradient local gi du processeur i est ŽvaluŽ de la mani•re suivante: gi = ti + mem Prs /(1- memInUse) avec t i le nombre de t‰ches, memPrs une constante (param•tre du simulateur positionnŽe ˆ la valeur 0,01 dans [LIN87]), et memInUse est la portion de mŽmoire utilisŽe (comprise dans lÕintervalle ]0,1[). Trois Žtats sont dŽfinis pour caractŽriser localement une pression: ¥ light : peut accepter toute nouvelle crŽation de processus; la pression locale est maintenue ˆ 0, ¥ moderate : dans ce cas le processeur Žvalue sa propre pression en tenant compte de celles des voisins; la crŽation de la nouvelle entitŽ est tout de m•me acceptŽe localement, ¥ heavy : saturation locale, le processeur tente de transfŽrer la t‰che courante vers un de ses voisins les moins saturŽs; la pression locale est ŽvaluŽe comme dans lÕŽtat prŽc•dent. 87 Chapitre 3 - Allocation dynamique Dans tous les cas, la nouvelle pression locale nÕest communiquŽe aux voisins que si celle-ci a changŽe depuis sa derni•re mise ˆ jour. Le seul inconvŽnient de cette mŽthode est que la propagation du gradient ˆ lÕensemble du syst•me risque dÕ•tre relativement longue... 3.1.7.5. MŽthode des ench•res Les algorithmes ˆ ench•res sont une autre forme de la rŽgulation de charge [STANKOVIC84b][SMITH80]. Dans ces mŽthodes, les t‰ches sont affectŽes aux processeurs suivant leur capacitŽ ˆ rŽaliser un tel travail. A la naissance dÕun processus, une requ•te dÕench•res est diffusŽe vers les autres processeurs. Chacun de ceux-ci communique ˆ son tour le cožt dÕexŽcution de la t‰che ˆ son niveau. Le processeur demandeur choisit donc la meilleure offre pour y placer la nouvelle t‰che. Le probl•me qui se pose dans cette approche est la multitude de rŽponses ˆ une seule requ•te. La solution ˆ ce probl•me est que, lorsque le processeur demandeur retient la meilleure offre ˆ sa requ•te dÕench•re, il rŽserve le processeur correspondant [ROSS90]. Ce dernier peut accepter ou rejeter cette rŽservation, suite aux changements intervenus durant cet Žchange de messages. En cas dÕŽchec, lÕopŽration dÕench•res est reprise. LÕinconvŽnient de cette solution est le risque de famine si une requ•te est toujours supplantŽe par une autre plus ÒprocheÓ des sites qui rŽpondent ˆ ces requ•tes. Bien que ces mŽthodes fournissent une solution sous-optimale, elles sont cependant largement plus extensibles et adaptables que beaucoup dÕautres mŽthodes. De plus, les facteurs impliquŽs dans lÕŽvaluation des ench•res nÕont pas ŽtŽ tr•s bien ŽtudiŽs. [STANKOVIC84b] utilise des connaissances a priori, comme par exemple, les fichiers utilisŽs par un processus, le cožt pour lÕacc•s ˆ ces fichiers localement et ˆ distance, lÕeffet de groupage ou de sŽparation de processus coopŽrants, etc. 88 Chapitre 3 - Allocation dynamique 3.1.7.6. MŽthode micro-Žconomique Dans cette approche tr•s originale [FERGUSON88], les processeurs ainsi que les t‰ches qui doivent sÕexŽcuter dessus, sont modŽlisŽs par des agents Žconomiques. Chaque agent tente dÕauto-satisfaire ses propres besoins en ressources, du mieux quÕil peut. Il nÕy a pas dÕapproche globale dans ce syst•me. En outre, le but dÕun tel syst•me est de dŽfinir les besoins des agents et les r•gles rŽgissant leur service de telle mani•re ˆ atteindre une amŽlioration des performances globales gr‰ce ˆ une Òmain invisibleÓ. Les diffŽrents agents agissent en compŽtition pour la satisfaction de leur besoins sans aucune coopŽration: ce syst•me est rŽgi par une politique de prix structurŽe. Deux types dÕagents coexistent dans ce syst•me: les agents clients, associŽs aux t‰ches ˆ exŽcuter qui ach•tent du service, et les agents serveurs, reprŽsentŽs par les processeurs qui vendent du service. Chaque agent client qui entre dans le syst•me est dotŽ dÕun portefeuille avec une somme dÕargent initiale. LÕagent peut migrer au travers du syst•me ˆ la recherche du processeur offrant le service au prix le plus bas. Toutefois, pour garantir une stabilitŽ du syst•me (cÕest ˆ dire que les agents ne passent pas leur temps ˆ migrer), ˆ chaque passage au travers dÕun lien de communication, lÕagent doit rŽgler une certaine somme dÕargent (fonction de la charge de celui-ci). Les agents serveurs vendent entre autres du temps CPU, de la bande passante pour la communication et de la mŽmoire. Ces agents fixent leur prix indŽpendamment des autres: leur but Žtant Ò mercantileÓ, ils essayent de maximiser leur gain. Un paradoxe est quÕils ne tentent pas de rŽguler la charge ou de minimiser le temps de rŽponse. La ÒpublicitŽÓ est autorisŽe dans ce syst•me. Chaque processeur peut publier ses prix dans un Òtableau dÕaffichageÓ, maintenu par les processeurs voisins. Eu Žgard ˆ ce tableau, et suivant le budget de lÕagent client et sa demande actuelle en ressources, il lance une ench•re vers le processeur de prix le plus attractif. LÕench•re est calculŽe de la mani•re suivante: ei = ri - o j 89 Chapitre 3 - Allocation dynamique r i est le reste dÕargent de lÕagent client sur le processeur Pi, et oj est la meilleure offre de prix re•u du processeur Pj. De cette fa•on, lorsque le processeur Pj re•oit plusieurs ench•res, il choisira celle qui lui ÒrapporteÓ le plus. LorsquÕune ench•re remporte la sŽlection, lÕoffre de lÕagent client doit retourner jusquÕˆ la source, tout en rŽglant ses droits de passage au travers des liens de communication. La charge des liens de communication est une prŽoccupation persistante dans cet algorithme, puisque cÕest un cožt prŽpondŽrant dans les syst•mes parall•les. Les prix sont maintenus selon la loi de lÕoffre et de la demande. Les plus bas prix correspondent aux ressources les moins sollicitŽes, et vice versa. La question que lÕon peut se poser ˆ ce niveau, est de savoir si une mŽthode qui ne repose que sur une structure de compŽtition peut fournir des performances satisfaisantes dans un syst•me distribuŽ? Les auteurs montrent au travers de leur article, que la rŽponse est positive en ce qui concerne le probl•me de la rŽgulation de charge. Toutefois, cette mŽthode suppose une connaissance des cožts dÕexŽcution et de communication des processus, ainsi que les temps de service CPU, que le syst•me nÕest pas toujours en mesure de conna”tre dans un environnement dynamique. 3.1.7.7. MŽthode stochastique [HAILPERIN88] propose une nouvelle mŽthode de rŽgulation de charge dynamique basŽe sur une analyse statistique de sŽries temporelles. Chaque nÏud estime une moyenne majorŽe de lÕindice de charge du syst•me en exploitant des connaissances passŽes des indices de charge de chacun des autres processeurs. Le but de chaque nÏud est dÕapprocher cette valeur. Cette mŽthode a ŽtŽ appliquŽe dans un syst•me qui exhibe des indices de charge pŽriodiques, sur une architecture qui assure un routage virtuel (du type ÒwormeholeÓ) et un mŽcanisme de communication Òone-to-manyÓ performant. PŽriodiquement, chaque processeur propage son information vers un Žchantillon alŽatoire des autres processeurs. [HAILPERIN88] montre que la distribution ainsi gŽnŽrŽe par cette communication suit une loi binomiale, pour rapidement converger vers une distribution de Poisson. Ainsi, il assure 90 Chapitre 3 - Allocation dynamique par cette m•me occasion un volume dÕinformation suffisant pour Žtablir une bonne approximation de la charge moyenne du syst•me, m•me lorsque la taille de lÕŽchantillon est petite. A la rŽception dÕun message dÕinformation, le processeur int•gre celle-ci dans sa propre connaissance, puis utilise le mod•le des sŽries temporelles (fourni ˆ priori suivant une expŽrimentation portŽe sur ce syst•me) pour estimer la charge moyenne courante du rŽseau. Il compare ensuite la charge prŽdite avec sa propre charge et celle re•ue de lÕŽmetteur. Si le processeur rŽcepteur semble relativement sous chargŽ par rapport ˆ lÕŽmetteur, une demande de t‰che sera Žmise en retour. Comme toutes les mŽthodes basŽes sur les Òench•resÓ, quelques prŽcautions doivent •tre prises pour Žviter une congestion du rŽseau de communication. Le processeur sous chargŽ ne propose plus de transfert de t‰ches jusquÕˆ ce quÕil re•oive du processeur surchargŽ soit une t‰che soit une excuse (si une meilleure ench•re a ŽtŽ obtenue dÕun autre processeur). Une autre possibilitŽ serait que le processeur Žmetteur rŽserve le processeur sous chargŽ; mais ceci suppose quÕil y ait Žchange de messages supplŽmentaires. Le seul inconvŽnient de cette mŽthode est quÕil nÕy a pas de dŽsignation de lÕobjet ˆ transfŽrer. Ce mŽcanisme a ŽtŽ surtout dŽveloppŽ pour un syst•me temps rŽel o• il est primordial dÕŽtablir une distinction nette entre les t‰ches prioritaires et les autres. 91 Chapitre 3 - Allocation dynamique 3.1.8. De la prŽdiction de quelques param•tres... Les donnŽes peuvent-elles fournir un ŽlŽment significatif pour pouvoir apprŽhender le probl•me de la rŽgulation dynamique de la charge dÕun rŽseau de processeurs? LÕŽtude statique dÕun programme peut-elle dŽgager des caractŽristiques qui peuvent •tre exploitŽes dans le but de faciliter par la suite la t‰che de rŽgulation de charge? Autant de questions qui sont ˆ lÕordre du jour, dans les prŽoccupations du domaine des syst•mes parall•les et distribuŽs [MEHRA93] [ROCH92] [KUNZ91] [DEVARAKONDA89] [ZHOU88] ... Une premi•re Žbauche de rŽponse est de dire que ce probl•me est intimement liŽ ˆ son expression. A savoir, les mod•les de programmation et dÕexŽcution utilisŽs, ainsi que lÕarchitecture cible dans une moindre mesure, puisque elle intervient en fin de cycle, au moment de lÕexŽcution. De m•me, les applications visŽes peuvent apporter un ŽlŽment supplŽmentaire dans lÕŽlaboration dÕun cadre dÕextraction de param•tres susceptibles dÕ•tre opportuns lors du placement dynamique. SÕagissant de la programmation logique par exemple, un graphe de dŽpendance des littŽraux dÕune clause, ainsi que les relations entre les diffŽrents arguments dÕune m•me clause peuvent fournir une estimation de la mŽmoire requise pour la liaison des variables, ainsi que le nombre maximal de clauses qui peuvent sÕexŽcuter simultanŽment (le cas des boucles nÕest pas considŽrŽ ˆ ce niveau). Dans le cas de la programmation par objet, il est toujours possible de dŽgager le graphe dÕexŽcution du rŽseau dÕobjets, en se rŽfŽrant ˆ leur interdŽpendance (dŽsignations entre objets). LÕanalyse de ce graphe permet dÕŽtablir pour chaque objet le degrŽ de parallŽlisme quÕil pourra gŽnŽrer ˆ chaque moment (degrŽ du sommet correspondant). Ainsi, au moment de lÕexŽcution, le syst•me rŽserve (de prŽfŽrence et dans la mesure du possible) autant dÕespace que le degrŽ du nÏud correspondant. Ce procŽdŽ entra”ne fatalement un gaspillage inutile de ressources critiques. NŽanmoins, la complexitŽ du probl•me rel•gue pour le moment celui-ci ˆ lÕarri•re plan en attendant des jours meilleurs! 92 Chapitre 3 - Allocation dynamique 3.1.9. RŽgulation de la charge dans la machine R.C.A.I Apr•s lÕexposŽ de quelques techniques de rŽgulation de la charge, une question se pose quant ˆ lÕintŽgration dÕun tel mŽcanisme au niveau de lÕarchitecture R.C.A.I: peut-on, ou ˆ la limite, doit-on intŽgrer la procŽdure de rŽgulation/partage de la charge? PosŽe de cette fa•on, la question nÕest pas dÕun grand intŽr•t si nous ne situons pas le contexte dÕune telle fonction. Rappelons que lÕarchitecture R.C.A.I rel•ve du grain fin et qui, pour lÕinstant, ne peut prendre en charge quÕun seul processus par processeur. Par consŽquent, les unitŽs de calcul appelŽes ˆ sÕexŽcuter sur cette machine sont de tr•s petite taille. Leur durŽe de vie est relativement tr•s courte (de lÕordre de quelques centaines de cycles en moyenne). La question qui se pose alors cÕest lÕopportunitŽ dÕune fonction qui, dans certains cas, peut •tre complexe. Le temps nŽcessaire pour calculer un emplacement ÒoptimalÓ au processus est dans beaucoup de cas Žgal au temps requis pour mener ˆ terme lÕexŽcution du processus proprement dit. Ceci nous am•ne ˆ priori ˆ ignorer la rŽgulation de charge dans de telles conditions. Cependant, il ne faut pas perdre de vue que pour sÕexŽcuter, un processus doit disposer auparavant dÕun emplacement, un processeur libre, pr•t ˆ le prendre en charge. NŽanmoins, le fait que les processeurs ne peuvent, pour le moment, exŽcuter quÕun seul processus ˆ la fois, rend inutile la rŽalisation de la rŽgulation de charge. En effet, le partage de charge suffit dans ce cas ˆ Žquilibrer la charge globale du syst•me [KRUEGER87a] [KRUEGER87b]. Ce point sera discutŽ dans la prochaine section. La condition sine qua non pour pouvoir rŽaliser de la rŽgulation de charge est la disponibilitŽ de la notion de multiprogrammation au niveau du processeur ŽlŽmentaire. Le souci omniprŽsent ˆ chaque niveau de la conception de la machine R.C.A.I est dÕarriver ˆ nÕintŽgrer que des fonctions simples. Vu la finesse de grain de notre machine, il est essentiel dÕŽviter lÕutilisation de techniques qui nŽcessitent, pour leur rŽalisation, lÕinterruption des processus. Ce qui conduit ˆ Žliminer dÕores et dŽjˆ toutes les mŽthodes de multiprogrammation qui feraient appel ˆ des moyens sophistiquŽs pour la gestion de la mŽmoire. CÕest ainsi que nous sommes arrivŽs ˆ dŽcider, quÕau 93 Chapitre 3 - Allocation dynamique lieu dÕintroduire un noyau pour lÕallocation, la rŽcupŽration et le tassement de la mŽmoire lorsque cela sÕimpose, il est plus judicieux dÕŽclater la mŽmoire en plusieurs blocs. Cette procŽdure revient ˆ paginer, en quelque sorte, la mŽmoire et de nÕallouer que des pages mŽmoire et non des fragments de celleci. Dans ce cas, chaque bloc est allouŽ ˆ un seul processus. Cette structuration rend inutile le tassement de la mŽmoire (lÕunitŽ dÕallocation Žtant la page mŽmoire). ¥ ¥ ¥ Bloc 0 Bloc 1 ¥¥¥ Bloc n Fig.3.1. Partition de la mŽmoire. Le probl•me qui se pose alors est de dŽterminer la taille du bloc de base (ainsi que le nombre de ces blocs par cellule). DÕapr•s les Žtudes menŽes par [ATHAS 86], travaux dont nous nous sommes inspirŽs pour Žlaborer notre mod•le dÕexŽcution dÕacteurs, il semble que la taille du bloc soit relativement petite (la taille dÕun acteur est en moyenne de lÕordre dÕune quinzaine dÕinstructions - de haut niveau). La partition de la mŽmoire nÕest que virtuelle. En effet, il suffit dÕassocier ˆ une mŽmoire normale, contigu‘, une structure de table pour lÕallocation des diffŽrentes pages de la mŽmoire (figure3.1). Les requ•tes de cellules libres seront traduites par un couple (p i , b j) qui signifie que pour cette demande, nous allouons sur le processeur pi, le bloc mŽmoire bj. La charge dÕun processeur sera alors le nombre de blocs dŽjˆ allouŽs. 94 Chapitre 3 - Allocation dynamique BasŽ sur cette structure, nous proposons un nouvel algorithme dans les sections qui suivent, que nous avons baptisŽ CLIMB, par association aux sauts quÕil rŽalise. Nous allons dans un premier temps exposer la solution qui a ŽtŽ retenue dans la version actuelle. Par la suite, nous dŽtaillerons notre proposition pour la rŽgulation de la charge comme perspective dÕamŽlioration des performances de la machine R.C.A.I. 95 Chapitre 3 - Allocation dynamique 3.2. Mise en Ïuvre de lÕallocation dynamique Durant son exŽcution, un processus peut rŽclamer une ou plusieurs ressources pour mener ˆ bien la t‰che qui lui aura ŽtŽ assignŽe. Une ressource dans notre cas est un noyau exŽcutif (composŽ dÕune mŽmoire, dÕune unitŽ centrale et de mŽcanismes de communication et de synchronisation). La demande de ressources se dŽcompose en plusieurs phases [LATROUS94a]. La premi•re Žtape consiste ˆ Žmettre une requ•te de localisation dÕune cellule libre. Une fois cette cellule trouvŽe, il faut y charger la partie de code (processus ou encore acteur) ˆ exŽcuter. Les variables locales de ce processus (contexte) doivent •tre initialisŽes ˆ des valeurs cohŽrentes avant dÕentamer son exŽcution. Nous dŽtaillons dans la suite de cette section chacun des points qui viennent dÕ•tre ŽvoquŽs. 3.2.1. Allocation de ressources dans la machine R.C.A.I Toute demande de ressource est transmise au rŽseau de communication qui se charge de la propager ˆ lÕensemble des cellules, puis de rendre la rŽponse ˆ la cellule Žmettrice. De cette mani•re, le processeur de calcul est dŽchargŽ de cette fonction qui trouve naturellement sa place au niveau de lÕunitŽ de routage. Nous pouvons imaginer plusieurs algorithmes pour la diffusion dans une grille [TSAI94] [TAKKELLA94] [MICHALLON93] [BERMOND92] [TOUZENE92]... Cependant, il ne faut pas perdre de vue que notre but est dÕarriver ˆ intŽgrer tous ces mŽcanismes avec une consommation minimale de silicium. Par consŽquent, nous devons renoncer ˆ tous les algorithmes basŽs sur des tables de routages volumineuses. De m•me, les algorithmes qui nŽcessitent des messages intermŽdiaires de grande taille sont ˆ Žcarter. 96 Chapitre 3 - Allocation dynamique Le nombre de messages nŽcessaires dans le rŽseau pour rŽaliser la recherche de cellules libres est au minimum dÕun seul message. Ce message doit couvrir lÕensemble du rŽseau. A lÕopposŽ, dans le cas de lÕutilisation de plusieurs messages, lÕexploration du rŽseau est alors rŽpartie entre ceux-ci. Un exemple de la recherche au travers dÕun message unique est lÕalgorithme en colima•on. LÕutilisation de plusieurs messages requiert, au niveau du rŽseau de communication, un mŽcanisme de diffusion pour •tre efficace. LÕalgorithme dit de diffusion par ondes constitue un exemple de cette stratŽgie que nous dŽveloppons ici. 3.2.1.1. Algorithme en colima•on Dans cette mŽthode, il nÕy a quÕun seul message par demande dans le rŽseau. Le message dŽcrit une spirale autour de la cellule Žmettrice (figure3.2). Fig.3.2. Principe de lÕalgorithme en colima•on. LÕadresse relative par rapport ˆ la cellule Žmettrice est entretenue (par des incrŽmentations et des dŽcrŽmentations) de sorte ˆ pouvoir rendre la rŽponse ˆ celle-ci. De m•me, un contr™le est effectuŽ sur le calcul de lÕadresse de retour, pour Žviter que cette demande ne dŽpasse lÕespace dÕadressage de la cellule source. Cet algorithme nÕest pas aussi trivial quÕil le para”t. Lors de sa mise en Ïuvre, nous avons relevŽ deux cas qui ont nŽcessitŽ un traitement particulier. Les cellules de bord requi•rent un traitement spŽcifique. En effet, dans une grille ouverte16, les cellules de bord doivent simuler la poursuite de la 16Dans un tore, ce type de probl•mes ne se prŽsente pas, puisque chaque cellule peut •tre considŽrŽe comme le centre du rŽseau par un simple changement de rep•re. 97 Chapitre 3 - Allocation dynamique recherche afin de ne pas perturber le dŽroulement normal de lÕalgorithme (figure3.3). Nous dŽsignons cette opŽration par une sortie virtuelle du rŽseau. Fig.3.3. Cas dŽlicat pour lÕalgorithme en colima•on. LÕautre cas concerne les rŽseaux de petite taille. Un message de requ•te dans ce genre de rŽseau risque de tourner indŽfiniment lorsque toutes les cellules de bord sont momentanŽment occupŽes. En effet, si un rŽseau est de taille rŽduite, il faut assurer que si un message de recherche rŽalise quatre fois de suite lÕopŽration de sortie virtuelle du rŽseau, il doit •tre supprimŽ. Autrement, ce message circulera sur la couronne externe des cellules sans dŽpasser lÕespace dÕadressage de la cellule source, donc sans risquer dÕ•tre extrait du rŽseau lorsque cela se produit. Nous dŽveloppons dans ce qui suit, une version compl•te de cet algorithme. 98 Chapitre 3 - Allocation dynamique /* INITIALISATIONS */ Length = 1 ; NextLength = 1 ; OutputDirection = WEST ; Remain_Dx = 0 ; Remain_Dy void SnailSearch () { /* ALGORITHME */ Length = Length - 1 ; if ( Length == 0 ) then { s w i t c h ( InputDirection ) {case NORTH : OutputDirection = WEST ; break case EAST : OutputDirection = NORTH ; break case SOUTH : OutputDirection = EAST ; break case WEST : OutputDirection = SOUTH ; break switch ( InputDirection ) {case NORTH : case SOUTH : NextLength = NextLength + 1 ; break default : break ; } s w i t c h ( OutputDirection ) {case EAST : case WEST : Length = NextLength - Remain_Dx break ; case NORTH : case SOUTH : Length = NextLength - Remain_Dy break ; } else { s w i t c h ( InputDirection ) {case NORTH : OutputDirection = SOUTH ; break case EAST : OutputDirection = WEST ; break case SOUTH : OutputDirection = NORTH ; break case WEST : OutputDirection = EAST ; break /* Border cells handling. */ Loop = TRUE ; while ( Loop ) { Loop = FALSE ; s w i t c h ( OutputDirection ) {case EAST : case WEST : if ( IsBorderCell (OutputDirection, Dx, Dy) ) then /* Detect the ring is already checked ? */ { Remain_Dx = Length Length = NextLength - Remain_Dy OutputDirection = ( OutputDirection == EAST) SOUTH : NORTH Loop = TRUE s w i t c h ( InputDirection ) {case NORTH : if ( NextLength >= ToBorder_Dy ) then StopSnail |= 0x01 ; /* 0001 break ; case EAST : if ( NextLength >= ToBorder_Dx ) then StopSnail |= 0x02 ; /* 0010 break ; case SOUTH : if ( NextLength >= ToBorder_Dy ) then StopSnail |= 0x4 ; /* 0100 break ; case WEST : if ( NextLength >= ToBorder_Dx ) then StopSnail |= 0x08 ; /* 1000 break ; } } break ; = 0 ; ; ; ; ; } ; ; ; } ; ; ; ; } ; ; ? ; ; */ */ */ */ 99 Chapitre 3 - Allocation dynamique case if NORTH : case ( IsBorderCell then { Remain_Dy = Length OutputDirection SOUTH : (OutputDirection, Dx, Dy) Length = NextLength - Remain_Dx = ( OutputDirection == EAST : Loop = TRUE s w i t c h ( InputDirection ) {case NORTH : if ( NextLength >= ToBorder_Dy then StopSnail |= 0x01 ; break ; case EAST : if ( NextLength >= ToBorder_Dx then StopSnail |= 0x02 ; break ; case SOUTH : if ( NextLength >= ToBorder_Dy then StopSnail |= 0x04 ; break ; case WEST : if ( NextLength >= ToBorder_Dx then StopSnail |= 0x08 ; break ; } break ; } } Algorithme du colima•on. 100 ) NORTH) WEST ; ; ? ; ; ) /* 0001 */ ) /* 0010 */ ) /* 0100 */ ) /* } } 1000 */ Chapitre 3 - Allocation dynamique 3.2.1.2. Algorithme de diffusion par ondes LÕalgorithme de diffusion par ondes est parmi les plus simples ˆ mettre en Ïuvre. Dans notre cas, cet algorithme ne nŽcessite aucun dŽcoupage du message avant son envoi. Les algorithmes qui recourent ˆ des dŽcoupages de messages pour exploiter au maximum tous les liens de communication sont souvent confrontŽs ˆ des probl•mes de dŽbit de ces liens [MICHALLON93]. A priori, dans notre cas, le rŽseau de communication ne prŽsente pas de probl•me de dŽbit [KARABERNOU93]. De plus, une telle stratŽgie requiert un mŽcanisme de reconstruction des messages. Dans lÕapproche par ondes (figure3.4), la demande de cellule est diffusŽe dans le rŽseau de communication suivant une onde autour de la cellule Žmettrice. Une cellule libre qui re•oit un message de requ•te rŽpond ˆ la cellule Žmettrice et interrompt par la m•me occasion la diffusion ˆ son niveau. ... Etape 1 Etape 2 Etape 3 Fig.3.4. Principe de lÕalgorithme de diffusion par ondes. LÕinconvŽnient majeur de cette mŽthode est le traitement des rŽponses multiples. Pour y remŽdier, nous avons introduit une horloge logique pour dater chaque demande. A la rŽception dÕune premi•re rŽponse, lÕhorloge est avancŽe dÕune unitŽ. De cette fa•on, toutes les rŽponses antŽrieures ˆ la date courante seront ignorŽes (plus exactement annulŽes comme nous le verrons par la suite). 101 Chapitre 3 - Allocation dynamique LÕalgorithme qui en rŽsulte est tr•s simple, comme nous pouvons le constater dans la fonction suivante: void WaveSearch ( void ) { /* ALGORITHME S w i t c h ( InputDirection ) {case NORTH : BroadcastTo case EAST : BroadcastTo case SOUTH : BroadcastTo case WEST : BroadcastTo } */ (SOUTH, (NORTH, (NORTH, (NORTH, NIL, WEST, NIL, EAST, NIL) SOUTH) NIL) SOUTH) ; ; ; ; break break break break ; ; ; ; } Algorithme de diffusion par ondes. 3.2.1.2.1. Calcul des bornes des messages de rŽponses Dans le but de limiter la prolifŽration des messages dans le rŽseau, et eu Žgard aux spŽcifications matŽrielles de R.C.A.I, la recherche par onde est bornŽe. Elle est limitŽe par la taille physique de lÕadresse. Dans R.C.A.I, cette taille est de 8 bits (cf.¤1.2.3). A chaque progression dans une direction, nous incrŽmentons ou dŽcrŽmentons le champ correspondant de lÕadresse de retour. LorsquÕune des deux directions provoque un dŽbordement, le message correspondant est retirŽ du rŽseau et dŽtruit17 . De cette mani•re, nous rŽduisons considŽrablement la multiplication des messages de rŽponse en retour. Nous allons aborder ˆ prŽsent lÕŽvaluation de ces bornes. Plusieurs messages sont introduits dans le rŽseau pour une m•me recherche. Ce nombre n peut •tre bornŽ par la relation: 1 £ n £ 2(2* k + 1) o• k est la distance maximale pouvant •tre parcourue dans un sens ou dans lÕautre de lÕaxe des abscisses (figure3.5). 17Le cas particulier des cellules aux extrŽmitŽs est traitŽ au paragraphe 4.3. Il sÕagit de la notion de relais. 102 Chapitre 3 - Allocation dynamique k k k k Fig.3.5. Limites de la diffusion. Dans le cas qui nous concerne, k prend au maximum la valeur de 14, ce qui correspond au plus ˆ 48 messages18 (cf.¤4.3). La valeur 14 correspond en fait ˆ un niveau de relais que nous dŽtaillerons au chapitre 4. Un tel nombre de messages est nŽgligeable dans R.C.A.I compte tenu des capacitŽs du routeur [RUBINI92]. De plus, ce cas extr•me signifie quÕautour de la cellule Žmettrice, toutes les cellules sont occupŽes, ˆ lÕexception des cellules de bord. Ce cas est assez rare dans la pratique... 3.2.1.2.2. Protocole de rŽservation des cellules A la rŽception dÕun message de recherche de cellule libre, la cellule interroge lÕunitŽ de gestion de la ÒrŽgulation de chargeÓ pour savoir si la cellule en question est libre, pr•te ˆ recevoir un processus. A ce moment, deux rŽactions sont possibles: ¥ celle qui consiste ˆ rŽpondre par lÕaffirmative ˆ une premi•re demande et ˆ refuser les suivantes; pour cela, la cellule se dŽclare comme Žtant rŽservŽe d•s la rŽception de cette demande (ce schŽma correspond dans une certaine mesure ˆ celui adoptŽ dans [HAILPERIN88] au ¤3.1.7.7), ¥ lÕautre attitude consiste ˆ rŽpondre par l'affirmative tant que cette cellule est effectivement libre. A partir du moment o• une autre cellule aura confirmŽ sa rŽservation, la cellule rŽpond alors par la nŽgative. Dans le premier cas, une cellule qui re•oit une rŽponse invalide ˆ sa demande (la date de cette confirmation est antŽrieure ˆ lÕhorloge locale) annule sa requ•te par un message de type ÒCANCELÒ. Ce message, une fois 18En rŽalitŽ, k a pour valeur 7 (taille physique de chacune des deux parties dÕune adresse dans R.C.A.I). Ce qui induit 30 messages au maximum. 103 Chapitre 3 - Allocation dynamique arrivŽ ˆ destination, lib•re la cellule cible qui devient alors disponible pour les requ•tes suivantes. LÕinconvŽnient de cette mŽthode est Žvidemment la rŽquisition, temporaire, de cellules sans •tre exploitŽes. Ceci pŽnalise donc les cellules qui ne trouvent pas de cellules libres ˆ leur demande. De ce fait, il est nŽcessaire de pouvoir rŽitŽrer la recherche apr•s plusieurs Žchecs successifs, laissant ainsi le temps aux cellules qui en ont rŽquisitionnŽes dÕautres de les libŽrer. La seconde approche nŽcessite par contre pour chaque recherche un protocole plus contraignant. Apr•s une diffusion de la requ•te, la cellule attend un message de type ÒFREEÓ (cellule libre, pr•te ˆ recevoir un processus). Elle envoie ensuite un message de type ÒCONFIRMÓ (pour certifier sa demande) ou ÒCANCELÓ (si elle a dŽjˆ re•u une rŽponse). Dans le cas dÕune confirmation, la cellule attend un message de type ÒLOADÓ qui confirme ˆ son tour que la cellule cible est rŽellement pr•te ˆ recevoir du code. Ce protocole en quatre phases entra”ne une multiplication du nombre de messages mis en Ïuvre pour chaque demande. CÕest la raison pour laquelle nous avons optŽ pour la premi•re solution. 3.2.1.3. Comparaison des deux mŽthodes de recherche de cellules libres L'avantage de la recherche en colima•on est qu'il n'existe qu'un seul message dans le rŽseau pour chaque appel. Cependant, cette technique proc•de dÕune mani•re sŽquentielle. De plus, elle ne prend pas en compte les dŽbits des liens de communication. La seconde solution prŽsente l'avantage de trouver non seulement la premi•re cellule libre la plus proche, mais Žgalement celle o• les dŽbits des canaux de communication sont les moins chargŽs. 104 Chapitre 3 - Allocation dynamique T max L T min l n Les temps dÕacheminement de messages peuvent •tre formulŽes comme suit: max tcom = [L + ( n -1)] m ù é êëb + n t c úû min tcom = [l + ( n -1)] éb + mt ù c êë n úû avec m la longueur du message ˆ transmettre, n la taille dÕun paquet, b le temps dÕamor•age de la communication et t c le temps ŽlŽmentaire de transfert. En simplifiant les Žcritures prŽcŽdentes, nous obtenons les Žquations suivantes: max tcom = s + telem* L min tcom = s + telem* l avec: m s = ( n - 1) æ b + t c ö è n ø telem = b + L m tc n = l + l© (car: L ñ l) 105 Chapitre 3 - Allocation dynamique LÕavantage de la solution par diffusion dÕune requ•te peut •tre expliquŽ par le fait quÕune cellule ŽloignŽe rŽpond dans un laps de temps plus long quÕune cellule proche, pour des dŽbits de communication similaires sur les liens respectifs reliant les deux cellules. De cette fa•on, nous pouvons Žcrire: L ñ Þ l max tcom ñ min tcom Par contre, une cellule qui se trouve sur des liens de communication saturŽs met plus de temps ˆ faire parvenir sa rŽponse ˆ la cellule Žmettrice. Dans le m•me temps, une cellule, bien quÕŽloignŽe, mais qui se trouve sur des liens de communication peu saturŽs, rŽpond plus rapidement. En considŽrant t s u p le temps supplŽmentaire induit par la charge des liens de communication, les Žquations qui dŽcoulent de cette constatation sÕŽcrivent comme suit: min = s + telem * l + tsup, tcom ( ) max tcom = s + telem * l + l© , max = s + telem* l + telem* l©, tcom max min t com = tcom - tsup+ telem * l© tsup ñ telem* l© Þ min max tcom ñ tcom En rŽsumŽ, le tableau ci-dessous reprend les diffŽrents ŽlŽments comparatifs des deux mŽthodes. 106 Chapitre 3 - Allocation dynamique ComplexitŽ Risque Nombre de Minimise RŽgulation messages la distance de la charge d'Interblodes communi- cage cations Recherche en colima•on Recherche par ondes 1 oui non oui Beaucoup de contr™le 1 £ n £ 30 oui oui non Simple ˆ intŽgrer Les constatations relevŽes dans ce tableau nous ont amenŽ ˆ Žcarter la recherche en colima•on, surtout pour les cas dÕinterblocage quÕelle peut occasionner. En effet, la stratŽgie mise en Ïuvre ne respecte plus les r•gles Žtablies au paragraphe1.2.3.2, qui garantissaient lÕabsence dÕinterblocage. On se convaincra facilement au vu de lÕexemple de la figure3.6 de la rŽalitŽ de ce risque. Requ•te 1 Changements de direction Requ•te 2 Requ•te 4 Requ•te 3 Fig.3.6. Cas simple dÕinterblocage lors de quatre recherches simultanŽes en colima•on. Du fait que lÕalgorithme du colima•on ne respecte plus un routage incrŽmental, routage toujours dans le m•me sens, en abscisse puis en ordonnŽ par exemple, des cas dÕinteblocage peuvent facilement survenir, comme nous lÕavons montrŽ au ¤1.2.3.2. 107 Chapitre 3 - Allocation dynamique 3.2.2. ImplŽmentation et intŽgration de la recherche par ondes De par sa nature m•me, cet algorithme impose une structure diffŽrente pour les routeurs NORD/SUD et EST/OUEST. En effet, dans le cas des routeurs NORD et SUD, il suffit de retransmettre le message re•u sur un lien dans la direction opposŽe. Dans le cas des routeurs EST et OUEST, il faut diffuser ce message dans les trois directions restantes. LÕopŽration de diffusion peut •tre rŽalisŽe soit de mani•re sŽquentielle, soit en parall•le. Dans la premi•re situation, la solution est assez Žvidente. En suivant un ordre prŽŽtabli, la diffusion de la requ•te est acheminŽe vers la prochaine direction d•s que le message sur la direction prŽcŽdente a ŽtŽ compl•tement transfŽrŽ. Avant dÕ•tre acheminŽ vers une quelconque direction, le message de recherche est stockŽ dans une structure de sauvegarde (rŽutilisŽe successivement pour les diffŽrents transferts, cf.figure3.7). Par contre, sÕagissant de lÕapproche parall•le, il faut prŽvoir trois structures indŽpendantes - une pour chaque direction. Cette approche prŽsente lÕavantage de ne pŽnaliser aucune des trois directions. Toutefois, un premier probl•me soulevŽ par cette mŽthode est celui du traitement de plusieurs requ•tes successives. Le fait quÕun des tampons soit saturŽ, entra”ne nŽcessairement la sauvegarde de toute la suite des requ•tes pour pouvoir •tre rŽexpŽdiŽes plus tard. A moins de pouvoir poser une borne sur la longueur de cette liste, et qui soit tout de m•me modŽrŽe, il est impossible de pouvoir intŽgrer efficacement une telle solution. De plus, le recours ˆ une structure triple entra”ne un cožt supplŽmentaire non nŽgligeable au niveau silicium. Par consŽquent, pour des considŽrations dÕoptimisation et de simplicitŽ en vue dÕune intŽgration peu cožteuse sur silicium, nous avons retenu la solution sŽquentielle. Nous allons donc discuter de cette solution dans ce qui suit. 108 Chapitre 3 - Allocation dynamique 3.2.2.1. Structure des tampons La structure des tampons de rŽception des requ•tes est reprŽsentŽe dans la figure3.7. Tampon d'EntrŽe Demande de Cellule Libre DONNƒE ƒTIQUETTE ADRESSE TYPE Structure pour les routeurs EST & OUEST uniquement Traitement suivant le type en entrŽe Diffusion dans les trois directions Tampon Local Fig.3.7. Structure des tampons. La localisation de cellules libres est amorcŽe par lÕinstruction FIND. Le processus dŽbute par la construction dÕun message de type ÒFINDÓ de la mani•re suivante: FIND ADRESSE_EN_MƒMOIRE Cette instruction gŽn•re un message dont la structure est dŽtaillŽe dans la figure3.8. FIND HORLOGE Adresse de Retour Calcul Adresse mŽmoire de rŽce InutilisŽ Fig.3.8. Structure dÕun message de recherche. LÕadresse de retour est initialisŽe ˆ la valeur (0,0). Le champ ADRESSE_EN_MƒMOIRE correspond ˆ lÕadresse mŽmoire de rŽception (o• sera rangŽe la rŽponse ˆ la requ•te courante). Le processeur se met ensuite en attente sur cette position mŽmoire (tant que le neuvi•me bit reste ˆ zŽro). 109 Chapitre 3 - Allocation dynamique M[ADRESSE_EN_MEMOIRE].valid ¬ 0 En for•ant le contenu de cette case mŽmoire ˆ la valeur ^ (nil), nous imposons une attente sur ce canal de communication (synchronisation): la tentative de lecture de la valeur ^ entra”ne la mise en attente dÕune donnŽe ˆ cette position mŽmoire du processus courant (voir mod•le dÕexŽcution). A la rŽception dÕune rŽponse, le processus qui a exŽcutŽ cette instruction poursuit normalement son traitement. 3.2.2.2. Structure du chemin de donnŽes Le chemin de donnŽes proposŽ par [KARABERNOU93] a ŽtŽ modifiŽ pour intŽgrer les unitŽs spŽcialisŽes pour la gestion de lÕallocation dynamique de ressources (figure3.9). UNITE DE REGULATION DE CHARGE BUS DE DONNEES 4 P C U A L A B N V I Z R A C INTERFACE DE ROUTAGE Tampons Sortie Bloc RAM 4 D T A T A A D Y T G R P A E UNITE DE ROUTAGE DE LA CELLULE Tampons EntrŽe T D A A G T A +1 4 4 BUS D'ADRESSES UNITE DE GESTION DE L'HORLOGE LOGIQUE Fig.3.9. Diagramme du chemin de donnŽes. De la m•me mani•re, nous avons Žgalement modifiŽ les blocs dÕentrŽe et de sortie pour les adapter aux nouvelles exigences de la gestion dynamique du rŽseau (figures3.10 & 3.11). LÕunitŽ de routage de la cellule dispose de quatre tampons dÕE/S indŽpendants et parall•les [LATROUS94b] pour augmenter le degrŽ de parallŽlisme de la recherche de cellules libres (cf.¤3.2.2.3). 110 Chapitre 3 - Allocation dynamique INTERFACE TO THE CELL LOAD BALANCING & LOGICAL CLOCK UNITS I N P U T Message Packet Fill IsEmpty IsLocked B U F F E R Flag Lock LB O U C F A F L E R TYPE DECIPHER L o c k Transparency e d U E L o n m L p c o t k c y k I s F u l l To the ce router M U X Update Address C O N T R O L S Compute 5 Direction Aknowledgements 5 To other direction Requests t other directions Internal Broadcast Buffers CONTROL AUTOMATA Requests from other directions Fig.3.10. Synoptique du block dÕentrŽe (le rŽcepteur). Packets 1 incomin 2 3 from al 4 5 direction 1 2 3 4 5 Memoriz & Select Request Detectio N S e a x v t e 8 OB UU TF PF UE TR M U X Rotatin Priority I s R o F E t i m a l p t l t y e Flag I s L o c k e d Lock To the next cell IsFul Clear IsLocke Lock CONTROL AUTOMATA Fig.3.11. Synoptique du block de sortie (lÕarbitre). 111 Chapitre 3 - Allocation dynamique Il faut noter que les quatre routeurs dÕentrŽe de la cellule sont indŽpendants. Par consŽquent, pour assurer lÕexclusion mutuelle lors de la rŽception simultanŽe de plusieurs demandes, le routeur se rŽf•re ˆ une seule unitŽ de la rŽgulation de charge. Toutes les interrogations sur lÕŽtat de la cellule sont adressŽes ˆ cette unitŽ. CÕest la seule entitŽ habilitŽe ˆ rŽpondre ˆ ces questions (figure3.12). Demande de cellule Reset Nord Est Sud Ouest Politique de RŽgulation de charge Cyclique PrioritŽ tournante Nord Est Sud Ouest 1 RŽponse ˆ la Direction en cours de service 0 0 0 Next Fig.3.12. Vue fonctionnelle de lÕunitŽ de rŽgulation de charge. LÕinstruction de recherche de cellules libres Žmet simultanŽment dans les quatre directions un message de requ•te et se met en attente dÕune rŽponse. Chacune des quatre directions est indŽpendante des autres Buffer NOR Processeu Buffer EST Buffer OUEST (figure3.13). Buffer SU Fig.3.13. Tampons de sortie parall•les. Ainsi, si lÕune de ces directions est bloquŽe en attente de la libŽration du tampon de sortie correspondant, en raison dÕune ancienne communication 112 Chapitre 3 - Allocation dynamique non encore acheminŽe, les autres directions diffusent tout de m•me la demande de la cellule dans le rŽseau. Envois EffectuŽs Nord {Servi, Attente} Est {Servi, Attente} Sud {Servi, Attente} Ouest {Servi, Attente} Flags Tampons Sortie Nord {Plein, Vide} Est {Plein, Vide} Sud Ouest Traitement Cyclique Vers Prochaine sortie Libre {Plein, Vide} {Plein, Vide} Fig.3.14. Envoi parall•le (cyclique) de FIND. De plus, cette approche permet de maximiser le parallŽlisme de lÕopŽration de recherche. Pour cela, lÕinstruction FIND proc•de dÕune mani•re cyclique. Elle cherche perpŽtuellement la prochaine sortie libre, toujours dans le m•me sens (figure3.14). Toutefois, avant et apr•s chaque envoi (Žgalement une fois tous les envois effectuŽs), le routeur de la cellule proc•de au test dÕarrivŽe dÕune rŽponse (positive) ˆ lÕun des messages dŽjˆ acheminŽs (figure3.15). if (M[ADRESSE_EN_MƒMOIRE].valid) then ¥ Arr•ter la recherche ¥ Branchement ˆ l'instruction suivant fi Fig.3.15. Attente dÕarrivŽe dÕune rŽponse pour lÕinstruction FIND. Si une rŽponse a dŽjˆ ŽtŽ re•ue, les envois restants sont abandonnŽs afin de ne pas saturer le rŽseau de communication. En effet, tout message ÒpŽrimŽÓ qui arrive ˆ une cellule doit •tre annulŽ par un autre message de type ÒCANCELÓ, dÕo• une multiplication de messages superflus. 113 Chapitre 3 - Allocation dynamique 3.2.3. Une nouvelle proposition dÕalgorithme pour la rŽgulation de charge dans la machine R.C.A.I: lÕalgorithme CLIMB La rŽgulation de charge par le biais de techniques qui nŽcessitent une connaissance globale sÕav•re incompatible avec les contraintes imposŽes par les syst•mes massivement parall•les [HAILPERIN88]. En effet, le temps requis pour collecter une information globale est trop important pour •tre rŽaliste (vu le nombre ŽlevŽ des processeurs). C'est le cas notamment de l'algorithme du gradient [LIN87] (cf.¤3.1.7.4) qui doit diffuser une nouvelle pression ˆ l'ensemble du rŽseau. Il faut donc privilŽgier les mŽthodes qui reposent sur une connaissance partielle (tr•s restreinte) pour rŽaliser une rŽgulation de charge dans les syst•mes massivement parall•les. [HAILPERIN88] propose l'utilisation d'un mod•le stochastique basŽ sur les sŽries temporelles. Bien que les rŽsultats rapportŽs semblent satisfaisants, l'heuristique dŽveloppŽe sÕapplique, comme le souligne l'auteur, ˆ des syst•mes qui prŽsentent des charges pŽriodiques (rŽpŽtitives), tels que les syst•mes temps rŽels. Il nous a donc semblŽ possible dÕamŽliorer lÕalgorithme du gradient. Nous proposons ˆ notre tour un nouvel algorithme qui repose uniquement sur la connaissance de la charge des voisins immŽdiats et qui ne suppose ˆ priori aucun type d'applications spŽcifiques. Le point critique dans l'algorithme de Lin est la mise ˆ jour de lÕinformation dans le rŽseau. Cette mise ˆ jour nŽcessite dans le pire cas une diffusion de cette donnŽe ˆ lÕensemble des cellules. Dans le cas de la machine R.C.A.I, le nombre de messages nŽcessaires ˆ une telle opŽration est de 2n pour un rŽseau de n x n cellules. Nous avons alors imaginŽ un autre algorithme, CLIMB, qui nŽcessite au plus 4 messages pour cette m•me opŽration. Un autre crit•re important, pour la comparaison de ces deux algorithmes, est la qualitŽ de lÕinformation disponible ˆ un moment donnŽ pour prendre une dŽcision. Dans le cas de lÕalgorithme du gradient, une information disponible ˆ un instant donnŽ au niveau dÕun processeur peut •tre erronŽe. En effet, entre le moment o• cette information aura ŽtŽ communiquŽe au processeur en question et celui o• ce dernier dŽcide de lui 114 Chapitre 3 - Allocation dynamique envoyer un processus, dÕautres processeurs ont dŽjˆ pu faire appel ˆ ce m•me processeur pour se dŽcharger de leur surplus de travail. De cette mani•re, et dans le cas dynamique, il peut survenir le cas o• un processeur ait ˆ rŽitŽrer plusieurs fois sa requ•te avant de la voir satisfaite. Par contre, dans le cas de notre algorithme, les dŽcisions sont prises successivement par les diffŽrents processeurs qui voient passer cette requ•te eu Žgard ˆ la connaissance, toujours fiable, de leur propre charge et de celles de leurs voisins immŽdiats19. Pour terminer, signalons que l'algorithme du gradient ne prend pas en considŽration les communications. Or, dans les syst•mes (massivement) parall•les, ce facteur tient une importance prŽpondŽrante dans les performances globales d'une machine de ce type. L'algorithme CLIMB est en mesure d'inclure ce facteur dans son principe (cf. paragraphe 3.2.3.2). DÕautre part, notre algorithme reprend Žgalement une philosophie inhŽrente au recuit simulŽ: la possibilitŽ de sÕŽchapper de minima locaux pour approcher un minimum global du syst•me considŽrŽ. Dans cette optique, notre algorithme permet ˆ un objet, suivant lÕŽnergie cinŽtique acquise durant son mouvement, de remonter des c™tes, pour sÕŽchapper de minima locaux. Bri•vement, notre algorithme repose sur la notion de quantitŽ de mouvement. En se dŽpla•ant, un objet acquiert de lÕŽnergie cinŽtique qui lui permet de se mouvoir entre les ÒsommetsÓ du plan dŽfinis par les charges des processeurs (figure3.16). Cette analogie: la minimisation de la fonction de cožt avec la fonction dÕŽnergie potentielle sur une surface dans lÕespace soumis ˆ un champ de gravitation, est parlante et frŽquemment employŽe. Nous allons donc la reprendre. 19 Au niveau silicium, on peut imaginer que lÕŽchange dÕinformation entre deux cellules voisines puisse sÕeffectuer directement par une ligne Žlectrique qui indique un processus en plus ou en moins au niveau de la cellule en question. 115 Chapitre 3 - Allocation dynamique Fig.3.16. Plan dŽfini par les charges des processeurs. 3.2.3.1. Principe de lÕalgorithme proposŽ Le principe gŽnŽral de lÕalgorithme proposŽ repose sur deux mouvements essentiellement: un objet peut descendre ou remonter une c™te suivant les inclinaisons du plan dŽfini par les charges respectives des diffŽrents processeurs du rŽseau. Il sÕagit de calculer, dans tous les cas de figure, la valeur de lÕŽnergie cinŽtique acquise durant ce mouvement sur une certaine distance20. Lors de lÕapplication de cet algorithme aux syst•mes parall•les, nous simplifions largement les formules, ce qui nous permettra dÕapprŽhender plus facilement le cas de frottements proportionnels. 20On ne considŽrera, pour lÕŽcriture des Žquations, que le cas de frottements constants. En effet, le cas de frottements proportionnels ˆ la masse dÕun objet en dŽplacement nŽcessite des Žcritures dÕŽquations tr•s difficiles ˆ dŽchiffrer. 116 Chapitre 3 - Allocation dynamique 3.2.3.1.1. Un objet en descente Dans ce premier cas, les frottements vont contribuer ˆ ralentir lÕallure de lÕobjet, avec une accŽlŽration dans le sens du mouvement (positive). ® F c x ® mg ® mg a d Fig.3.17. Un objet progressant le long dÕune pente. La valeur de lÕŽnergie cinŽtique est calculŽe de la sorte: Ec = m. g .x + E c0 g = g.sina - avec F m sachant que F est la force de frottement supposŽe constante, g lÕaccŽlŽration de lÕobjet de masse m, et g lÕattraction dans le syst•me considŽrŽ. E c0 reprŽsente lÕŽnergie cinŽtique initiale. Il en dŽcoule lÕexpression suivante: Ec = (m.g.sina - F)x + E c0 117 Chapitre 3 - Allocation dynamique 3.2.3.1.2. Un objet en montŽe Les frottements et lÕaccŽlŽration sont cette fois-ci dans le m•me sens, contraire ˆ celui de la trajectoire de lÕobjet. LÕobjet se meut gr‰ce ˆ lÕŽnergie (initiale) acquise au prŽalable. A cause de lÕaction conjuguŽe des frottements et de lÕaccŽlŽration, lÕobjet ralentit son allure jusquÕˆ une (Žventuelle) immobilisation. x ® F ®g m ® c mg b d Fig.3.18. Un objet progressant le long dÕune c™te. La valeur de lÕŽnergie cinŽtique est calculŽe de la sorte: E© = -m. g ©.x + E© c c0 avec g© = g.sinb + F m Ce qui donne lÕŽquation ci-apr•s: ( ) E© = - m.g.sinb + F x + E© c c0 Pour simplifier lÕŽcriture de ces expressions, considŽrons les deux Žquations suivantes: sinq = et 118 c æ qÎ x è {a,b}öø Chapitre 3 - Allocation dynamique d2 + c2 x = les Žquations sÕŽcrivent donc de la mani•re suivante: Ec æ d2 ö = cç m.g - F 1+ 2 ÷ + E c0 c ø è E© c æ d2 ö = -cç m.g + F 1+ 2 ÷ + E© c0 c ø è 3.2.3.1.3. Etude des frottements Concernant les bornes de la force de frottement, elles sont dŽfinies de la fa•on suivante: tga c d = , c = 0,1,2...max dÕo• a Î éê0, p êé ë 2ë En considŽrant la relation suivante: m.g.sina > F ³ 0 nous obtenons: si(a = 0) si(a ¹ 0) = F0 ,obligatoirem ù 1é F Î ú 0, 2 êë û Le cas o• (F = 0) et (a = 0) est exclu, car il peut induire une oscillation ˆ lÕinfini (figure3.19). Pour une m•me hauteur (h) des deux c™tŽs (avec des pentes diffŽrentes ou Žgales), et en lÕabsence de frottement pour ralentir lÕŽvolution de lÕobjet, celui-ci va rŽaliser des va-et-vient incessants sur chacune des pentes (entre les deux points dŽfinissant la hauteur h sur chacune des deux pentes). 119 Chapitre 3 - Allocation dynamique h a b Fig.3.19. Oscillation infinie dÕun objet en lÕabsence de frottement. Dans le cas o• les processus sont de diffŽrentes masses, celle-ci doit respecter la relation suivante: c* m* g - F c 2 + d 2 > 0 avec E c0 = E© c0 = 0 dÕo•: m > 120 F g 2 1 + d2 c r Chapitre 3 - Allocation dynamique 3.2.3.2. Application ˆ la rŽgulation de charge Les syst•mes parall•les peuvent •tre considŽrŽs comme un graphe G=(P, L), o• P est lÕensemble des nÏuds (processeurs) et L lÕensemble des ar•tes (liens de communication) reliant les diffŽrents nÏuds. P0 P3 P6 P1 P2 P5 P4 P7 Chacun des processeurs peut gŽnŽrer de nouveaux processus, accepter des processus dÕautres processeurs et dŽtruire des processus locaux. Le nombre de ceux-ci dŽtermine au niveau de chacun des processeurs la charge de ce dernier. La diffŽrence de charge entre deux processeurs voisins (liŽs physiquement) sera notŽe c dans les diffŽrentes Žquations. Tous les processeurs directement connectŽs seront sŽparŽs par une distance considŽrŽe uniforme et notŽe d. Cependant dans le cas de rŽseaux distribuŽs cette distance peut intervenir pour diffŽrencier les processeurs susceptibles dÕentrer en compŽtition lors de la recherche dÕun processeur capable dÕaccepter une nouvelle t‰che. Chaque processus sera affectŽ dÕune masse m. La gravitation g dans ce syst•me peut varier dÕun processeur ˆ un autre, suivant des crit•res ˆ dŽfinir: le type du processeur et/ou du processus, la nature du processeur recherchŽ (comme par exemple un processeur graphique pour le traitement dÕune image)... Au terme de lÕŽvolution de lÕobjet, celui-ci sÕimmobilise dans un minimum de la fonction dÕŽnergie. Il ne nous est pas possible de dŽmontrer, de fa•on thŽorique, que ce minimum local correspond gŽnŽralement ˆ une solution de bonne qualitŽ. Cependant, nous nous efforcerons de le mettre en Žvidence par des simulations (cf. paragraphe 3.2.3.4). Il est possible dÕincorporer la charge de communication dÕun lien dans les diffŽrentes Žquations. Pour cela, suivant la charge constatŽe sur un lien donnŽ, il faut multiplier par un facteur k (proportionnel ˆ la charge des 121 Chapitre 3 - Allocation dynamique communications sur ce lien) la diffŽrence de charge c entre les deux processeurs liŽs par ce canal. 3.2.3.3. Cas de la machine R.C.A.I Dans le cas de notre machine, o• les processeurs sont homog•nes (non diffŽrenciŽs), la gravitation est la m•me pour tous. La distance entre les processeurs voisins est considŽrŽe comme identique. De ce fait, on peut Žcrire: d = g = 1 Les Žquations dŽcrites plus haut sÕŽcrivent maintenant: E c = mc - F 1+ c2 + E c0 (1) 2 © E© c = - mc - F 1+ c + E c0 (2) m ñ F F á 1 + 1 (3) c2 m 1+ (4) 1 c2 De plus, si lÕon consid•re que les frottements sont proportionnels ˆ la masse: F = k* m avec k Î[0,1] (k est un rŽel) les Žquations (1) et (2) se rŽŽcrivent dŽfinitivement comme suit: Ec = m Ec = - m (c (c - k* 1 + + k* 1 + c2) c2) Ec + (1) 0 + Ec 0 (2) Nous donnons dans la suite lÕalgorithme synthŽtique de CLIMB avant de prŽsenter les rŽsultats de son Žvaluation. 122 Chapitre 3 - Allocation dynamique LÕalgorithme /* short { int float short switch {case case case case case } CLIMB CLIMB ( NetWork potentialDiff, energy, status ( input NORTH : EAST : SOUTH : WEST : CELL : /* Calculer potentialDiff ddp energy toCell status pour la = = = = = la *cell rŽgulation , int toCell, ddp, initialEnergy ) initialEnergy initialEnergy initialEnergy initialEnergy initialEnergy = = = = = cell cell cell cell 0 input i -> -> -> -> de la charge. */ ) ; ; ; NorthIn.energy EastIn.energy SouthIn.energy WestIn.energy ; ; ; ; ; break break break break break DDP entre les cellules adjacentes. 0 ; 0 ; 0 ; UNDEF ; _NOP ; ; ; ; ; ; */ for ( i = 0; i < 4; i++ ) { /* Le sens du mouvement est incorporé directement dans */ /* l’expression qui suit. */ potentialDiff = cell -> cellLoad - cell -> NeighboorLoad [i] ; if ( toCell == UNDEF ) then { toCell = i ddp = potentialDiff } else { if ( potentialDiff > ddp ) then { toCell = i ddp = potentialDiff } } ; ; ; ; } if ( toCell != UNDEF ) then { if ( toCell == CELL ) then /* Minimum local, cellules voisines saturées. */ status = _STORE ; else /* Calculer l’énergie à acquérir. */ { energy = (ddp * __Masse__ * __Gravitation__) - ((SQRT (1 + POW (ddp, 2))) * __Frottements__) + initialEnergy ; if ( energy then status else status >= = = 0 ) _CLIMBE _STORE ; ; } } return (status) } /* End CLIMB. ; */ 123 Chapitre 3 - Allocation dynamique 3.2.3.4. Quelques rŽsultats Nous prŽsentons dans ce paragraphe les rŽsultats prŽliminaires de lÕalgorithme CLIMB. ConsidŽrons une grille 2D de 10x10 cellules et un certain nombre de processus ˆ crŽer par chaque processeur. Dans la table3.1 nous donnons la configuration sur laquelle nous avons rŽalisŽ nos Žvaluations, cÕest ˆ dire le nombre de processus ˆ crŽer au niveau de chacun des processeurs. Le nombre de ces processus a ŽtŽ gŽnŽrŽ alŽatoirement entre les bornes 0 et 200. La durŽe dÕexŽcution de tous les processus est identique. Le comportement du rŽseau faisant appel ˆ lÕalgorithme CLIMB a ŽtŽ simulŽ de fa•on tr•s simple, et a fourni les rŽsultats de la table3.2: le nombre de processus exŽcutŽ par chaque processeur. 1,7585 Ecart Type Moyen 1,758 1,7575 1,757 1,7565 1,756 1,7555 1,755 1,7545 0 20 40 60 80 100 120 Force Frottement Fig.3.20. Ecart type moyen des solutions en fonction de la masse des objets et de la force de frottements21. 21 Pour chaque valeur de la force de frottement, on rŽalise une moyenne des solutions obtenues en faisant varier la masse. 124 Chapitre 3 - Allocation dynamique 38 158 113 115 51 27 10* 19* 12* 86 149 167 84 60 25 143 89 183* 137 166 166 178 95 111 167 54 31 145 82 136 124 105 194* 102 51 67 154 53 161 96 28 188* 85 143 167 6* 165 3* 162 34 153 120 44 3 162 118 22 127 57 145 79 151 94 70 59 48 157 29 106 6* 183* 190* 138 116 14 62 116 25 181* 134 143 22 33 136 160 179 71 1* 136 61 160 5* 129 44 75 93 114 139 88 121 Table3.1. Nombre de processus ˆ crŽer par processeur. 100 101 101 100 99 98 99 99 99 98 100 101 102 101 100 99 99 100 99 99 101 102 102 101 100 99 99 99 98 98 101 102 103 102 101 100 99 98 98 97 102 102 102 101 100 99 98 97 98 97 101 102 101 100 99 98 97 96 97 96 100 101 101 100 99 98 97 97 98 97 100 101 100 100 99 98 97 97 98 97 99 100 99 99 98 98 97 97 97 96 98 99 98 98 97 97 97 96 96 96 Table3.2. Charge des processeurs apr•s application de lÕalgorithme CLIMB (nombre de processus exŽcutŽs par chacun des processeurs). * Les valeurs en gras correspondent aux 20% des plus faibles et des plus fortes charges du rŽseau. 125 Chapitre 3 - Allocation dynamique Nous donnons dans les figures qui suivent la reprŽsentation graphique des tables3.1 et 3.2 respectivement. La premi•re correspond ˆ une allocation sans application dÕune rŽgulation de charge sur les processeurs. Dans la seconde, nous pouvons constater le rŽsultat obtenu en utilisant lÕalgorithme CLIMB. 200 150 100 50 S9 1 2 3 4 5 6 7 8 9 10 0 S5 S1 ReprŽsentation graphique de la table3.1. 104 102 100 98 96 94 S9 1 2 3 4 5 6 7 8 9 10 92 S5 S1 ReprŽsentation graphique de la table3.2. 126 Chapitre 3 - Allocation dynamique Le nombre total de processus ˆ gŽnŽrer est de 9904 unitŽs, situant ainsi la moyenne ˆ 99,04 processus par processeur. Pour dŽgager la qualitŽ des solutions obtenues apr•s application de notre algorithme, nous calculons lÕŽcart type de celles-ci par rapport ˆ la moyenne du rŽseau. La valeur moyenne de cet Žcart type est de 1,7567. Cette valeur constitue lÕŽcart moyen, constatŽ sur chacun des processeurs, par rapport ˆ la moyenne globale du rŽseau. Dans le cas prŽsent, ceci reprŽsente une diffŽrence de 2 processus en moyenne sur les processeurs du rŽseau. Ce rŽsultat est tr•s stable pour diffŽrentes valeurs de lÕensemble des param•tres (figure3.20). Une premi•re conclusion sÕimpose au vu des tables3.1 et 3.2. Les rŽsultats de la table3.2 sont tr•s satisfaisants, faisant appara”tre de tr•s faibles disparitŽs. Toutefois, nous allons analyser plus finement lÕeffet de chaque param•tre. Dans un premier temps, nous montrons quÕil nÕest pas nŽcessaire, pour obtenir une m•me qualitŽ de solution (voire meilleure), de laisser un objet osciller entre les cellules au delˆ dÕune certaine valeur (figure3.21). Nous considŽrons donc le rŽseau de la table3.1 dans lequel nous faisons varier uniquement la masse de lÕobjet. 127 Chapitre 3 - Allocation dynamique Moyenne Cellules Maximum Cellules 8 10 4 300 7 10 4 6 10 4 200 5 10 4 150 4 10 4 3 10 4 100 2 10 4 50 Maximum Cellules Moyenne Cellules 250 1 10 4 0 0 20 40 60 80 Masse 100 120 0 140 Fig.3.21. Transitions entre cellules en absence de toute limitation des oscillations. En imposant une borne aux transitions possibles entre les cellules pour un objet, nous rŽduisons dÕune mani•re significative le nombre dÕoscillations entre les cellules du rŽseau (nous passons de 8x104 ˆ 10 transitions au plus) sans pour autant nuire ˆ la qualitŽ finale du rŽsultat obtenu. Limit_10 Limit_50 Limit_100 No_Limit 1,761 1,76 Ecart Type 1,759 1,758 1,757 1,756 1,755 1,754 0 20 40 60 80 Masse 100 120 140 Fig.3.22. Comparaison de diffŽrentes bornes pour les transitions dÕun objet dans le rŽseau22. Cela est dž principalement au fait que les objets sÕŽloignent en moyenne de 0,0519 unitŽs de leur source. La distance maximale de la source constatŽe 22 Les courbes associŽes aux valeurs 10, 50 et 100 du nombre dÕoscillations maximales sont pratiquement confondues sur ce graphique. 128 Chapitre 3 - Allocation dynamique dans cet exemple est de 13 unitŽs. Les rŽsultats correspondants ˆ la qualitŽ des solutions suivant le nombre de transitions fixŽes sont reportŽs dans la figure3.22. Dans la suite nous considŽrons que les objets sont limitŽs ˆ 100 transitions au maximum. Il est important dÕexpliciter quelques notions pour la comprŽhension ultŽrieure des figures. La distance moyenne notŽe dans celles qui suivent ont une relation directe avec le nombre de processus transfŽrŽs sur dÕautres processeurs (que le processeur source), mais ne constitue pas en soi un indicateur direct sur leur nombre. En effet, une valeur du genre 0,06 unitŽs signifie que les processus sÕŽloignent en moyenne de cette valeur de leur source. Cependant, cela ne signifie nullement quÕil y a 6% des processus qui sÕŽloignent de leur source (comme on pourrait le penser ˆ priori). Pour sÕen convaincre, nous allons vŽrifier cette relation en considŽrant successivement une m•me configuration avec des charges initiales des processeurs diffŽrentes (figure3.23). Les valeurs de lÕaxe des abscisses dŽsignent, pour chacune dÕelles, la charge des processeurs avant lÕapplication de lÕalgorithme CLIMB. Cette charge est gŽnŽrŽe alŽatoirement entre les bornes 0 et la valeur considŽrŽe. Processus hors source Distance Moyenne 162,10 Nombre de processus stockŽs sur d'autres processeurs que la source (%) Charge moyenne 30 0,6 110,99 25 0,5 78,77 20 54,32 15 10 5 0 -50 0,7 0,4 0,3 14,1 25,99 0,2 0,1 0 0 0 5 0 100 150 200 250 300 350 Charges initiales des processeurs Distance moyenne d'Žloignement de la source 35 Fig.3.23. Relation entre la distance dÕŽloignement et le nombre de processus ayant effectivement quittŽ leur processeur source. 129 Chapitre 3 - Allocation dynamique Distance maximale 20 15 10 5 0 -50 0 50 100 150 200 250 300 350 Charges initiales des processeurs Fig.3.24. Distance maximale dÕŽloignement de la source en fonction des charges initiales des processeurs. La moyenne des charges des processeurs ˆ cet instant est reportŽe ˆ c™tŽ du point relatif sur la courbe. LÕapplication de notre algorithme intervient alors23 et fournit sur la seconde courbe le nombre de processus qui ont effectivement quittŽ leur source vers dÕautres processeurs. La distance maximale dÕŽloignement des processus de leur source est schŽmatisŽ dans la figure3.24. Dans le reste des Žvaluations effectuŽes dans ce chapitre, le nombre de processus qui quittent leur processeur source reste faible en raison de lÕefficacitŽ de lÕalgorithme CLIMB d•s les premi•res applications. En effet, CLIMB tend ˆ uniformiser ˆ chaque Žtape la charge des diffŽrents processeurs, en se rapprochant tout le temps de la moyenne de la charge du rŽseau24 . De ce fait, les processus au niveau dÕun m•me processeur, qui se trouvent dans un voisinage de m•me charge (ou de plus forte charge), restent au sein du processeur source. CÕest ce qui explique la faible valeur de la moyenne des distances relevŽes dans les diffŽrentes simulations qui suivent. La figure3.23 montre quÕen partant de charges initiales diffŽrentes sur les processeurs du rŽseau, cette distance sÕaccro”t chaque fois que cette diffŽrence prend de lÕampleur. 23Nous utilisons la m•me configuration de la table 3.1 avec des processeurs dŽjˆ chargŽs. 24 [SALETORE_90] et [KALE_88] sugg•rent dÕailleurs de procŽder ˆ la rŽgulation de la charge ˆ chaque nouvelle crŽation de processus sans attendre de dŽpasser un seuil pour activer cette opŽration (comme dans le cas du gradient par exemple). 130 Chapitre 3 - Allocation dynamique Nous allons tenter ˆ prŽsent de mettre en avant lÕinfluence des diffŽrents param•tres sur la qualitŽ des solutions obtenues apr•s la mise en Ïuvre de notre algorithme: la masse de lÕobjet, la gravitation exercŽe sur celui-ci ainsi que la force de frottement qui lui est appliquŽe. F_1 F_5 F_10 F_20 F_40 F_50 F_80 F_100 1,761 1,76 Ecart Type 1,759 1,758 1,757 1,756 1,755 1,754 0 20 40 60 80 Masse 100 120 140 Fig.3.25. QualitŽ des solutions en fonction de la masse des objets et de la force de frottement. La figure3.25 montre lÕŽcart type pour diffŽrentes valeurs de la masse et de la force de frottement au niveau du rŽseau dŽcrit prŽcŽdemment (table3.1). Nous pouvons noter que lÕensemble des courbes convergent vers une m•me solution. Cela signifie que pour arriver ˆ de meilleures solutions, la force de frottement doit rester suffisamment faible (par rapport ˆ la masse de lÕobjet) pour ne pas altŽrer la qualitŽ des rŽsultats de lÕalgorithme CLIMB. Par ailleurs, la figure3.26 montre que parall•lement, il nÕest pas nŽcessaire de trop sÕŽloigner de la source pour obtenir les meilleurs solutions. En effet, ce contraste peut sÕexpliquer par le fait quÕun objet qui sÕŽloigne de la source perd rapidement de lÕŽnergie (surtout lorsquÕil est lŽger) et ne peut donc plus sÕŽchapper de minima locaux dans lesquels il risque de tomber. 131 Chapitre 3 - Allocation dynamique F_1 F_10 F_20 F_40 F_60 F_80 F_100 F_120 F_140 0,1 Distance 0,09 0,08 0,07 0,06 0,05 0,04 0 20 40 60 80 Masse 100 120 140 Fig.3.26. ƒloignement des objets de leur source en fonction de leur masse et de la force de frottement. Le nombre moyen de cellules visitŽes est reportŽ au niveau de la figure3.27. Nous constatons que pour atteindre une certaine efficacitŽ de la solution, il faut permettre aux objets de transiter par plusieurs cellules. Le nombre de ces cellules reste toutefois limitŽ (2,5 cellules en moyenne dans le cas considŽrŽ). Nous pouvons noter que plus la force de frottement est ŽlevŽe, moins un processus peut sÕŽloigner du processeur source (figure3.27). Cet Žtat peut •tre contrebalancŽ par une charge plus forte, comme nous le constatons sur cette m•me figure. 132 Chapitre 3 - Allocation dynamique F_1 F_5 F_10 F_20 F_40 F_60 F_80 F_100 F_120 F_140 3 2,5 Cellules 2 1,5 1 0,5 0 -0,5 0 20 40 60 80 Masse 100 120 140 Fig.3.27. Nombre de cellules visitŽes en fonction de leur masse et de la force de frottement. Les rŽsultats obtenus, en faisant varier la gravitation, semblent corroborer les rŽsultats prŽcŽdents. En effet, pour emp•cher un objet de trop sÕŽloigner de la source, et ainsi converger vers la moyenne du rŽseau, il faut que la gravitation soit suffisamment importante - par rapport ˆ la masse (figures3.28, 3.29 et 3.30). G_1 G_5 G_10 G_15 G_20 1,761 Force de frottements 20 unitŽs 1,76 Ecart Type 1,759 1,758 1,757 1,756 1,755 1,754 0 20 40 60 80 Masse 100 120 140 Fig.3.28. QualitŽ des solutions en fonction de la masse des objets et de la gravitation. 133 Chapitre 3 - Allocation dynamique G_1 G_5 G_10 G_20 0,07 Force de frottements 20 unitŽs Distance 0,065 0,06 0,055 0,05 0,045 0 20 40 60 80 Masse 100 120 140 Fig.3.29. ƒloignement des objets de leur source en fonction de leur masse et de la gravitation. G_1 G_5 G_10 G_15 G_20 3 Cellules 2,5 2 1,5 Force de frottements 20 unitŽs 1 0,5 0 20 40 60 80 Masse 100 120 140 Fig.3.30. Nombre de cellules visitŽes en fonction de leur masse et de la gravitation. A titre dÕillustration, nous donnons lÕŽcart type correspondant ˆ des mesures de frottements proportionnels ˆ la masse dÕun objet. 134 Chapitre 3 - Allocation dynamique 1,761 F_10%_G_1 F_10%_G_5 F_10%_G_10 F_20%_G_1 F_20%_G_5 F_20%_G_10 F_50%_G_1 F_50%_G_5 F_50%_G_10 1,76 Ecart Type 1,759 1,758 1,757 1,756 1,755 1,754 0 20 40 60 80 Masse 100 120 140 Fig.3.31. QualitŽ des solutions en fonction de frottements proportionnels ˆ la masse des objets et de la gravitation. La figure3.31 exprime le fait que nous pouvons compenser des frottements trop importants par rapport ˆ la masse dÕun objet par une force de gravitation plus faible. CÕest le cas des forces de frottement ˆ 50% et ˆ 20% de la masse de lÕobjet considŽrŽ. 135 Chapitre 3 - Allocation dynamique 3.2.3.5. Conclusion Pour clore ces rŽsultats prŽliminaires, nous montrons que cet algorithme est efficace pour diffŽrentes tailles de rŽseaux (figures3.33 et3.34). Pour cela, nous considŽrons des rŽseaux de 20x20 et 40x40 cellules. Chaque processeur peut gŽnŽrer, alŽatoirement, un nombre de processus compris entre 0 et 100. RŽseau_20x20 RŽseau_40x40 1,842 1,84 Ecart Type 1,838 1,836 1,834 1,832 1,83 1,828 1,826 0 20 40 60 80 Masse 100 120 140 Fig.3.32. QualitŽ des solutions pour de grandes tailles de rŽseaux. Nous pouvons noter que lÕŽcart type se situe entre les valeurs 1 et 2 (figure3.32); ceci signifie quÕen moyenne, il y a une diffŽrence dÕau plus deux processus sur les diffŽrents processeurs, par rapport ˆ la moyenne du rŽseau. En conclusion, nous dirons que lÕensemble des rŽsultats prŽsentŽs dans cette partie montrent lÕefficacitŽ de notre algorithme. Nous nÕavons pas comparŽ CLIMB ˆ dÕautres algorithmes pour la rŽgulation de charge pour la simple raison que les rŽsultats que fourniraient ces derniers ne peuvent pas •tre significativement meilleurs. Cependant, lÕintŽr•t principal de notre algorithme, outre ses rŽsultats de bonne qualitŽ, est le faible nombre de messages ŽchangŽs, aussi bien pour la recherche dÕun processeur peu chargŽ, que pour la mise ˆ jour des ŽlŽments dÕinformation nŽcessaires pour prendre une bonne dŽcision en vue de rŽguler la charge du rŽseau. 136 Chapitre 3 - Allocation dynamique A titre dÕexemple, dans le cas du rŽseau de 40x40 cellules, nous avons une premi•re distribution alŽatoire de processus, reflŽtŽe par la figure 3.33. 100 80 60 40 20 S29 S1 36 26 31 21 11 S15 16 1 6 0 Fig.3.33. Un rŽseau 40x40 cellules sans rŽgulation de charge. LÕapplication de lÕalgorithme CLIMB donne le rŽsultat de la figure 3.35. Nous constatons une distribution uniforme tr•s nette des charges sur les diffŽrents processeurs. 60 50 40 30 20 10 S34 S12 S1 37 25 29 33 9 13 17 21 1 S23 5 0 Fig.3.35. Un rŽseau 40x40 cellules apr•s application de lÕalgorithme CLIMB pour la rŽgulation de charge. 137 Chapitre 3 - Allocation dynamique 3.3. Ramasse-miettes et gestion de la mŽmoire 3.3.1. NŽcessitŽ dÕun ramasse-miettes La rŽclamation dÕobjets inactifs est nŽcessaire dans les syst•mes o• la ressource mŽmoire est considŽrŽe comme Žtant limitŽe. Dans un premier temps nous considŽrons la notion dÕobjet au sens le plus large du terme25. La fonction dÕun collecteur dÕobjets inactifs26 est de retrouver, par un quelconque mŽcanisme, tous les objets inactifs. Un objet est dit inactif sÕil nÕest plus rŽfŽrencŽ par aucun processus du syst•me considŽrŽ. A lÕopposŽ, tout objet potentiellement accessible par un ou plusieurs processus, via une sŽrie de pointeurs, est dit actif. De tels objets doivent •tre prŽservŽs par lÕopŽration de collection dÕobjets inactifs. La notion dÕactivitŽ est une propriŽtŽ globale ˆ partir du moment o• tout objet peut •tre rŽfŽrencŽ par plusieurs processus. Dans un environnement centralisŽ, une liste commune sera gŽrŽe par lÕensemble des objets crŽŽs dans le syst•me. Par contre, dans un environnement distribuŽ, la t‰che du collecteur devient plus ardue. La rŽpartition de la liste des objets du syst•me sur lÕensemble des sous-syst•mes qui le constituent, nŽcessite une gestion de la cohŽrence des informations enregistrŽes au niveau de chacune des sous-listes. En rŽsumŽ, nous dirons quÕun collecteur doit rŽaliser essentiellement les deux fonctions suivantes: ¥ dŽceler les objets inutilisŽs dans le syst•me (dŽtection), ¥ reprendre lÕespace quÕils occupaient pour une utilisation future par dÕautres processus (rŽcupŽration)27. La dŽtection dÕobjets inactifs repose sur le principe dÕaccessibilitŽ: en partant dÕentitŽs dites ÒracinesÓ - censŽes exister tout au long de lÕexŽcution 25La notion dÕobjet est Žtendue de la simple position mŽmoire (entier, caract•re, structure de donnŽe...) jusquÕaux ÒobjetsÓ dŽfinis suivant lÕapproche orientŽe objets. 26Nous dŽsignerons par la suite le collecteur dÕobjets inactifs par simplement collecteur. 27Les considŽrations de lÕŽmiettement de la mŽmoire qui pourraient en rŽsulter ne sont pas niveau. 138 Chapitre 3 - Allocation dynamique dÕun programme, tous les objets ˆ leur portŽe seront dŽsignŽs actifs. LÕespace occupŽ par les autres objets doit •tre rŽcupŽrŽ. Le processus de rŽcupŽration est gŽnŽralement dŽclenchŽ lorsquÕune demande de mŽmoire est insatisfaite. Une fois le processus de rŽcupŽration engagŽ, le collecteur ne sÕintŽressera quÕaux Òvariables globalesÓ. En effet, les objets locaux ˆ une portion de code sont considŽrŽs actifs tant que celle-ci lÕest Žgalement. Il existe diffŽrentes mŽthodes pour rŽaliser la rŽcupŽration dÕespace inutilisŽ. Nous allons en exposer quelques unes, des plus connues ˆ celles qui le sont moins. 3.3.2. Algorithme du compteur de rŽfŽrences Dans cette approche, chaque objet est dotŽ dÕun compteur qui reprŽsente le nombre de rŽfŽrences qui lui sont faites [DEUTSCH76] [DeTREVILLE90]. A chaque nouvelle rŽfŽrence ˆ un objet, son compteur est incrŽmentŽ de 1. De m•me, lorsquÕune rŽfŽrence ˆ un objet est supprimŽe, son compteur est dŽcrŽmentŽ de 1. Au moment o• celui-ci passe ˆ zŽro, lÕespace que cet objet occupait est rŽcupŽrŽ, puisque cet Žtat indique quÕil nÕy a plus de rŽfŽrences ˆ cet objet (inaccessible par les autres objets). Les objets ainsi rŽcupŽrŽs sont gŽnŽralement liŽs dans une liste dÕobjets libres pour •tre rŽutilisŽs ultŽrieurement. A la rŽcupŽration dÕun objet tous les compteurs des ŽlŽments quÕil pointe sont dŽcrŽmentŽs de 1. LÕavantage de cette mŽthode est quÕelle fait partie intŽgrante du syst•me, et Žvolue avec lui en temps rŽel, sans pour autant induire de traitements supplŽmentaires excessifs. Les seules opŽrations nŽcessaires sur un objet sont les incrŽmentations et dŽcrŽmentations, ainsi que le test dÕun compteur. Cependant, si les objets ont une durŽ de vie ŽphŽm•re, les opŽrations de mise ˆ jour augmentent proportionnellement avec le nombre de ces objets et ainsi deviennent prŽjudiciable pour le bon dŽroulement du programme en question. 139 Chapitre 3 - Allocation dynamique ElŽment racine 2 ElŽment racine 1 2 1 1 3 2 3 1 1 1 1 1 0 1 1 IrŽcupŽrab LÕinconvŽnient majeur de cet algorithme est lÕimpossibilitŽ de rŽcupŽrer des structures circulaires. Dans un circuit formŽ par deux objets ou plus, leur compteur de rŽfŽrences ne passe jamais ˆ zŽro et ne sont donc pas rŽcupŽrables. Nous pouvons proposer notamment deux rem•des ˆ ce probl•me: ¥ Le premier consiste ˆ introduire un second mŽcanisme de rŽcupŽration dÕespace (parmi ceux dŽcrits par la suite). Cette seconde mŽthode est lancŽe ˆ lÕŽchec dÕune rŽclamation dÕespace. Toutefois, cette solution nuit aux applications temps rŽel, puisque ce sont gŽnŽralement des mŽthodes qui supposent lÕarr•t momentanŽ de lÕapplication en vue du nettoyage de la mŽmoire. ¥ Le second rem•de est soit dÕinterdire tout simplement la crŽation de tels circuits en imposant un style de programmation ÒarborescentÓ (CANTOR), soit de les rŽduire ˆ quelques mod•les [BOBROW80] ce qui, dans les deux cas, limite le type dÕapplications envisageables. 140 Chapitre 3 - Allocation dynamique 3.3.3. Algorithme ÒMark & SweepÓ (RŽcupŽrer & Nettoyer) Cet algorithme proc•de en deux phases [HAYES91] [ZORN90]: ¥ Marquage: en partant des ŽlŽments racines, puis de proche en proche, tous les objets accessibles sont marquŽs suivant une certaine mŽthode (en altŽrant leur Žtat, en les enregistrant dans une structure spŽcifique...). ¥ RŽcupŽration: une fois les diffŽrents objets marquŽs, tous ceux qui ne lÕont pas ŽtŽ sont considŽrŽs dŽsuets et ainsi, leur espace est enregistrŽ (en r•gle gŽnŽrale) dans une liste dÕobjets libres. Lorsque nous gŽrons des ŽlŽments de mŽmoire de tailles diffŽrentes, un inconvŽnient de cette mŽthode est lÕŽmiettement de la mŽmoire. Ce probl•me se rencontre Žgalement dans la stratŽgie prŽcŽdente. La solution ˆ ce probl•me rel•ve du type de gestion de la mŽmoire adoptŽ (BEST FIT, WORST FIT...) et nŽcessite donc un traitement supplŽmentaire. La seconde difficultŽ, entra”nŽe par la prŽcŽdente, est le mŽlange de ÒgŽnŽrationsÓ dÕobjets: des objets rŽcemment crŽŽs sont m•lŽs ˆ de plus anciens, pŽnalisant ainsi la localitŽ des rŽfŽrences. Par consŽquent, ces mŽthodes ne sont pas adaptŽes ˆ la gestion de la mŽmoire virtuelle. Les rŽfŽrences dispersŽes ˆ travers diffŽrentes pages impliquent dÕincessants vas-et-vients entre ces pages. 3.3.4. Algorithme ÒMark & CompactÓ (Marquer & Compacter) Le probl•me de la localitŽ des rŽfŽrences est rŽsolu par cette autre approche. Apr•s avoir marquŽ dans une premi•re phase tous les objets accessibles ˆ partir dÕobjets racines, les objets sont ensuite ÒcompactŽsÓ [COHEN83]. Tous les objets actifs sont dŽplacŽs vers le haut (ou vers le bas) de la mŽmoire jusquÕˆ ce quÕils ne forment plus quÕun seul bloc contigu (laissant ainsi en un seul bloc le reste de la mŽmoire libre). 141 Chapitre 3 - Allocation dynamique MARK Racine 1 2 8 5 1 1 * 2 2 4 6 9 * 6 4 9 * 3 3 COMPACT 4 5 * 7 * 6 7 8 9 La localitŽ des rŽfŽrences est ainsi sauvegardŽe: les objets sont ÒreconstituŽsÓ suivant leur ordre de crŽation, et ne sont pas entrem•lŽs ˆ des objets plus rŽcents. LÕinconvŽnient de cette mŽthode est la nŽcessitŽ de rŽaliser plusieurs passages sur chacun des objets: une premi•re fois pour les marquer, une seconde pour leur trouver un nouveau emplacement en mŽmoire, et enfin une phase de translation des adresses. Si beaucoup dÕobjets survivent ˆ une opŽration de rŽcupŽration, le temps nŽcessaire pour rŽaliser cette derni•re est par consŽquent important. Il existe diffŽrentes variantes de cet algorithme [COHEN83]. 3.3.5. Algorithme ÒStop & CopyÓ (Arr•ter & Copier) Tout comme lÕalgorithme prŽcŽdent, celui-ci rŽalise le compactage des objets dans une m•me zone contigu‘. Cependant, contrairement ˆ lÕalgorithme Òmark & compactÓ, les phases de marquage puis de copie sont rŽalisŽes en une seule Žtape. La mŽmoire est gŽnŽralement dŽcoupŽe en deux zones distinctes: la zone courante ( from space), o• sont allouŽs les nouveaux objets, et la zone future (to space), qui reprŽsente la zone destination des objets qui survivent ˆ lÕopŽration de ramasse-miettes. Durant cette opŽration, les objets sont progressivement copiŽs vers la zone future au fur et ˆ mesure quÕils sont accŽdŽs [ZORN90] [CHENEY70]. Une fois cette opŽration terminŽe, les deux zones intervertissent leur r™le respectif: la zone courante devient la zone future et inversement. 142 Chapitre 3 - Allocation dynamique 3.3.6. Algorithmes ÒgŽnŽrationnelsÓ La derni•re famille dÕalgorithmes de rŽcupŽration dÕobjets concerne les algorithmes dits gŽnŽrationnels (ÒGenerational Garbage Collection AlgorithmsÒ) [HAYES91] [DeTREVILLE90] [UNGAR84]. Ces derniers rŽpartissent les objets en plusieurs ÒgŽnŽrationsÓ suivant lÕ‰ge de ces objets. LÕ‰ge dÕun objet correspond au temps depuis lequel cet ŽlŽment est prŽsent dans le syst•me. Ces algorithmes sont capables de rŽaliser lÕopŽration de rŽcupŽration dans des dŽlais tr•s courts, en concentrant leur effort de recherche sur les gŽnŽrations les plus jeunes (cÕest-ˆ-dire les objets rŽcemment allouŽs). Cette catŽgorie dÕalgorithmes par du fait que les objets les plus rŽcents ont des durŽes de vie nettement plus courtes que celle des objets les plus anciens [APPEL89] [UNGAR88]. Une zone mŽmoire est attribuŽe ˆ chaque gŽnŽration dÕobjets. Tous les nouveaux objets sont allouŽs dans la zone mŽmoire rŽservŽe ˆ la gŽnŽration la plus jeune. Les objets sont ÒpromusÓ des jeunes gŽnŽrations vers de plus anciennes suivant leur capacitŽ (traduite par le nombre de fois) ˆ rŽsister (survivre) ˆ plusieurs opŽrations de rŽcupŽration. GŽnŽralement, lÕopŽration de rŽcupŽration, pour une gŽnŽration k, est engagŽe lorsque le taux dÕespace libre restant est en de•ˆ dÕun seuil fixŽ pour lÕensemble des gŽnŽrations ou, au contraire, ce seuil est fixŽ indŽpendamment pour chaque gŽnŽration [LIEBERMAN83] [MOON84]. Pour permettre la rŽcupŽration dÕune gŽnŽration k sans pour autant accŽder aux gŽnŽrations plus anciennes, une table de rŽfŽrences en arri•re au niveau de la gŽnŽration k (qui regroupe toutes les rŽfŽrences ˆ partir des objets dans les anciennes gŽnŽrations vers ceux de la gŽnŽration k) doit •tre mise ˆ jour pour maintenir la cohŽrence des pointeurs lors de la collecte des objets dans k. Un Òensemble de rappelÓ (remembered set) est utilisŽ pour indiquer les objets anciens qui effectuent ces rŽfŽrences en arri•re. De m•me, il est important de garder trace des rŽfŽrences en avant (depuis la gŽnŽration k vers les gŽnŽrations plus anciennes), toujours pour assurer la cohŽrence des rŽfŽrences. Cependant, lÕexplosion de telles tables nŽcessite de prendre des prŽcautions quant ˆ leur utilisation. La solution proposŽe par [LIEBERMAN83], par exemple, consiste ˆ collecter toutes les gŽnŽrations i, tel que i £k, afin dÕŽviter dÕinclure dans les tables de rappel les rŽfŽrences ˆ partir des gŽnŽrations plus jeunes qui sont les plus nombreuses dans le syst•me. 143 Chapitre 3 - Allocation dynamique Nous nous proposons ˆ prŽsent dÕaborder la rŽcupŽration de la mŽmoire dans un environnement parall•le. Les premiers travaux sur les algorithmes parall•les de ramasse-miettes dŽbut•rent avec lÕŽtude des approches Òau-volÓ pour la rŽcupŽration dÕespace. Dans cette approche, deux processeurs distincts op•rent sur une mŽmoire commune. LÕun (le ÒmutateurÓ) rŽalise le travail ÒeffectifÓ (il sÕagit de lÕapplication proprement dite) et lÕautre (le ÒcollecteurÓ) rŽcup•re lÕespace inutilisŽ. Les algorithmes dŽveloppŽs pour le ramasse-miettes au-vol ont ŽtŽ utilisŽs plus souvent comme des exemples dans les techniques de preuve de programmes parall•les que dans les syst•mes rŽels [BEN_ARI84] [DIJKSTRA78]. Ces algorithmes ont parallŽlisŽ les traditionnels algorithmes Òmark-and-sweepÓ. Ils hŽrit•rent donc des inconvŽnients de ces algorithmes, et en premier lieu, la nŽcessitŽ dÕaccŽder ˆ un grand nombre dÕobjets, aussi bien inactifs quÕactifs. Cet inconvŽnient, comme nous lÕavons vu auparavant, a ŽtŽ corrigŽ par les mŽthodes dites de Òcopy collectionÓ (tels que les algorithmes Òstop & copyÓ). Par la suite, les algorithmes gŽnŽrationnels ont affinŽ et rŽduit la copie dÕobjets stables, en concentrant la majeure partie des efforts sur les gŽnŽrations dÕobjets ÒjeunesÓ. Nous illustrons lÕapproche parall•le par deux algorithmes dus respectivement ˆ [SHARMA91] et ˆ [HERLIHY93]. Le premier concerne une parallŽlisation de lÕapproche gŽnŽrationnelle et le second propose une solution qui ne repose sur aucun syst•me de synchronisation pour mener ˆ bien sa t‰che, contrairement au prŽcŽdent. 144 Chapitre 3 - Allocation dynamique 3.3.7. Un algorithme ÒgŽnŽrationnelÓ parall•le La parallŽlisation de lÕapproche ÒgŽnŽrationnelleÓ peut intervenir ˆ deux niveaux: ¥ lÕopŽration de rŽcupŽration peut •tre entreprise en parall•le avec le programme courant, ¥ ou encore, et lÕauteur [SHARMA91] met lÕaccent davantage sur cet aspect, les t‰ches parall•les du ÒramasseurÓ (collecteur) peuvent opŽrer en concurrence, chacune Žtant chargŽe de la rŽcupŽration des objets inactifs dans une gŽnŽration distincte. La mŽthode prŽsentŽe consid•re la parallŽlisation dÕun ramasse-miettes gŽnŽrationnel sur une architecture multiprocesseurs ˆ mŽmoire partagŽe. Le collecteur est composŽ de plusieurs entitŽs qui travaillent en parall•le pour exploiter au mieux lÕarchitecture sous-jacente. Le calcul peut Žvoluer concurremment avec le collecteur pendant la phase de collecte. LÕavancement (promotion) dÕun objet au travers des gŽnŽrations repose sur le nombre de fois que ce dernier survit aux diffŽrentes phases de collecte. Tout comme dans le cas de [LIEBERMAN83], la collecte dÕune gŽnŽration k nŽcessite celle de toutes les gŽnŽrations i, tel que i £k, pour les m•mes raisons ŽvoquŽes au paragraphe3.3.6. Toutefois, la collecte de chacune des gŽnŽrations est rŽalisŽ en parall•le. Cette parallŽlisation rend nŽcessaire lÕutilisation de verrous pour assurer la synchronisation entre les diffŽrentes t‰ches parall•les. Pour Žviter le cas dÕinterblocage, causŽ par une attente circulaire sur les verrous, lÕauteur utilise une mŽthode de prŽvention: pour chaque gŽnŽration, il existe diffŽrentes classes de verrous qui contr™lent chacune lÕacc•s ˆ diffŽrentes variables. De plus, pour Žviter la prolifŽration des Òensembles de rappelÓ (cf.¤3.3.6), cette technique recourt ˆ une table globale de rappel pour tout le syst•me. Cette table contient toutes les pages (mŽmoires) qui poss•dent des objets qui ont des rŽfŽrences en arri•re vers des gŽnŽrations plus jeunes que la leur. Lors dÕune collecte des gŽnŽrations 1 ˆ k, les pages mŽmoires dŽsignŽes par lÕensemble de rappel sont parcourues uniquement lorsquÕelles appartiennent ˆ des gŽnŽrations plus anciennes (donc plus grandes que k). La mŽmoire est divisŽe en plusieurs gŽnŽrations, dont une particuli•re: le ÒvieilÓ espace (Old Space - OS), qui contient les objets les plus anciens (suite ˆ de multiples promotions de gŽnŽration en gŽnŽration). Les autres gŽnŽrations sont divisŽes en deux parties: la partie courante et la partie future (figure3.35). La premi•re partie contient une zone appelŽe Ònouvelle 145 Chapitre 3 - Allocation dynamique zoneÓ, o• sont allouŽs tous les nouveaux objets (de cette gŽnŽration) ainsi que les objets promus depuis les gŽnŽrations plus jeunes vers elle. La partie ÒfutureÓ est utilisŽe lors de la collecte de cette gŽnŽration (en inter changeant ˆ ce moment les deux parties28). GŽnŽrations ì ï Partie courante í ï Nouvelle zone î ì ï Partie future í ï î 1 2 3 OS ¥¥¥ Fig.3.35. Division de lÕespace mŽmoire dans [SHARMA91] . Le principe gŽnŽral de cet algorithme peut •tre rŽsumŽ comme suit. Lorsque lÕespace libre est jugŽ insuffisant (eu Žgard ˆ un seuil) pour assurer les prochaines demandes en mŽmoire, le processus de rŽclamation est enclenchŽ. LÕapplication est alors temporairement suspendue et le collecteur se met, Žventuellement, en attente de la fin dÕexŽcution dÕune prŽcŽdente opŽration de ramasse-miettes. Il intervertit les deux zones de chaque rŽgion (une par gŽnŽration) dans les k premi•res gŽnŽrations. Puis, il copie les objets racines des ces premi•res gŽnŽrations dans la zone appelŽ Òpartie couranteÓ. Un objet racine est dŽfini comme Žtant tout objet accessible directement par les processus de lÕapplication. Le collecteur dŽtermine ensuite et marque nonexplorŽes toutes les pages de lÕensemble de rappel qui se trouvent dans des gŽnŽrations plus anciennes que k (car ces pages contiennent des objets qui doivent •tre examinŽs). Il initie en parall•le le processus de ramasse-miettes pour chacune des gŽnŽrations comprises entre 1 et k. Finalement, le collecteur reprend lÕactivitŽ suspendue de lÕapplication. Pour prŽserver la cohŽrence des pointeurs, toutes les pages non encore examinŽes sont verrouillŽes, interdisant ainsi lÕacc•s aux objets de cette page tant que celle-ci nÕa pas ŽtŽ traitŽe par le collecteur. 28Dans la littŽrature, cette opŽration est souvent dŽsignŽe sous le nom de flip. 146 Chapitre 3 - Allocation dynamique 3.3.8. Un algorithme parall•le non-bloquant Comme nous venons de le voir, dans [SHARMA91] [APPEL88] et bien dÕautres, les algorithmes de ramasse-miettes pour les multiprocesseurs ˆ mŽmoire partagŽe reposent dÕune fa•on gŽnŽrale sur une synchronisation globale (qui peut se prŽsenter sous diffŽrents aspects) pour prŽserver une cohŽrence entre les diffŽrentes rŽfŽrences entre objets. NŽanmoins, une telle synchronisation globale nÕest pas appropriŽe ˆ des architectures asynchrones: lorsquÕun processus est arr•tŽ ou mis en attente, dÕautres processus, corrects, seront incapables de progresser (car liŽs ˆ ces derniers). DÕautre part, un algorithme de gestion de lÕallocation mŽmoire est nonbloquant si, en absence dÕŽpuisement de ressources (il sÕagit typiquement de la mŽmoire), un processus en pleine allocation ou rŽcupŽration de mŽmoire peut subir un retard considŽrable sans pour autant forcer dÕautres processus ˆ se bloquer. [HERLIHY93] prŽsente un algorithme de copie incrŽmentale nonbloquant pour la rŽcupŽration de la mŽmoire: la synchronisation dans cet algorithme est Žtablie en appliquant ˆ la mŽmoire partagŽe les opŽrations de base read, write et compare&swap. Cet algorithme nÕutilise aucune notion de verrou ou dÕattente active; de m•me, un processus ne peut pas observer ou modifier les variables locales ou registres dÕun autre processus, ni recourir ˆ des interruptions inter-processus. Le mod•le de mŽmoire adoptŽ par lÕauteur est composŽ de trois aspects: LÕarchitecture sous-jacente Dans cet algorithme, lÕauteur consid•re des architectures MIMD sur lesquelles n processus asynchrones partagent une mŽmoire globale. Cependant, chaque processus poss•de une zone privŽe (la pile et les registres), inaccessible aux autres processus. Les opŽrations primitives de la mŽmoire sont: ¥ read, qui copie une valeur de la mŽmoire partagŽe vers sa propre zone privŽe, ¥ write, qui rŽalise lÕopŽration inverse de la primitive prŽcŽdente, ¥ compare&swap, pour rŽaliser une synchronisation de base et dont le code de la primitive est le suivant: 147 Chapitre 3 - Allocation dynamique compare&swap if (w: world, old, new: value) returns (boolean) w = old then else w := new return true return false endif e n d compare&swap. Le niveau application Il sÕagit ˆ ce niveau de la sŽmantique de la gestion de la pile mŽmoire au niveau application. Une application poss•de des variables locales et partage, avec dÕautres processus, un ensemble dÕobjets. Du point de vue de lÕapplication, un objet appara”t sous la forme dÕun vecteur de valeurs, de taille fixe. Une valeur peut •tre un boolŽen, un entier ou un pointeur vers un autre objet. Les opŽrations de base ˆ ce niveau sont: ¥ create (s), qui crŽe un objet de taille s et retourne le pointeur sur cet objet, ¥ fetch (x, i), qui prend en argument un pointeur vers un objet x et un indexe i dans cet objet, et retourne la valeur du composant ainsi indŽxŽ, ¥ store (x, i, v) qui range la valeur v dans lÕobjet x ˆ la position i. LÕaspect structurel Cet aspect concerne la structuration de la mŽmoire partagŽe, dans le but de supporter la sŽmantique du niveau application. La mŽmoire est partitionŽe en n rŽgions contigu‘s: une pour chaque processus. Un processus peut accŽder ˆ nÕimporte quelle position mŽmoire, mais, par contre, ne peut allouer ou collecter de lÕespace mŽmoire que dans sa propre rŽgion uniquement. Un objet est reprŽsentŽ sous la forme dÕune liste cha”nŽe de versions. Chaque version est contenue dans la rŽgion mŽmoire dÕun seul processus. Chaque version pointe vers la suivante. La derni•re, qui ne pointe sur aucune autre, est la version courante. NÕimporte quel processus peut dŽterminer le processus au niveau duquel rŽside une adresse x par le biais de la fonction owner(x) . 148 Chapitre 3 - Allocation dynamique Les primitives de gestion de la mŽmoire ˆ ce niveau sont: ¥ find_current(x) , dŽtermine la version courante dÕun objet x, ¥ fetch(x, i) , lit le contenu du composant indexŽ par i dans lÕobjet x, ¥ store(x, i, v) , modifie lÕobjet x en crŽant et cha”nant cet ŽlŽment dans une nouvelle version courante. LÕutilisation de plusieurs versions dÕun m•me objet permet de rŽaliser des mises ˆ jours concurrentes sur un m•me objet sans avoir recours ˆ lÕexclusion mutuelle. De m•me, cette organisation permet de ÒdŽplacerÓ un objet, lors de la phase de copie de lÕopŽration de rŽcupŽration de la mŽmoire, en le cha”nant, sans avoir ˆ le verrouiller. Le principe de cet algorithme est celui des algorithmes qui proc•dent par copie dÕun espace mŽmoire vers un autre. Chaque rŽgion (associŽe ˆ un processus) est partagŽe en plusieurs zones contigu‘s: une seule zone ÒtoSpaceÓ, zŽro ou plus de zones ÒfromSpaceÓ, et zŽro ou plus de zones libres (se reporter au ¤3.3.5 pour lÕorigine de ce dŽcoupage). BasŽ sur le mod•le que nous venons de dŽcrire, lÕauteur propose une stratŽgie, non-bloquante, de parcours des diffŽrentes zones mŽmoires lors de lÕopŽration de ramasse-miettes. Cette opŽration est initiŽe lorsquÕun seuil du taux dÕoccupation de la zone libre dÕallocation est dŽpassŽ. 149 Chapitre 3 - Allocation dynamique 3.3.9. Conclusion La fonction de ramasse-miettes est un service qui est soit intŽgrŽ dans le langage de programmation (tel que LISP, EIFFEL...), soit offert par lÕenvironnement dÕexŽcution. LÕintroduction dÕune telle fonction permet au programmeur de sÕaffranchir des considŽrations dÕallocation/restitution de ressources et de se concentrer davantage sur les aspects fonctionnels de son application. Ceci permet en outre dÕaccro”tre la productivitŽ et la fiabilitŽ du logiciel qui en rŽsulte. Globalement, le ramasse-miettes se prŽsente sous lÕune des trois formes suivantes: ¥ Les algorithmes avec compteur de rŽfŽrences; ces algorithmes comptent le nombre de rŽfŽrences pour chaque objet. Les objets dont le compteur passe ˆ zŽro sont rŽcupŽrŽs. Les algorithmes ˆ compteur de rŽfŽrences pures sont incapables de rŽcupŽrer des structures de donnŽes circulaires. ¥ Les algorithmes de tra•age; ces derniers parcourent les structures de donnŽes afin de dŽterminer les objets inaccessibles. Les objets accessibles sont marquŽs, les autres sont rŽcupŽrŽs. Nous pouvons aussi ranger dans cette famille les algorithmes de coloriage. En effet, leur principe revient ˆ marquer les objets, suivant une certaine stratŽgie, puis ˆ rŽcupŽrer tous les objets dÕune certaine couleur [KAFURA90]. ¥ Les algorithmes gŽnŽrationnels; ces algorithmes, qui semblent retenir de plus en plus lÕattention des chercheurs ([HAYES91] [DeTREVILLE90] [APPEL89] [UNGAR88]...), sont gŽnŽralement plus rapide que ceux de la seconde famille. Leur principe est de diviser les objets en plusieurs classes, en fonction de leur ‰ge. Les objets sont le plus souvent rŽcupŽrŽs parmi les gŽnŽrations les plus jeunes. LÕespace de recherche dÕobjets inutilisŽs est ainsi rŽduit. En ce qui concerne les algorithmes parall•les de ramasse-miettes, la plupart consid•rent une mŽmoire globale distribuŽe [HERLIHY93] [SHARMA91][LANGENDOEN92] ... Lorsque ce nÕest pas le cas, on suppose un syst•me de dŽsignation globale, distribuŽ sur les nÏuds du rŽseau [AGHA94] ou encore la gestion de la pile est centralisŽe [LADIN92]. 150 Chapitre 3 - Allocation dynamique Ce que nous pouvons retenir des deux algorithmes parall•les que nous avons prŽsentŽs dans ce chapitre 29 , cÕest que le passage dÕun milieu monoprocesseur vers un milieu multiprocesseurs ˆ mŽmoire commune partagŽe nŽcessite une coopŽration entre les diffŽrentes entitŽs du collecteur distribuŽ, et surtout, un mŽcanisme de synchronisation. La philosophie inhŽrente ˆ chaque approche (mŽthode de copie ou rŽpartition des objets par gŽnŽration) reste inchangŽe lors de ce passage. Nous avons donc pensŽ quÕil serait possible de considŽrer, ˆ la mani•re de [KAFURA90], un ramasse-miettes adaptŽ au mod•le acteur. Toutefois, nous allons plus loin que la solution proposŽe par Kafura en proposant une stratŽgie parall•le (distribuŽe). Rappelons que la mŽthode de Kafura ,ŽlaborŽe pour un contexte monoprocesseur, repose sur un algorithme de coloriage qui dŽtermine les acteurs accessibles de ceux qui ne le sont pas (suivant leur couleur). Ces derniers doivent restituer lÕespace quÕils occupent. Nous proposons dans ce qui suit un nouvel algorithme distribuŽ pour la rŽcupŽration dÕespace dans un environnement parall•le. 29 Il existe beaucoup dÕautres algorithmes, basŽs sur les techniques traditionnelles: les algorithmes de copie et ceux dits gŽnŽrationnels [NETTLES93] [LANGENDOEN92] [LeSERGENT92] [LADIN92] [LESTER??] [MANCINI88] [KUNG77]... 151 Chapitre 3 - Allocation dynamique 3.3.10. Un algorithme distribuŽ pour la rŽcupŽration dÕacteurs Nous considŽrons ˆ ce niveau lÕapplication des algorithmes de ramassemiettes dans le cas de R.C.A.I. Dans le cadre de nos travaux, il sÕagit de rŽcupŽrer des acteurs qui nÕentrent plus dans le calcul dÕune fonction en cours dÕŽvaluation. Rappelons que dans cette premi•re version du projet R.C.A.I ˆ gestion dynamique, les notions dÕacteurs et de cellules sont confondues puisquÕil y a prŽcisŽment un acteur par cellule. RŽcupŽrer un acteur inutilisŽ revient donc ˆ rŽcupŽrer la cellule qui le contient. Les algorithmes de rŽcupŽration, basŽs sur la notion de marquage (Òmark & sweepÓ, Òmark & compactÓ, ...), posent, dans un milieu distribuŽ, un sŽrieux probl•me. En effet, en supposant quÕune opŽration de rŽcupŽration ait ŽtŽ initiŽe par un quelconque ŽlŽment du syst•me, le probl•me qui survient est celui de la dŽtection de la terminaison de cette opŽration. A quel moment peut-on •tre sžr que tous les ŽlŽments racines, pour simplifier la chose, ont procŽdŽ au marquage de lÕensemble des ŽlŽments qui leur sont potentiellement accessibles? Cette question soul•ve Žgalement celle de la connaissance mutuelle des ŽlŽments racines. Chacun dÕeux doit •tre mis au courant de la crŽation et de la destruction de ces ŽlŽments particuliers. Ceci reprŽsente donc, a priori, le seul ŽlŽment de contr™le possible dans un milieu distribuŽ. Pour rŽsoudre ce probl•me, nous proposons la solution dŽcrite dans la suite de ce paragraphe. DŽfinition: Un acteur est dit ÒracineÓ lorsquÕil est apte ˆ rendre compte ˆ lÕh™te de son Žtat ou de celui dÕautres acteurs. Nous supposerons que cette caractŽristique est dŽtectŽe au moment de la compilation du source, en relevant des rŽfŽrences ˆ des entitŽs externes (rŽfŽrences externes), tel que console, fichier... Tout acteur de ce type sera marquŽ comme Žtant un acteur-racine. De m•me, lors de lÕexŽcution, tout acteur ˆ qui un autre acteur communique une rŽfŽrence externe est marquŽ ˆ son tour acteur-racine. 152 Chapitre 3 - Allocation dynamique Pour rŽaliser le contr™le de terminaison, dont nous avons donnŽ une Žbauche plus haut, nous avons besoin dÕun autre type dÕacteur: lÕ acteur contr™leur. LÕacteur contr™leur est en quelque sorte un super acteur-racine. Il garde trace des premiers acteurs-racines et dŽcide du moment de procŽder ˆ la rŽcupŽration des cellules inutilisŽes. Cet acteur est la racine de lÕarbre constituŽ par les acteurs-racines (figure3.36). La crŽation et la destruction dÕacteurs-racines entra”ne une modification de lÕarborescence formŽe par les acteurs de ce type (figure3.37). Ces modifications correspondent ˆ des mises ˆ jour de pointeurs entre les acteursracines. Une crŽation dÕun acteur-racine correspond ˆ une duplication dÕun autre acteur de ce type. CÕest donc cet acteur qui garde trace de lÕexistence de ce dernier. LorsquÕun acteur-racine est dŽtruit, il doit passer ˆ lÕacteur-racine p•re lÕidentitŽ du (des) prochain(s) acteur(s)-racine(s) sur lequel (lesquels) il pointe. LorsquÕun acteur, ˆ la recherche dÕune cellule libre, sÕaper•oit quÕaucune cellule nÕest disponible, il diffuse une demande de rŽcupŽration de cellules. LÕacteur contr™leur qui re•oit cet ordre va dŽclencher en parall•le lÕopŽration de ramasse-miettes. Il envoie ˆ tous ses nÏuds fils un ordre de rŽcupŽration, qui ˆ leur tour renvoient cet ordre ˆ leur propre descendance. Un acteurracine qui re•oit un ordre de rŽcupŽration envoie un signal ˆ tous les acteurs quÕil peut atteindre, directement ou indirectement, lÕordre de se marquer comme ÒvalideÓ. Les acteurs racines se marquent ÒvalidesÓ d•s la rŽception de lÕordre dÕinitiation de cette opŽration. Nous rŽalisons ainsi une fermeture transitive ˆ partir des nÏuds racines. Lorsque chaque ŽlŽment des sousarbres constituŽs des acteurs-racines aura rŽpondu avoir contactŽ et re•u un accusŽ de rŽception de la part des acteurs quÕil conna”t, lÕacteur-racine de cette sous-arborescence renvoie un accusŽ de rŽception ˆ son p•re. De ce fait, lÕopŽration prend fin lorsque les acteurs racines, directement reliŽs ˆ lÕacteur-contr™leur, auront tous renvoyŽ un accusŽ. A la rŽception de tous ces accusŽs, lÕacteur-contr™leur diffuse lÕordre, ˆ toutes les cellules non marquŽes, de se dŽclarer libres. Durant cette opŽration, toutes les demandes dÕune autre opŽration de rŽcupŽration sont ignorŽes. De m•me, ˆ la diffusion de la premi•re requ•te de 153 Chapitre 3 - Allocation dynamique rŽcupŽration, toutes les cellules inhibent dÕŽventuelles demandes de cette nature, jusquÕˆ rŽception de lÕordre de libŽration. Il faut remarquer que, contrairement aux algorithmes de marquage citŽs dans les paragraphes prŽcŽdents, cet algorithme ne nŽcessite pas lÕarr•t de lÕapplication pour rŽaliser cette opŽration. Les acteurs rŽagissent aux ŽvŽnements qui leurs sont envoyŽs en sÕauto-dŽtruisant ou tout simplement en poursuivant leur traitement. Il nÕy a que la demande dÕautres opŽrations de rŽcupŽration qui sont inhibŽes, afin de ne pas saturer le rŽseau inutilement. Cet algorithme est repris dans la figure3.38. Avant dÕimplŽmenter cette solution et dÕen mesurer lÕefficacitŽ, nous nous sommes attachŽs ˆ rŽgler un certain nombre dÕautres probl•mes dÕimplŽmentation; cÕest pourquoi des rŽsultats dÕŽvaluation prŽcis nÕont pu •tre obtenus sur cet algorithme. La solution retenue dans R.C.A.I est beaucoup plus simple comme nous le verrons par la suite30. Avant dÕaborder lÕexposŽ de la solution prŽconisŽe dans R.C.A.I, nous devons dŽfinir quelques ŽlŽments. Ces Žclaircissements vont appara”tre au dŽbut du prochain chapitre. Ils seront suivis par notre proposition pour la rŽcupŽration dÕacteurs dans une machine massivement parall•le ˆ grain fin, R.C.A.I. 30 La solution que nous prŽsenterons pour R.C.A.I repose sur la notion de compteur de rŽfŽrences. Cette solution devra •tre combinŽe avec celle exposŽe ˆ ce niveau pour obtenir un meilleur rendement. Ainsi, lorsquÕun acteur se trouve dans lÕincapacitŽ de dŽcouvrir une cellule libre, alors quÕil en existe potentiellement certaines occupŽes par des acteurs inactifs, il sÕagit ˆ ce moment lˆ de cellules qui nÕont pas pu •tre rŽcupŽrŽes par le biais de leur compteur - car elles forment un cycle. Toutefois, cette solution ne pourra •tre effective que si ce genre de cycle sont permis par le langage dÕacteur retenu. 154 Chapitre 3 - Allocation dynamique Acteur Contr™leur Acteur Racine Acteur Fig.3.36. Structure des acteurs dÕune application. CrŽation Destruction Acteur Racine Branche dŽtruite Fig.3.37. Mise ˆ jour de lÕarborescence de contr™le de la rŽcupŽration parall•le dÕacteurs. 155 Chapitre 3 - Allocation dynamique ¥ ¥ ¥ ¥ ¥ /* Pour Toutes Les Cellules */ A l’échec d’une recherche de cellule libre { Si ( Diffusion_Requête == AUTORISÉE ) Alors • Diffuser la demande de récupération FinSi } ¥ ¥ ¥ ¥ A la réception d’une demande de récupération { Marque_Cellule <- NON_VALIDE Diffusion_Requête <- NON_AUTORISÉE } ¥ A la réception d’un ordre de ramasse-miettes { Si ( Marque_Cellule == VALIDE ) Alors Diffusion_Requête <- AUTORISÉE Sinon Etat_Cellule <- LIBRE FinSi } ¥ A la réception d’un ordre de récupération { Marque_Cellule <- VALIDE ¥ ¥ ¥ Pour_Tout ( Acteur ) Faire • Envoyer ordre de récupération FinFaire ¥ Attendre_Tout (Acteur ) ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ • Envoyer accusé à l’acteur père ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ } /* Pour Toute Cellule Acteur-Racine */ A la réception d’un ordre de récupération { Marque_Cellule <- VALIDE ¥ ¥ ¥ ¥ ¥ ¥ Pour_Tout ( Acteur_Racine & Acteur ) Faire • Envoyer ordre de récupération FinFaire ¥ Attendre_Tout (Acteur_Racine & Acteur ) ¥ • Envoyer accusé à l’acteur-racine père ¥ ¥ ¥ ¥ ¥ ¥ } Si ( Récupération_En_Cours == VRAI ) Alors • Ignorer la requête Sinon Pour_Tout ( Acteur-Racine ) Faire • Envoyer ordre de récupération FinFaire ¥ ¥ ¥ ¥ ¥ /* Pour La Cellule Acteur-Contrôleur */ A la réception d’une demande de récupération { Marque_Cellule <- VALIDE ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ ¥ Attendre_Tout ( Acteur-Racine ) ¥ ¥ • Diffuser l’ordre de rammasse-miettes ¥ ¥ ¥ Récupération_En_Cours <- FAUX FinSi } Fig.3.38. Algorithme du ramasse-miettes parall•le. 156 ¥ ¥ ¥ C HAPITRE 4 A UTRES PROBLéMES LIƒS AUX LIMITATIONS DE R.C.A.I. 4. AUTRES PROBLéMES LIƒS AUX LIMITATIONS DE R.C.A.I Quelques-uns des probl•mes de mise en Ïuvre sont intimement liŽs aux limitations de notre machine. Il sÕagit notamment de lÕespace dÕadressage qui est relativement rŽduit dans R.C.A.I. Ces probl•mes mettent en exergue lÕalgorithmique parall•le en relation avec notre architecture et sa spŽcificitŽ. Il faut •tre toujours ˆ la recherche de solutions simples (qui peuvent •tre intŽgrŽes facilement) et indŽpendantes de la taille du rŽseau (ˆ cause de lÕespace dÕadressage) et de la taille du grain visŽ (tr•s fin, en relation avec la mŽmoire de faible taille). 4.1. Serveur de code Durant lÕexŽcution dÕun acteur, il y a crŽation et destruction dÕacteurs intermŽdiaires, pour lÕŽvaluation dÕune fonction commune. LÕopŽration de crŽation se dŽroule en plusieurs phases: ¥ recherche dÕune cellule libre, ¥ copie du code correspondant, ¥ mise ˆ jour des espaces de rŽfŽrences des acteurs concernŽs par cette crŽation, ¥ initialisation de lÕacteur qui vient dÕ•tre crŽŽ, ¥ dŽclenchement ˆ distance de lÕexŽcution de lÕacteur. La recherche de cellules libres a ŽtŽ abordŽe dans le chapitre prŽcŽdent. A prŽsent, nous nous intŽressons ˆ un probl•me particulier: la dŽsignation du code ˆ copier. Trois cas sont possibles: ¥ la copie du code se trouve ˆ lÕextŽrieur du rŽseau; dans ce cas, ˆ chaque crŽation dÕun acteur nous faisons appel ˆ lÕh™te qui copie le code correspondant dans la cellule spŽcifiŽe. Il est Žvident que cette solution est tr•s cožteuse ˆ cause du nombre dÕE/S ˆ effectuer pour mener ˆ terme lÕapplication. ¥ La copie du code est rŽalisŽe ˆ partir dÕune cellule particuli•re; chaque acteur diffŽrent est affectŽ ˆ une cellule du rŽseau. Une telle dŽmarche pose lÕŽpineux probl•me du goulot dÕŽtranglement que constitue cette cellule. 159 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Une autre approche consiste ˆ distribuer plusieurs copies dÕun m•me acteur, rŽpartissant ainsi la charge sur ces cellules. CÕest cette solution que nous dŽveloppons dans cette section. 4.1.1. DŽfinition de lÕespace dÕadressage Comme nous lÕavons dŽjˆ vu, lors de la dŽfinition du mod•le dÕexŽcution, nous dŽgageons ˆ la compilation le graphe non orientŽ dÕacteurs de lÕapplication (figure4.1). C A G E B D F Fig.4.1. RŽseau dÕacteurs. Pour chaque acteur nous dressons la table suivante qui dŽfinit entre autre son espace dÕadressage que nous notons W. Chaque entrŽe de cette table correspond ˆ une rŽfŽrence dÕun acteur de ce type dans le syst•me. Acteur i Acteur i.1 Ref. 1 Acteur i.2 Ref. 2 ... Acteur i.j Ensemble W Ref. j D ^ Acteur dŽlŽguŽ å n Compteur des rŽfŽrences Fig.4.2. DŽfinition de lÕespace dÕadressage dÕun acteur. En considŽrant lÕexemple de la figure4.1, la construction de toutes les tables de rŽfŽrences des diffŽrents acteurs donne le rŽsultat de la figure4.3. 160 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Root A A0 D ^ å 2 A0 B B0 D Root å 4 B0 C0 D0 E0 F0 G0 A A0 B B0 B B0 C C0 D D0 C C0 E E0 D D0 C C0 B B0 E E0 G G0 C C0 E E0 F F0 F F0 D E0 D C0 D D0 G G0 D B0 D B0 å 4 å 4 D A0 D B0 å 6 å 6 å 8 å 8 Fig.4.3. Exemple dÕespaces dÕadressage dÕacteurs dÕun graphe. Eu Žgard ˆ ces tables de rŽfŽrences, chaque acteur qui dŽsire crŽer un nouvel acteur consulte sa propre table pour dŽgager la derni•re rŽfŽrence (ou prototype) connue de cet acteur dans l'ensemble W. Un nouvel acteur signale ˆ chacun des ŽlŽments de lÕensemble W sa crŽation de telle sorte que chacun puisse mettre ˆ jour son propre compteur de rŽfŽrences. LÕacteur ˆ lÕorigine de cette crŽation informe lÕacteur qui correspond ˆ la derni•re rŽfŽrence connue de ce prototype (qui figure dans son ensemble W) de sa dŽcision de ne plus garder de lien avec lui pour une Žventuelle demande de copie. Une fois quÕil lÕaura averti, cet acteur remplace lÕancienne rŽfŽrence dans son ensemble W par la nouvelle. LÕespace dÕadressage (ensemble des rŽfŽrences avec lesquelles une entitŽ est en mesure de communiquer) se prŽsente sous la forme reportŽe dans la figure4.4. 161 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. DonnŽes Syst•mes RŽfŽrence 1 RŽfŽrence 2 ¥¥¥ RŽfŽrence n Compteur de rŽfŽre Zone d'initialisation Reste du code Fig.4.4. ReprŽsentation de lÕespace dÕadressage. 4.1.2. DiffŽrents types de copies de code Comme nous lÕavons ŽvoquŽ prŽcŽdemment, la crŽation dÕun acteur dŽbute par la recherche dÕune cellule libre. Une fois cette cellule trouvŽe, il faut procŽder ˆ la copie du code correspondant. Deux cas de figure apparaissent (figure4.5): ¥ soit il sÕagit dÕune duplication de lÕentitŽ elle-m•me, ¥ soit il sÕagit dÕune copie ˆ partir dÕune autre cellule. (a) Duplication (b) Copie Fig.4.5. Serveur de code. La diffŽrence entre les deux types de copies est Žvidente. LÕune est dŽclenchŽe localement, alors que lÕautre provoque, ˆ distance, lÕamorce de lÕopŽration de copie (qui ne correspond pas ˆ la progression normale de lÕacteur impliquŽ dans cette action). 162 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.1.2.1. Duplication Cette opŽration est provoquŽe par lÕintermŽdiaire de lÕinstruction MOVE. La syntaxe correspondante est la suivante: <adresse> MOVE Cette instruction proc•de de la mani•re suivante. Le compteur associŽ ˆ cette instruction est initialisŽ ˆ la taille du code ˆ transfŽrer. Cette donnŽe est indiquŽe dans la zone syst•me (figure4.4). Les mots mŽmoires sont acheminŽs lÕun ˆ la suite de lÕautre ˆ leur destination (indiquŽe dans le contenu du mot mŽmoire <adresse> de lÕinstruction), jusquÕau passage ˆ zŽro du compteur. Ce schŽma est explicitŽ dans la figure4.6. Initialiser le compteur oui Compteur ˆ zŽro Instruction suivante non non Tampon sortie occupŽ oui Construire message suivant Signaler Tampon sortie PLEIN IncrŽmenter le compteur Fig.4.6. Duplication de code. Cette instruction est bloquante. En effet, tant que le code nÕaura pas ŽtŽ transfŽrŽ en entier, nous ne passons pas ˆ lÕinstruction suivante. 4.1.2.2. Copie distante Cette opŽration est provoquŽe par lÕintermŽdiaire de lÕinstruction COPY. La syntaxe correspondante est la suivante: 163 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. <adresse> COPY Contrairement ˆ la premi•re instruction, cette derni•re ne fait pas partie du code de la cellule o• elle est interprŽtŽe (exŽcutŽe). La cellule qui accomplit cette opŽration re•oit un ordre (message) pour une copie diffŽrentielle. Ce message provoque une interruption au niveau de la cellule. A partir de ce moment, le schŽma dÕexŽcution est, ˆ peu de choses pr•s, semblable au prŽcŽdent: nous commen•ons par initialiser un compteur, puis les mots mŽmoires sont transfŽrŽs successivement ˆ leur destination. Toutefois, cette instruction nÕest pas bloquante pour la cellule mise ˆ contribution dans cette action. En effet, il y a partage de la ressource que constitue le tampon de sortie entre la structure gŽrant la copie de code et le routeur de la cellule. Interruption Initialiser le compteur oui Effacer l'intŽrruption Signaler fin opŽration ˆ la cellule Žmettrice Compteur ˆ zŽro non non Tampon sortie occupŽ Construire le message suivant Signaler Tampon sortie PLEIN IncrŽmenter le compteur Fig.4.7. Copie de code ˆ distance. 164 oui Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.1.2.3. Derni•re phase de la copie de code Aussi bien dans lÕune que dans lÕautre instruction, lÕopŽration de copie est terminŽe par lÕenvoi dÕun message particulier: le message de dŽbut dÕexŽcution sur le processeur (cellule) cible. Ce message est en fait interprŽtŽ comme un signal, puisquÕil se contente de demander au processeur en question de se brancher ˆ son premier point dÕentrŽe. LÕadresse de ce point dÕentrŽe spŽcial est intŽgrŽe dans les donnŽes syst•me de chaque acteur. MŽmoire Point d'entrŽe · PC Taille Code ¥¥¥ ¸ RŽception d'un ŽvŽnement externe ¶ Fig.4.8. DŽclenchement dÕexŽcution ˆ distance. La section de code qui correspond ˆ cette adresse est la phase dÕinitialisation. En effet, il faut pouvoir assurer pour chaque acteur un environnement cohŽrent pour quÕil puisse entamer correctement son exŽcution. La rŽaction ultŽrieure aux messages quÕil recevra en sera profondŽment influencŽe. La valeur des diffŽrentes variables locales dŽtermine lÕaction ˆ entreprendre par lÕacteur vis ˆ vis des requ•tes des autres acteurs. 4.1.3. Exemple de gestion dÕun espace dÕadressage L'entitŽ nouvellement crŽŽe hŽrite de tout l'espace de rŽfŽrences de l'entitŽ gŽnŽratrice. Cette derni•re met ˆ jour son propre espace par celles rŽcemment crŽŽes. Elle informe ensuite celles prŽcŽdemment rŽfŽrencŽes ˆ cet usage que cette derni•re ne garde plus trace de leur existence pour des copies ultŽrieures. De cette fa•on, nous Žvitons d'introduire des goulots d'Žtranglement pour la dŽsignation des "mod•les" (ou prototypes) des entitŽs ˆ gŽnŽrer. 165 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. B A D E C F G Fig.4.9. Exemple dÕun graphe dÕacteurs extrait dÕune application. CÕest ˆ partir dÕun graphe dÕacteurs que lÕespace dÕadressage est extrait pour chacun dÕeux. Par exemple, pour lÕacteur C, lÕespace de rŽfŽrences est le suivant: WC = {E,F,G,A} Supposons la crŽation, au niveau de lÕacteur C, dÕune nouvelle entitŽ (EÕ) dÕun acteur dont le prototype connu actuellement par celui-ci est dŽsignŽ par E. WC devient alors: WC = {E ,F,G,A} © B A D E C F G E' Fig.4.10. Le nouveau graphe dÕacteurs. La prochaine crŽation dÕun acteur du type E au niveau de ce m•me acteur se fera ˆ partir de EÕ. Pendant ce temps, au niveau de lÕacteur B qui nÕa pas encore procŽdŽ ˆ une crŽation de ce type, celle-ci se fera toujours ˆ partir de la rŽfŽrence E quÕil a de ce m•me acteur. 166 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.2. Ramasse-miettes dans R.C.A.I A la mani•re du langage HAL [KIM92] [HOUCK92], qui dispose dÕune instruction spŽciale suicide, nous avons Žgalement introduit une instruction spŽciale de restitution de lÕespace inutilisŽ. Il sÕagit de lÕinstruction END. Un acteur qui souhaite libŽrer la cellule quÕil occupe le rŽalise par le biais de cette instruction. La finesse du grain de R.C.A.I. nous interdit le recours ˆ des solutions complexes. CÕest pour cette raison que nous avons ŽlaborŽ une technique basŽe sur la notion de compteur de rŽfŽrences. Cette stratŽgie est connue pour •tre simple ˆ implŽmenter et ˆ gŽrer dÕune mani•re distribuŽe (cf.¤3.3.2). CÕest cette solution que nous dŽveloppons dans ce qui suit. Initialement, les liens entre les acteurs sont bidirectionnels. CÕest ˆ dire quÕils expriment la notion de Òconna”tre un acteurÓ et Ò•tre connu dÕun acteurÓ. CÕest la raison pour laquelle les compteurs de rŽfŽrences sont doublŽs ˆ lÕorigine. A la crŽation dÕun nouvel acteur, son compteur de rŽfŽrences est automatiquement positionnŽ au cardinal de son ensemble de rŽfŽrences W dont il a hŽritŽ. Ce compteur est augmentŽ de un qui correspond au fait quÕil est connu par lÕacteur qui lÕa crŽŽ. De m•me, lÕacteur qui proc•de ˆ cette crŽation engendre un lien vers cet acteur, cÕest ˆ dire quÕil incrŽmente de un son propre compteur de rŽfŽrences. Le nouvel acteur communique ensuite ˆ chacun des ŽlŽments de son ensemble W sa propre crŽation. LorsquÕun un acteur re•oit lÕannonce de la crŽation dÕun autre acteur, il incrŽmente de un son propre compteur de rŽfŽrences, puisquÕil est rŽfŽrencŽ par ce dernier. A la rencontre de lÕinstruction END, lÕacteur informe lÕensemble des ŽlŽments de son espace de rŽfŽrences de son souhait de quitter le syst•me. Un acteur qui re•oit une annulation pour un lien dŽcrŽmente de un son compteur de rŽfŽrences (puisquÕil nÕest plus rŽfŽrencŽ par ce dernier). Au 167 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. m•me moment, lÕacteur qui envoie cette annulation dŽcrŽmente de un son compteur de rŽfŽrences. LÕacteur se met ensuite en attente de lÕannulation de tous les acteurs qui le rŽfŽrencent (mais qui ne font pas partie de son ensemble W). Ainsi, un acteur nÕest autorisŽ ˆ abandonner le syst•me que si son compteur de rŽfŽrences est ˆ zŽro. Pour illustrer ce mŽcanisme, nous allons considŽrer un exemple basŽ sur le graphe dÕacteurs suivant avec les ensembles de rŽfŽrences de chaque acteur (W) et le compteur de rŽfŽrences associŽ (å): Root W B A D C A {B,C,Root} B {A,D} C E F Ref. å 6 4 8 {A,D,E,F} D {B,C} 4 E {C} 2 F {C} 2 Supposons la crŽation, au niveau de lÕacteur C, dÕun nouvel acteur DÕ ˆ partir du prototype D. Il y a donc crŽation dÕun nouveau lien bidirectionnel (entre les acteurs C et DÕ). Root W B A D D' A {B,C,Root} B {A,D} C C E F {A,D,E,F} å 6 4 D' 9 D {B,C} 4 E {C} 2 F {C} 2 D' 168 Ref. Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. LÕacteur C informe lÕacteur D de la rupture de leur liaison et remplace cette rŽfŽrence par la nouvelle vers DÕ. Root W B A D C A {B,C,Root} B {A,D} C E D' F Ref. {A,D,E,F} å 6 4 D' 8 D {B,C} 3 E {C} 2 F {C} 2 D' Pendant ce temps, lÕacteur DÕ a hŽritŽ de lÕespace de rŽfŽrence de D. DÕ signale ensuite ˆ tous les ŽlŽments de W sa crŽation. Ce qui donne comme nouvelle reprŽsentation: Root W B A D C C D' A {B,C,Root} B {A,D} E F {A,D,E,F} Ref. å 6 5 9 D {B,C} 3 E {C} 2 F {C} 2 D' {B,C} 2+1 169 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Supposons maintenant que lÕacteur B a atteint la fin de son exŽcution (lÕinstruction END). Il signale donc aux ŽlŽments de son ensemble W sa fin et met ˆ jour son compteur de rŽfŽrences. Nous obtenons alors: Root W B A D C D' A {B,C,Root} B C E F {A,D,E,F} Ref. å 5 3 9 D {B,C} 2 E {C} 2 F {C} 2 D' {B,C} 3 LÕacteur B se met par la suite en attente de lÕautorisation de quitter le syst•me des acteurs A, D et DÕ (pour que son compteur de rŽfŽrences passe ˆ zŽro). 170 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.3. Limitation de lÕespace dÕadressage de R.C.A.I 4.3.1. Limites physiques de la machine R.C.A.I Tous les probl•mes qui ont ŽtŽ soulevŽs jusquÕˆ prŽsent (recherche de cellules libres, gestion des serveurs de code,...) sont accentuŽs par la rŽduction (physique) de lÕespace dÕadressage de la machine R.C.A.I. Rappelons que toute rŽfŽrence ˆ une cellule distante sÕŽcrit dÕapr•s le format suivant: Bit de signe Dx 0 Dy 3 4 7 Le dŽplacement, dans lÕune ou lÕautre direction (abscisse ou ordonnŽe), reste toujours de longueur bornŽe (parce que le nombre de bits est limitŽ). Dans R.C.A.I la borne est petite (±7 unitŽs) et le probl•me se pose avec beaucoup dÕacuitŽ. Il faut donc trouver un moyen pour augmenter la zone de recherche pour pouvoir offrir un plus grand espace de recherche pour chaque cellule, et accro”tre de ce fait la probabilitŽ de trouver une cellule libre (sÕil y en a au moins une). Dans le cas dÕun rŽseau statique, un tel adressage est efficace m•me si le nombre de bits utilisŽ semble rŽduit [PAYAN91] [RUBINI92]! 4.3.2. Notion de relais Pour Žlargir lÕespace d'adressage dans le rŽseau R.C.A.I plusieurs stratŽgies peuvent •tre explorŽes: ¥ la premi•re Žtant celle reposant sur un syst•me de routage performant en considŽrant un routage du type whormhole o• une adresse se prŽsente sur plusieurs mots successifs (comme cÕest le cas dans [FLAIG87]), ¥ l'autre solution est de considŽrer qu'il existe une entitŽ, physique ou logique, que nous appellerons par la suite relais, dont le r™le est de faire suivre un message entre deux cellules (ou plus) distantes. Dans un premier temps, nous avons considŽrŽ la premi•re solution qui consiste ˆ offrir un mŽcanisme dÕadressage dynamique du type whormhole, indŽpendant de la taille du rŽseau. 171 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Q Dn ¥¥¥ D1 D0 ±Dy ¥ ¥¥¥ ±Dy ±Dx ¥¥¥ ±Dx Fig.4.11. Utilisation dÕune adresse de taille variable. Dans cette approche, lÕacheminement de messages se fait pas ˆ pas, suivant une direction, puis lÕautre: suite de dŽplacements (dx 1, dx2, ... dxn) puis (dy1, dy2, ... dym). Chacune des entitŽs de dŽplacement dxi ou dyj est de longueur fixe k. La valeur de cette taille k est assez dŽlicate ˆ dŽterminer. A premi•re vue, un message arrivant ˆ une cellule a deux possibilitŽs: ¥ continuer son chemin par lÕune des trois sorties restantes, ¥ ou ne plus progresser si la cellule en question est la cellule destinataire du message. Quatre cas au total: un codage sur 2 bits est donc suffisant. NŽanmoins, en supposant une adresse sur n bits, le nombre de paquets du message peut n atteindre 22 - 2 paquets pour la description de la seule adresse (comme nous allons lÕexpliquer dans ce qui suit). DÕune fa•on gŽnŽrale, considŽrons un codage sur k bits par paquet qui spŽcifie une portion de lÕadresse, et une adresse ˆ coder sur n bits (n>k). Rappelons quÕune adresse dans notre contexte est dŽfinie par un couple (dx,d y). Chacune des deux parties est munie dÕun bit de signe. De plus, en considŽrant le cas le plus simple -sans optimisation du codage-, un paquet de k bits nŽcessite, en plus du dŽplacement, un bit de signe et un bit de direction (abscisse ou ordonnŽe). Pour dŽgager le nombre maximal de paquets, il faut considŽrer le rapport suivant (rapport de quantitŽ dÕinformation utile): Valeur_maximale_de_l©adresse Valeur_maximale_reprŽsentable_sur_un_paquet Ce qui donne Dxmax = Dymax = 172 n 2 2 - 1 Þ @ max = 2 * n 2 2 - 1 n = 22 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. La taille maximale du paquet ˆ laquelle nous retranchons les bits de signe et de direction est donnŽe par: 2k paquet max = - 2 DÕo• le rapport final: n 2 k 2 2 - 2 n = 2 2 - k + 2 o (1) Pour garantir quÕil nÕy a pas de perte dÕinformation lors du codage (lÕadresse ˆ reprŽsenter doit •tre de taille supŽrieure ˆ celle sur laquelle elle devra •tre reprŽsentŽe), nous devons satisfaire la r•gle suivante: n - k+ 2 > 0 2 dÕo• n > 2( k - 2) o (2) Lorsque n È k nous aurons une adresse de taille relativement grande dÕapr•s la relation (1). De plus, un tel mŽcanisme nŽcessiterait dÕinclure des drapeaux pour diffŽrencier aussi bien la t•te, que le corps et la queue dÕun message; chacune des parties correspond respectivement ˆ lÕadresse (et Žventuellement ˆ la taille du message), ˆ lÕinformation ˆ transmettre et ˆ la fin du message (dans le cas o• la taille du message nÕest pas fournie au prŽalable). La taille du message est variable, dÕo• une augmentation de la complexitŽ du routeur. Cette solution pose donc le probl•me de la borne supŽrieure sur la longueur totale du message. 173 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. La seconde solution consiste ˆ augmenter lÕespace dÕadressage en conservant une longueur fixe des messages. On introduit (statiquement ou dynamiquement) des entitŽs pour rŽaliser une continuitŽ dans lÕadressage entre deux cellules ŽloignŽes (figure4.12). L'avantage de cette mŽthode est de pouvoir garder le syst•me de routage actuel dont la particularitŽ principale est sa simplicitŽ et ses performances [RUBINI92]. Cellule relais Fig. 4.12. Notion de relais. 4.3.3. Introduction de relais pour lÕextension de l'adressage L'introduction de relais est effectuŽe lorsque les conditions suivantes sont satisfaites: dx ìïdmax ìdxmax y = í min & dy = í min ïî dy î dx Ces conditions signifient que nous sommes arrivŽ ˆ la limite de lÕadressage de la cellule. Ce qui, schŽmatiquement, peut •tre reproduit par la figure ci-apr•s: 174 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. R1 R4 dx min dx max dy max dy min R3 R2 Signalons d•s ˆ prŽsent qu'il existe deux types de relais: ¥ les relais introduits lors de la recherche d'une cellule libre, ¥ les relais dus ˆ la communication de rŽfŽrences d'une cellule ˆ une autre ("changement de coordonnŽes"). Dans le premier cas, lorsque nous arrivons aux fronti•res d'adressage d'une cellule, l'opŽration est reprise par une des quatre cellules formant cette limite, ˆ la demande de la cellule Žmettrice. De cette mani•re, nous pouvons, par programmation des relais, Žtendre l'espace d'adressage d'une cellule ˆ l'ensemble du rŽseau. R E L A I S Fig. 4.13. Position des relais par rapport ˆ une cellule. Comme nous lÕavons spŽcifiŽ auparavant, un relais est une entitŽ logique ou physique. DŽveloppons cette notion. 175 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.3.3.1. Cas d'un relais physique Dans le cas dÕun rŽseau statique, [PAYAN91] a proposŽ dÕutiliser des cellules particuli•res du rŽseau appelŽes relais. Dans ce cas, on rŽserve une cellule ˆ cet effet par pavŽ de 8x8 cellules. Ces cellules sont utilisŽes pour des adressages de longueur supŽrieure ˆ 7 (ou infŽrieure ˆ -7). Dans cette version statique de R.C.A.I, chaque bout de code est placŽ suivant la technique du recuit-simulŽ qui minimise la longueur entre les cellules les plus reliŽes. De ce fait, pour le peu de cellules qui nÕont pas pu •tre placŽes dans le voisinage immŽdiat des cellules auxquelles elles sont reliŽes, une zone tampon au niveau dÕune cellule particuli•re, connue ˆ lÕavance, sera utilisŽe chaque fois que ceci est nŽcessaire. Le nombre de telles cellules tampon a ŽtŽ ŽvaluŽ ˆ au plus2% du rŽseau entier [PAYAN91]. Une telle solution nÕest cependant pas envisageable dans le cas dÕun rŽseau dynamique. En effet, nous ne pouvons pas faire dÕa priori sur lÕŽvolution du syst•me: celui-ci est compl•tement imprŽvisible (par hypoth•se). Il faudrait donc dresser dÕune fa•on active des relais (lors de la recherche de cellules libres ou lors dÕun Žchange de rŽfŽrences). Par consŽquent, il nÕest pas possible de rŽserver des cellules au prŽalable ˆ cet usage: lÕŽvolution du syst•me pourrait ne jamais recourir aux relais. Ces cellules seraient alors tout simplement inexploitŽes, dÕo• une sous-utilisation du rŽseau. Finalement, nous avons optŽ pour une solution intermŽdiaire qui, tout en gardant les avantages de la simplicitŽ de la solution adoptŽe dans le cas du rŽseau statique, ne limite pas la taille de lÕespace dÕadressage. Dans cette solution, chaque cellule est dotŽe dÕune structure pour la retransmission des messages au niveau des cellules intermŽdiaires. Il sÕagit dÕune table ÒassociativeÓ: chaque entrŽe dans cette table contient lÕadresse de la cellule vers laquelle devra •tre rŽacheminŽ le message correspondant. Dans le cas le plus simple, chaque cellule ne peut •tre le relais que de quatre autres cellules au plus. Il suffit, pour sÕen convaincre, de considŽrer la figure4.13 dans le sens inverse. En ne considŽrant quÕun seul niveau dÕextension et quÕun seul relais autorisŽ par cellule, la table de correspondance est constituŽe de seulement quatre ŽlŽments. 176 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. T a m p o n Non Si Adresse Relais? d' E n t r Ž e T a m p o n Traitement normal suivant le type du message l o c a l Oui 0 1 Adresse 0 2 Adresse 2 Adresse 1 n-2 Adresse n-2 n-1 Adresse n-1 Vers les autres direction Fig. 4.14. Relais physique. Par contre, nous pouvons obtenir une imbrication de plusieurs niveaux de relais: chacun Žtend lÕespace dÕadressage du relais prŽcŽdent. De ce fait, dans le cas gŽnŽral, cette table prŽsente une taille de: table size = (4* n* m) ŽlŽmen n correspond au nombre de niveaux autorisŽs par cellule et m le nombre dÕentrŽes allouŽes au niveau de ce relais pour une m•me cellule (figure suivante). 0 1 ¥¥¥ m-1 0 1 ¥¥¥ m-1 R0 R1 Niveau 1 de relais Niveau 2 de relais R2 177 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.3.3.2. Cas d'un relais logique Dans cette autre approche, cÕest une entitŽ logique qui prend en charge lÕextension de lÕespace dÕadressage. Cette entitŽ est un acteur particulier, appelŽ acteur relais. Tout comme dans lÕapproche dŽveloppŽe auparavant, lorsque les conditions de dŽpassement de la capacitŽ dÕadressage des cellules sont satisfaites, une interruption sera gŽnŽrŽe au niveau de la cellule en question. LÕacteur relais prend alors la main afin de rŽserver une entrŽe pour cette demande, apr•s approbation par la cellule source (figure4.15). Interruption pour dŽpassement de capacitŽ d'adressage Au niveau d'un routeur ¶ de · Offre relais Acteur Relais Acteur Source ¸ Demande/Annulation de Relais Fig. 4.15. Relais logique. LÕannulation dÕun relais peut survenir lorsquÕune cellule, qui a demandŽ une cellule libre, a dŽjˆ re•u une rŽponse favorable ˆ sa requ•te de la part dÕune autre cellule. 178 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.3.3.3. DiffŽrence entre les deux types de relais La diffŽrence entre les deux approches rel•ve de lÕŽternel probl•me de la diffŽrence entre une fonction intŽgrŽe rapide, mais figŽe, et une fonction logicielle plus lente, mais flexible. LÕavantage des relais physiques est la rapiditŽ avec laquelle seront converties les adresses relais en adresses physiques. De plus, ce mŽcanisme reste transparent vis ˆ vis de lÕapplication en cours dÕexŽcution. Il nÕy a pas dÕinterruption des processus en cours, comme cÕest le cas dans la seconde solution, pour la traduction des adresses. LÕintŽr•t des relais logiques est leur extensibilitŽ. DÕun point de vue conceptuel, cette solution ne prŽsente aucune limite (autre que la mŽmoire disponible dans le rŽseau). Comme nous lÕavons exposŽ plus haut, chaque cellule ne peut •tre que le relais de quatre autres cellules. De ce fait, chaque relais logique de base peut •tre considŽrŽ comme prŽsentant la structure suivante: Acteur Relais Relais 0 Relais 1 Adresse Relais Relais 2 Adresse convertie Relais 3 Prochain Relais Fig. 4.16. Structure dÕun relais logique multi-niveaux. A chaque demande dÕun niveau de relais supplŽmentaire, nous procŽdons ˆ la crŽation dÕun nouvel acteur. De cette mani•re, il y a extension dÕun niveau pour toutes les cellules concernŽes. Les cellules qui nŽcessitent par la suite un nouveau relais font toujours appel ˆ la m•me cellule. 179 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Trois cas de figure se prŽsentent lorsquÕune cellule re•oit une demande de relais: ¥ la cellule dispose localement dÕune entrŽe libre pour rŽsoudre ce probl•me dÕadressage, ¥ la cellule ne dispose pas dÕune entrŽe, dans ces conditions la cellule crŽe un nouvel acteur relais qui prend en charge ce litige, ¥ finalement, la cellule ne dispose pas localement dÕune entrŽe, mais peut dŽlŽguer ce conflit ˆ un autre acteur relais (quÕelle aura crŽŽ dans une Žtape antŽrieure), de niveau supŽrieur qui devra prendre en compte ce conflit. Ce dernier cas est rŽcursif et aboutit ˆ lÕun des deux points prŽcŽdents. Act 0 Act 2 Act 1 Act3 Act 5 Act 4 Fig. 4.17. Structure ˆ six niveaux de relais logique pour une m•me cellule Il est indŽniable que lÕapproche par des relais logiques est la plus adaptŽe pour une programmation aisŽe au niveau le plus haut et une meilleure exploitation des ressources du syst•me. Cette solution est tr•s flexible et peut Žvoluer avec les spŽcifications de la machine actuelle. Cependant, dans lÕŽtat actuel de la machine, la solution retenue est celle basŽe sur les relais physiques avec un seul niveau supplŽmentaire dÕadressage. Cette limitation, comme nous lÕavons dŽjˆ vu, offre, tout de m•me, un espace dÕadressage relativement important pour chaque cellule. La solution faisant appel ˆ des relais logiques ne peut •tre mise en Ïuvre que lorsquÕun langage dÕacteur aura ŽtŽ dŽfini pour notre machine (puisque faisant partie intŽgrante de ce mod•le). 180 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. 4.3.3.4. Relation entre relais et recherche de cellules libres Les relais, surtout les relais logiques, ne prŽsentent a priori aucune limite pour lÕextension de lÕespace dÕadressage de chaque cellule ˆ lÕensemble du rŽseau. Cependant, il nÕest pas rŽaliste dÕaugmenter cet espace au delˆ dÕun ou de deux niveaux. En effet, lÕaccroissement du nombre de relais par cellule augmenterait dÕune mani•re drastique ˆ chaque niveau supplŽmentaire. La figure4.18 fournit le nombre de cellules adressables (au maximum) ˆ partir dÕune cellule en fonction du nombre de transitions possibles dans une direction (notŽe k dans la figure). Avec aucun relais, la valeur de k est 7 et le nombre de cellules potentiellement adressables est de 900 cellules. Pour un niveau, la valeur est de 14 et le nombre de cellules atteint la valeur de 3364 cellules. A partir du second niveau de relais on dŽpasse les 7000 cellules adressables. 5 3,5 10 3 105 2,5 105 Nombre de cellules 2 105 1,5 105 1 105 50000 0 0 50 100 150 Valeur de k Fig. 4.18. Nombre de cellules adressables en fonction du nombre de niveaux de relais possibles. Pour revenir ˆ la procŽdure de recherche de cellules libres, il est essentiel de limiter lÕexplosion du nombre de messages de recherche dans le rŽseau31. 31 Nous avons dŽjˆ abordŽ ce sujet au paragraphe 3.2.1.2.1. Nous le complŽtons ˆ ce niveau apr•s avoir introduit la notion de relais. 181 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Comme il vient dÕ•tre exposŽ, un relais est crŽŽ ˆ la demande de la cellule Žmettrice. A chaque relais supplŽmentaire correspond un pavŽ (potentiel) additionnel de recherche de 254 cellules. A la demande de la mise en place dÕun relais, une cellule ˆ la recherche dÕune cellule libre doit savoir ˆ quel moment autoriser cette opŽration. En effet, si la cellule, d•s la rŽception de ce message, rŽpond positivement, on risque dÕŽtendre inutilement la recherche ˆ un niveau supŽrieur, alors quÕau niveau courant on nÕest pas encore sžr quÕil nÕexiste pas de cellules libres. De ce fait, toutes les rŽponses aux demandes de mise en place de relais sont mises en attente, jusquÕˆ la rŽception de la rŽponse des quatre cellules Re la is extr•mes (figure4.19). Ces rŽponses sont soit des demandes de mise en Ïuvre de relais soit des signaux dÕŽchec de recherche (lorsquÕune cellule se trouve au bord du rŽseau). c he c E Fig.4.19. Protocole dÕŽtablissement de relais. Nous pouvons imaginer plusieurs stratŽgies ˆ ce niveau. Des stratŽgies de prŽvention, comme celle que nous venons de prŽsenter, ou des stratŽgies de guŽrison. Dans ce dernier cas, une cellule qui re•oit une demande pour la crŽation dÕun relais y rŽpond positivement, sans attendre. A la rŽception dÕun message lui signalant la prŽsence dÕune cellule libre, elle devra mettre en Ïuvre un mŽcanisme pour intercepter et annuler les demandes en cours. Pour cela, il faut prŽvoir une prioritŽ entre les diffŽrents messages pour que les messages dÕannulation puisse progresser plus rapidement que les messages de demande de cellules libres. 182 Chapitre 4 - Autres probl•mes liŽs aux limitations de R.C.A.I. Cependant, nous penchons beaucoup plus pour les mŽthodes de prŽvention qui, comme dans ce cas, nŽcessitent moins de ressources. Elles reposent sur des protocoles plus simples ˆ mettre en place. 183 C HAPITRE 5 E XPƒRIMENTATION & ƒVALUATIONS 5. EXPƒRIMENTATION ET ƒVALUATIONS Bon nombre de raisons ont justifiŽ le temps non nŽgligeable consacrŽ ˆ la rŽalisation dÕun simulateur de bas niveau pour lÕŽvaluation des performances des solutions proposŽes. Parmi ces raisons, nous en citons les plus importantes: ¥ Le caract•re imprŽvisible du comportement des programmes parall•les rend extr•mement difficile lÕŽlaboration de mod•les suffisamment fiables pour se passer de simulateurs. Les Žquipes qui travaillent sur lÕŽvaluation des machines parall•les ont mesurŽ cette difficultŽ [TRON94] [KITAJIMA93]. Il para”t tout particuli•rement dŽlicat dÕŽtablir un mod•le pour les communications dans un rŽseau ÒrŽelÓ o• les liens de communication ne sont pas tous sollicitŽs de la m•me mani•re aux m•mes instants (charges diffŽrentes). ¥ Le choix entre plusieurs options dÕimplantation, que ce soit au niveau du jeu dÕinstructions quÕau niveau du rŽseau de communication, nŽcessite dÕen Žvaluer les performances sur des exemples ÒrŽelsÓ. ¥ La mise en Žvidence de phŽnom•nes tr•s fins ou difficilement prŽvisibles nŽcessite une simulation fine. Pour illustrer ce dernier point, nous pouvons mentionner le comportement du rŽseau par rapport au protocole de recherche de cellules libres. Dans certaines conditions, ce protocole peut induire des cas dÕinterblocage. Rappelons que le message de recherche de cellule est composŽ de quatre paquets successifs. Dans une premi•re version du simulateur, on rŽalisait un recouvrement entre lÕenvoi de la requ•te et la rŽponse ˆ celle-ci, Žmise d•s rŽception du premier paquet (figure5.1). RŽponse ˆ une recherche ¥¥¥ ¥¥¥ ¥¥¥ ¥¥¥ Cellule libre Recherche de cellule Fig.5.1. Recouvrement entre une demande de cellule et sa rŽponse. 187 Chapitre 5 - ExpŽrimentation et Žvaluations Mais la simulation fine a permis de montrer que, lors dÕun Žchange entre deux cellules, il pouvait se produire le cas dÕinterblocage de la figure5.2. Messages liŽs par un quelconque traitement Message bloquŽ Il faut consomme ce message pour libŽrer le canal Fig.5.2. Cas dÕinterblocage. Cette constatation nous a conduits ˆ considŽrer ce protocole diffŽremment: tout message dÕune requ•te est dÕabord consommŽ (extrait du rŽseau de communication) avant dÕy rŽpondre. Ces raisons nous ont donc poussŽs ˆ rŽaliser un simulateur fondŽ sur le cycle de base de la machine cible. La difficultŽ principale rŽside alors dans le dŽverminage de programmes parall•les. 5.1. LÕenvironnement de simulation LÕenvironnement de simulation est construit autour de trois modules (figure5.3): ¥ un assembleur pour la description du code des diffŽrents algorithmes, ¥ un Žditeur de liens , et ¥ le simulateur proprement dit. Le temps qui nous Žtait imparti ne nous a pas permis dÕŽlaborer un compilateur pour un langage dÕacteur du type CANTOR (cf.¤2.3). Dans cette premi•re expŽrimentation, nous avons dŽfini un assembleur pour lÕŽcriture des programmes (voir annexeII). Nous sommes cependant tout ˆ fait conscients de la difficultŽ que reprŽsente la programmation ˆ un niveau aussi bas. 188 Chapitre 5 - ExpŽrimentation et Žvaluations ; Code en assembleur ; Code en assembleur )))))))ORG))0 ; Code en assembleur )))))))ORG))0 )))))))DS)))2 )))))))ORG))0 )))))))DS)))2 Canal:))DC )) 2:1 )))))))DS)))2 Canal:))DC )) 2:1 Adr:))))DC)))Etiq Canal:))DC )) 2:1 Adr:))))DC)))Etiq Valeur:)DC)))$A1 Adr:))))DC)))Etiq Valeur:)DC)))$A1 )))))))LDA))Valeur Valeur:)DC)))$A1 )))))))LDA))Valeur )))))))LDA))Valeur ¥¥¥ ¥¥¥ ¥¥¥ ;Code exŽcutable 8501 8 0 8 3 14 Canal Adr Valeur 0 0 4 -1 0 12 ¥¥¥ Assembleur (RapAs) ; Code objet ; Code objet 1 ; Code objet 1 0 0 1 0 0 0 0 3 3 ))Canal 3 2 0 ))Canal 2 0 )) Adr ))Canal 3 12 0 )) Adr 3 1 Valeur )) Adr 4 3 2 1 Valeur 4 2 Valeur 4 2 ¥¥¥ ¥¥¥ ¥¥¥ Editeur de liens (RapLink) Vers la machine R.C.A.I. Fig.5.3. SchŽma dÕexŽcution du processus de simulation. 189 Chapitre 5 - ExpŽrimentation et Žvaluations LÕassembleur fournit du code intermŽdiaire ainsi que la table des symboles pour chaque fichier source spŽcifiŽ en entrŽe de ce module. LÕŽditeur de liens rŽsout les rŽfŽrences croisŽes extraites ˆ partir de ces tables. De plus, en combinant tous les fichiers intermŽdiaires engendrŽs par lÕassembleur dans une premi•re Žtape, lÕŽditeur de liens gŽn•re un fichier unique de code exŽcutable. Les instructions sont rŽparties suivant leur fonction (calcul, communication, recherche de cellule libre...). Chaque groupe dÕinstructions dŽtermine, ˆ lÕexŽcution, la nature de lÕactivitŽ de la cellule qui exŽcute une des instructions de ce groupe. 5.1.1. Le simulateur Le processus de simulation est dŽcoupŽ en trois phases: ¥ le chargement du code et la spŽcification du fichier des donnŽes, ¥ le param•trage de la session courante, et finalement ¥ lÕexŽcution du code chargŽ et la prise de mesures suivant les indications de lÕutilisateur. 5.1.1.1. Chargement du code A la demande de lÕutilisateur, le fichier du code objet est chargŽ suivant les spŽcifications contenues dans ce dernier. Il faut signaler que si une m•me position mŽmoire, au niveau dÕune cellule donnŽe, est rŽfŽrencŽe ˆ plusieurs reprises dans le fichier, cÕest la derni•re valeur lue qui est conservŽe (les autres ayant ŽtŽ ŽcrasŽes). LorsquÕune cellule est dŽclarŽe active, son registre PC est initialisŽ ˆ la valeur indiquŽe par la m•me instruction (voir le listing de la figure5.6). Les autres cellules, les cellules inactives, sont marquŽes libres. 5.1.1.2. Param•trage dÕune session Le param•trage dÕune session consiste ˆ spŽcifier principalement trois valeurs: ¥ le temps limite du routeur, au-delˆ duquel il faut retirer du rŽseau le message ayant provoquŽ le dŽbordement du compteur et le rŽexpŽdier ultŽrieurement, ¥ le temps limite de la recherche, au bout duquel on relance la recherche dÕune cellule libre, ¥ le nombre de relances de la recherche de cellules libres. 5.1.1.3. ExŽcution et extraction de mesures 190 Chapitre 5 - ExpŽrimentation et Žvaluations Une fois le code chargŽ, on peut exŽcuter le programme selon trois modes: ¥ pas ˆ pas, ¥ durant un certain nombre de cycles, ¥ ou dÕune mani•re continue. Pour suivre le dŽroulement dÕune exŽcution, nous proposons plusieurs vues: ¥ une vue de lÕactivitŽ du rŽseau, ¥ une vue du rŽseau de communication et des messages qui y transitent, ¥ une trace dÕune ou plusieurs cellules, ¥ une vue des registres dÕun ensemble de cellules. LÕextraction de mesures est rŽalisŽe ˆ la demande de lÕutilisateur sur la pŽriode et suivant lÕintervalle dÕobservation quÕil fixe. On enregistre lÕactivitŽ moyenne par zone dÕactivitŽ pour lÕensemble du rŽseau (ˆ chaque intervalle dÕobservation spŽcifiŽ). 191 Chapitre 5 - ExpŽrimentation et Žvaluations 5.2. Les benchmarks Pour Žvaluer les performances des solutions proposŽes dans ce manuscrit, nous avons retenu les exemples suivants: ¥ le crible dÕErathost•ne, ¥ le tri dÕune suite dÕentiers, ¥ et le calcul de la suite de Fibonacci. 5.2.1. Crible dÕErathost•ne Le crible dÕErathost•ne32 permet dÕobtenir lÕensemble des nombres premiers compris entre 2 et une borne fournie par lÕutilisateur. Le principe de cet algorithme est tr•s simple. Un acteur spŽcifique, acteur racine, gŽn•re lÕensemble des entiers compris entre 2 et la borne n et les fait parvenir au premier maillon de la cha”ne (figure5.4). GŽnŽrateur Acteur Racine 2 3 ¥¥¥ n Acteur Erathos Fig.5.4. Crible dÕErathost•ne. LorsquÕun acteur re•oit une valeur, il la divise par le nombre premier quÕil reprŽsente. Si celle-ci nÕest pas multiple du nombre premier en question, elle est renvoyŽe vers le prochain maillon de la cha”ne. Par contre, lorsquÕune valeur a ŽtŽ reconnue multiple du nombre premier courant, elle est dŽtruite. Dans le cas o• lÕacteur Erathos courant est le bout de la cha”ne, il proc•de ˆ une recherche de cellule libre pour sÕy dupliquer. Apr•s quoi, il communique ˆ ce nouvel acteur le nombre premier qui vient dÕ•tre trouvŽ. Pour signaler la fin du traitement, le gŽnŽrateur envoie la valeur -1 au premier ŽlŽment du crible. Chaque acteur qui re•oit celle-ci va la renvoyer au prochain acteur avant de se suicider. Apr•s un suicide, la cellule est libre et peut donc •tre rŽutilisŽe par dÕautres acteurs du crible. La figureII.1 (de lÕannexeII) reprend le code assembleur de lÕacteur Erathos. Le gŽnŽrateur de nombres (acteur racine) produit les entiers entre 2 et 255. Cet exemple a ŽtŽ testŽ sur un rŽseau de 8 x3 cellules uniquement. Les 32Le code source de cet exemple a ŽtŽ prŽsentŽ dans le paragraphe 2.3.5. 192 Chapitre 5 - ExpŽrimentation et Žvaluations cellules libŽrŽes sont rŽutilisŽes par dÕautres acteurs Erathos. De plus, cÕest le rŽseau de communication qui sert de tampon pour lÕabsorption des entiers gŽnŽrŽs par lÕacteur racine. Les communications sont, dans le cas du mod•le dynamique, compl•tement asynchrones. La figure5.5 retrace la surcharge ( overhead) occasionnŽ par le dŽplacement de code dans cet exemple. Nous remarquons que ces cožts supplŽmentaires pour la gestion de la distribution de code sont en de•ˆ des 4,5% de lÕactivitŽ totale du rŽseau. Ceci est dž essentiellement au bon recouvrement entre le calcul proprement dit du crible dÕErathost•ne et celui 4,50% 4,00% 3,50% 3,00% 2,50% 2,00% 1,50% 1,00% 0,50% 0,00% MOVE 93000 84400 75800 67200 58600 50000 41400 34500 30200 25900 21600 17300 13000 8700 4400 FIND 100 % de la copie de code vers dÕautres cellules. Cycles Fig.5.5. ActivitŽ des instructions de recherche de cellules libres et de dŽplacement de code. Le chargement de code du rŽseau dure ˆ peu pr•s 28000 cycles dans une premi•re phase (figure5.6). LÕactivitŽ du rŽseau commence ˆ baisser ˆ partir de ce moment. Cette seconde phase correspond au vidage du rŽseau (sortie des rŽsultats). 193 Chapitre 5 - ExpŽrimentation et Žvaluations 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% SEND COMPUTE 93200 85600 78000 70400 62800 55200 47600 40000 34300 30500 26700 22900 19100 15300 7700 11500 3900 100 GET Cycles Fig.5.6. ActivitŽ des instructions de calcul et de communication. 5.2.2. Tri dÕentiers Il nous fallait aborder cet aspect algorithmique du fait que les algorithmes de tri sont souvent citŽs dans les diffŽrents benchmarks. Cependant, vu la nature de notre mod•le dÕexŽcution, nous ne pouvons pas utiliser les algorithmes de tri basŽs sur les rŽseaux (statiques) de tri [QUINN87] ou les algorithmes basŽs sur la circulation de donnŽes uniquement (le code Žtant supposŽ dŽjˆ prŽsent sur place). Nous avons alors mis en Ïuvre un algorithme simple, qui suit le m•me schŽma dÕexŽcution que le prŽcŽdent (figure5.7). Chaque acteur correspond ˆ un entier. LorsquÕun acteur re•oit un entier il le compare ˆ lui-m•me. Si celuici est plus grand il le renvoie au prochain. Sinon, lÕacteur devient ce nouvel entier et fait parvenir au prochain acteur son ancienne valeur. Entiers lus ˆ partir de l'H™te 0 n1 n2 ¥¥¥ nk Fig.5.7. Tri dÕentiers. Dans le cas o• lÕacteur en cours de traitement est en bout de cha”ne, il proc•de ˆ la recherche dÕune cellule libre dans une premi•re phase. Puis, il sÕy duplique et lui communique la valeur adŽquate. De la m•me mani•re que prŽcŽdemment, il existe une valeur spŽciale (-1) qui provoque la terminaison des acteurs inutilisŽs. Dans cet exemple, nous trions 150 entiers, sur un rŽseau de 8x8 cellules. Chaque cellule prend en charge un seul entier. 194 Chapitre 5 - ExpŽrimentation et Žvaluations Le cožt du dŽplacement de code dans cet exemple reste similaire au prŽcŽdent pour les m•mes raisons ŽvoquŽes plus haut (figure5.8). 2,50% ActivitŽ 2,00% 1,50% MOVE 1,00% FIND 0,50% 3,13E+05 2,99E+05 2,86E+05 2,72E+05 2,59E+05 2,45E+05 2,31E+05 2,18E+05 2,04E+05 1,91E+05 1,77E+05 1,63E+05 1,50E+05 1,36E+05 1,23E+05 95400 1,09E+05 81800 68200 54600 41000 27400 200 13800 0,00% Cycles Fig.5.8. ActivitŽ des instructions de recherche de cellules libres et de dŽplacement de code. LÕimportance de lÕactivitŽ des instructions dÕenvoi de messages est la consŽquence des arr•ts nŽcessaires en bout de cha”ne pour laisser le temps ˆ ce dernier de copier le code correspondant au nouvel ŽlŽment vers sa destination. A partir du moment o• le nombre de ces ŽlŽments est suffisant pour absorber tous les messages en entrŽe (vers le cycle 72000), cette activitŽ commence ˆ dŽcliner. Aussi bien dans le cas du crible dÕErathost•ne que celui du tri, le cožt dž au dŽplacement de code reste stable. En effet, comme nous lÕavons signalŽ auparavant, il nÕy a quÕune cellule ˆ tout moment dans le rŽseau qui rŽalise lÕopŽration de copie de code. 195 Chapitre 5 - ExpŽrimentation et Žvaluations 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% GET SEND COMPUTE 3,12E+05 2,95E+05 2,79E+05 2,46E+05 2,63E+05 2,30E+05 2,13E+05 1,81E+05 1,97E+05 1,64E+05 1,48E+05 1,31E+05 98600 1,15E+05 65800 82200 49400 33000 200 16600 10,00% 0,00% Cycles Fig.5.9. ActivitŽ des instructions de calcul et de communication. Nous constatons que pour ces deux exemples tr•s simples, le calcul ne reprŽsente quÕune mince portion de lÕactivitŽ totale des processeurs, et que les communications sont plus importantes 33 . Cependant, les opŽrations dÕallocation consomment peu de temps. Le comportement de ces deux algorithmes est peu dynamique: il y a crŽation dÕacteurs au dŽbut, ensuite davantage de communications. Toutefois, m•me dans de telles configurations, lÕallocation dynamique de processeurs prŽsente un net avantage par rapport ˆ lÕallocation statique: le calcul se dŽveloppe de lui-m•me ˆ lÕintŽrieur du rŽseau de cellules, sans nŽcessiter le chargement prŽalable de toutes les cellules (cf.¤5.2.4). Nous allons maintenant Žtudier un exemple dont le comportement en terme de crŽations dÕacteurs est beaucoup plus dynamique. 33Ceci est dž au principe m•me de ces algorithmes qui font circuler des donnŽes (donc des messages) pour, dans un premier cas soit Žliminer ces nombres soit les abouter en fin de cha”ne comme nouveaux nombres premiers, et dans un autre cas, permuter des nombres afin de les classer. 196 Chapitre 5 - ExpŽrimentation et Žvaluations 5.2.3. Calcul de la suite de Fibonacci Contrairement aux deux exemples prŽcŽdents, le calcul de la suite de Fibonacci fournit un arbre binaire (figure5.10). Il y a donc concurrence pour la recherche de cellules libres. La formule de calcul de la suite de Fibonacci est: ìFib(0) = 0 ï íFib(1) = 1 ïFib(n) = Fib(n- 1)+ Fib(n- 2) î Chaque acteur Fib qui re•oit une valeur (supŽrieure ˆ 2) crŽe deux nouveaux acteurs Fib auxquels il communique les valeurs appropriŽes. Il se met ensuite en attente des rŽsultats avant de les renvoyer ˆ celui qui lÕa crŽŽ. 3 4 1 2 3 1 2 1 2 1 1 1 1 0 0 0 1 0 Fig.5.10. Calcul de la suite de Fibonacci (pour n = 4). Contrairement aux deux exemples prŽcŽdents, le nombre dÕacteurs ˆ la recherche de cellules libres est variable et assez important. Par consŽquent, lÕactivitŽ correspondante est normalement plus importante. Dans le cas du calcul de la suite de Fibonacci de 9, sur un rŽseau de 10x10 cellules, cette activitŽ prŽsente un maximum de 12% (figure5.11). Cependant, cette activitŽ nÕest que de 5,07% en moyenne de lÕactivitŽ totale du rŽseau. Elle reste donc relativement faible. 197 Chapitre 5 - ExpŽrimentation et Žvaluations FIND MOVE 0,14 0,12 x100 (%) 0,1 0,08 0,06 0,04 0,02 0 -0,02 0 1 10 4 2 10 4 3 10 4 4 10 4 Cycles 5 10 4 6 10 4 Fig.5.11. ActivitŽ des instructions de recherche de cellules libres et de dŽplacement de code (Fib (9) dans un rŽseau 10x10 cellules). En revanche, lÕexŽcution de cet algorithme sur des rŽseaux de plus petite taille peut nŽcessiter plus de recherche (figure5.12). En effet, une m•me quantitŽ dÕactivitŽ sur des rŽseaux de dimensions diffŽrentes induit une activitŽ relative (par rapport ˆ la taille du rŽseau en question) diffŽrente. FIND MOVE FIND 0,25 0,2 0,08 x100 (%) 0,15 x100 (%) MOVE 0,1 0,1 0,05 0,06 0,04 0,02 0 0 -0,02 -0,05 0 5000 1 10 4 1,5 104 2 10 4 2,5 104 3 10 4 3,5 104 Cycles 0 1 10 4 2 10 4 3 10 4 4 10 4 5 10 4 6 10 4 Cycles (a) (b) Fig.5.12. ActivitŽ des instructions de recherche de cellules libres et de dŽplacement de code: (a) Fib(8) sur un rŽseau de 10 x10 cellules, (b) Fib(8) sur un rŽseau de 7x5 cellules. 198 Chapitre 5 - ExpŽrimentation et Žvaluations Dans la figure5.13, le nombre de processus en attente de messages est relativement important. Cela est dž au schŽma dÕexŽcution de la suite de Fibonacci. Chaque acteur qui crŽe deux nouveaux acteurs se met automatiquement en attente des rŽsultats. COMPUTE SEND GET 0,25 0,2 x100 (%) 0,15 0,1 0,05 0 -0,05 0 1 10 4 2 10 4 3 10 4 4 10 4 Cycles 5 10 4 6 10 4 Fig.5.13. ActivitŽ des instructions de calcul et de communication. 199 Chapitre 5 - ExpŽrimentation et Žvaluations 5.2.4. Comparaison dynamique des mod•les statique et Un des objectifs de cette th•se a ŽtŽ de rŽduire le temps nŽcessaire au chargement de code. Nous allons mettre en Žvidence ce gain en considŽrant les exemples du tri de 150 entiers et du calcul de la suite de Fibonacci de 8. Les E/S entre le rŽseau et le syst•me h™te sont rŽalisŽes au taux de 500 Ko/s. Le point le plus important ˆ noter est celui du nombre de cellules nŽcessaires ˆ lÕŽvaluation de ces fonctions. Dans le cas statique, il aurait fallu 67 cellules pour le calcul de la suite de Fibonacci de 8 (en suivant le dŽveloppement strict de cette fonction). Dans la version dynamique, nous nÕen utilisons que 35. Nous rŽalisons donc une Žconomie non nŽgligeable de ressources gr‰ce ˆ la rŽutilisation de cellules qui ne servent plus (fonction de ramasse-miettes). De plus, dans les deux exemples, nous ne chargeons que le code dÕune seule cellule. Le dŽveloppement de chaque fonction, par la suite, gŽn•re le nombre nŽcessaire dÕacteurs pour lÕŽvaluation de la fonction correspondante. De ce fait, le temps de chargement du code et de son exŽcution dans la version dynamique est tr•s infŽrieur ˆ celui nŽcessaire uniquement au chargement du code correspondant dans la version statique (table5.1). Code ChargŽ I/O (500 K/s) Dyn. Stat. Tri d'entiers 1 cellule 0,5ms 82ms (8x8 cells) 31ms Calcul Fibonacci1 cellule 0,5ms 40ms (Fib:8, 7x5 cells) 3,7ms Nombre de Overhead du Cellules Cellules dŽplacement utiles utilisŽes de code (Stat.) (Dyn.) (en moyenne 64 (43%) 150 1,5% 35 (52%) 67 11,3% Table5.1. Comparaison des mod•les dynamique et statique 34. Pour terminer, nous pouvons remarquer que le cožt supplŽmentaire occasionnŽ par le dŽplacement de code reste relativement faible par rapport ˆ lÕactivitŽ totale du rŽseau. 34 Les parties grisŽes reprŽsentent le temps dÕexŽcution de lÕalgorithme dans la version dynamique. 200 Chapitre 5 - ExpŽrimentation et Žvaluations 5.3. Quelques rŽsultats globaux sur des points dŽlicats Dans cette section, nous mettons en Žvidence la relation qui existe entre la frŽquence du processeur de communication (le routeur) et celle du processeur de calcul. La version statique de R.C.A.I., dont un prototype a ŽtŽ rŽalisŽ par S.M.KARABERNOU [KARABERNOU93], fixait la frŽquence dÕhorloge du processeur ˆ 10MHz et celle du routeur ˆ environ 20MHz. Les Žvaluations menŽes par P.RUBINI [RUBINI92] ont montrŽ que le rŽseau Žtait suffisamment performant et quÕil nÕŽtait pas nŽcessaire dÕen augmenter les performances. La batterie de simulations qui suit va nous permettre de montrer que ceci nÕest plus valable dans la version dynamique. Pour cela, nous considŽrons le cas plus gŽnŽral des benchmarks utilisŽs dans ce chapitre, ˆ savoir celui du calcul de la suite de Fibonacci. En effet, comme nous lÕavons vu auparavant, cette fonction gŽn•re un arbre binaire ˆ lÕexŽcution. Il y a donc plusieurs cellules ˆ la fois qui concourent pour la recherche de cellules libres. 60000 Temps d'exŽcution (cycles) 55000 50000 45000 40000 35000 30000 25000 Freq_17 Freq_11 Freq_5 Freq_4 Freq_3 Freq_2 20000 Fig.5.14. Comparaison des performances suivant le rapport des frŽquences du routeur et du processeur. Nous calculons la suite de Fibonacci pour 9 sur un rŽseau de 16 x 16 cellules. Ce calcul gŽn•re 109 ŽlŽments. Nous avons rŽalisŽ les simulations pour des frŽquences du routeur 2, 3, 4, 5, 11 et enfin 17 fois plus rapide que celle de lÕunitŽ de calcul (processeur). 201 Chapitre 5 - ExpŽrimentation et Žvaluations Nous remarquons quÕil y a un gain de 36,22 % de temps dÕexŽcution entre une frŽquence double (la frŽquence actuelle du routeur du prototype de la version statique) et une frŽquence triple (figure5.14). Il y a donc tout intŽr•t ˆ ce que le routeur soit beaucoup plus performant que le processeur de calcul. En effet, le nombre important de messages de mouvement de code entre les cellules nŽcessite que cette opŽration soit rŽalisŽe en un temps minimal pour ne pas pŽnaliser le calcul sur les processeurs. Cependant, comme il ressort de la figure5.14, il est inutile que cette frŽquence aille au-delˆ du quintuple (ce qui correspond ˆ une frŽquence du routeur de 50MHz). Le gain apr•s cette valeur est ˆ lÕŽvidence beaucoup moins important. Cependant, nous devons vŽrifier que ces rŽsultats restent valables dans le cas du transfert dÕun nombre diffŽrent de messages de code. Pour cela nous considŽrons le calcul de la suite de Fibonacci de 8 sur un rŽseau de 16x16 cellules. Nous prenons en compte successivement les tailles de 125, 150, 200 et 250 messages de code ˆ transfŽrer ˆ chaque nouvelle crŽation dÕacteurs (figure5.15). M_125 M_150 M_200 M_250 90000 Temps d'exŽcution (cycles) 80000 70000 60000 50000 40000 30000 20000 0 2 4 6 8 FrŽquences 10 12 Fig.5.15. Temps dÕexŽcution en fonction de la frŽquence du routeur et du nombre de messages (de code) transfŽrŽs. Ce dernier graphique confirme bien quÕen augmentant les performances du routeur nous arrivons ˆ amŽliorer nettement celles du rŽseau. De la m•me mani•re que dans la figure5.14, le seuil du gain de performances se situe bien entre une frŽquence quadruple et une frŽquence quintuple. 202 Chapitre 5 - ExpŽrimentation et Žvaluations Eu Žgard ˆ ces diffŽrentes frŽquences du routeur, nous allons voir la rŽpartition des messages de donnŽes, de recherche de cellules libres et de duplication de code. Nous donnons dans un premier temps cette rŽpartition pour une frŽquence double, cÕest ˆ dire la m•me frŽquence que celle du routeur de la version statique, pour le dŽplacement de 125 messages de code ˆ la fois (par acteur crŽŽ). Data Find Move 80 Messages 60 40 20 0 -20 -1 10 4 0 1 10 4 2 10 4 3 10 4 Cycles 4 10 4 5 10 4 Fig.5.16. RŽpartition des diffŽrents messages. Nous voyons clairement sur la figure5.16 que les messages de duplication de code sont prŽpondŽrants (cf.table5.2). Type message DonnŽes Code Recherche Total Observation 116 DonnŽes & rŽsultats 5040 (125+1)*40 acteurs 389 9,49 messages en moyenne par acteur Table5.2. RŽpartition des diffŽrents types de messages pour lÕexŽcution de la suite de Fibonacci de 8 sur un rŽseau de 16x16 cellules. Par consŽquent, dans toutes les simulations qui suivent, nous ne reprenons que les messages de dŽplacement de code pour la comparaison des performances suivant des frŽquences diffŽrentes du routeur (figures5.17, 5.18, 5.19 & 5.20). Toutes ces figures montrent quÕˆ chaque frŽquence supŽrieure, il y a une plus grande concentration de messages sur un m•me intervalle de temps et un gain de temps dÕexŽcution significatif. 203 Chapitre 5 - ExpŽrimentation et Žvaluations F_2 F_3 F_5 F_10 200 Messages 150 100 50 0 -50 -1 10 4 1 10 4 0 2 10 4 3 10 4 Cycles 4 10 4 5 10 4 Fig.5.17. RŽpartition des messages de code pour 125 messages ˆ dŽplacer ˆ diffŽrentes frŽquences. F_2 F_3 F_5 F_10 200 Messages 150 100 50 0 -50 -1 10 4 0 1 10 4 2 10 4 3 10 4 4 10 4 5 10 4 6 10 4 Cycles Fig.5.18. RŽpartition des messages de code pour 150 messages ˆ dŽplacer ˆ diffŽrentes frŽquences. 204 Chapitre 5 - ExpŽrimentation et Žvaluations F_2 F_3 F_5 F_10 200 Messages 150 100 50 0 -50 -2 10 4 0 2 10 4 4 10 4 Cycles 6 10 4 8 10 4 Fig.5.19. RŽpartition des messages de code pour 200 messages ˆ dŽplacer ˆ diffŽrentes frŽquences. F_2 F_3 F_5 F_10 200 Messages 150 100 50 0 -50 -2 10 4 0 2 10 4 4 10 4 6 10 4 Cycles 8 10 4 1 10 5 Fig.5.20. RŽpartition des messages de code pour 250 messages ˆ dŽplacer ˆ diffŽrentes frŽquences. 205 Chapitre 5 - ExpŽrimentation et Žvaluations Cette concentration de messages risque, dans le cas des messages de donnŽes, dÕengendrer des cas de dŽpassement de la capacitŽ de traitement des processus de lÕensemble de ces messages. Il y a donc lieu ˆ ce que la zone de rŽception de messages de donnŽes soit accrue. La question est de savoir dans quelle proportion doit sÕopŽrer cet accroissement. Dans la table5.3, nous reportons la moyenne du nombre de messages transfŽrŽs dans un m•me intervalle de temps. Il sÕagit du calcul de la suite de Fibonacci de 9. Ces moyennes sont calculŽes en fonction de la taille du code ˆ dŽplacer et de la frŽquence du routeur. Pour la dŽmonstration qui nous concerne, nous considŽrons les messages de dŽplacement de code plut™t que ceux des donnŽes proprement dites. En effet, lÕŽvaluation de la suite de Fibonacci pour un m•me nombre gŽn•re la m•me quantitŽ de donnŽes. CÕest la raison pour laquelle le nombre de ces messages ne peut constituer un ŽlŽment pertinent pour lÕŽvaluation de la taille des bo”tes aux lettres (BAL) ˆ affecter aux acteurs. Par contre, nous pouvons faire varier la taille du code ˆ transfŽrer ˆ chaque nouvelle crŽation dÕun acteur. Parmi les messages de code transfŽrŽs, il est Žvident quÕune grande partie (des messages ajoutŽs) ne fait pas rŽellement partie du code de la fonction de Fibonacci. Nous allons donc Žvaluer la taille idŽale de la BAL pour absorber les messages supplŽmentaires engendrŽs par les performances accrues du routeur (dans un m•me intervalle de temps). En considŽrant que la version statique du rŽseau R.C.A.I rŽalisait un Žquilibre entre la capacitŽ de traitement du processeur et celle dÕacheminement de messages par le routeur35, nous pouvons ˆ ce moment lˆ Žtablir la relation suivante (eu Žgard ˆ la table5.4) : = Taille * Taille BAL _Dynamique BAL _Statique 1,59 (1) Le coefficient 1,59 de la relation (1) correspond au rapport maximal lors du passage dÕune frŽquence double ˆ une frŽquence triple. Ce coefficient peut donc •tre majorŽe par 2 (puisquÕil sÕagit du nombre de messages de la BAL). Il suffit donc de doubler la taille de la bo”te aux lettres pour absorber les messages engendrŽs par lÕaugmentation des performances du routeur. 35DÕapr•s les travaux de [RUBINI_92] ceci semble •tre le cas. 206 Chapitre 5 - ExpŽrimentation et Žvaluations Taille du code transfŽrŽ FrŽquence 2 FrŽquence 3 FrŽquence 5 FrŽquence 10 125 36,000 52,500 70,986 74,118 150 34,514 54,909 73,659 75,500 200 34,068 54,324 75,140 77,308 250 34,384 52,292 76,641 78,437 (nombre de messages) Table5.3. Moyenne du nombre de messages transfŽrŽs dans les m•mes dŽlais suivant la taille du code ˆ dŽplacer et la frŽquence du routeur. Taille du code transfŽrŽ FrŽquence passage de 2 ˆ 3 FrŽquence FrŽquence passage de 3 ˆ 4 passage de 5 ˆ 10 (nombre messages) 125 1,46 1,35 1,04 150 1,59 1,34 1,02 200 1,59 1,38 1,02 250 1,52 1,47 1,02 Moyenne: 1,54 1,39 1,03 Table5.4. Rapports dÕaugmentation du nombre de messages suivant la frŽquence du routeur. 207 C ONCLUSION & PERSPECTIVES FUTURES 6. CONCLUSION ET PERSPECTIVES FUTURES Cette th•se a concernŽ lÕŽtude de la gestion dynamique dÕun rŽseau cellulaire, massivement parall•le ˆ grain fin. Le point de dŽpart fut lÕutilisation dÕun langage dÕacteur simple pour la programmation du rŽseau. Au cours de lÕŽvolution de la th•se, des probl•mes fondamentaux ont ŽtŽ mis en exergue. Dans la mesure du possible, nous avons apportŽ une solution ˆ plusieurs dÕentre eux. CÕest ainsi que nous avons proposŽ ˆ partir de la spŽcification du mod•le dÕacteurs un ensemble dÕamŽliorations des fonctions de communication et du jeu dÕinstructions du processeur. Dans une premi•re partie, nous avons abordŽ les probl•mes liŽs ˆ la rŽgulation de charge du rŽseau cellulaire. Nous sommes arrivŽs ˆ la conclusion quÕil fallait, vu la finesse visŽe du grain, une solution qui requiert un minimum (voire pas du tout, comme cÕest notre cas) dÕŽchange dÕinformations pour le maintien dÕune connaissance partielle de la charge des voisins immŽdiats, et qui, de prŽfŽrence, soit intŽgrŽe dans le rŽseau de communication. La solution proposŽe repose sur la diffusion dÕune requ•te de cellules libres. Nous avons Žgalement proposŽ une solution originale, ˆ notre connaissance, pour la rŽgulation de la charge dans une machine de plus gros grain. Nous nous sommes aussi intŽressŽs ˆ la rŽcupŽration de cellules qui ne servent plus pour les rŽutiliser. Cette fonction est transparente ˆ lÕutilisateur. Le mŽcanisme de ramasse-miettes repose sur lÕalgorithme classique du compteur de rŽfŽrences. Nous avons proposŽ une solution plus gŽnŽrale mais que nous nÕavons pas pu implŽmenter pour lÕinstant. Elle fait partie intŽgrante du mod•le dÕacteurs. Nous avons mis en Ïuvre une solution originale pour la duplication de code, en installant plusieurs ÒserveursÓ ou ÒprototypesÓ de code, dans le but de rŽduire la charge sur ces ŽlŽments pour la copie dynamique de code. 211 Conclusion et perspectives futures Un autre aspect de cette Žtude a ŽtŽ la prise en compte de mŽcanismes hŽritŽs des versions prŽcŽdentes du rŽseau36 . Il sÕagit notamment de la limitation de lÕespace dÕadressage de chaque cellule (acteur). La solution que nous avons proposŽe pour ce probl•me a ŽtŽ intŽgrŽe au mod•le dÕacteurs, en ajoutant des acteurs spŽcifiques que nous appelons acteurs-relais37. Ces acteurs brisent ces restrictions. Pour Žvaluer les performances des solutions proposŽes, nous avons dŽveloppŽ un simulateur de bas niveau (cycle), un assembleur et un Žditeur de liens. Les premiers rŽsultats que nous avons obtenus montrent que la surcharge (overhead) gŽnŽrŽe par le mouvement du code est relativement faible en terme de temps des processeurs (temps CPU). Par contre, le rŽseau au niveau des communications est saturŽ tel quÕil a ŽtŽ imaginŽ dans la version statique, et nous avons vu quÕil faudrait en augmenter les performances pour obtenir un fonctionnement satisfaisant. LÕensemble des rŽsultats dŽmontrent lÕintŽr•t de lÕapproche, ˆ condition toutefois de disposer dÕun outil de communication suffisamment puissant. LÕavantage de cette approche est dÕŽviter le probl•me du chargement initial du code. Par ailleurs, il faut noter que, m•me si le rŽseau de communication interne est saturŽ par moment et ralentit de ce fait lÕexŽcution de lÕapplication, le rŽsultat final est tout de m•me meilleur que celui obtenu en chargeant enti•rement le code dans une premi•re phase (cf.table5.1). 36 Le but de cette th•se nÕest pas de revoir enti•rement lÕarchitecture de la machine R.C.A.I, mais de proposer quelques amŽliorations pour lÕadapter au mod•le dÕexŽcution dynamique. 37 Comme nous lÕavons dŽjˆ spŽcifiŽ au niveau du chapitre IV, la solution retenue pour lÕinstant, dans cette premi•re version dynamique de R.C.A.I, est celle basŽe sur des relais physiques (cf.¤4.3.3.1). 212 Conclusion et perspectives futures Perspectives Nous envisageons plusieurs perspectives possibles. La premi•re, concernant le mod•le de programmation, serait dÕŽtudier les syst•mes dÕintelligence artificielle distribuŽs (SIAD), suivant le mod•le dÕacteurs, et dÕŽtudier leur adŽquation ˆ des architectures comme la n™tre. Une Žtude menŽe dans le cadre du projet PVC/BOX [HEMERY94], laisse ˆ lÕutilisateur le choix dÕune politique de transfert de processus, dÕŽchange dÕinformation et de localisation pour la rŽgulation de la charge des processeurs. Il serait intŽressant dÕŽtudier son intŽgration dans un mŽta-langage dÕacteur qui spŽcifierait pour chaque application devant sÕexŽcuter tous les protocoles de communications38. Ces travaux se sont restreints ˆ lÕŽtude du cas particulier o• une cellule nÕabrite quÕun seul acteur. Le cas de plusieurs acteurs par cellule, qui constitue une suite logique de notre Žtude, nŽcessite lÕintŽgration dÕun mŽcanisme de rŽgulation de charge. Cette intŽgration peut intervenir soit au niveau logiciel soit au niveau matŽriel. De la m•me fa•on, il serait intŽressant dÕexpŽrimenter et dÕŽvaluer lÕalgorithme CLIMB sur des machines existantes du type TNode ou SP1. Un tout autre aspect quÕil serait souhaitable dÕaborder est celui du dŽverminage de programmes parall•les. Cette fonction est assez dŽlicate ˆ mettre en Ïuvre. Cependant, il existe beaucoup de travaux en cours sur ce sujet (tel que le projet TRACE du LMC/IMAG) ˆ partir desquels chacun peut sÕinspirer, ou mieux encore, collaborer avec ces Žquipes pour ouvrir de nouveaux horizons! Nous terminerons par le r•ve de toute Žquipe de recherche en architectures de machines: voir le jour dÕun prototype sur silicium des mŽcanismes dŽveloppŽs dans cette th•se! 38Il sÕagit de la notion de rŽflexivitŽ dans les SIAD [FERBER_90]. 213 B IBLIOGRAPHIE BIBLIOGRAPHIE [AGHA86a] G.AGHA, C.HEWITT, Concurrent Programming Using Actors: Exploiting Large-Scale Parallelism, Dans Interaction Languages, Structures and Protocols, Juin1986. [AGHA86b] G.AGHA, ACTORS, a Model of Concurrent Computation in Distributed Systems, The MIT Press Series in Artificial Intelligence, 1986. [AGHA93] G.AGHA, I.A.MASON, S.SMITH & C.TALCOTT, Foundation of Actor Computation, Stanford University Report, Juillet1993. [AGHA94] G.AGHA, N.VENKATASUBRAMANIAN & C.TALCOTT, Scalable Distributed Garbage Collection for Systems of Active Objects, Document disponible par ftp au site cs.uiuc.edu, 1994. [AHAMAD87] M. AHAMAD, M. H. AMMAR, J. BERNABEU, M.Y.KHALDI, A Multicast Scheme for Locating Objects in a Distributed Operating System, Technical Report #GIT-ICS-87/01, Janvier1987. [AKOUTF92] Ch.AKTOUF, S.-M.KARABERNOU, Y.LATROUS & G. MAZARE, RAP : Une Perspective de Machine Massivement Parall•le, Revue Technologies AvancŽes, Vol.2, N °2, DŽcembre1992, pp16-21. [AKTOUF93] Ch.AKTOUF, S.-M.KARABERNOU, Y.LATROUS & G.MAZARE, RAP: A Fine Grain MIMD Machine , Dans Parallel Computing Trends and Applications, Editeurs. G. R. JOUBERT, D. TRYSTRAM, F. J. PETERS & D. J. EVANS, P A R C O Õ 9 3 , Elsevier Science B.V., Grenoble, Septembre1993, pp665-670. [APPEL88] W.A.APPEL, J.R.ELLIS & K.LI, Real-Time Concurrent Collection on Stock Multiprocessors, SIGPLANÕ88, Procs. of the Conf. on Programming Language Design & Implementation, Atlanta, Juin1988, pp11-20. [APPEL89] A.APPEL, Simple Generational Garbage Collection and Fast Allocation, Software Practice and Experience, Vol.19, N°2, FŽvrier1989, pp171-183. [ATHAS86] W.C.ATHAS & C.L.SEITZ, CANTOR User Report, Version 2.0, Computer Sc. Dept., California Inst. of Technology, Tech. Report, 5232:TR:1986. [ATHAS87a] W.C.ATHAS & C.L.SEITZ, Fine Grain Concurrent Computations, Computer Sc. Dept., California Inst. of Technology, Tech. Report #5242:TR:1987. A Bibliographie [ATHAS87b] W.C.ATHAS & C.L.SEITZ, Multicomputers, Computer Science Departement, California Inst. of Technology, Tech. Report #5244:TR:1987. [ATHAS88] W.C.ATHAS & C.L.SEITZ, Multicomputers: MessagePassing Concurrent Computers, IEEE Computer, Vol.21, N°8, Aožt1988, pp9-24. [BAIARDI89] F.BAIARDI & S.ORLANDO, Strategies for Massively Parallel Implementation of Simulated Annealing, PARLEÕ89, LNCS, Vol.366, Springer-Verlag, Eindhoven, Netherlands, Juin1989, pp273-287. [BAILLY87] C. BAILLY, J.-F. CHAILLINE, P. Y. GLOESS, H.-C.FERRI & B.MARCHESIN, Les Langages OrientŽs Objets - Concepts, Langages, et Applications, CepaduesEditions, 1987. [BANAWAN78] BANAWAN, An Evaluation of Local Sharing in Locally Distributed Systems, Technical Report #87-08-02, University of Washington, Seattle, Aožt1978. [BEN_ARI84] M.BEN-ARI, Algorithms for On-the-Fly Garbage Collection, ACM Transactions on Programming Languages and Systems, Vol.6, N °3, Juillet1984, pp333-344. [BERMOND92] J.-C.BERMOND, P.MICHALLON & D.TRYSTRAM, Broadcasting in Wraparound Meshes With Parallel Monodirectional Links, Parallel Computing 18 (1992), PARCO 625, North-Holland, pp639-648. [BOBROW80] D.G.BOBROW, Managing Reetrant Structures Using Refrence Counts, ACM Transactions on Programming Languages and Systems, Vol.2, N °2, Juillet1980, pp269-273. [BOKHARI81] S.H.BOKHARI, On the Mapping Problem, IEEE Trans. on Computer, Vol.C-30, N °3, Mars1981, pp207-214. [BURMEISTER91] B.BURMEISTER & K.SUNDERMEYER, Cooperative Problem Solving Guided by Intentions and Perception, 3rd Modeling Autonomous Agent in Multi-Agent World Workshop, Kaiserslautern, 1991. [CHEN90] G.-H.CHEN & J.S.YUR, A Branch and Bound with Underestimates Algorithm for the Task Assignement Problem with Precedence Constraint, The 10th Conference on Distributed Systems, Paris, France, Mai1990, pp494-501. [CHENEY70] C.J.CHENEY, A Nonrecursive List Compacting Algorithm, Communications of the ACM, Vol. 13, N ° 11, Novembre1970, pp677-678. [CLAUZEL94] D. CLAUZEL, PrŽsentation de lÕIBM 9076 Scalable POWERparallel 1, IBM France, Lyon Ecully, Avril1994. [COHEN83] J.COHEN & A.NICOLAU, Comparison of Compacting Algorithms for Garbage Collection, ACM Transactions on Programming Languages and Systems, Vol.5, N °4, Octobre 1983, pp532-553. Bibliographie [COHEN90] P.R.COHEN & H.J.LEVESQUE, Intention is Choice with C o m m i t m e n t , Artificial Intelligence, Vol.42, 1990, pp213-261 [CORNU88] R.CORNU-EMIEUX, RŽseau Cellulaire IntŽgrŽ: Etude dÕune Architecture pour des Applications de CAO de VLSI, Th•se Docteur INPG, Septembre1988. [DALLY84] W.J.DALLY & J.T.KAJIYA, An Object-Oriented Architecture, Computer Sc. Dept., California Inst. of Technology, Tech. Report #5168:TR:1984. [DALLY87] M. J. DALLY, L. CHAO, A. CHIEN, S. HASSOUN, W. HORWAT, J. KAPLAN, P. SONG, B. TOTTY & D.S.WILLS, Architecture of a Message-Driven Processor, Proceedings of the 14th ACM/IEEE Symposium on Computer Architecture, June 1987, pp189-196. [DALLY89] M.J.DALLY & D.S.WILLS, Universal Mechanisms for Concurrency, Lecture Notes in Computer Science, N°365, Edited by G.GOOS, J.HARTMANIS, Parallel Architectures and Languages Europe, Volume 1: Parallel Architectures, Editeurs: E.ODIJK, M.REM & J.-C.SYRE, PARLEÕ89, Eindhoven, The Netherlands, June 1989, pp19-33, Proceedings - Springer Verlag. [DELASALLE90] D.DELASSALE, D.TRYSTRAM & D.WENSEK, Tout ce que Vous Voulez Savoir sur la Connection Machine (Sans Oser le Demander), Document Interne LMC, Avril1990. [DeTREVILLE90] J.DeTREVILLE, Experience with Concurrent Garbage Collectors for Modula-2+, Technical Report #64, Digital Equipment Corp. Systems Research Center, Palo Alto, California, Aožt1990. [DEUTSCH76] L. P. DEUTSCH & D. G. BOBROW, An Efficient, Incremental, Automatic Garbage Collector, Communications of the ACM, Vol.19, N °9, Septembre1976, pp522-526. [DEVARAKONDA89] M.V.DEVARAKONDA & R.K.IYER, Predictability of Process Resource Usage: A Measurement-Based Study on UNIX, IEEE Transactions on Software Engineering, Vol.15, N °12, DŽcembre1989, pp1579-1586. [DIJKSTRA78] E. W. DIJKSTRA, L. LAMPORT, A. J. MARTIN, C.S.SCHOLTEN & E.F.M.STEFFENS, On-the-Fly Garbage Collection : An Exercise in Cooperation , Communications of the ACM, Vol. 21, N ° 11, Novembre1978, pp966-975. [EAGER86] D.L.EAGER, E.D.LAZOWSKA & J.ZAHORJAN, comparaison of Receiver-Initiated and Sender-Initiated Adaptative Load Sharing, Performance Evaluation 6, 1, Mars1986, pp53-68. [EAGER86b] D. L. EAGER, E. D. LAZOWSKA & J. ZAHORJAN, Adaptative Load Sharing in Homogeneous Distributed Systems, IEEE Transactions on Software Engineering, Vol.SE-12, N °5, Mai1986, pp662-675. A Bibliographie [FAURE90] B.FAURE & G.MAZARE, Neural Networks: A Cellular Architecture, Procs. of the International Conference ÒNeural Networks, Biological Computers or Electronic BrainsÓ, AFCET-Entretiens de Lyon, Mars1990. [FERBER86] J.FERBER, La Programmation par Acteur (1), lÕOrdre par le Dialogue, <ARTEFACT>, Micro-Syst•mes, Mars1986, pp140-144. [FERBER87] J.FERBER, Des Objets aux Agents: Une Architecture S t r a t i f i Ž e , Actes du 6i•me Congr•s Annuel de Reconnaissance de Formes & Intelligence Artificielle, Antibes, 1987, pp275-286. [FERBER89] J.FERBER, Objets et Agents: Une Etude des Structures de ReprŽsentation et de Communication en Intelligence Artificielle, Th•se dÕEtat, UniversitŽ Pierre et Marie Curie (ParisVI), Juin1989. [FERBER90] J.FERBER & P.CARLE, Actors and Agents as Reflective Concurrent Objects: A MERING IV Perspective, Laboratoire Formes et Intelligence Artificielle, Rapport Technique N°18/90, Juin1990. [FERBER91] J.FERBER, The Framework of ECO-Problem Solving, dans Decentralized Artificial Intelligence II, Editeurs : Y.Demazeau & J.P.MŸller, Elsevier Science Publishers, B.V. (North-Holland), 1991, pp181-195. [FERGUSON88] D. FERGUSSON, Y. YEMINI & C. NIKOLAOU, Microeconomic Algorithms for Load Balancing in Distributed Computer Systems, IEEE, 1988, pp491-499. [FLAIG87] C.M.FLAIG, VLSI Mesh Routing Systems, Computer Sc. Departement, California Inst. of Technology, Tech. Report #5241:TR:1987. [FLYNN72] M.J.FLYNN, Some Computer Organisations and Their Effectiveness, IEEE Transaction on Computers, Vol.21, N°9, Septembre1972. [GERMAIN89] C. GERMAIN-RENAUD, Etude des MŽcanismes de Communication pour une Machine Massivement Parall•le: MEGA, Th•se de lÕUniversitŽ Paris-Sud, DŽcembre1989. [GHOSH89] J.GHOSH & K.HWANG, Mapping Neural Networks onto Message-Passing Multicomputers, Journal of Parallel and Distributed Comp., Vol.6, N °2, 1989, pp291-330. [GOLDBERG83] A.GOLDBEGR & D.ROBSON, SMALLTALK-80: The Language and its Implementation, Addison-Wesley, 1983. [GOSCINSKI91] A.GOSCINSKI, Distributed Operating Systems: The Logical Design, Addison-Wesley, 1991, pp479-514. [GRUNWALD90] D.C.GRUNWALD, B.A.A.NAZIEF & D.A.REED, Empirical Comparison of Heuristic Load Distribution in Point-to-Point Multicomputer Networks, The 5th Distributed Memory Computing Conference, Charleston, Avril1990, pp984-993. Bibliographie [HAILPERIN88] M.HAILPERIN, Load Balancing for Massively-Parallel Soft-Real-Time Systems, Tech. Report #STAN-CS-88-1222 (aussi numŽrotŽ #KSL-88-62), Department of Computer Science, Stanford University, Septembre1988. [HANDLERS77] W.HANDLERS, The Impact of Classification Schemes on Computer Architecture, Procs. of the International Conference on Parallel Processing, New York, Aožt1977, pp7-15. [HASSAS92] S.HASSAS, GMAL: Un mod•le dÕActeurs RŽflexif pour la Conception de Syst•mes dÕIntelligence Artificielle DistribuŽe, Th•se Doctorat Lyon-1, 21 Septembre1992. [HAYES91] B.HAYES, Using Key Object Opportunism to Collect Old Objects, Dans ACM SIGPLAN 1991 Conf. on ObjectOriented Programming Systems, Languages and Applications (OOPSLAÕ91), ACM Press, Pheonix, Arizona, Octobre1991, pp33-46. [HEMERY94] F.HEMERY, Etude de la RŽpartition Dynamique dÕActivitŽs sur Architectures DŽcentralisŽes, Th•se de lÕUniversitŽ des Sciences et Technologies de Lille, Juin1994. [HERLIHY93] M.HERLIHY & J.E.MOSS, Non-Blocking Garbage Collection for Multiprocessors, Tech. Report #CRL90/9, Digital Equipt. Corp., Septembre1993. [HEWITT77] C.HEWITT & H.BAKER, Actors and Continuous Functionals, I F I P Working Conference on Formal Description of Programming Concepts, St Andrews, Canada, 1977. [HEWITT82] C.HEWITT, P.de JONG, Open Systems, Artificial Intelligence Laboratory, MIT, Technical Report, A.I.Memo N°691, DŽcembre1982. [HEWITT83] C.HEWITT & G.BARBER, Semantic Support for Work in Organization, Artificial Intelligence Laboratory, MIT, Technical Report, A.I. Memo N°719, Avril1983. [HILLIS85] W.D.HELLIS, The Connection Machine, MIT Press, Cambridge, Mass., 1985. [HOUCK92] C.HOUCK & G.AGHA, HAL: A High-level Actor Language and Its Distributed Implementation, 21st International Conference on Parallel Processing (ICPPÕ92), St Charles, IL, Vol.II, Aožt1992, pp158-165. [ITO86] N.ITO, M.SATO, M.KISHI, E.KUNO & K.ROKUSAWA, The Architecture & Preliminary Evaluation Results of the Experimental Parallel Inference Machine PIM-D, The 13th Annual Symposium on ComputerArchitecture, 1986. [KAFURA90] D.KAFURA, D.WASHABAUGH & J.NELSON, Garbage Collection of Actors, ECOOP/OOPSLAÕ90 Proceedings, European Conference on Object-Oriented Programming, Editeur: N. MEYROWITZ, ACM Press, 1990, pp126-134. Bibliographie [KALE88] L.V.KALE, Comparing the Performance of Two Dynamic Load Distribution Methods, Dans International Conference on Parallel Processing, 1988. [KARABERNOU93] S.-M.KARABERNOU, Conception et RŽalisation dÕun Processeur pour une Architecture Cellulaire Massivement Parall•le IntŽgrŽe, Th•se Docteur INPG, Juillet1993. [KIM92] W.KIM & G.AGHA, Compilation of a Highly Parallel Actor-Based Language, The Fifth Workshop on Languages and Compilers for Parallel Computing, YALEU/DCS/RR915, New Haven, CT, Septembre92, pp1-12. [KITAJIMA93] J.P.KITAJIMA, C.TRON & B.PLATEAU, ALPES: A Tool for the Performance Evaluation of Parallel Programs, Dans: Environments and Tools for Parallel Scientific Computing, Editeurs: J.J.Dongarra & B.Tourancheau, Amsterdam, The Netherlands, 1993, pp213-228. [KNIGHT9?] K.KNIGHT, Are Many Reactive Agents Better Than a Few Deliberative Ones? , Distributed AI, 199?, pp432-437. [KORNFELD79] W.A.KORNFELD, ETHER: A Parallel Problem Solving System, Proc. of the 6th IJCAI, 1979. [KORNFELD80] W. A. KORNFELD & C. HEWITT, The Scientific Community Metaphor, AILab.Memo N °641, MIT, Cambridge, 1980. [KRAKOWIAK85] S.KRAKOWIAK, Introduction ˆ la Programmation par Objets, CORNAFION, Mai 1985, Version 1, pp1-25. [KRAVITZ87] S.A.KRAVITZ & R.A.RUTENBAR, Placement by Simulated Annealing on a Multiprocessor, IEEE Trans. on Computer-Aided Design, Vol.CAD-6, N °4, Juillet1987, pp534-549. [KRUEGER87a] Ph.KRUGER & M.LIVNY, When is the Best Load Sharing Algorithm a Load Balancing Algorithm? , Computer Science Technical Report #694, Aožt1987. [KRUEGER87b] Ph.KRUGER & M.LIVNY, Load Balancing, Load Sharing and Performance in Distributed Systems, Computer Science Technical Report #700, Aožt1987. [KRUEGER88] Ph.KRUGER & M.LIVNY, A Comparaison of Preemptive and Non-Preemptive Load Distributing, The 8th International Conference on Distributed Computing Systems, Juin1988, California, pp123-130. [KUCHEN91] H.KUCHEN & A.WAGNER, Comparison of Dynamic Load Balancing Startegies, Dans: Parallel & Distributed Processing, Editeur: K.BOUYANOV, North-Holland, Mars1991, pp303-314. [KUNG77] H.T.KUNG & S.W.SONG, An Efficient Parallel Garbage Collection System and its Correctness Proof, Dept. of Computer Science, Carnegie-Mellon University, Septembre1977. Bibliographie [KUNZ91] T.KUNZ, The Influence of Different Workload Descriptions on a Heuristic Load Balancing Scheme, IEEE Transactions on Software Engineering, Vol.17, N °7, Juillet1991, pp725-730. [LADIN92] R. LADIN & B. LISKOV, Garbage Collection of a Distributed Heap, The 12th Inter. Conf. on Distributed Computing Systems, Mokohama, Juin1992, pp708-715. [LANGENDOEN92] K.G.LANGENDOEN, H.L.MULLER & W.G.VREE, Memory Management for Parallel Tasks in Shared Memory, LNCS637, I W M M Õ 9 2 , Inter. Workshop on Memory Management, France, Septembre1992, pp165-178. [LATROUS88] Y.LATROUS & N.TALBI, PICMOS: Un Logiciel de Placement et dÕInterconnexion dans les Circuits IntŽgrŽs VLSI suivant lÕApproche Building-Blocks, MŽmoire dÕIngŽnieur, INI-Alger (ex. CERI), Septembre1988. [LATROUS94a] Y.LATROUS & G.MAZARE, Code Distribution in A Parallel Fine Grain Machine, First International Workshop on Parallel Processing, Bangalore, India, 26-30DŽcembre1994, ˆ para”tre. [LATROUS94b] Y.LATROUS & G.MAZARE, Integrating Dynamic Mechanisms in a Parallel Fine Grain Machine, ICMÕ94, Procs. 6th International Conference on Microelectronics, Istanbul, Turquie, Septembre1994, pp112-120. [LATROUS95] Y.LATROUS & G.MAZARE, Distributing Code in a Parallel Fine Grain Machine Using the Actor Model, Procs. of the 3rd Euromicro Workshop on Parallel and Distributed Processing, San Remo, Italie, 25-27Janvier1995, ˆpara”tre . [LATTARD89] D.LATTARD, Architecture Massivement Parall•le: Un RŽseau de Cellules IntŽgrŽ pour la Reconstruction dÕImages, Th•se Docteur INPG, Novembre1989. [LeSERGENT92] T.LeSERGENT & B.BERTHOMIEV, Incremental Multithreaded Garbage Collection on Virtually Shared Memory Architectures, LNCS637, IWMMÕ92, Inter. Workshop on Memory Management, France, Septembre 1992, pp179-199. [LESTER??] D.R.LESTER, An Efficient Distributed Garbage Collection Algorithm, LNCS365, pp207-223. [LIEBERMAN81] H.LIEBERMAN, A Preview of ACT1, Artificial Intelligence Laboratory, MIT, Technical Report, A.I. Memo N°625, 1981. [LIEBERMAN83] H.LIEBERMAN & C.HEWITT, A Real-Time Garbage Collector Based on the Lifetimes of Objects, Communications of the ACM, Vol.26, N °6, Juin1983, pp419-429. [LIN87] F.C.LIN & R.M.KELLER, The Gradient Model Load Balancing Method, IEEE Transactions on Software Engineering, Vol. SE-13, N°1, Janvier1987, pp32-38. Bibliographie [MANCINI88] L.V.MANCINI & S.K.SHRIVASTAVA, Fault-Tolerant Reference Counting for Garbage Collection in Distributed Systems, Technical Report #260, University of Newcastle upon Tyne, Juin1988. [MASINI90] G.MASINI, A.NAPOLI, D.COLNET, D.LEONARD, K.TOMBE, Les Langages ˆ Objets, Langages de classes, Langages de Frames, Langages dÕActeurs, InterEditions, 1990. [MAY93] M.D.MAY, R.M.SHEPHERD & P.W.THOMPSON, T9000 Communications Architecture, dans Networks, Routers and Transputers: Function, Performance, and Applications, Editeurs: M.D.MAY, P.W.THOMPSON & P. H. WELCH, Inmos Limited, SGS-THOMSON MicroElectronics, FŽvrier1993, pp15-38. [MEHRA93] P.MEHRA & B.W.WAH, Automated Learning of Worload Measures for Load Balancing on a Distributed System, Procs. of the International Conference on Parallel Processing, Vol.III, Aožt1993, pp263-270. [MEYER90] B.MEYER, Conception et Programmation par Objets, Pour du Logiciel de QualitŽ, InterEditions, 1990. [MICHALLON93] P.MICHALLON, Communications Globales dans les Grilles Toriques, Th•se Docteur INPG, FŽvrier1993. [MINSKY75] M.MINSKY, A Framework for Representing Knowledge, Dans: The Psychology of Computer Vision, Editeur: P.WINSTON, McGrawHill, 1975, pp221-281. [MOOIJ89] W.G.P.MOOIJ & A.LIGTENBERG Architecture of a Communication Network Processor, LNCS N°365, Editeur: G.GOOS, J.HARTMANIS, PARLEÕ89, Parallel Architectures and Languages Europe, Volume 1: Parallel Architectures, Editors: E.ODIJK, M.REM, J.-C.SYRE, Eindhoven, Proc. - Springer Verlag, Juin1989, pp238-250. [MOON84] A.D.MOON, Garbage Collection in a Large Lisp System, ACM Symposium on LISP & Functional Programming, Texas, Aožt1984, pp235-246. [NETTLES93] S.NETTLES, J.OÕTOOLE & D.GIFFORD, Concurrent Garbage Collection of Persistent Heap, Tech. Report #CMUCS-93-137 ˆ Carnegie Mellon Univ., existe aussi au MIT sous #MIT-LCS-TR-569, avril1993. [NGAI87] J.N.NGAI & C.L.SEITZ, A Framework for Adaptative R o u t i n g , Computer Sc. Dept., California Inst. of Technology, Tech. Report #5246:TR:1987. [NI89] L.M.NI, Y.LAN & A.-H.ESFAHANIAN, A VLSI Router Design for Hypercube Multiprocessors, INTEGRATION, The VLSI Journal 7 (1989), Elsevier Science Publishers B.V., pp103-125. [NUGENT88] S. F. NUGENT, The iPSC/2 Direct-Connect Communication Technology, The 3rd Conf. on Hypercube Concurrent Computers and Applications, 1988. The Bibliographie [OBJOIS88] Ph.OBJOIS, RŽseau de Cellules IntŽgrŽ: MŽcanisme de Communication Inter-Cellulaire et Application ˆ la Simulation L o g i q u e , Th•se Docteur INPG, Septembre1988. [PAYAN91] E. PAYAN, Etude dÕune Architecture, Celllulaire Programmable: DŽfinition Fonctionnelle et MŽthodologie de Programmation, Th•se Docteur INPG, Juin1991. [PIERCE94] P.PIERCE & G.REGNIER, The Paragon Implementation of th NX Message Passing Interface, Scalabale HighPerformance Computing Conference, Knoxville, Tennessee, Mai1994, pp184-190. [QUINN87] M.J.QUINN, Designing Efficient Algorithms for Parallel Computers, Mc GrawHill Computer Science Series, 1987. [ROCH92] J.L.ROCH, A.VERMEERBERGEN & G.VILLARD, Cost Prediction for Load-Balancing: Application to Algebraic Computations, Parallel Processing, CONPARÕ92, VAPP V, Lyon, pp467-478. [ROSS90] A.ROSS & B.McMILLIN, Experimental Comparison of Bidding and Drafting Load Sharing Protocols, The 5th Distributed Memory Computing Conference, Procs. Vol.II, Charleston, Avril1990, pp968-974. [RUBINI92] P.RUBINI, Programmation dÕune Architecture Cellulaire Massivement Parall•le, Th•se Docteur INPG, Juin1992. [RUSSEL89] S.J.RUSSEL, Execution Architectures and Compilation, IJCAI Conference, 1989, pp15-20. [SAAD89] Y.SAAD, M.H.SCHULTZ, Data Communication in Parallel Architectures, Parallel Computing 11,, Elsevier Science Publishers B. V. (North-Holland), 1989, pp131-150. [SALETORE90] V.A.SALETORE, A Distributed and Adaptative Dynamic Load Balancing Scheme for Parallel Processing of MediumGrain Tasks, The 5th Distributed Memory Computing Conference, Procs. VolII ( Architecture, Software Tools & Other General Issues), South Carolina, 1990, pp994-999. [SANSONNET91] J.P.SANSONNET, Concepts dÕArchitectures AvancŽes, Cours DEA Informatique, LRI Paris XI-Orsay, 1990-1991. [SARGEANT86] J.SARGEANT, Load Balancing, Locality and Parallelism Control in Fine Grain Parallel Machines, Technical Report Series, UCMS-86-11-5, 1986. [SCH…NAUER93 ] W. SCH…NAUER & H. HAFNER, Supercomputer Architectures and their Bottlenecks, PARCOÕ93, Dans: Parallel Computing: Trends and Applications , Editeurs: G. R. JOUBERT, D. TRYSTRAM, F. J. PETERS & D. J. EVANS, Elsevier Science B. V., Grenoble, Septembre1993, pp411-417. [SEITZ84] C.L.SEITZ, Concurrent VLSI Architectures, IEEE Transaction on Computers Vol. C-33, N° 12, DŽcembre1984, pp1247-1265. Bibliographie [SHARMA91] R.SHARMA & M.L.SOFFA, Parallel Generational Garbage Collection, Procs. of the O O P S L A Õ 9 1 Conf. (SIGPLAN Notices, Vol. 26, N ° 11), Arizona, Octobre1991, pp16-32. [SMITH80] R.G.SMITH, The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver, IEEE Transactions on Computer, Vol.C-29,N °12, DŽcembre1980, pp1104-1113. [SOHMA85] Y.SOHMA, K.SATOH, K.KUMON, H.MASUZAWA & A.ITASHIKI, A New Parallel Inference Mechanism Based on Sequential Processing, Dans: Fifth Generation Computer Architecture, Editeur: J.WOODS, North Holland, 1985. [STANKOVIC84a] J.A.STANKOVIC, Simulations of Three Adaptative, Decentralized Controlled, Job Scheduling Algorithms, Computer Networks 8, 1984, pp199-217. [STANKOVIC84b] J.A.STANKOVIC & I.S.SIDHU, An Adaptative Bidding Algorithm for Processe, Clusters and Distributed Groups, Procs. of Inter. Conf. on Parallel Processing, Aožt1984, pp49-59. [STUNKEL94] C. B. STUNKEL, D. G. SHEA, D. G. GRICE, P. H. HOCHSCHILD & M. TSAO, The SP1 HighPerformance Switch, Procs. of the Scalable HighPerformance Computing Conference, Knoxville, Tennessee, Mai1994, pp150-157. [TAKKELLA94] S.TAKKELLA & S.SEIDEL, Complete Exchange and Broadcast Algorithms for Meshes, Scalabale High-Performance Computing Conference, Knoxville, Tennessee, Mai1994, pp422-428. [TALBI93] E.-G.TALBI, Allocation de Processus sur les Architectures Parall•les ˆ MŽmoire DistribuŽe, Th•se Docteur INPG, Mai1993. [TMC92] Thinking Machines Corporation, CM5, Technical Summary, Cambridge, Massachusetts, Janvier1992 [TOUZENE92] A.TOUZENE, RŽsolution des Mod•les Markoviens sur Machines ˆ MŽmoires DistribuŽes, Th•se Docteur INPG, Septembre1992. [TREW91] A.TREW & G.WILSON, Past, Present, Parallel Survey of Available Parallel Computing Systems, Springer-Verlag, 1991. [TRON94] C.TRON & B.PLATEAU, Modelling of Communication Contention in Multiprocessors, Proceedings of the 7th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation - Vienna, Austria, Editeurs: G.HARING & G.KOTSIS, SpringerVerlag, Berlin, LNCS794, Mai1994, pp406-424. Bibliographie [TSAI94] Y.-J.TSAI & P.K.McKINLEY, An Extended Dominating Node Approach to Collective Communication in All-Port Wormhole-Routed 2D Meshes, Scalable High-Performance Computing Conference, Knoxville, Tennessee, Mai1994, pp199-206. [TUCKER88] L.W.TUCKER & G.G.ROBERTSON, Architecture and Applications of the Connection Machine, IEEE Computer, Vol.21, N °8, Aožt1988, pp26-38. [UNGAR84] D.M.UNGAR, Generation Scavenging: A Non-Disruptive High-Performance Storage Reclamation, A C M SIGSOFT/SIGPLAN, Software Engineering Symposium on Practical Software Development Environments, Pittsburgh, Pennsylvania, Avril1984, pp157-167. [UNGAR88] D. UNGAR & F. JACKSON, Tenuring Policies for Generation-Based Storage Reclamation, Procs. of the Conference on Object-Oriented Programming Systems, Languages, and Applications, ACM SIGPLAN Not.23, 11, Nov.1988, San Diego, Cal., Septembre1988, pp1-17. [WAILLE91] Ph.WAILLE, Architectures Parall•les ˆ Connectique Programmable: Reconfiguration et Routage , Th•se Docteur INPG, Septembre1991. [WANG85] Y.T.WANG & J.T.MORIS, Load Sharing in Distributed Systems, IEEE Transactions on Computers, Vol.C-34, N°3, Mars1985, pp204-217. [WEINREB80] D.WEINREB & D.MOON, FLAVORS: Message Passing in the LISP Machine, MIT, A.I. Memo N ° 602, Novembre1980. [XU93] J.XU & K.HWANG, Heuristic Methods for Dynamic Load Balancing in a Message-Passing Multicomputer, Journal of Parallel and Distributed Computing, Vol.18, N °1, Mai1993, pp1-13. [YUM81] T. YUM, The Design & Analysis of a Semidynamic Deterministic Routing Rule, IEEE Transactions on Communication, Vol.COM-29, Avril1981, pp498-504. [ZHOU88] S.ZHOU & D.FERRARI, An Empirical Investigation of Load Indices for Load-Balancing Applications, Dans: P E R F O R M A N C E Õ 8 7 , Editeurs: P.J.Courtois & G. Latouche, Elsevier Science Publishers B. V. (NorthHolland), 1988. [ZORN90] B.ZORN, Comparing Mark-and-Sweep and Stop-and-Copy Garbage Collection, ACM Conference on LISP and Functional Programming, Nice, France, Juin1990, pp87-98. A NNEXE 1 C LASSIFICATION DES MACHINES PARALLéLES ANNEXE I: CLASSIFICATION DES MACHINES PARALLéLES Nul ne peut Žchapper ˆ la classification traditionnelle Žtablie par [FLYNN72]. Cette classification est basŽe sur le sŽquencement des donnŽes et des instructions au niveau des processeurs. Cette classification compte les catŽgories dÕarchitectures suivantes: ¥ Les architectures SISD (Single Instruction Single Data): cÕest la machine de Von Neumann traditionnelle; les instructions (lues ˆ partir dÕune mŽmoire vive) sont exŽcutŽes lÕune ˆ la suite de lÕautre. MŽmoire Centrale UnitŽs de Traitement UnitŽs de Contr™le Processeur ¥ Les architectures MISD (Multiple Instruction Single Data): ces machines sont plus connues sous le nom dÕarchitectures pipeline. CÕest le travail ˆ la cha”ne : plusieurs donnŽes (de m•me type en r•gle gŽnŽrale) sont introduites dans le circuit pour subir une sŽrie de traitements. LÕefficacitŽ de cette approche tient au recouvrement rŽalisŽ entre les diffŽrentes t‰ches (chaque t‰che Žtant assignŽe ˆ un Žtage du pipeline). Les machines dites VLIW (Very Large Instruction Word) sont une extension de ce principe : il y a recouvrement entre plusieurs instructions par mot mŽmoire [ZERROUK9?]. 229 Annexe 1 - Classification des machines parall•les Etage 0 Etage 1 Etage 1 Etage 2 Etage 2 ¥¥¥ Etage n Etage n UnitŽs de Contr™le Etage 0 ¥¥¥ UnitŽs de Traitement MŽmoire Centrale Processeur ¥ Les architectures SIMD (Single Instruction Multiple Data): plusieurs unitŽs de traitement (UT) sont supervisŽes par la m•me unitŽ de contr™le (UC). Toutes les UT sont donc synchrones. LÕUC diffuse une m•me instruction ˆ lÕensembles des UT. Chaque UT op•re sur des donnŽes distinctes, en provenance (Žventuellement) dÕun banc mŽmoire distinct. La mŽmoire est partagŽe entre les diffŽrentes UT. MŽmoire M0 M1 Mn UT UT 1 UTn 0 U C ¥ Les architectures MIMD (Multiple Instruction Multiple Data): la derni•re catŽgorie est caractŽrisŽe par une duplication de plusieurs processeurs. On peut exŽcuter autant dÕinstructions quÕil y a de processeurs. La mŽmoire peut •tre soit partagŽe soit distribuŽe. 230 UT M1 0 UT 1 UT 0 UT 1 Mn ¥¥¥ processeur n M0 processeur 1 processeur 0 M Ž m o i r e Annexe 1 - Classification des machines parall•les UTn UTn Cette classification ne tient compte ni du rŽseau de communication, ni du grain des applications ˆ exŽcuter sur ces architectures. La topologie des machines parall•les dŽfinit, pour chacune, des schŽmas de communications plus ou moins bien adaptŽs. Les rŽseaux de communication en une grille, un hypercube ou une pyramide ne sÕadressent pas tous aux m•mes applications. La topologie du rŽseau de communication, fixe ou reconfigurable, a une incidence importante sur les stratŽgies de routage et les mod•les de programmation [WAILLE91]. De m•me, les machines systoliques, qui peuvent •tre considŽrŽes comme des automates ou des processeurs spŽcialisŽs, ne peuvent •tre classŽes dans aucune des catŽgories citŽes. Pourtant, malgrŽ toutes les constations que nous venons de faire, il nÕy jusquÕˆ prŽsent aucune autre classification qui ait re•u un consensus de la part de la communautŽ scientifique39 ! 39Il existe dÕautres classifications, notamment celle de HŠndler [HANDLER77], mais qui ne sont pas tr•s rŽpandues dans le monde scientifique. 231 A NNEXE 2 E NVIRONNEMENT DE SIMULATION ANNEXEII: ENVIRONNEMENT DE SIMULATION II.1. LÕassembleur Dans la version statique du projet R.C.A.I, lorsque les processeurs devaient recevoir du code plus ou moins diffŽrent, on utilisait des directives ÒdÕassemblage conditionnelÓ pour dŽvelopper le code pour lÕensemble des processeurs. Une directive dÕassemblage conditionnel servait alors ˆ spŽcifier un groupe de cellules homog•nes (codŽes de la m•me mani•re), par le biais dÕexpressions arithmŽtiques des rŽfŽrences relatives ou absolues des cellules. Contrairement ˆ la version statique, les cellules re•oivent toutes du code diffŽrent. De ce fait, des directives dÕassemblage conditionnel sont tout ˆ fait inutiles. NŽanmoins, nous avons conservŽ la possibilitŽ de charger un m•me code soit sur lÕensemble du rŽseau (adresse cellule (-1,-1) 40), soit sur une m•me ligne (adresse cellule (x,-1)) soit sur une m•me colonne (adresse cellule (-1,x)). Cette approche peut •tre utile dans le cas de la programmation des cellules dÕentrŽes/sorties par exemple, ou encore dans le cas de lÕintŽgration dÕun noyau syst•me. La directive dÕassemblage sÕŽcrit: RapAs -d <rŽpertoire> -c lig col <nom_fichier> LÕoption (-d) indique le rŽpertoire dans lequel lÕassembleur cherche et sauvegarde ses fichiers dÕentrŽe et de rŽsultats. LÕoption (-c) spŽcifie la cellule (lig, col) rŽceptrice du code courant. <nom_fichier> est le fichier ˆ assembler. Chaque ligne du code assembleur peut reprŽsenter: ¥ un simple commentaire, ¥ une directive dÕassemblage, ¥ ou une instruction arithmŽtique, logique, de branchement ou de communication. 40Une adresse de cellule se prŽsente sous la forme (ligne, colonne). 235 Annexe 2 - Environnement de simulation II.1.1. Commentaires Un commentaire est une suite de caract•res alphanumŽriques, qui dŽbute par le caract•re spŽcial ; et se termine par un retour ˆ la ligne. ;<suite_caract•res_alphanumŽriques> II.1.2. Directives dÕassemblage Nous disposons de trois directives dÕassemblage : ORG <entier> Cette directive indique une nouvelle valeur pour le compteur de gŽnŽration de code. La valeur par dŽfaut de ce compteur est 0. <symbole> : EQU {<entier>, <rŽfŽrence>, <adresse>} Cette directive spŽcifie des constantes symboliques, manipulŽes dans le reste du code. [<symbole> :] DS <entier> Cette directive rŽserve le nombre de positions mŽmoires spŽcifiŽ. Le compteur de gŽnŽration est incrŽmentŽ dÕautant de fois que de mots rŽservŽs. La zone ainsi dŽlimitŽe est initialisŽe ˆ la valeur zŽro. Elle est rŽfŽrencŽe par le symbole attenant. [<symbole> :] DC {<entier>, <rŽfŽrence>, <adresse>} Cette directive initialise une position mŽmoire ˆ la valeur indiquŽe. Cette valeur peut •tre soit une valeur enti•re, une adresse relative dÕune autre cellule ou une adresse en mŽmoire. 236 Annexe 2 - Environnement de simulation II.1.3. Instructions Chaque instruction se prŽsente sous la forme suivante: [<label> :] <mnŽmonique> [<mode_adressage> <valeur>] Dans cette dŽfinition, le champ <l a b e l > est une adresse de branchement. Les mnŽmoniques correspondent au jeu dÕinstructions de R.C.A.I. Quant aux modes dÕadressage, ce sont ceux dŽcrits dans le premier chapitre, lors de la prŽsentation de la machine R.C.A.I. Une instruction peut •tre suivie dÕun commentaire. Afin dÕillustrer lÕutilisation de lÕassembleur, nous prŽsentons dans ce qui suit lÕalgorithme du crible dÕErathost•ne ainsi que le code objet gŽnŽrŽ par cet outil (figuresII.1 et II.2). 237 Annexe 2 - Environnement de simulation ; Programme cellule 0,1 (Crible d’Erathostène): ORG 0 DS DC DC ADVANCE: DS PPOST: DC DC UNKNOWN: DS SIEVE: DC PRIME: DC INIT: DC DC DC 2 0:0 SIEVE 1 0:0 PRIME 1 2 0 0:0 CELL 0 NEXT: GET BMI STA STA DIV MUL SUB BEQ LDA BNE FIND MOVE LDA STA STA SEND SEND BRA FORWARD: SEND BRA PRIME FIN ADVANCE UNKNOWN SIEVE SIEVE ADVANCE NEXT CELL FORWARD CELL CELL CELL PPOST INIT INIT CELL NEXT PPOST NEXT FIN: LDA STA -1 UNKNOWN LDA BEQ PPOST FINISH SEND PPOST OUT SIEVE CELL: FINISH: ; Réception de la valeur -1 ; signal de la fin de traitement ; Recherche d’une cellule libre ; Duplication du code ; Renvoyer la valeur non reconnue ; Si dernier élément de la chaîne ; Envoyer la valeur -1 pour ; terminer le traitement END Fig.II.1. Listing de lÕexemple du crible dÕErathost•ne en assembleur (cf.paragraphe2.3.5). 238 Annexe 2 - Environnement de simulation 1 ;Validité du code objet (1: valide, 0: non valide) 1 0 ;Adresse absolue de la cellule réceptrice (lig,col) 11 ;Nombre de symboles ;TABLE DES SYMBOLES: Symbole Adresse Rang FORWARD 49 0 CELL 2 1 UNKNOWN 7 2 INIT 10 3 NEXT 13 4 SIEVE 8 5 PRIME 9 6 PPOST 5 7 FINISH 63 8 FIN 53 10 ADVANCE 4 15 12 ; ;Nombre de variables Adresse Symbole Rang 0 2 3 4 5 6 7 8 9 10 11 12 ;CODE: ; PC 13 15 17 19 21 23 25 27 ••• 39 41 43 45 47 49 51 53 55 57 59 61 63 Taille __NONE__ CELL __NONE__ ADVANCE PPOST __NONE__ UNKNOWN SIEVE PRIME INIT __NONE__ __NONE__ 9 1 11 15 7 12 2 5 6 3 13 14 Mnemo. 286 309 263 263 294 293 265 305 Permission 3 3 3 3 3 3 3 3 Zone Opérande 2 6 3 10 2 15 2 2 2 5 2 5 2 15 3 4 263 263 287 287 299 287 299 261 263 261 305 287 319 3 3 3 3 3 3 3 2 3 3 3 3 0 2 2 2 2 3 2 3 0 2 2 3 2 -1 2 1 1 1 1 1 1 1 1 1 1 1 Type (0 ou 1) 0 1 0 0 1 0 0 0 0 1 0 0 Valeur (entière ou référence) 2 0 0 8 1 0 0 8 1 2 0 0 0 2 0 7 3 3 1 4 7 4 -1 2 7 8 7 ; Fin du code Fig.II.2.Listing du code objet gŽnŽrŽ par lÕassembleur pour lÕexemple de lÕalgorithme du Crible dÕErathost•ne. 239 Annexe 2 - Environnement de simulation II.2. LÕŽditeur de liens La phase dÕassemblage est terminŽe par la gŽnŽration dÕun code intermŽdiaire, dans lequel figure, pour chaque fichier, une table des symboles. CÕest ˆ partir de ces tables que les rŽfŽrences croisŽes sont rŽsolues par lÕŽditeur de liens. La directive dÕŽditions de liens est de la forme: RapLink -p -o <nom_fichier_code> -d <rŽpertoire> -h <i> -v <j> -m <taille_mŽmoire> <fichier1>.obj <fichier2>.obj... LÕoption (-p) indique ˆ lÕŽditeur de liens RapLink de fournir un Žtat de progression de cette opŽration. LÕoption (-o) spŽcifie le fichier rŽsultat du code exŽcutable. LÕoption (-d) dŽtermine le rŽpertoire de travail. Les deux options suivantes (-h) et (-v) font Žtat de la taille du rŽseau sur lequel sera placŽ ce code, respectivement le nombre de colonnes et le nombre de lignes. Finalement, lÕoption (-m) dŽfinit la taille de la mŽmoire locale de chaque processeur. On fournit par la suite lÕensemble des fichiers ˆ traiter. LÕŽditeur de liens gŽn•re, en combinant lÕensemble des fichiers objets de lÕapplication, un fichier unique du code exŽcutable de R.C.A.I (figureII.3). Les instructions sont dŽcoupŽes en plusieurs groupes suivant leur fonction. Il y a principalement six zones dÕactivitŽ41: ¥ zone dÕinactivitŽ, lorsque la cellule est libre, ¥ zone de calcul, pour lÕensemble des instructions arithmŽtiques, logiques et de branchement, ¥ zone dÕenvoi de message (instructions SEND et PUT), ¥ zone de rŽception de message (instructions GET et TRY), ¥ zone de recherche de cellules libres (instruction FIND), et ¥ zone de copie de code (instructions MOVE et COPY). Lors de la gŽnŽration du code exŽcutable (figureII.3), chaque groupe dÕinstructions est identifiŽ par un code de zone, qui est exploitŽ lors de lÕexŽcution pour informer sur lÕactivitŽ du rŽseau (cf.¤5.1.3.3.). 41Une zone dÕactivitŽ correspond au type de lÕinstruction en cours dÕexŽcution. 240 Annexe 2 - Environnement de simulation 8501 ;Taille du code 8 ;Taille du mot mémoire 0 ;Version du processeur 8 3 ;Taille du réseau 14 ;Nombre de symboles ADVANCE ;SYMBOLES FIN FINISH PPOST PRIME SIEVE NEXT INIT UNKNOWN CELL FORWARD VALUE DATA_OUT LOOP 0 0 4 -1 0 5 ;Cellule active, contient du code (@ 5). 0 1 4 -1 0 -1 ;Cellule inactive, pas de code. 0 2 4 -1 0 -1 ;Cellule inactive, pas de code. 1 0 4 -1 0 13 ;Cellule active, contient du code (@ 13). 1 1 4 -1 0 -1 ;Cellules inactives, pas de code. ••• 7 2 4 -1 0 -1 ;Code de la cell(0,0):(Lig Col Zone Permission Adr Code) 0 0 0 1 0 5 ;Point d’entrée 0 0 0 1 1 22 ;Taille du code 0 0 0 1 2 1 ;Zone de donnée ••• 0 0 1 1 5 38 ;Zone de code ••• 0 0 4 1 21 129 ;Fin du code 0 0 4 0 22 0 ;Suite de la mémoire ••• 0 0 4 0 255 0 ;Fin de la mémoire de la cellule (0, 0) ;Code de la cellule (0,1), 4 premiers mots car cellule vide. 0 1 4 0 0 0 0 1 4 0 1 0 0 1 4 0 2 0 0 1 4 0 3 0 ••• ;Code de la cellule (1, 0), correspond au précédent listing. 1 0 0 1 0 13 ;Point d’entrée 1 0 0 1 1 66 ;Taille du code 1 0 0 1 2 0 ;Zone de données ••• 1 0 3 1 13 63 ;Zone de code ••• 1 0 4 1 65 129 ;Fin du code 1 0 4 0 66 0 ;Reste de la mémoire vide ••• 1 0 4 0 255 0 ;Fin de la cellule (1, 0). 1 1 4 0 0 0 ;Reste des cellules vides. ••• 7 2 4 0 0 0 ••• 7 2 4 0 3 0 ;Fin du code exécutable Fig.II.3. Listing du code exŽcutable pour lÕexemple prŽcŽdent. 241 Annexe 2 - Environnement de simulation 242
© Copyright 2021 DropDoc