Vous êtes sur la page 1sur 60

Rapport de projet de n dtude e

Etude de la technologie JavaSpace sur un cluster de PCs Suplec - Option IIC e Professeurs Encadrants : Stphane Vialle et Virginie Galtier e 12 Avril 2006 par Farid Rahba et Renaud Boutet

Rsum : Dans ce projet, nous tudions les performances de la technologie e e e JavaSpace dans les calculs parall`les. Nous disposons pour ce faire dun cluster e de 32 PCs sur lequel nous dployons la simulation des trajectoires de N plan`tes e e (plus connu sous le nom de probl`me des N corps). Nous nous intressons aux e e performances de ce syst`me quant aux acclrations obtenues, et nous essayons e ee de mettre en place une gestion ecace des pannes.

Table des mati`res e


1 Introduction 2 Prsentation du probl`me des N-Corps e e 3 Algorithmes squentiels mis e 3.1 Algorithme de rfrence . ee 3.1.1 Implantation . . . 3.1.2 Rsultats . . . . . e 3.2 Algorithme optimis . . . e 3.2.1 Implantation . . . 3.2.2 Rsultats . . . . . e en . . . . . . . . . . . . uvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4 6 6 6 9 10 10 12 14 14 16

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Premiers pas avec JavaSpace 4.1 Principes gnraux . . . . . . . . . . . . . . . . . . . . . . . . . . e e 4.2 Comment lance-t-on un JavaSpace ? . . . . . . . . . . . . . . . . .

5 Quelques remarques pour une mise en place ecace de benchs 17 5.1 Mesure des performances . . . . . . . . . . . . . . . . . . . . . . . 17 5.2 Mise en place des benchs . . . . . . . . . . . . . . . . . . . . . . . 18 5.3 Automatisation des connexions . . . . . . . . . . . . . . . . . . . 19 6 Paralllisation de lalgorithme de rfrence e ee 6.1 Introduction au probl`me de paralllisation . e e 6.2 Algorithme avec centralisateur . . . . . . . . 6.2.1 Implantation . . . . . . . . . . . . . 6.2.2 Dploiement . . . . . . . . . . . . . . e 6.2.3 Rsultats . . . . . . . . . . . . . . . e 21 21 22 22 22 24 28 28 29 29 29 30

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

7 Deuxi`me paralllisation de lalgorithme de rfrence e e ee 7.1 Nouveau transit de donnes . . . . . . . . . . . . . . . e 7.2 Travailleur ` recouvrement de donnes . . . . . . . . . a e 7.3 Introduction dune information de commande . . . . . 7.3.1 Principe . . . . . . . . . . . . . . . . . . . . . . 7.3.2 Intrts majeurs . . . . . . . . . . . . . . . . . . ee

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

ii 7.4 7.5 7.6

` TABLE DES MATIERES Rcapitulation du fonctionnement de lalgorithme . . . . . . . . . e Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Version sans recouvrement . . . . . . . . . . . . . . . . . . . . . . 30 35 40 42 42 42 42 43 44 45 49 50 51 54

8 Tolrance aux pannes e 8.1 Introduction du probl`me . . . . . . . . . . . . . . . . . . . e 8.2 Gestion des pannes des travailleurs . . . . . . . . . . . . . . 8.2.1 Mise en place dun syst`me dannonce des travailleurs e 8.2.2 Dtection de la panne . . . . . . . . . . . . . . . . . e 8.2.3 Gestion des pannes . . . . . . . . . . . . . . . . . . . 8.2.4 Rcapitulatif et schmas de principe . . . . . . . . . e e 8.2.5 Performances obtenues . . . . . . . . . . . . . . . . . 9 Conclusion A Automatisation des connexions Bibliographie

. . . . . . .

. . . . . . .

. . . . . . .

Table des gures


3.1 3.2 3.3 3.4 3.5 4.1 6.1 6.2 6.3
Diagramme UML de lalgorithme squentiel . . . . . . . . . . . . . . . . e Trajectoires de 16 plan`tes en interaction gravitationnelle e

. . . . . . . . .

8 9 10 12 13 15 23 24

Evolution des performances de lalgorithme squentiel de rfrence en fonction e ee du nombre de plan`tes . . . . . . . . . . . . . . . . . . . . . . . . . . e Evolution des performances de lalgorithme squentiel optimis en fonction du e e nombre de plan`tes . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Comparaison des deux algorithmes squentiels . . . . . . . . . . . . . . . e Les direntes oprations sur un JavaSpace . . . . . . . . . . . . . . . . e e Dploiement sur le cluster de 32 PCs . . . . . . . . . . . . . . . . . . . e Temps dexcution en fonction du nombre de plan`tes et du nombre de proe e cesseurs pour la version 1 de lalgorithme paralllis . . . . . . . . . . . . e e Temps dexcution en fonction du nombre de plan`tes pour direntes cone e e gurations du nombre de processeurs et pour la version 1 de lalgorithme paralllis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Temps dexcution en fonction du nombre de processeurs pour direntes e e congurations du nombre de plan`tes et pour la version 1 de lalgorithme e paralllis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Courbes de speed-up pour direntes congurations du nombre de processeurs e pour la version 1 de lalgorithme paralllis . . . . . . . . . . . . . . . . e e Etape 1 de lalgorithme paralllis version 2 . . . . . . . . . . . . . . . . e e Etape 2 de lalgorithme paralllis version 2 . . . . . . . . . . . . . . . . e e Etape 3 de lalgorithme paralllis version 2 . . . . . . . . . . . . . . . . e e Etape 4 de lalgorithme paralllis version 2 . . . . . . . . . . . . . . . . e e Temps dexcution en fonction du nombre de plan`tes et du nombre de proe e cesseurs pour la version 2 de lalgorithme parallelis . . . . . . . . . . . . e Temps dexcution en fonction du nombre de plan`tes pour direntes cone e e gurations du nombre de processeurs et pour la version 2 de lalgorithme paralllis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e

26

6.4

26 27 31 32 33 34 35

6.5

7.1 7.2 7.3 7.4 7.5 7.6

36

iv

TABLE DES FIGURES

7.7

7.8 7.9 7.10 7.11 7.12 7.13 8.1 8.2 8.3 8.4 8.5 8.6

Temps dexcution en fonction du nombre de processeurs pour direntes e e congurations du nombre de plan`tes et pour la version 2 de lalgorithme e paralllis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e Courbes de speed-up pour direntes congurations du nombre de processeurs e pour la version 2 de lalgorithme paralllis . . . . . . . . . . . . . . . . e e Temps dexcution en fonction du nombre de processeurs pour la version 2 de e lalgorithme et pour 7000 plan`tes . . . . . . . . . . . . . . . . . . . . e Speed-up en fonction du nombre de processeurs pour la version 2 de lalgorithme et pour 7000 plan`tes . . . . . . . . . . . . . . . . . . . . . . . e Ecacit en fonction du nombre de processeurs pour la version 2 de lalgoe rithme et pour 7000 plan`tes . . . . . . . . . . . . . . . . . . . . . . . e Extensibilit pour la deuxi`me paralllisation de lalgorithme de rfrence e e e ee . Gain moyen de la version sans recouvrement Calculs/Communications par rapport ` la version avec recouvrement en fonction du nombre de processeurs a Calcul des priodes dannonces et de vrications (gestion des pannes) e e Gestion des pannes, initialisation des travailleurs . . . . . . . . . . . Gestion des pannes, initialisation du client . . . . . . . . . . . . . . Gestion des pannes, annonces de prsence . . . . . . . . . . . . . . e Gestion des pannes, absence dune annonce 1 . . . . . . . . . . . . Gestion des pannes, absence dune annonce 2 . . . . . . . . . . . .

36 37 38 38 39 40 41 44 46 46 47 47 48

. . . . . .

. . . . . .

. . . . . .

Liste des tableaux


6.1 7.1
Bilan des communications en un cycle pour la version 1 de lalgorithme paralllis 25 e e Bilan des communications en un cycle pour la version 2 de lalgorithme paralllis 29 e e

Liste des Algorithmes


1 2 Algorithme squentiel de rfrence . . . . . . . . . . . . . . . . . . e ee Algorithme squentiel optimis . . . . . . . . . . . . . . . . . . . . e e 7 11

Chapitre 1 Introduction
Les clusters de PCs constituent aujourdhui une solution conomique et exe tensible aux probl`mes de calcul intensif. La mthode native et non triviale de e e programmation dun cluster de PCs est la cration de processus communiquant e par envois de mesages ` travers le cluster. La programmation par partage de a mmoire est souvent plus simple ` exploiter, mais ncessite une mmoire pare a e e tage alors que les clusters norent quune mmoire distribue. e e e Une solution hybride consiste ` installer une mmoire partage virtuelle (ou a e e DSM : Distributed Shared Memory) au-dessus de larchitecture native du cluster pour muler une machine parall`le ` mmoire partage. Des solutions 100% e e a e e matrielles existent jusqu` 512 processeurs et se rv`lent performantes mais tr`s e a e e e ch`res. A loppos, des solutions purement logicielles sont bon march et supe e e portent lensemble des oprations standards sur une mmoire partage, mais elles e e e restent peu performantes et limites ` 32 processeurs. Une variante consiste ` utie a a liser une DSM au-dessus dun ensemble de JVM, et ` orir aux utilisateurs un ena semble plus limit de mcanismes dacc`s ` la mmoire partage. Les JavaSpaces e e e a e e constituent une technologie apprcie dans le monde industriel, car bnciant de e e e e la portablilit Java et dune grande simplicit de partage de donnes (on pourra e e e se reporter ` [5]). a Cependant, les JavaSpaces ne rsolvent pas tous les probl`mes poss par e e e lutilisation dun cluster de PCs. Par exemple, la tolrance aux pannes et e le respect des contraintes de temps restent de rels probl`mes, car tous les e e composants dun syst`me distribu sont rarement oprationnels en mme temps. e e e e Ainsi, nous avons cherch dans ce projet ` explorer cette technologie an de e a rpondre aux questions suivantes : e Comment assurer la tolrance aux pannes (si une machine dispara subie t tement du cluster) ? Comment ventuellement tirer prot de larrive dune nouvelle machine e e dans le cluster en cours dexprience ? e Cette technologie permet-elle dobtenir des acclrations convenables et de ee

