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

1227438

1227416

1227202

1227423

1227310

1227417

1230271

1227292

1227479

1227295

1227371

1227042

1227222

1226685

1227289

1227309

1228431

1231584

1227422

1228266

1232185

1229262