passer ` lchelle ? a e ... Pour mener ` bien ces investigations, nous avons dvelopp une application a e e support gnrant de gros calculs et de nombreux acc`s aux donnes stockes e e e e e en mmoire : le probl`me des N-Corps. On simule alors le mouvement de N e e plan`tes, en attractions mutuelles, sur notre cluster de 32 PCs ` travers des e a JavaSpaces. Ce document prsente de mani`re dtaille les algorithmes, les procdures mis e e e e e en place pour le calcul parall`le, ainsi que les rsultats obtenus suite aux dirents e e e bancs dessais. Il sorganise de la mani`re suivante : le chapitre 2 est consacr ` la e ea prsentation du probl`me des N-Corps ; le chapitre 3 dtaille les deux algorithmes e e e squentiels mis en place ; le chapitre 4 prsente les direntes techniques utilises e e e e pour facilement grer un cluster de PCs et mettre en place les mesures, et enn e les chapitres suivants exposent les direntes versions de paralllisation mises en e e uvre.

Chapitre 2 Prsentation du probl`me des e e N-Corps


Il sagit dun probl`me classique sur lequel se sont penchs de nombreux phye e siciens et mathmaticiens. Il consiste ` rsoudre les quations du mouvement de e a e e N corps interagissant gravitationnellement, connaissant leurs masses ainsi que leurs positions et vitesses initiales. Une application cl`bre concerne lvolution du syst`me solaire grce ` ee e e a a ltude du mouvement des plan`tes. e e Si il a tant attir lattention des scientiques, cest sans aucun doute d ` sa e ua dicult. Certes, pour N = 2 et N = 3, le probl`me est rsoluble analytiquement, e e e mais au-del`, cela devient impossible. Comment faire ? a Comme souvent, on se contente de solutions approches, deux approches sont e utilises : e la thorie des perturbations, qui permet de faire des calculs analytiques e approchs sous la forme de dveloppements en srie. e e e lanalyse numrique. e Cest cette derni`re approche qui nous intresse ici, car elle met en oeuvre e e des mthodes numriques que lon peut facilement automatiser et ainsi mettre ` e e a prot les ordinateurs. Lide est relativement simple : elle consiste ` discrtiser les quations de la e a e e physique. Dcrivons un peu cette dmarche. e e Nous partons de la cl`bre relation fondamentale de la dynamique : ee

m = F a

5 o` m dsigne la masse, lacclration et F lensemble des forces qui u e a ee sappliquent sur un objet. On consid`re d`s lors N plan`tes de masse mi , de position pi . La force gravie e e tationnelle quexerce la plan`te j sur la plan`te i est donne par : e e e F ji = Gmi mj pj pi pj pi

o` G dsigne la constante gravitationnelle, u e entre les plan`tes i et j. e

pj pi

reprsente la distance e

En combinant les deux quations prcdentes, on obtient : e e e d2 pi pj pi =G mj dt2 pj pi 1jN


j=i

On a obtenu ainsi un syst`me dquations direntielles non-linaires, e e e e insoluble de mani`re analytique. On va discrtiser cette quation en essayant de e e e calculer les positions pi aux instants nt . On dsigne alors par pn la position de e i la plan`te i ` linstant n. e a On approche lexpression dt2i par devient :
d2 p
n1 pn+1 +pi 2pn i i . t2

Notre syst`me dquations e e

pn+1 = 2pn + t2 G i i
1jN j=i

mj

pn pn j i pn pn j i

pn1 i

On peut ainsi calculer la position de la plan`te i ` linstant n+1 en connaise a sant les positions de toutes les plan`tes aux instants n et n-1. e Lalgorithme est alors simple : connaissant les positions et vitesses initiales des N plan`tes, on calcule toutes les positions tape apr`s tape (cest-`-dire ` linstant e e e e a a t, puis 2t, puis 3t...). Remarque : pour calculer les positions des plan`tes ` linstant t, il faut e a conna les positions des plan`tes ` linstant t . Pour cela, on utilise laptre e a proximation :

p1 = p0 tvi (vi est la vitesse initiale de la plan`te i) e i i

Chapitre 3 Algorithmes squentiels mis en e uvre


3.1
3.1.1

Algorithme de rfrence ee
Implantation

Dans un premier temps, nous avons cherch ` coder le probl`me de mani`re ea e e simple, cest ` dire en respectant les quations discr`tes pralablement trouves. a e e e e Lalgorithme qui en dcoule est prsent ci-apr`s (Algorithme (1)). e e e e Il est ` remarquer que cet algorithme est en O(n2 ) : en eet, pour chaque plan`te a e il faut calculer (n 1) interactions, ce qui fait au total n(n 1) interactions. Cet algorithme est na dans le sens o` nous calculons 2 fois la mme interaction f u e (sachant que linteraction dun plan`te p sur une plan`te q est la mme que celle e e e exerce par q sur p selon le principe dinteraction F pq = F qp ). e Nous avons utilis le langage Java (en vue de lutilisation future des JavaSe paces). Dun point de vue objet, nous avons dni les classes suivantes : e la classe Plan`te : on y consigne les informations suivantes : la vitesse inie tiale, la masse, son nom ainsi que sa position aux instants nt et (n 1)t. la classe Univers : on y trouve la constante gravitationnelle G, lintervalle de discrtisation t, son nom ainsi que le tableau des objets Plan`te qui e e constituent cet univers. La mthode c positions() permet le calcul des poe sitions de lensemble des plan`tes de lunivers ` linstant (n + 1)t (les e a positions aux instants nt et (n 1)t tant consignes dans les objets e e Plan`te). e la classe Scrib : permet lcriture des positions dans un chier texte. e la classe Main : elle permet deectuer le calcul pour un nombre de plan`tes e et un nombre de cycles donns en argument. e

3.1 Algorithme de rfrence ee

Algorithme 1 : Algorithme squentiel de rfrence e ee Donnes : le nombre de cycles nb cycles et le nombre de plan`tes e e nb planetes e e e Cration dun univers Univers de nb planetes plan`tes : on quirpartit e les plan`tes sur une sph`re ou sur un cercle ; on choisit des vitesses e e initiales tangantielles et de mme norme. e pour i 1 ` nb cycles faire a pour chaque plan`te courante dans Univers faire e initialisation t Rsultat [] ; /* tableau de taille nb planetes e qui va permettre de calculer les positions ` a linstant it pour lensemble des plan`tes */ e a pi1 e courant position de plan`te courante ` linstant (i 1)t j0 pour chaque plan`te inuence dans Univers tel que e e plan`te inuence = plan`te courante faire e distance distance entre plan`te courante et e plan`te inuence e masse M asse de plan`te inuence e i1 a pinf luence position de plan`te inuence ` linstant (i 1)t e composante inuence inf luence courant distance t Rsultat [ j ] t Rsultat [ j ]+ masse e e composante inuence i2 pcourant position de plan`te courante ` linstant (i 2)t e a i1 i2 t Rsultat [ j ] (t)2 G t Rsultat[j] + 2 pcourant pcourant e e j ++ Mise ` jour de la position de plan`te courante a e
pi1 pi1

Algorithmes squentiels mis en uvre e

Le diagramme 3.1 permet de visualiser lorganisation de ces classes.

Fig. 3.1 Diagramme UML de lalgorithme squentiel e Cest dans la mthode main() de la classe Main que se trouve la boucle de e cycles qui permet de calculer les positions instant apr`s instant. Les arguments ` e a passer sont dans lordre : le nombre de plan`tes, le nombre de cycles et Oui/Non e si on veut crire les rsultats des trajectoires. Lorsque le calcul est termin, nous e e e imprimons sur la console le temps total dexcution, le nombre de plan`tes, le e e nombre de cycles et le nombre de processeurs (ici 1). Ainsi, si on veut lancer un calcul, on cre une instance de la classe Univers. e Cet univers sera compos dun ensemble dobjets Plan`te, qui poss`dent comme e e e attribut la position ` linstant courant et ` linstant prcdent. La classe Univers a a e e poss`de quant ` elle une mthode qui calcule les positions de toutes les plan`tes e a e e en remettant ` jour les attributs correspondants. a Lunique instance de la classe Scrib crit, si elle en a lordre, toutes les positions e

3.1 Algorithme de rfrence ee

des n plan`tes dans n chiers .txt correspondants. e

3.1.2

Rsultats e

La premi`re tape an de tester notre programme est de visualiser les trae e jectoires des plan`tes. Voici par exemple le comportement de 16 plan`tes unie e formment rparties sur un cercle, de mme masse et de vitesse initiale de mme e e e e 1 norme et tangente au cercle (gure 3.2) :

Ici, les tests sont faits en 2D avec des plan`tes e quirparties e e sur un cercle mais par la suite, les plan`tes seront e quirparties e e sur une sph`re. e

Fig. 3.2 Trajectoires de 16 plan`tes en interaction gravitationnelle e On remarque linvariance par rotation des trajectoires, les plan`tes sont toutes e attires par le centre du cercle qui constitue le centre de gravit du syst`me. e e e Nous supposons maintenant que lalgorithme fonctionne correctement et nous ne nous intresserons plus ` la visualisation des trajectoires des plan`tes. e a e Nous ferons juste des comparaisons de valeurs par rapport ` cet algorithme de a rfrence an de vrier la validit des programmes futurs. ee e e Nous allons maintenant nous intresser aux temps dexcution de lalgorithme. e e Les courbes suivantes prsentent les premiers rsultats en fonction du nombre de e e plan`tes : e
1

Ici, nous visualisons les rsultats ` laide du logiciel GnuPlot. e a

10

Algorithmes squentiels mis en uvre e

Fig. 3.3 Evolution des performances de lalgorithme squentiel de rfrence en fonction du e ee


nombre de plan`tes e

On remarque bien le caract`re en O(n2 ) de lalgorithme sur la premi`re e e courbe, les points reprsentent les mesures relles et la courbe lapproximation e e en moindres carrs dun polynme de degr 2. Celle-ci sera utilise dans toutes e o e e nos tudes car elle permet de raliser de bonnes prvisions concernant le temps e e e dexcution du programme. e La deuxi`me courbe permet de conrmer la linarit de lalgorithme lorsque e e e lon reprsente le temps par cycle et par plan`te. e e

3.2
3.2.1

Algorithme optimis e
Implantation

Loptimisation de lalgorithme consiste ` ne pas raliser deux fois le mme a e e calcul dinteraction entre plan`tes. Pour ce faire, nous ralisons une double boucle e e en triangle , la boucle externe se fera sur la collection de plan`tes et la boucle e interne sur les plan`tes dindice suprieur ` lentit courante. Au lieu des n(n 1) e e a e calculs dinteraction prcdents, il ny en a plus que n(n1) . Lalgorithme est e e 2 prsent ci-apr`s (Algorithme (2)). e e e

3.2 Algorithme optimis e

11

Algorithme 2 : Algorithme squentiel optimis e e Donnes : le nombre de cycles nb cycles et le nombre de plan`tes e e nb planetes Cration dun univers Univers de nb planetes plan`tes : on quirpartit e e e e les plan`tes sur une sph`re ou sur un cercle ; on choisit des vitesses e e initiales tangantielles et de mme norme. e pour i 1 ` nb cycles faire a pour pi 1 ` nb plan`tes faire a e initialisation t Rsultat [] ; /* tableau de taille nb planetes e qui va permettre de calculer les positions ` a linstant it pour lensemble des plan`tes */ e e e plan`te courante pii`me plan`te e masse courante M asse de plan`te courante e i1 pcourant position de plan`te courante ` linstant (i 1)t e a e pour pj pi + 1 ` nb plan`tes faire a e plan`te inuence pj i`me plan`te e e distance distance entre plan`te courante et e plan`te inuence e e masse inuence M asse de plan`te inuence pi1luence position de plan`te inuence ` linstant (i 1)t a e inf composante inuence inf luence courant distance t Rsultat [ pi ] t Rsultat [ pi ]+ masse inuence e e composante inuence e e t Rsultat [ pj ] t Rsultat [ pj ] masse courante composante inuence /* on retranche le rsultat par le principe e dinteraction : Fij = Fji */ pi2 e a courant position de plan`te courante ` linstant (i 2)t i1 i2 2 t Rsultat [ j ] (t) G t Rsultat[j] + 2 pcourant pcourant e e Mise ` jour de la position de plan`te courante a e
pi1 pi1

12

Algorithmes squentiels mis en uvre e

3.2.2

Rsultats e

Les performances de cette version sont les suivantes :

Fig. 3.4 Evolution des performances de lalgorithme squentiel optimis en fonction du e e nombre de plan`tes e Les calculs se font encore bien sr en O(n2 ), cependant la dirence de peru e formance est notable. En eet, comparons les performances des deux versions, un indicateur intressant est celui du rapport entre les temps par cycle pour un e nombre de plan`tes donn (ou speed-up)(gure 3.5). e e La seconde version est donc environ deux fois plus rapide que la premi`re. e Cela tait prvisible puisquil y a n(n 1) calculs dinteraction pour la version e e e de rfrence et n(n1) calculs pour la version optimise. ee 2 Il para alors vident quil faille adapter lalgorithme optimis aux calculs t e e parall`les. Cependant , deux facteurs nous incitent ` commencer par parallliser e a e la version na en premier lieu : ve 1. lexprience montre quil est assez complexe de parallliser un algorithme e e optimis. On peut entrevoir les dicults concernant notre probl`me. En e e e eet, imaginons que le processeur p soccupe de la plan`te 1 et le processeur e q soccupe de la plan`te 2. Le processeur q devra attendre que p ait ni le e calcul de linteraction entre 1 et 2 avant de continuer ses calculs.

3.2 Algorithme optimis e

13

Fig. 3.5 Comparaison des deux algorithmes squentiels e 2. Outre la complexit de la paralllisation, lexemple prcdent montre un e e e e autre aspect : parallliser notre algorithme optimis implique galement e e e laugmentation du nombre de communications. On gagne en temps CPU mais on perd toute notre avance dans lattente des transferts. Rsum du chapitre Nous avons dans un premier temps implant en Java e e e deux versions du probl`me des N-Corps pour le calcul des trajectoires de plan`tes. e e Les deux algorithmes suivent le schma numrique expos au chapitre prcdent e e e e e avec une optimisation sur le second. Les deux ont fourni des rsultats prvisibles : e e lvolution en fonction du nombre de plan`tes suit une loi parabolique et lon e e atteint des temps consquents (plusieurs heures) d`s lors que lon traite plusieurs e e milliers de plan`tes. Si les deux versions prsentent des dirences notoires, cest e e e la version na qui sera utilise pour la paralllisation. Pour faute de temps, nous ve e e navons pu parallliser la version optimis, mais il serait intressant dtudier les e e e e performances que lon obtient.

Chapitre 4 Premiers pas avec JavaSpace


Dans ce chapitre, nous voquons les principes de la technologie JavaSpace e ainsi que la mise en place concr`te de cette technologie. e

4.1

Principes gnraux e e

JavaSpace est une technologie base sur la mthode Linda. Elle propose un e e espace de stockage permettant le partage dobjets Java. Il sagit dun service propos au sein de larchitecture Jini de Sun Microsystems. Jini est un syst`me e e distribu permettant la communication de dirents matriels au sein dun e e e rseau local an dorir des services rseaux ` des applications. Toutefois, cette e e a architecture est limite ` des rseaux locaux et utilise un gestionnaire centralis e a e e pour rpertorier les dirents services disponibles. Le service JavaSpace repose, e e pour les communications, sur la technologie RMI de Java. Comment se fait ce partage dobjets Java ? Avant de dcrire les oprations permettant de grer notre espace de mmoire e e e e partage, il faut dnir la notion dentre (Entry en anglais). Il sagit sime e e plement dobjets typs que lon dpose dans lespace. Concr`tement, lorsque e e e lon veut dposer un objet dans lespace, il sut que la classe quil reprsente e e soit srialisable et implmente linterface net.jini.core.entry.Entry. Dtaillons e e e maintenant les oprations que lon peut eectuer sur notre espace : e lopration write permet denregistrer une nouvelle entre dans un JavaSe e pace. pour rechercher une entre contenue dans un JavaSpace, on utilise des e entres mod`les (template) en remplissant tout ou partie des champs core e respondant exactement ` celles des entres recherches. Il y a deux types a e e de recherche dentre : read et take. Lopration read renvoit une copie de e e

4.1 Principes gnraux e e

15

lentre qui correspond ` une entre mod`le demande, ou une indication e a e e e si aucune entre ne correspond. Lopration take fait la mme chose mais e e e retire lentre du JavaSpace. e Lopration notify permet dtre inform lorsquune entre, correspondant e e e e a ` un certain mod`le, est enregistre dans le JavaSpace. e e Toutes les oprations qui modient un JavaSpace sont ralises de faon trane e e c sactionnelle. Ainsi, apr`s une opration write russie, on est assur que lobjet e e e e se trouve bien dans le JavaSpace. De mme, apr`s une opration take russie, on e e e e est assur que lobjet a t retir du JavaSpace. e ee e Le schema (4.1) permet de visualiser ces oprations : e

Fig. 4.1 Les direntes oprations sur un JavaSpace e e Enn, il existe plusieurs modes dutilisation dun JavaSpace (et plus gnralement des services Jini) : e e un mode transient : les donnes, objets stocks ne sont valides et accessibles e e que lorsque les services sont en tat de marche. Si lun des services tombe e en panne, les donnes sont perdues ` jamais. e a un mode persistant : ici au contraire les donnes sont crites sur le disque e e et on peut les rcuprer apr`s une panne. e e e On peut galement rendre ce dernier mode activable ou non-activable. Lace tivation, base sur Java RMI permet par exemple de relancer automatiquement e un service en cas de panne de celui-ci. Pour plus dinformations sur les JavaSpace et plus gnralement sur Jini, on e e pourra se reporter ` [1]. a

16

Premiers pas avec JavaSpace

4.2

Comment lance-t-on un JavaSpace ?

On dcrit ici bri`vement comment lancer les services JavaSpace pour avoir e e un espace prt ` lemploi. e a Apr`s avoir install la technolgie Jini (dans la cas prsent, le Jini Techology e e e Starter Kit v2.1 disponible sur le site http ://starterkit.jini.org), il sagit principalement de lancer 4 services : 1. Un RMI activation daemon sur chaque hte hbergeant un service. Ce o e service permet de grer le mode activable : cest un processus qui sassure e que les services activables sont disponibles si besoin est. 2. Un serveur web pour le chargement dynamique de classes. 3. Un look-up service Jini (limplmentation Sun sappelle reggie) : cest un e service central de linfrastructure Jini qui permet de localiser les services Jini. 4. Un javaspace (limplmentation Sun sappelle outrigger). e Pour un exemple dtaill dutilisation du JavaSpace, on pourra se reporter ` [2]. e e a

Chapitre 5 Quelques remarques pour une mise en place ecace de benchs


Une fois notre algorithme squentiel paralllis, lobjectif principal est la mee e e sure de ses performances. En eet nous voulons par exemple savoir si notre algorithme passe ` lchelle. Pour ce faire, il faut mesurer les temps dexcution a e e du programme dans un ensemble de congurations possibles : en fonction de la taille du probl`me (nombre de plan`tes), du nombre de processeurs, du nombre e e de cycles. Il est d`s lors tr`s intressant dautomatiser ces mesures, cest ` dire e e e a de mettre en place des benchs (ou bancs dessais) an de rcuprer les rsultats e e e consigns dans un chier texte par exemple. Nous avons d rpondre aux quese u e tions suivantes : Comment mesure-t-on les performances de lalgorithme (quel temps mesuret-on) ? Comment mettre en place des benchs ? Comment automatiser les connexions au travers du cluster ?

5.1

Mesure des performances

Il existe de nombreuses techniques pour mesurer le temps et on peut mesurer dirents types de temps : le temps total, le temps CPU, le temps de la boucle e de calcul uniquement ... Nous utilisons dans nos programmes les lignes de code suivantes :
1

2 3

long wctAvant = System . currentTimeMillis () ; /* heure au d but de l ex cution */ e e .... Calculs ...... long wctApres = System . currentTimeMillis () ; /* Heure ` la fin de l xecution */ a e

18

Quelques remarques pour une mise en place ecace de benchs

long duree = wctApres - wctAvant ; /* temps d ex cution */ e

Il sagit dun temps de type wallclocktime : on mesure le temps total du point de vue utilisateur. Nous avons choisi ce temps1 car il permet de mesurer ` la fois a les temps de calcul et de communication.

5.2

Mise en place des benchs

Pour valuer la performance dune paralllisation, il est ncessaire de faire une e e e batterie de calculs dans direntes congurations. Il devient d`s lors intressant e e e dautomatiser la mise en place de ces calculs. Par exemple, on lance un calcul le soir et on revient rcuprer lensemble des rsultats le lendemain matin. e e e Pour ce faire, on crit un script en langage bashshell. Prenons un exemple de e script utilis : e
1 2 3 4 5

rm -f resall . txt for (( I =12; I <46; I ++) ) ; do / usr / java / jdk1 .5.0 _06 / bin / java - Djava . security . policy =/ tmp / Projet_Boutet_Rahba / Config / jsk - all . policy - classpath / usr / java / Jini2_1 / lib / jini - ext . jar :/ tmp / Projet_Boutet_Rahba / CodePlanetes / Client 193.48.224.86\ $ ((\ $I *\ $I ) ) 30 3 " non " >& res1 . txt cat res1 . txt >> resall . txt ; done

6 7 8 9

Ici, la ligne /usr/java/jdk1.5.0_06/bin/java -Djava.security.policy= /tmp/Projet_Boutet_Rahba/Config/jsk-all.policy-classpath /usr/java/Jini2_1/ lib/jini-ext.jar :/tmp/Projet_Boutet_Rahba/CodePlanetes/ Client 193.48.224.86\$((\$I*\$I)) 30 3 "non" permet deectuer le calcul parall`le pour I 2 plan`tes, 30 cycles et 3 processeurs. e e et on copie le rsultat (cest ` dire le temps dexcution) grce ` e a e a a >& res1.txt
1

ce principe de mesure est galement utilis pour les mesures de lalgorithme squentiel. e e e

5.3 Automatisation des connexions

19

La ligne cat res1.txt >> resall.txt ; permet de rcuprer les rsultats pour direntes valeurs de I dans le chier e e e e resall.txt. Pour rendre notre script excutable, il sut de changer ses proprits en e ee utilisant la commande linux chmod. Une fois cela fait, on lance les calculs en tapant dans une fentre de commande : e ./<nom du script> En sortie, on rcup`re un chier texte de la forme suivante2 : e e
1

3 4

6 7

9 10

11

12

# Nbre Planetes = 100 Nbre Cycles = 50 Ecriture fichiers = non # TempsReelCalcul , Temps par cycle , NbrePl , NbreCycles , NbProcs 687 13.0 100 50 1 # Nbre Planetes = 300 Nbre Cycles = 50 Ecriture fichiers = non # TempsReelCalcul , Temps par cycle , NbrePl , NbreCycles , NbProcs 5618 112.0 300 50 1 # Nbre Planetes = 500 Nbre Cycles = 50 Ecriture fichiers = non # TempsReelCalcul , Temps par cycle , NbrePl , NbreCycles , NbProcs 16486 329.0 500 50 1 # Nbre Planetes = 700 Nbre Cycles = 50 Ecriture fichiers = non # TempsReelCalcul , Temps par cycle , NbrePl , NbreCycles , NbProcs 33186 663.0 700 50 1

5.3

Automatisation des connexions

Pour lancer un calcul parall`le, il faut lancer les dirents services JavaSpace e e ainsi que les PCs sur lesquels se feront les calculs. Cela devient vite fastidieux, car ` chaque fois que lon se connecte sur un PC, il y a une authentication. a
2

le temps est mesur en millisecondes e

20

Quelques remarques pour une mise en place ecace de benchs

Nous avons fait en sorte quil ny ait plus aucune authentication. Pour plus de renseignements, on pourra se reporter ` lannexe. a

Chapitre 6 Paralllisation de lalgorithme de e rfrence ee


6.1 Introduction au probl`me de paralllisation e e

Les deux objectifs principaux ` atteindre pour un bon algorithme parall`le a e sont les suivants : Un nombre de communications minimum : Les communications permettent de faire circuler les rsultats dun procese seur ` un autre. Si le nombre de communications est important, nous risa quons lengorgement du rseau. e Il faut donc ne dclencher que les communications strictement ncessaires e e et si possible taler les communications dans le temps (tr`s dicile). e e Une utilisation des CPU ` quasi 100% du temps : a Le manque dinformations est forcment bloquant car sans elles, le CPU e ne peut pas travailler. Ainsi, ` chaque moment o` le CPU attend nous a u perdons forcment de la performance en terme de speed-up. e Pour viter ces cueils, les solutions suivantes sont envisageables : e e faire du load balancing : on essaie dquilibrer les charges de chaque procese seur. acheminer les donnes avant den avoir besoin : on a par exemple recours e au recouvrement calculs/communications. Par la suite, nous vous prsentons direntes versions de paralllisation de la e e e plus simple, na ` la plus labore, permettant la gestions des pannes. Nous ve, a e e utilisons frquemment quelques termes pour lensemble des versions : e client : proceseur qui g`re le contenu du JavaSpace et distribue le travail e au dirents travailleurs (on ne parle pas du PC sur lequel est loutrigger ). e

22

Paralllisation de lalgorithme de rfrence e ee

travailleur : processeur qui eecute des calculs.

6.2
6.2.1

Algorithme avec centralisateur


Implantation

An de raliser les premiers tests nous avons cherch ` coder de la mani`re e ea e la plus simple possible. Nous utilisons donc un PC en tant que synchroniseur ou centralisateur, il est charg de rcuprer toutes les informations, de les rarranger e e e e puis de les remettre dans le JavaSpace an que les travailleurs puissent aborder le cycle suivant. Le parc de travailleurs, au nombre de P, reprsente les machines de calcul. e Un travailleur coute si une tche correspondant ` son attente (cest-`-dire ` son e a a a a mod`le ou template ) se trouve sur le JavaSpace. Si oui, il la rcup`re, excute le e e e e travail et la repose sur le JavaSpace. Le centralisateur aura ainsi pour rle de crer p tches que devront eectuer o e a les p travailleurs ou processeurs. Chaque tche est constitue de la liste des N plan`tes et de deux indices a e e (dbut et n) pour la boucle de calcul. Chaque machine devra alors calculer les e positions des N/p plan`tes correspondant aux indices dbut et n. e e

6.2.2

Dploiement e

Nous dcrivons ici comment nous avons dploy les divers services JavaSe e e paces, les travailleurs et le client sur le cluster de 32 PCs. Nous pouvons remarquer que les travailleurs et le client ncessitent chacun un e PC. Il reste donc ` savoir comment rpartir les services JavaSpace. Apr`s plusieurs a e e tests de performance, nous avons remarqu que les dirences sont faibles selon e e que lon concentre tous les services sur un seul PC ou contraire lorsquon les rpartit. Nous avons utilis pour tous nos benchs le diagramme de dploiement e e e reprsent en gure 6.1. Les 32 PCs ` notre disposition sont nomms sh01, sh02, e e a e sh03, ..., sh32. Il sagit de Shuttle Pentium 4 3 GHz avec 1GO de RAM.

6.2 Algorithme avec centralisateur

23

Fig. 6.1 Dploiement sur le cluster de 32 PCs e

24

Paralllisation de lalgorithme de rfrence e ee

6.2.3

Rsultats e

Etudions maintenant les performances obtenues, nous avons pour ce faire utilis le logiciel Matlab. e Le bench sur lequel se basent nos rsultats est le suivant : e
1 2 3

4 5

Pour I de 0 ` 9 faire a Pour J de 0 ` 10+2* I a Calcul parall lis pour 100+200* J plan` tes , 50 e e e cycles et 2+3* I processeurs Fin Pour Fin Pour

Autrement dit, nous eectuons les calculs pour 2,5,8,...,26,29 processeurs et un nombre de plan`tes de plus en plus important avec le nombre de processeurs. e Une premi`re mani`re de visualiser est de reprsenter le temps dexcution e e e e en fonction du nombre de plan`tes et du nombre de processeurs. On obtient e 1 ainsi la surface suivante (gure 6.2) :

Fig. 6.2 Temps dexcution en fonction du nombre de plan`tes et du nombre de processeurs e e pour la version 1 de lalgorithme paralllis e e Cependant, cette reprsentation nest pas tr`s pratique an danalyser les e e rsultats. Nous allons maintentant tudier direntes coupes de cette surface. e e e Tout dabord, on peut vrier que les calculs sont toujours en O(n2 ) pour les e
On parle de surface semi-relle car nous lavons complte grce ` une approximation e ee a a polynmiale de degr 2 pour chaque conguration du nombre de processeurs. Les points rels o e e sont dlimits par la ligne rouge. e e
1

6.2 Algorithme avec centralisateur

25

direntes congurations du nombre de processeurs (gure 6.3). e Lorsque lon reprsente le temps dexcution en fonction du nombre de procese e seurs pour un nombre de plan`tes donn, on obtient dans lidal une hyperbole. e e e Cependant, dans la ralit, plus le nombre de processeurs est important, plus e e leet des communications se fait ressentir. Le rsultat obtenu est reprsent en e e e gure 6.4. Pour un nombre de processeurs infrieur ` 10, on obtient bien un comportement e a hyperbolique. Cependant, ce nest plus le cas au-del`. Faisons alors un bilan des a communications : (tableau 6.1) Nb de plan`tes envoyes e e NP N 2N P Nb de plan`tes recues Nb de connexions e NP 2P N 2 2N P 4P

Client 1 Travailleur Total

Tab. 6.1 Bilan des communications en un cycle pour la version 1 de lalgorithme paralllis e e On remarque ainsi que le client doit envoyer et recevoir N P plan`tes, ce qui e fait un transit total de 2N P plan`tes ; d`s lors, limpact des communications se e e fait ressentir au fur et ` mesure que lon augmente le nombre de processeurs a (par contre cette augmentation ne se fait pas ressentir au niveau du travailleur). En outre, pendant que le client met plus de temps pour rcuprer et envoyer les e e plan`tes, les travailleurs ne peuvent pas travailler. On peut rsumer de la mani`re e e e suivante : pour un nombre de plan`tes donn, plus on augmente le nombre de e e processeurs, plus le client doit grer des communications et consquemment, plus e e les travailleurs sont oisifs.

26

Paralllisation de lalgorithme de rfrence e ee

Fig. 6.3 Temps dexcution en fonction du nombre de plan`tes pour direntes congurae e e tions du nombre de processeurs et pour la version 1 de lalgorithme paralllis e e

Fig. 6.4 Temps dexcution en fonction du nombre de processeurs pour direntes congue e
rations du nombre de plan`tes et pour la version 1 de lalgorithme paralllis e e e

6.2 Algorithme avec centralisateur

27

Analysons maintenant les courbes de speed-up (gure 6.5) :

Fig. 6.5 Courbes de speed-up pour direntes congurations du nombre de processeurs e


pour la version 1 de lalgorithme paralllis e e

Cette courbe est obtenue de la mani`re suivante : e On note T (N, P ) le temps dexcution de notre algorithme paralllis. Nous e e e choisissons comme rfrence T (N, 1). Le speed-up S(N, P ) est alors donn par : ee e S(N, P ) = T (N, 1) T (N, P )

Nous aurions pu galement choisir le temps mis par lalgorithme squentiel e e comme rfrence, mais nous avons remarqu que celui-ci tait tr`s peu dirent ee e e e e de T (N, 1). Ainsi, pour 2 et 4 processeurs, on obtient bien le speed-up dsir, mais pour e e 17 processeurs, on atteint ` peine un speed-up de 8 pour 6000 plan`tes. Pire a e encore, pour 29 processeurs, le speed-up atteint est de 4 ! Lalgorithme ne permet donc pas dobtenir des acclrations convenables. Ici encore, on ressent leet des ee communications grandissantes avec le nombre de proceseurs.

Chapitre 7 Deuxi`me paralllisation de e e lalgorithme de rfrence ee


7.1 Nouveau transit de donnes e

Ayant accumul un peu dexprience, nous sommes alors en mesure de e e concevoir un programme paralllis conomisant un peu plus les communications. e ee En eet, lun des cueils de lalgorithme prcdent est le surcot engendr par e e e u e la mauvaise gestion des informations. En eet, un travailleur prend lensemble des N plan`tes, traite le rsultat et renvoie le mme groupe dans le JavaSpace. e e e Le client se charge alors de rcuprer toutes les informations pour les classer an e e de rmettre P groupes de N plan`tes. ee e Dans la nouvelle version, le client nest plus utilis comme synchronisateur, il e est simplement charg de collecter les informations juges inutiles dans le JavaSe e pace. Le principe du nouvel algorithme est alors le suivant : sur le JavaSpace est prsente la liste des N plan`tes. Chaque travailleur (ou processeur) est charg du e e e calcul pour N/P plan`tes. Pour ce faire, chaque travailleur vient lire les donnes e e directement sur le JavaSpace. Une fois le calcul fait pour un groupe de N/P plan`tes, le travailleur dpose le groupe de plan`tes sur le JavaSpace. Une fois e e e que tous les travailleurs ont ni cette tche, le client fait le mnage en retirant a e les donnes obsol`tes. e e De la mme mani`re que prcdemment, essayons dvaluer les communicae e e e e tions pour cette version (tableau 7.1) : On voit nettement lamlioration : du point de vue Client, au lieu du transit de e 2N P plan`tes, il na plus que N plan`tes transites. Du ct Travailleur, on passe e e e oe de 2N ` N plan`tes transites. On augmente les chances de passage ` lchelle a e e a e (on esp`re obtenir des hyperboles !). e Cependant, il a plus de connexions dclenches dans cette version : on atteint e e

7.2 Travailleur ` recouvrement de donnes a e Nb de plan`tes envoyes e e Client 0 1 Travailleur N/P N Total

29 Nb de plan`tes recues Nb de connexions e N P (P 1)N/P P 1 NP P2

Tab. 7.1 Bilan des communications en un cycle pour la version 2 de lalgorithme paralllis e e

P 2 connexions au total, autrement dit, pour 29 processeurs, 841 connexions par cycle. On esp`re que cela naura pas trop de consquences sur les performances e e du syst`me. e Ct calculs, les travailleurs ont toujours N/P trajectoires ` leur charge mais oe a nont plus en leur possession la totalit des plan`tes. e e

7.2

Travailleur ` recouvrement de donnes a e

Nous avons cherch au maximum ` ne pas perdre de temps CPU. Pour ce e a faire, les travailleurs calculeront en mme temps quils rcupreront les donnes. e e e e Le thread collectant les informations se charge de rcuprer des groupes de e e N/P plan`tes et les place dans une liste que le thread de calcul peut consulter. e Il se met en veille sil a rcupr P 1 paquets de N/P plan`tes. e ee e Le thread de calcul peut alors directement encha ner dune boucle de N/P interactions ` une autre. On recouvre le temps de communication. a

7.3
7.3.1

Introduction dune information de commande


Principe

Nous avons pens ` mettre en uvre un transit dinformations entre le client ea et les travailleurs autre que les donnes de calculs. Il sagit dinformations de e commande concernant le probl`me ` traiter comme le nombre de travailleurs en e a contact, le nombre de cycles ` raliser et le numro de paquet ` traiter ` chaque a e e a a cycle. Cette implantation tait ncessaire car auparavant les tches que le client e e a dposait contenait toutes ces informations. Maintenant, le client ne fournit que e les donnes ` linitialisation et se contente de rcuprer les fruits du calcul, il e a e e nest plus ladministrateur du calcul.

30

Deuxi`me paralllisation de lalgorithme de rfrence e e ee

Il est important de comprendre que cette information de commande nest utilise que lors des initialisations ou des rallocations de tches. En dautres e e a termes le client aecte ` un travailleur cibl deectuer un calcul sur un certain a e groupe de plan`tes, pour un nombre de cycles donn en prcisant le nombre de e e e ses partenaires.

7.3.2

Intrts majeurs e e

Le travailleur conna les informations du probl`me lorsquil ramasse t e la commande dans le JavaSpace. Ainsi un travailleur peut tre utilis e e dynamiquement, il nest plus la peine de le relancer si le probl`me change e ses param`tres (nombre de cycles, nombres de processeurs, ...). e Il est possible dentrevoir une gestion aise des pannes. En eet, si le client e dtecte quune machine ne rend pas ses informations alors il envoie de e nouvelles commandes. Ces commandes ralloueront dynamiquement les e tches de calcul aux machines restantes. a Une troisi`me utilisation est galement possible : la gestion optimale dun e e parc de machines. Si une machine tombe en panne, nous grons cette sie tuation comme dcrit prcdemment. Si une machine se rajoute au rseau, e e e e elle se signale au client qui met de nouvelles commandes an de prendre e en compte la nouvelle machine. Ainsi chaque machine est utilise d`s son e e entre. e

7.4

Rcapitulation du fonctionnement de lalgoe rithme

Les schmas suivants permettent de rcapituler les direntes tapes de lale e e e gorithme, dans le cas de deux processeurs : Etape 1 : Initialisation Le client met en place les chiers de commande, les groupes de plan`tes et les dpose dans le JavaSpace (gure 7.1). e e Etape 2 : Les travailleurs rcup`rent (grce ` take ) leur chier de commande : e e a a ils connaissent dsormais le nombre de processeurs, le nombre de cycles, ainsi que e leur numro (gure 7.2). e Etape 3 : Les travailleurs rcup`rent le groupe de plan`tes correspondant ` e e e a leur numro. Ils peuvent alors commencer ` calculer pendant que le rcolteur e a e rcup`re les autres groupes de plan`tes (gure 7.3). e e e

7.4 Rcapitulation du fonctionnement de lalgorithme e

31

Etape 4 : Le cycle se termine alors : les travailleurs dposent leur rsultat, e e puis commencent ` calculer sur le groupe correspondant ` leur numro et qui a a a e t calcul au cycle prcdent. Pendant ce temps, le client fait le mnage dans le ee e e e e JavaSpace (gure 7.4). Le processus se droule ainsi cycle apr`s cycle. A la n du dernier cycle, il y e e a un vidage complet de lespace.

Fig. 7.1 Etape 1 de lalgorithme paralllis version 2 e e

32

Deuxi`me paralllisation de lalgorithme de rfrence e e ee

Fig. 7.2 Etape 2 de lalgorithme paralllis version 2 e e

7.4 Rcapitulation du fonctionnement de lalgorithme e

33

Fig. 7.3 Etape 3 de lalgorithme paralllis version 2 e e

34

Deuxi`me paralllisation de lalgorithme de rfrence e e ee

Fig. 7.4 Etape 4 de lalgorithme paralllis version 2 e e

7.5 Rsultats e

35

7.5

Rsultats e

Etudions maintenant les performances obtenues, nous utilisons toujours le logiciel Matlab. Nos rsultats sont bass sur le mme type de bench que prcdemment. e e e e e En premier lieu, on peut visualiser la surface qui reprsente le temps e dexcution en fonction du nombre de plan`tes et du nombre de processeurs (e e gure 7.5) :

Fig. 7.5 Temps dexcution en fonction du nombre de plan`tes et du nombre de processeurs e e


pour la version 2 de lalgorithme parallelis e

On remarque une zone de turbulences pour peu de plan`tes et un e grand nombre de processeurs. Cela est srement la consquence du nombre de u e connexions : il y a P 2 connexions par cycle donc elles se font dautant plus ressentir que le temps dun cycle de calcul est faible (moins il y a de plan`tes, plus ce e temps est faible). On peut toujours vrier le caract`re en O(n2 ) de lalgorithme e e (gure 7.6). Lorsque lon reprsente le temps dexcution en fonction du nombre de e e processeurs pour un nombre de plan`tes donn, on obtient cette fois ci une e e hyperbole. Le rsultat est reprsent en gure 7.7. e e e

36

Deuxi`me paralllisation de lalgorithme de rfrence e e ee

Fig. 7.6 Temps dexcution en fonction du nombre de plan`tes pour direntes congurae e e tions du nombre de processeurs et pour la version 2 de lalgorithme paralllis e e

Fig. 7.7 Temps dexcution en fonction du nombre de processeurs pour direntes congue e
rations du nombre de plan`tes et pour la version 2 de lalgorithme paralllis e e e

7.5 Rsultats e

37

Analysons maintenant les courbes de speed-up : (gure 6.5)

Fig. 7.8 Courbes de speed-up pour direntes congurations du nombre de processeurs e


pour la version 2 de lalgorithme paralllis e e

On remarque une amlioration des rsultats : pour 17 processeurs, on arrive e e a ` atteindre un speed-up de 15 (alors que auparavant on atteignait ` peine un a speed-up de 4) et pour 29 processeurs, on atteint un speed-up de 20. Nous essayons maintentant danalyser les rsultats asymptotiques, cest ` dire e a pour un grand nombre de plan`tes (7000) et pour un nombre de processeurs e variant entre 1 et 29. Tout dabord, le temps dexcution en fonction du nombre e de processeurs est reprsent en gure 7.9. e e On remarque que d`s que le nombre de processeurs est important (au del` de e a 5), notre algorithme ne suit pas tout ` fait lhyperbole de rfrence, mais leet a ee des communications se fait moins ressentir. Les gures 7.10 et 7.11 permettent dobserver les speed-up et lecacit. Ces gures conrment bien que le syst`me e e permet dobtenir des acclrations convenables, avec une ecacit de 76 % pour ee e 29 processeurs. On imagine bien cependant que pour un grand nombre de processeurs, le seed-up atteindra une valeur asymptotique maximale (cest ce que lon peut entrevoir sur la courbe 7.10).

38

Deuxi`me paralllisation de lalgorithme de rfrence e e ee

Fig. 7.9 Temps dexcution en fonction du nombre de processeurs pour la version 2 de e


lalgorithme et pour 7000 plan`tes e

Fig. 7.10 Speed-up en fonction du nombre de processeurs pour la version 2 de lalgorithme


et pour 7000 plan`tes e

7.5 Rsultats e

39

Fig. 7.11 Ecacit en fonction du nombre de processeurs pour la version 2 de lalgorithme e


et pour 7000 plan`tes e

40

Deuxi`me paralllisation de lalgorithme de rfrence e e ee

Un autre rsultat intressant est celui de lextensibilit. On essaie de rpondre e e e e a ` la question suivante : lorsquon augmente la taille du probl`me (le nombre de e plan`tes), quel nombre de processeurs permet daboutir ` un temps minimal ? e a Pour ce faire, on trace la courbe dextensibilit : il sagit du temps dexcution e e minimal parmi les congurations du nombre de processeurs possibles en fonction du nombre de plan`tes. Si cette courbe est constante, cela signie que lorsquon e augmente la taille du probl`me, on saura garder le mme temps dexcution par e e e plan`te avec notre syst`me. On obtient la courbe reprsente en gure 7.12. e e e e

Fig. 7.12 Extensibilit pour la deuxi`me paralllisation de lalgorithme de rfrence e e e ee Les rsultats sont tout ` fait satisfaisants : on arrive ` maintenir un temps e a a constant. Ce temps vaut environ 0.3 ms.

7.6

Version sans recouvrement

On sintresse ici aux rsultats obtenus sans recouvrement calculs/communie e cations, cest ` dire lorsque le travailleur rcup`re un groupe de plan`tes, calcule a e e e sur ce groupe de plan`tes, puis rcup`re un autre groupe de plan`tes et ainsi de e e e e suite.

7.6 Version sans recouvrement

41

On reprsente sur la gure 7.13 le gain moyen obtenu de la version e avec recouvrement par rapport ` celle sans recouvrement en fonction du a nombre de processeurs. Ce gain est obtenu avec la formule suivante : G = T emps sans recouvrememtT emps avec recouvrement . On remarque ainsi que lon peut obT emps sans recouvrement tenir des gains tout ` fait intressants (jusqu` plus de 26% pour 29 processeurs). a e a Cela est tout ` fait encourageant et montre que le recouvrement calculs/commua nications est ecace.

Fig. 7.13 Gain moyen de la version sans recouvrement Calculs/Communications par rapport a ` la version avec recouvrement en fonction du nombre de processeurs

Chapitre 8 Tolrance aux pannes e


8.1 Introduction du probl`me e

Nous avons maintenant un algorithme parall`le able qui se prte ` la gestion e e a des pannes. Plusieurs types de pannes ont t identies : ee e Panne du client : critique et dicilement grable car le client rcup`re tous e e e les rsultats intermdiaires. e e Panne dun travailleur : principal objectif et pannes les plus courantes tant e donn du nombre de machines en jeu. e Panne du serveur : critique, pas de solutions ` ce jour. a Panne du JavaSpace : critique, grable par lutilisation du dmon RMI et e e de la persistance. Panne du lookup : non critique par`s la phase de connexion au JavaSpace. e Une grande partie de ce chapitre est donc consacr ` la gestion des pannes ea de travailleurs, probl`me algorithmiquement dicile ` mettre en place et qui e a ncessite dtre robuste. e e

8.2
8.2.1

Gestion des pannes des travailleurs


Mise en place dun syst`me dannonce des trae vailleurs

Notre gestion de ce type de panne est base sur un syst`me dannonce e e priodique des travailleurs. Une annonce est constitue de plusieurs champs : e e du nom du travailleur comme identiant gnral. e e

8.2 Gestion des pannes des travailleurs

43

du numro du travailleur comme identiant en relation avec le travail en e cours. dune valeur boolenne travail ni indiquant si lannonce est nale, cest ` e a dire si le travailleur vient de nir sa tche. a dune valeur boolenne travail en cours indiquant si le travailleur ayant e post lannonce est en cours de travail. e Les deux valeurs boolennes peuvent para redondantes mais sont cependant e tre ncessaires pour grer certaines situations. e e Maintenant, lorsque lon dmarre un travailleur pour le rendre disponible ` la e a tche il poste une annonce portant son nom et ayant les deux valeurs boolennes a e fausses. Lorsque tous les travailleurs disponibles ont t dmarrs, on peut alors lancer ee e e le client. Ce dernier aura pour param`tres, comme prcdemment, un nombre de e e e plan`tes, un nombre de cycles et un nombre de travailleurs. Lors de linitialisation, e il se chargera de rcuprer autant dannonces quil lui en faut. Le client conna e e t alors les travailleurs qui accompliront la tche et aecte, de faon cible, une a c e macro tche ` chacun deux, nous avons dailleurs ajout un champ comportant a a e le nom du travailleur dans le chier de commande. En cas de dfaut de travailleurs, le client se contente alors de ce quil a ` e a disposition. Il annonce alors que lon tourne en sous rgime. e Il y a donc deux actions distinctes ` raliser, celle de la dtection qui consiste a e e a ` armer de la faon la plus sr possible quil y a bien une panne et celle de c u la gestion qui consiste ` avertir les travailleurs an quils se re-initialisent et le a client peut alors rattribuer le travail. Cest ce que nous allons dtailler dans les e e deux prochains paragraphes.

8.2.2

Dtection de la panne e

Pass la phase dinitialisation, le travailleur se met alors ` mettre e a e priodiquement des annonces an de signaler sa prsence. e e De son ct, le client vrie priodiquement son parc de travailleurs. Si une oe e e annonce vient ` manquer, le client consid`re le travailleur en question comme a e tant en panne. e Il est vident ici que cette priodicit risque dengendrer de fausses pannes, e e e en eet, si une annonce met trop de temps ` traverser le JavaSpace le client a consid`re le travailleur rellement actif comme en panne. Cette ventualit est e e e e bien sr inadmissible. u Une question se pose alors concernant ces deux priodes, en eet, sans temps e de communication elles pourraient tre gales. Cependant, la ralit nest pas si e e e e

44

Tolrance aux pannes e

avantageuse, nous pouvons alors modliser le probl`me de la mani`re suivante : e e e (gure 8.1)

Fig. 8.1 Calcul des priodes dannonces et de vrications (gestion des pannes) e e Dans le programme, vu que lincertitude est dicilement mesurable, nous avons pris une priode travailleur gale ` 500 ms et une priode client gale ` e e a e e a 3000 ms. Aucune fausse panne na t signale ` ce jour avec cette conguration. ee e a Avec ce rglage, les pannes sont dtectes avec une certaine incertitude allant e e e de 3000 ms ` 6000 ms ce qui reste acceptable au vu de la quantit de calculs ` a e a eectuer. Il est ` noter quil faudra rajouter ` ce temps celui de la gestion de la a a panne, cest-`-dire, le temps entre la dtection et la remise en route des calculs a e sur une nouvelle conguration.

8.2.3

Gestion des pannes

Comme nous lavons voqu prcdemment, cette partie consiste ` rinitialiser e e e e a e les travailleurs restants puis ` rinitialiser le client. Nous allons dtailler ici la a e e faon dont notre programme fonctionne. c Lorsque le client saperoit de la panne, il se charge denvoyer des chiers de c commande cibls ayant le boolen panne x ` true. Chacun des threads chargs e e ea e de la gestion des pannes ct travailleurs se rend alors compte de la panne. oe A ce moment, le thread dannonce avertit les deux autres threads (Calculateur et Rcolteur) de la panne puis steint. Toute la complexit de la gestion se trouve e e e a ` ce niveau ; il faut dans lordre : En parall`le, lancer la rinitialisation du Calculateur et du Rcolteur qui e e e taient tous les deux en cours de travail. Il faut ainsi placer des tests de e sorties de boucle ` des endroits stratgiques en pensant bien ` ne pas trop a e a inuer sur les lourdes boucles de calcul. Remettre ` un tat cohrent les variables de stockage et de synchronisation. a e e Attendre que chacun des threads ait ni son initialisation.

8.2 Gestion des pannes des travailleurs

45

Annoncer la disponibilit du travailleur sur le JavaSpace. e Attendre la nouvelle commande. La mise en place dun tel syst`me a demand un grand nombre de remaniee e ments , notamment lintervention de nouvelles variables et structures de synchronisation.

8.2.4

Rcapitulatif et schmas de principe e e

Dans les schmas suivants nous allons considrer que les threads Annonceur e e sur les travailleurs et le thread GestionnairesPannes sur le client, constituant les entits de gestion des pannes. e La suite correspond ` un exemple o` deux travailleurs sont disponibles sur le a u JavaSpace, le client en demande en demande galement 2. e Etape 1 : Les travailleurs doivent tre lancs en premier an quils postent e e leurs annonces de disponibilit avant que le client eectue le compte. A ce moe ment, aucun travail na t dclench, les threads de calcul et de rcupration des ee e e e e informations sont en attente. On peut maintenant ajouter le client (gure 8.2). Etape 2 : Initialisation du client Le client rcup`re autant dannonces de e e disponibilit quil en a besoin, en cas de manque, il se contentera de ce quil a et e partitionnera le travail en consquence (gure 8.3). e Etape i : Annonces de prsence : A chaque cycle, les travailleurs annoncent e leur prsence, il ny a donc pas de probl`mes quant au travail ` raliser. Le client e e a e se charge tout simplement de vrier chacune des annonces (gure 8.4). e Cas de prsence de panne : En cas de panne dun travailleur, lannonce e correspondante va manquer sur le JavaSpace. Le client se rend alors compte de la panne et va mettre une commande de rinitialisation aux travailleurs restants. e e Le client va attendre la rinitialisation du travailleur pour se relancer lui-mme e e (lordre des oprations est not par les tiquettes comportant un numro)(gures e e e e 8.5 et 8.6). A ce moment, le syst`me se relance de faon normale sauf que les groupes de e c plan`tes fournies seront les plus rcentes connues, nous ne perdons pas les calculs e e prcdents. e e

46

Tolrance aux pannes e

Fig. 8.2 Gestion des pannes, initialisation des travailleurs

Fig. 8.3 Gestion des pannes, initialisation du client

8.2 Gestion des pannes des travailleurs

47

Fig. 8.4 Gestion des pannes, annonces de prsence e

Fig. 8.5 Gestion des pannes, absence dune annonce 1

48

Tolrance aux pannes e

Fig. 8.6 Gestion des pannes, absence dune annonce 2

8.2 Gestion des pannes des travailleurs

49

8.2.5

Performances obtenues

Nous avons refait un bench complet de cette version de lalgorithme et il est apparu quil ny a aucune dirence notable de performance avec la version sans e gestion des pannes. Lorsquune panne est dclenche, le client renvoie le temps de gestion de la e e panne apr`s dtection, on remarque quelle uctue autour de 2 secondes. e e Le temps total de gestion de pannes se chire alors de 4.5 secondes ` 8.5 a secondes. Les premiers tests ont engendr quelques probl`mes, il apparaissait que pour e e un nombre de plan`tes consquent, de fausses pannes taient dclenches. Nous e e e e e en avons alors dduit que les threads de gestion des pannes ne devaient pas e respecter leur priode respective. Ce probl`me a pu tre gr par la mise en e e e ee place de priorits. Voici celles que nous avons choisies : e Client DeposeurRecolteur, priorit = 1 e GestionnairePannes, priorit = 10 e Travailleur Calculateur, priorit = 1 e Rcolteur, priorit = 2 e e Annonceur, priorit = 10 e Les priorits absolues ont t donnes aux threads de gestion des pannes, e ee e en eet, comme le respect du timing est prioritaire ici et sachant quils sont en sommeil une grande partie du temps de calcul cette dcision ninue pas sur les e performances du syst`me. e Ct travailleur, une priorit a t accorde au Recolteur sur le Calculateur car oe e ee e ce dernier a besoin davoir les informations ncessaires ` chaque n de boucle. e a Si lacc`s ` linformation ne se fait qu` la n de chaque boucle de calcul de e a a N/P interactions il ny a en eet plus de recouvrement dinformations car le Calculateur se mettra alors en attente.

Chapitre 9 Conclusion
Ce projet nous a permis dexplorer la technologie JavaSpace applique ` un e a cluster de 32 Pcs. Grce ` notre probl`me support exigeant en calculs et en a a e communications, nous avons mis en vidence les caractristiques suivantes de e e JavaSpace : Cette technologie permet une programmation parall`le relativement simple. e En eet, les primitives de gestion de lespace sont faciles dutilisation. Une gestion ecace des pannes des postes de calcul est faisable avec des performances tout ` fait acceptables : une panne engendre une perte de a seulement quelques secondes dans le temps total dexcution. e De mme que lon peut grer les pannes de postes de calcul, on peut e e galement prendre en compte larrive de nouveaux Pcs en cours de calcul e e Leort de mettre en place un recouvrement calculs/communications nest pas vain : on atteint un gain en performance tr`s intressant : en moyenne e e 25 % pour 29 processeurs. Pour notre probl`me, le syst`me passe assez bien ` lchelle : on atteint e e a e une ecacit de 76% pour 25 processeurs. e Cependant, des questions restent en suspens. En eet, il faudrait tudier une e gestion des pannes gnralise (cest ` dire que lon envisage galement les pannes e e e a e des services ou du client) ; il pourrait tre galement intressant de parallliser e e e e la version optimise de lalgorithme squentiel. Enn, une derni`re notion est e e e a ` noter : le syst`me passe bien ` lchelle pour notre probl`me en particulier, e a e e mais il faudrait tudier le cas dautres types de probl`mes : produit de matrices, e e relaxation de Jacobi, ...

Annexe A Automatisation des connexions


Pour lancer un calcul parall`le, il faut lancer les dirents services JavaSpace e e ainsi que les PCs sur lesquels se feront les calculs. Cela devient vite fastidieux, car ` chaque fois que lon se connecte sur un PC, il y a une authentication. a Nous avons fait en sorte quil ny ait plus aucune authentication. Nous avons en premier lieu essay de faire en sorte que le password ne soit plus demand pour e e obtenir une connexion directe. Par exemple, pour se connecter ` lordinateur sh16, on tape la ligne de coma mande suivante : ssh sh16 Ensuite nous est demand le login et le mot de passe. e Ainsi, les communications et les changes se font par ssh (Secure Shell) : cest e un protocole qui permet ` des utilisateurs daccder ` des machines distantes a e a grce ` des communications chires (appele Tunnel). a a e e Deux mthodes dauthentication sont possibles : e la mthode la plus connue est le traditionnel mot de passe. Le client envoie e un nom dutilisateur et un mot de passe au serveur au travers de la communication scuris et le serveur vrie si lutilisateur concern a acc`s ` e e e e e a la machine et si le mot de passe fourni est valide (cest cette mthode que e nous voulons viter) e une mthode moins connue mais plus souple est lutilisation de cls pue e bliques. Si lauthentication par cl est choisie par le client, le serveur va e crer un challenge et donner un acc`s au client si ce dernier parvient ` e e a dchirer le challenge avec sa cl prive e e e Cest cette derni`re mthode que nous avons mis en place. e e Ssh sappuie sur des algorithmes ` paire de clefs, ce qui signie que lon a dispose dune clef publique, disponible pour tout un chacun et une clef prive dont e

52

Automatisation des connexions

on garde jalousement lentre. Ce syst`me va nous permettre de nous identier e e aupr`s des htes que nous dsirons contacter. Il nous faut au pralable crer le e o e e e trousseau. Pour cela, on utilise la ligne de commande suivante : ssh-keygen -t rsa On a ainsi cr une paire de clefs base sur lalgorithme dencryptage rsa. ee e Pour tre reconnu dun hte, il sut de copier la clef publique dans le chier e o e o authorized keys du rpertoire .ssh. sur lhte. Maintenant, lorsque lon entre la ligne de commande : ssh sh16 la connexion se fait automatiquement, sans authentication ! Une fois cela acquis, pour automatiser la mise en place des services JavaSpace et des stations de calcul, il sut dcrire un script shell. Nous donnons ci-apr`s par e e exemple le script qui permet de lancer les services JavaSpace :

53

1 2 3 4

# Lancement des services # Serveur ssh sh09 - f / usr / java / jdk1 .5.0 _06 / bin / java - jar / usr / java / Jini2_ 1/ lib / tools . jar - port 8085 dir / usr / java / Jini2_1 / lib - dl sleep 3 s # Rmid ssh sh09 - f / usr / java / jdk1 .5.0 _06 / bin / rmid -J Djava . security . policy =/ tmp / Projet_Boutet_Rahba / Config / jsk - all . policy echo rmid lance sleep 3 s # Reggie ssh sh10 - f / usr / java / jdk1 .5.0 _06 / bin / java - jar Djava . security . policy =/ tmp / Projet_Boutet_Rahba / Config / jsk - all . policy / usr / java / Jini2 \ _ 1/ lib / start . jar / tmp / Projet_Boutet_Rahba / Config / start reggie sleep 1 s # Outrigger ssh sh10 - f / usr / java / jdk1 .5.0 _06 / bin / java -jar Djava . security . policy =/ tmp / Projet_Boutet_Rahba / Config / jsk - all . policy / usr / java / Jini2_1 / lib / start . jar / tmp / Projet_Boutet_Rahba / Config / start outrigger sleep 3 s

5 6 7

8 9 10 11 12

13 14 15 16

17

Bibliographie
[1] W. Keith Edwards. Core Jini. Prentice Hall, 2000. [2] Virginie Galtier. Notice JavaSpace sur le Cluster. Suplec, 2006. e [3] James Gosling, Ken Arnold, and David Holmes. The Java Programming Language. Addison-Wesley Professional, 2000. [4] Kathy Sierra and Bert Bates. Java Tte la premi`re. OReilly, 2004. e e [5] Stphane Vialle. Cours de paralllisme et Grid, Option IIC. Suplec, 2006. e e e