Ecole doctorale IAEM - DEA Informatique de Lorraine

Ecole doctorale IAEM - DEA Informatique de Lorraine

Conception d’une bibliotheque de calcul

cellulaire etendue sur cluster et grille de

clusters, disposant de modes decommunications hybrides.

Rapport de Stage de DEA

soutenance le 28 Juin 2005

Composition du jury :Membres permanents : Dominique Mery

Didier GalmicheNoelle Carbonell

Representant de la filiere : Dieter KratschEncadrant : Stephane Vialle

Didier [email protected]

SUPELEC, Technopole Metz 2000. 2 rue Edouard Belin. 57070 Metz

Remerciements

Mon stage a Supelec et l’issue de ce stage, n’auraient jamais ete rendus pos-sibles sans l’aide et le soutien de certaines personnes.

Je souhaiterai remercier d’abord Stephane Vialle, professeur et chercheura Supelec qui m’a permis de m’epanouir a travers ce sujet en m’apportant deserieuses connaissances dans le domaine, ainsi qu’un encadrement efficace.

Mon stage n’aurait pas ete aussi prolifique, sans la presence de tout le person-nel du departement informatique de Supelec, et entre autres de mes collegues debureau, Jacques Henry, etudiant de DEA et Mircea Ifrim, Lucian Alecuetudiants de l’universite Polytechnique de Bucarest.

Table des matieres

Introduction

1 Etat de l’art des langages cellulaires 1.1 Concepts de base . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1.1 Automates cellulaires . . . . . . . . . . . . . . . . . . . . 1.1.2 La granularite du parallelisme . . . . . . . . . . . . . . . . 1.1.3 Les langages cellulaires . . . . . . . . . . . . . . . . . . . . 1.1.4 Langages paralleles contemporains . . . . . . . . . . . . .

1.2 Les solutions materielles . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 CAM-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Une ”CA machine” a processeur virtuel realisee en FPGA 1.2.3 Inconvenients des solutions materielles . . . . . . . . . . .

2 Problematique du passage a l’echelle pour les calculs a grainfin 2.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1.1 Granularites des applications, des langages et des machines 2.1.2 Un compromis entre temps de developpement et temps

d’execution . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Interets economiques . . . . . . . . . . . . . . . . . . . . .

2.2 Difficultes relatives au mapping grain fin / gros grain . . . . . . . 2.2.1 Quelques difficultes soulevees lors de l’analyse de ParCeL-

6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Le modele conceptuel ParCeL-6 et son modele de Programma-tion ParCeL-6.2 associe 3.1 Apercu du modele conceptuel ParCeL-6 . . . . . . . . . . . . . . 3.2 Recherche d’un bon compromis (besoins utilisateur / besoins ar-

chitecture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Besoins de l’architecture . . . . . . . . . . . . . . . . . . . 3.2.2 Besoins de l’utilisateur . . . . . . . . . . . . . . . . . . . .

3.3 Architecture client / serveur . . . . . . . . . . . . . . . . . . . . . 3.4 Gestion cellulaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Specifications des communications cellulaires . . . . . . . . . . .

3.5.1 Modes de communication definis dans ParCeL-6 . . . . . 3.5.2 Restriction des communications cellulaires dans ParCeL-6.2

TABLE DES MATIERES

4 Strategie d’implantation de P6.2 4.1 Problemes d’heterogeneite des machines . . . . . . . . . . . . . . 4.2 Gestion parallele des donnees . . . . . . . . . . . . . . . . . . . .

4.2.1 Variables Globales . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Unicite des Cellules . . . . . . . . . . . . . . . . . . . . .

4.3 Librairies assurant la portabilite . . . . . . . . . . . . . . . . . . 4.3.1 MPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2 SSCRAP . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4 Techniques de communication et de synchronisation . . . . . . . 4.4.1 Schema de communication sous MPI . . . . . . . . . . . . 4.4.2 Les communications sous SSCRAP . . . . . . . . . . . . .

5 Experimentations et Mesures de Performances de P6.2 5.1 Cout de la mise en place de l’application . . . . . . . . . . . . . .

5.1.1 Experimentations ParCeL-6.2 / MPI . . . . . . . . . . . . 5.1.2 Experimentations ParCeL-6.2 / SSCRAP . . . . . . . . . 5.1.3 Bilan des Analyse du cout de surcharge des couches MPI

et SSCRAP . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Autres mesures de performances . . . . . . . . . . . . . . . . . .

Conclusion

Introduction

Dans de nombreux domaines de recherche, comme par exemple discretiserla matiere en physique ou encore la mise en œuvre d’applications corticalesutilisant des reseaux de neurones, les chercheurs se heurtent au prix tres elevede super-calculateurs, ou au manque de performances d’ordinateurs a proces-seurs scalaires. Une solution serait de disposer de systemes cellulaires operantde maniere parallele sur un ensemble de machines a processeurs scalaires afinde pouvoir augmenter significativement les ressources utilisables. Cependant,il n’est pas forcement evident de gerer la coordination de tout un systeme depetites entites de travail, ni de pouvoir garantir l’interoperabilite efficace deplusieurs machines distinctes d’un cluster. ParCeL-6 est un modele de pro-grammation developpe a Supelec pour tenter de resoudre ces problemes, touten recherchant le meilleur compromis confort d’utilisation / performance. Nousallons presenter ici les reflexions et solutions apportees afin d’obtenir une im-plantation pour machines a architecture a memoire distribuee.

Dans une premiere partie, nous allons aborder les concepts des langages cel-lulaires simples et paralleles ainsi que certaines solutions materielles deja pro-posees a ce jour. Puis nous discuterons les problemes relatifs au passage a echellepour les calculs a grain fin. Finalement, nous developperons les objectifs de cestage, les modeles de programmation et de strategie passes en revus ainsi queceux retenus, avant de terminer par les resultats obtenus tout au long de cestage de DEA.

Section 1

Etat de l’art des langagescellulaires

1.1 Concepts de base

ParCeL-6.2 est une bibliotheque de calcul cellulaire etendue sur cluster1 dePCs, disposant de modes de communication hybrides et mis au point a partirdu modele de programmation ParCeL-6 developpe a Supelec. Afin de mieuxsaisir la notion de langage cellulaire, il convient de presenter tout d’abord lanotion fondamentale qui en est la base, a savoir l’automate cellulaire. Nouspresenterons egalement dans ce chapitre quelques langages cellulaires deja exis-tants, ainsi que le principe de langage parallele generique avant de terminer pardes exemples d’applications de langages cellulaires.

1.1.1 Automates cellulaires

Les automates cellulaires sont apparus dans les annees 1950 alors que J. VonNeumann[1] s’interessait a representer l’autoreproduction en biologie par unmodele abstrait. En 1970, les automates cellulaires ont gagne de la popularitelorsque Martin Gardner presenta le jeu de la vie de Conway dans le journalScientific American.

Concretement, les automates cellulaires sont des systemes constitues d’unnombre important d’elements simples, stables et petits (les cellules) qui inter-agissent chacun avec leur voisinage, et qui se mettent a jour. Habituellement,les automates cellulaires (CA) sont supposes operer de maniere synchrone, cequi signifie que toutes les cellules sont mises a jour simultanement. Cependant,on peut decider de mettre a jour les cellules une par une, et l’ordre de mise ajour peut etre completement aleatoire par exemple. Alternativement, la cellulea etre mise a jour au cycle suivant peut etre determinee directement par lesregles d’evolution du CA[3].

1 : grappe de PCs


Un automate cellulaire dispose d’une fonction de transition qui est l’ensembledes regles qui permettent de determiner le nouvel etat d’une cellule en fonctionde son etat precedent et de l’etat precedent de son voisinage.

Differentes topologies de reseaux existent pour permettre de relier les cellulesd’un automate cellulaire. Parmi les plus classiques, l’on retrouve les matrices(de dimensions 1 a 3) et les tores. Ainsi la distance entre les cellules d’un memevoisinage est bornee et identique pour toutes les cellules.

De plus, il a ete demontre[3] qu’un automate cellulaire est equivalent a unemachine de Turing. Les automates cellulaires sont donc interessants d’un pointde vue programmation car ils permettent des calculs extremement distribues eta grain fin, utiles par exemple a des applications corticales.

Les applications corticales sont composees de reseaux d’entites appelees neu-rones, qui sont des sortes de cellules fonctionnant de maniere parallele a l’instardes neurones du cerveau humain. Elles se pretent bien a une implantation a basede langages ou automates cellulaires. L’exemple le plus simple est l’idee d’unrobot qui doit analyser l’image recue par ses capteurs pour essayer d’attraperun objet, et le systeme d’apprentissage de ce robot est base sur des connexionsentre neurones. Ce projet utilise d’ailleurs le langage cellulaire ParCeL-6.1.

1.1.2 La granularite du parallelisme

Empiriquement, on peut definir[4] la granularite comme le rapport entre letemps de calcul divise par le temps de communication.

Ainsi pour diminuer la granularite, il faut decouper chaque tache en sous-taches plus petites. On parle de grain plus fin. En pratique, diminuer la granu-larite augmente le parallelisme potentiel et permet d’utiliser plus de processeurs.Inversement, augmenter la granularite consiste a regrouper des taches. On parlealors de grain plus gros[9]. Augmenter la granularite permet de reduire le tempsnecessaire a la gestion du parallelisme.

On recherche souvent la granularite ideale pour une application et une ma-chine.

1.1.3 Les langages cellulaires

La plupart des langages cellulaires sont en fait bases sur le modele de pro-grammation d’un automate cellulaire. On peut ainsi recenser entre autres :Cellang2[15], CARPET3[17], ou encore la famille de langages ParCeL4.

2Cellular automata programming language3CellulAR Programming EnvironnemenT4Parallel Cellular Language


CARPET

CARPET[17] est un langage de programmation de haut niveau base sur latheorie des automates cellulaires. Il est concu pour permettre le developpementd’applications paralleles de haute performance tout en cachant l’architecturede la machine sous-jacente ce qui ajoute un certain confort d’utilisation. Lesmodeles definis sont composes de cellules discretes identiques reparties en ma-trices de dimension 1, 2, ou 3. Les automates cellulaires sont implementescomme un nombre de processus, dont chacun est situe sur un processeur dis-tinct, qui execute le meme code sur differentes donnees (SPMD5).

CARPET a la particularite de pouvoir definir des etats types pour ses cel-lules, ce qui permet une plus grande facilite d’implantation pour l’utilisateur.Par contre, l’evolution des cellules ne peut s’effectuer que de maniere syn-chrone, et il n’existe pas de canaux de communications differenciesentre les cellules.

De plus, CARPET permet de decrire des problemes qui sont representes pardes automates cellulaires a partir d’informations soumises :

– sa dimension, 2 ou 3,– le rayon de voisinage des cellules,– l’etat des cellules et chaque etat est divise en sous-etats types.

On voit donc ici que CARPET est trop parametrable en profondeur ce quitend a le rendre bas niveau alors que CARPET se voulait a la base une bi-bliotheque de haut niveau. Enfin, la seule information qu’une cellule peut obte-nir d’une autre est son etat.

Cellang

Le langage Cellang6[15] fait partie de l’environnement de simulation d’auto-mates cellulaires Cellular [16]. Il permet de definir des automates cellulaires a ndimensions, contrairement a CARPET qui se limite a 3 dimensions et il utiliseegalement des agents. Ces derniers sont de petites particules qui permettent derepresenter de maniere claire un ensemble de valeurs qui se deplace de celluleen cellule.

Cependant, le seul type de donnee disponible est le type entier, ce qui limiterapidement l’interet de Cellang dans les domaines qui font appel au calculen nombres reels. L’etat d’une cellule est ainsi represente par un ensemble denombres entiers.

De plus, seuls les voisinages de cellules rectangulaires sont autorises, ce quireduit considerablement la variete de voisinages utilisables.

5Single Program Multiple Data6Cellular automata programming language


La famille de langages ParCeL

La famille des ParCeL, quant a elle, commenca vers 1990 a Supelec, en col-laboration avec le LORIA.

Puis ParCeL-4/Hibs[24] en 1999 fut developpee pour repondre plus parti-culierement aux besoins des domaines corticaux et pour permettre la creationde reseaux de cellules plus simple.

Finalement en 2000, le modele theorique ParCeL-6 fut mis au point. ParCeL-6.2, que l’on va precisement etudier dans la suite de cet ecrit, en est un modelederive. Il vise le domaine d’application du ”calcul cellulaire” qui regroupe lesmodeles de calculs reguliers a espace et temps discrets. Ces modelessont abondamment utilises en simulation numerique et ont des caracteristiquescommunes avec les automates cellulaires.

FIG. 1.1 - Parallelisation d’un reseau de neurones par ParCeL-6 sur cluster etgrille de clusters.

1.1.4 Langages paralleles contemporains

Les langages cellulaires ont pour principales caracteristiques la communi-cation et la synchronisation entre les taches. On trouve dans un premier casles langages paralleles a communications par partage de memoire, et dans undeuxieme temps les langages paralleles a communications par envoi de messages(sur machines a memoire distribuee).

Langages paralleles a partage de memoire

Comme leur nom l’indique, les langages paralleles a communications par par-tage de memoire sont utilises dans des environnements ou la memoire est par-tagee entre tous les processeurs d’une machine. Les taches a realiser sont alorshabituellement des threads qui peuvent etre POSIX, Solaris, Windows... Onpeut aussi trouver des langages paralleles a memoire partagee derives de lan-gages logiques et fonctionnels comme Prolog[20] ou Lisp[21].

Si la gestion du partage des donnees est souvent realisee par le systeme lui-meme, il n’en est pas de meme pour la synchronisation des acces aux donneesqui reste souvent a la charge du programmeur. Il existe differents outils de syn-chronisation, allant de la semaphore (tres generique et portable) aux barrieresde synchronisation implantees seulement sur certaines architectures.


Langages paralleles a envois de messages

Les langages paralleles a envois de messages sont utilises pour programmerun ensemble de processus ayant des espaces memoire distincts. Cela implique dedevoir acheminer les donnees par un moyen quelconque entre chaque processeurcommuniquant.

Afin de gerer ce probleme, des bibliotheques d’envoi de messages dedieesau parallelisme ont ete developpees a l’instar de MPI7, CORBA. Plus parti-culierement, il existe deux bibliotheques de messages portables et assez connuesderivees du standard MPI : ce sont MPICH et lam/MPI.

Bien que le passage par messages ne releve pas tous les defis du passage aechelle sur grille[7], il permet de coupler plusieurs plateformes, d’architecturespotentiellement differentes, afin d’executer des applications MPI par exemple.Le programmeur doit toujours faire face a quelques taches lourdes telles quedecomposer les calculs, la repartition des charges, la disposition des donnees etla gestion des temps de latence.

Il existe egalement des bibliotheques de plus haut niveau comme SSCRAP8[10],qui est developpee au LORIA par l’equipe Algorille. SSCRAP est une bi-bliotheque developpee en C++ qui offre des outils de communication et desynchronisation pour les algorithmes a gros grain. SSCRAP est la premiere bi-bliotheque a supporter tous les modeles de programmation a gros grain basessur le passage de messages. En effet, elle permet l’implantation des algorithmesBSP[19], CGM[11] et PRO[12] en supportant simultanement leurs modelesd’execution respectifs. En offrant un haut niveau d’abstraction, SSCRAP prenden charge efficacement les echanges et les synchronisations inter-processeurs touten offrant a l’utilisateur des mecanismes de communication simples et puissants.

Langages a partage de memoire sur DSM

Il existe egalement des bibliotheques de partage virtuel de memoire au niveaudu systeme d’exploitation sur des clusters, entre autres les DSM9 logicielles,comme Kerrighed. Il existe des solutions du meme type mais plus rapides en-core : les DSM materielles. Mais leur cout eleve les rend difficilement accessible.

Une fois une DSM installee sur un cluster, celui-ci peut alors supporter leslangages paralleles a partage de memoire. Mais ces systemes ne sont pas efficacespour tous les types d’applications, et ne passent pas encore a l’echelle (leurnombre de noeuds par cluster est fortement limite).

7Message Passing Interface8Soft Synchronized Computing in Rounds for Adequate Parallelization9Distributed Shared Memory

1.2 Les solutions materielles


Apres avoir passe en revue les principales applications du calcul cellulaire, no-tamment differents langages cellulaires sequentiels et paralleles, il peut paraıtreinteressant de se pencher vers des solutions materielles afin d’evaluer leur interetface aux solutions logicielles. Dans un premier temps, nous allons presenter unordinateur parallele nomme CAM-8[13], avant d’evoquer une machine baseesur des FPGA[14].

1.2.1 CAM-8

CAM-8[13] est une architecture d’ordinateur complexe, basee sur des auto-mates cellulaires, qui fut creee en 1993, au MIT par l’equipe de Norman Mar-golus. Elle fut concue sur plusieurs echelles : systeme, boıte, carte et circuitsintegres specialises ASIC.

– Le systeme consiste en une ou plusieurs boıtes reliees entre elles dans unreseau torique 3D, ce qui permet d’en connecter un tres grand nombre enparallele sans que surgissent des problemes architecturaux ou logiciels.

– Les ASIC concentrent toute l’intelligence de l’architecture. L’utilisateurpeut controler de nombreux parametres comme la largeur des cellules, lenombre de dimensions ou les conditions aux limites.

La possibilite de configurer le voisinage site par site est un avantage nonnegligeable mais tres couteux en temps de mise au point. Une carte peutacceder a des elements non contigus dans la memoire. Cela permet aussi biende calculer dans des espaces a N dimensions ou d’effectuer des interactions nonlocales.

De plus, la CAM-8 a deja servi pour des recherches dans des domaines tresvaries mais l’interface est encore rudimentaire et la configuration des ASICnecessite de nombreux efforts logiciels ce qui n’oriente pas du tout la CAM-8vers la minimisation du temps de developpement de modeles de programmation.

1.2.2 Une ”CA machine” a processeur virtuel realisee en FPGA

Cette machine basee sur des FPGA10[14] est en fait un second pro-jet mene a bien par l’equipe de Norman Margolus au MIT. C’est plus parti-culierement une architecture FPGA pour les calculs systoliques bases sur desDRAM11. Le fonctionnement est similaire a celui de CAM-8, mais avec des sim-plifications, et des capacites accrues dues a l’utilisation de DRAM et de FPGAqui conferent une plus grande celerite que la SRAM et le processeur de CAM-8(25Mhz). L’interconnexion repetee des cellules forment le voisinage. Cette ar-chitecture permet alors d’etre 2 fois plus efficace que CAM-8 en ajoutant desfonctionnalites interessantes a la ”CA machine” de part la reprogrammabilited’un FPGA.

10FPGA : familles de circuits logiques programmables11DRAM : memoire a acces dynamique aleatoire


Toutefois, cette machine montre rapidement ses limites lorsque l’on augmentela dimension de l’automate cellulaire ; au-dela de 3 dimensions la realisationest tout simplement impossible. Pour finir, l’utilisation de FPGA ajoute dela flexibilite, mais au detriment encore de la rapidite de developpement d’unmodele de programmation.

1.2.3 Inconvenients des solutions materielles

L’inconvenient de ces methodes est qu’il faut descendre a un tres bas niveaumateriel, et developper du materiel completement specifique a ce type d’applica-tions. De plus, le fait que ces caracteristiques soient materielles fige la machine,et la rend peu ou difficilement evolutive. De plus, ces machines demandent desprocesseurs particuliers plus couteux que les processeurs standards des PCs.

Section 2

Problematique du passage al’echelle pour les calculs agrain fin

Jusqu’a present, nous nous sommes uniquement attardes sur les concepts debase des langages cellulaires sequentiels et paralleles, en les presentant toutd’abord, puis en citant quelques exemples de solutions materielles. Nous avonsegalement presente les inconvenients de ces dernieres, mais il apparaıt des main-tenant important d’approfondir les principaux interets de ces langages ainsi queles differents problemes de passage a echelle qu’ils peuvent engendrer.

2.1 Motivations

Avant meme de s’interesser plus en profondeur aux langages cellulaires eux-memes, il est imperatif de presenter le but d’un tel langage.

2.1.1 Granularites des applications, des langages et des ma-chines

On definit la granularite comme le rapport entre la quantite de communica-tions et la quantite de calculs sequentiels locaux a chaque processeur. Ces calculssont en fait simplement les calculs effectues entre chaque communication.

Les communications rajoutent typiquement de l’overhead a une application,alors que les calculs locaux peuvent permettre un gain de temps, surtout si lesphases de communications sont bien separees et que l’on peut les regrouper.Les algorithmes cellulaires d’applications cellulaires, sont a grain fin. De plus,les applications fortement basees sur les automates cellulaires, disposent d’unvoisinage delimite. A l’inverse, dans ParCeL-6 il n’y a pas de delimitation devoisinage, et chaque cellule peut etre amenee a communiquer avec n’importequelle autre cellule du reseau d’interconnexion.

2.1 Motivations

On distingue plus precisement trois types de granularite :– la granularite naturelle du parallelisme d’une application,– la granularite de la machine utilisee,– entre ces deux granularites, il y a egalement la granularite encouragee par

le modele de programmation.

Dans la section 1.2.2, nous avons cite un exemple extreme. En effet, la ma-chine basee FPGA presentee est faite pour des applications a grain fin, disposed’une architecture favorisant le grain fin, et encourage le grain fin de par sonmodele de programmation.

A l’extremite opposee de l’echelle granulometrique se trouvent les calculs agros grain et les calculs a tres gros grain (appeles ”parallelisme embarras-sant”), pour lesquels chaque sous-probleme est independant de tous les autresproblemes. C’est le cas, par exemple, des simulations dites de Monte Carlo.Ces methodes consistent a faire varier les parametres d’un modele complexed’un systeme reel et a etudier les resultats en utilisant des techniques statis-tiques - une sorte d’experience informatique. Chaque calcul peut alors etre faitindependamment des autres. Ce type de granularite correspondrait parfaite-ment a un reseau de PCs, meme interconnectes seulement en Fast Ethernet.

Avec ParCeL-6, le but est d’avoir un modele de programmation a grain finpour des applications a grain fin tres variees. ParCeL-6 doit ici permettre, en re-groupant et en optimisant les communications, de transformer ce grain fin en ungros grain, afin de beneficier de machines a architectures gros grain qui sont ac-tuellement bien plus abordables et plus generalistes que les supers-calculateurspar exemple.

2.1.2 Un compromis entre temps de developpement et tempsd’execution

Afin de faciliter l’implantation d’une application cellulaire, il faut que le lan-gage cellulaire propose soit le plus ergonomique, et le plus simple d’utilisation. Ildoit egalement permettre de mettre au point des modeles tres pointus, appelesmodeles a grain fin, a l’instar des systemes constitues de tres nombreuses petitesentites communicantes (reseaux de neurones). Tout ceci doit par exemple aiderles chercheurs, qui ont pour habitude de souvent effectuer des modifications surleurs modeles de programmation, a minimiser le temps de developpement.

Au final, on cherchera avec ParCeL-6 a proposer un modele de program-mation parallele, qui soit un bon compromis entre optimisation dutemps de developpement et optimisation du temps d’execution, afinde diminuer la somme du temps de developpement d’une application cellulaire,et des differents temps d’execution.

2.2 Difficultes relatives au mapping grain fin / gros grain

2.1.3 Interets economiques

Les premiers super-ordinateurs ont ete construits autour de microprocesseursvectoriels specifiques. Cette famille de microprocesseurs pipeline les operationselementaires pour calculer rapidement les operations d’algebre lineaire cou-rantes. En particulier, les ordinateurs Cray ont largement exploite cette tech-nique. Mais le prix des machines a base de microprocesseurs vectoriels les rendaccessibles seulement aux gros centres de calcul. Bien que les microprocesseursvectoriels soient toujours plus performants que les microprocesseurs scalairesclassiques, la difference de performance a tendance a diminuer. Aujourd’hui,beaucoup de constructeurs de super-ordinateurs utilisent des processeurs sca-laires courants, moins couteux et plus evolutifs.

L’ideal serait donc de pouvoir utiliser ParCeL-6 sur ce type de machines aprocesseurs scalaires moins couteux et plus evolutifs afin de beneficier de cesatouts financiers.

2.2 Difficultes relatives au mapping grain fin / grosgrain

Nous allons ici discuter de certains langages cellulaires paralleles deja evoquesdans les sections 1.1.3 et 1.1.4 et montrer que pour la plupart, il existe desproblemes caracteristiques peu ou prou solubles. Nous allons alors discuter lesdifficultes que nous avons pu rencontrer pour notre part lors de l’analyse et laconception de ParCeL-6.2.

FIG. 2.1 - Representation schematique d’un mapping grain fin vers gros grain.

2.2.1 Quelques difficultes soulevees lors de l’analyse de ParCeL-6.2

Lors de la conception du modele de programmation de ParCeL-6.2, nousavons repris le modele de base de ParCeL-6 deja existant en essayant del’ameliorer, et egalement en l’adaptant aux specificites de ce que l’on attend ; a


savoir nous disposions deja d’une version visant les machines a memoire par-tagee (de type SMP) appelee ParCeL-6.1, et nous souhaitons a present nousorienter vers une bibliotheque pour machines a memoire distribuee qui pourrasubir sans trop de problemes un passage a echelle sur clusters et eventuellementgrilles.

Afin de garantir une portabilite, et ce a grande echelle, nous avons uti-lise une bibliotheque de communications optimisee implantee sur Pthreads etsur MPI, du nom de SSCRAP[10], dont nous avons d’ailleurs deja evoque lesavantages en section 1.1.4. A titre de rappel, SSCRAP apporte des modelesde communication efficaces et de haut niveau, il est operationnel sur plusieurssystemes comme par exemple Linux, Windows, Solaris, IRIX..., il dispose d’unfonctionnement identique sur SMP et sur Cluster, et finalement, il peut utiliserdes schemas de communications MPI rapides et optimises.

Deuxiemement, et contrairement a une utilisation sur SMP ou l’on peut uti-liser des modes de communication directs entre les cellules, sur une architecturedistribuee il est pratiquement irraisonnable de penser utiliser un tel mode. Eneffet, implanter sur une architecture distribuee signifie utiliser des envois demessages. Ceci impliquerait une surcharge trop importante du reseau d’inter-connexion des ressources, ainsi que des envois de messages ”non planifies” atout moment, et des messages de petites tailles. C’est pourquoi le mode directest completement abandonne dans la version ParCeL-6.2.

D’autre part, nous avons rencontre quelques problemes au niveau du modede communication hybride, sense apporte un compromis entre communica-tions directes et buffered. Sous ParCeL-6.1, on utilisait un etalonnement desrafraıchissement des entrees des cellules :

– le rafraıchissement sur un processeur a lieu lors de la premiere lecture parune cellule de ce processeur,

– il y a au plus un rafraıchissement effectue par processeur a chaque cycle.

Etant a present sur architecture distribuee, ce type d’etalonnement, avecdeclenchement du rafraıchissement a tout moment n’est plus acceptable. Il estbeaucoup plus legitime et efficace de preferer un mode de communication hy-bride ou les rafraıchissements sont etales, mais planifies et regroupes, mode quenous preciserons dans la section 3.5.2.

Finalement, puisque l’on se place dans un contexte distribue, il faut mettreau point des mecanismes specifiques d’echanges de donnees entre l’utilisateuret les cellules qu’il cree :

– un mecanisme qui permet d’envoyer des donnees differentes a chaque cel-lule,

– un mecanisme qui permet de copier sur tous processeurs, des donnees quetoutes les cellules doivent pouvoir acceder,


– un mecanisme qui permet de regrouper les resultats produits par les cel-lules et les mettre a disposition de l’utilisateur.

Section 3

Le modele conceptuelParCeL-6 et son modele deProgrammation ParCeL-6.2associe

3.1 Apercu du modele conceptuel ParCeL-6

Les principaux concepts du modele ParCeL-6 se retrouvent dans un modeleplus ancien nomme BSP1, presente en 1990 par L. Valiant [19]

Le modele BSP est le premier modele gros grain et de loin le modele quia suscite le plus d’interet d’un point de vue experimental. C’est l’un des pre-miers modeles qui tient compte de l’aspect communication tout en offrant uneabstraction permettant de formaliser le modele d’architecture en quelques pa-rametres. Il offre au programmeur une vision abstraite tres simple de la machinesous-jacente. Elle se compose de trois elements :

– un ensemble de paires processeur-memoire,– un reseau de communication entre ces paires, qui permet de transmettre

des messages point-a-points,– un mecanisme efficace permettant la synchronisation de ces entites ou

seulement d’une partie de ceux-ci.

FIG. 3.1 - Modele architectural d’une machine BSP1BSP : Bulk Synchronous Parallel

3.2 Recherche d’un bon compromis (besoins utilisateur / besoinsarchitecture)

Dans ce modele, le nombre de processeurs, la capacite et la rapidite du reseaupour acheminer et synchroniser des donnees, sont les points les plus importants.

Cependant, il est encore plus interessant de preciser que le modele BSP peutetre percu en tant que modele de calcul : on ne considere plus les processeursreellement disponibles, mais des processeurs virtuels qui seront executes sur lamachine. Leur nombre est independant du nombre de processeurs reels.

Si l’on nomme step (ou ”etape”) l’unite de base de calcul, ie. operation envirgule flottante, un programme BSP peut alors se composer d’une suite desupersteps qui sont executes sur des processeurs virtuels qui seront eux memesrepartis sur les processeurs reels. Chaque superstep est constitue de 3 steps :calcul, communications et synchronisation. Chaque cellule est activee une etune seule fois seulement par superstep.

On voit ici clairement que certaines specificites se pretent particulierementbien a une utilisation dans le modele conceptuel ParCeL-6, par exemple, l’al-ternance de phases de calcul et de communication.

Nous allons a present nous attarder sur le modele de programmation deParCeL-6.2, apres avoir decortique certains problemes a resoudre. Il faut sa-voir que ParCeL-6.2 est un modele de programmation adapte aux architecturesa memoire distribuee, derive du modele conceptuel ParCeL-6. La plupart desjalonnements ont donc deja ete poses dans ParCeL-6.

3.2 Recherche d’un bon compromis (besoins utilisa-teur / besoins architecture)

Pour des applications de type cellulaire, les developpeurs aimeraient pouvoircreer de petites entites qui echangent sur demande de petits messages, alorsque les architectures standards d’aujourd’hui sont beaucoup plus efficaces si cesont de gros envois planifies a l’avance.

Le modele de ParCeL-6.2 doit donc etre un compromis entre deux types debesoins :

– les besoins de l’architecture pour atteindre de hautes performances,– les besoins de l’utilisateur pour developper rapidement un modele cellu-

laire a grain fin.

3.2.1 Besoins de l’architecture

Tout d’abord, les architectures contemporaines sont pour la plupart devenuesdes architectures a gros grain. L’interet d’utiliser ce type d’architecture est quel’on puisse beneficier d’architectures paralleles modernes, a base de composantsstandards du marche, et donc a moindre cout.

3.3 Architecture client / serveur

Le fait que les architectures actuelles soient plus favorables a acheminer degros envois de messages planifies, implique que nous devons essayer de trouverun moyen de grouper les communications par paquet et de planifier des etapesde communication pour convenir aux attentes de l’architecture. De plus, etantdonne que les envois/receptions doivent etre synchronises, cela implique doncque le regroupement des communications ne doit pas avoir d’impact negatif surles temps de communications au final.

3.2.2 Besoins de l’utilisateur

Comme nous l’avons deja evoque dans la section 2.1.2, ParCeL-6.2 faitpartie des langages cellulaires paralleles dont le but est de reduire le temps dedeveloppement des applications cellulaires. Les developpeurs aiment pouvoirutiliser de petites entites, ici des cellules, qui s’echangent de petits messages surdemande, comme precise plus haut. ParCeL-6.2 doit donc offrir a l’utilisateurun modele de programmation a grain fin a base de cellules.

3.3 Architecture client / serveur

ParCeL-6.2 est un modele de programmation sur architectures a memoiredistribuee , qui permet de fournir un serveur TCP parmi l’ensemble des pro-cesseurs, de maniere a ce qu’un client puisse toujours de maniere transparenteacceder a un serveur. Pour cela, un processeur maıtre sera elu a chaque executiond’une application P6.2 ; il pourra avoir ete designe par l’utilisateur, ou alors parle hasard.

FIG. 3.2 - Architecture Client-Serveur utilisee

3.4 Gestion cellulaire

Dans cette section, nous allons a present decrire la gestion des entites pharesde ParCeL-6.2, a savoir les cellules. Elles sont definies selon les trois criteressuivants :

3.5 Specifications des communications cellulaires

– creation dynamique de cellules : l’utilisateur est libre de definir un nombrequelconque de cellules,

– migration de cellules impossible : tentative d’eviter des saturations intem-pestives du reseau d’interconnexion,

– repartition equitable des cellules sur les ressources disponibles.

En ParCeL-6.1, version orientee architectures a memoire partagee, les cellulespouvaient etre creees dynamiquement par le serveur a l’intercycle sequentiel, oupar d’autres cellules en parallele.

Il est techniquement possible de faire de meme en ParCeL-6.2, cependant seull’intercycle sequentiel est reellement exploitable. En effet, les immatriculationsde cellules creees par une cellule mere, restent locales a cette derniere et nepeuvent etre exportees vers toutes les cellules du reseau.


3.5.1 Modes de communication definis dans ParCeL-6

Il existe 3 types de protocoles de communication entre les cellules :

– mode direct : un canal d’entree d’une cellule branche sur une sortie di-recte d’une autre cellule mettra immediatement a jour sa valeur apres unedemande de rafraıchissement, mais seulement une fois par cycle et par ca-nal d’entree. De plus, les sorties directes et leur mode de rafraıchissementpeuvent engendrer une sorte d’execution asynchrone.

– mode buffered : un canal d’entree connecte a une sortie buffered d’unecellule, rafraıchira automatiquement sa valeur, mais seulement entre deuxcycles de calculs, a l’inter-cycle precisement. Les sorties buffered ap-portent une sorte d’execution synchrone.

– mode hybride : un canal d’entree connecte a une sortie hybride auraun rafraıchissement intermediaire : ni trop ”on demand” (a la demande)comme une connection a une sortie directe, ni trop rare comme uneconnection a une sortie buffered. Les sorties de cellules hybrides imposentun compromis entre executions asynchrones et synchrones.

Quelques experimentations sur des problemes de relaxation et sur des systemescorticaux, ont montre que le mode asynchrone implique une convergence rapidedes reseaux cellulaires (moins de cycles de calculs sont necessaires), mais aussiun temps d’execution accru, en raison des rafraıchissements on demand quigenerent des communications non planifiees qui perturbent les calculs. A l’op-pose, les modes synchrones apportent une convergence plus lente, mais chaquecycle est execute plus rapidement.


FIG. 3.3 - Mode de communication direct

FIG. 3.4 - Mode de communication buffered

Le mode de communication hybride a pour but de converger rapidement touten s’executant rapidement. Mais les specifications de ce mode de communica-tion ne sont pas arretees et dependent de l’architecture utilisee (architecturea memoire partagee, cluster a memoire distribuee, grilles...). Deux modes hy-brides sont actuellement disponibles, l’un dans ParCeL-6.1 pour les machines amemoire partagee, et l’autre dans ParCeL-6.2 pour les clusters (voir ci-apres).

3.5.2 Restriction des communications cellulaires dans ParCeL-6.2

Puisque ParCeL-6.2 se veut etre le modele de programmation pour architec-tures a memoire distribuee base sur ParCeL-6, il serait logique qu’il dispose demodes de communication plus ou moins identiques. Cependant, il n’en est rien.

– mode direct : impossible car il faudrait passer par des envois de mes-sages pour la lecture directe de sorties de cellules. Or le mecanisme peutdevenir beaucoup plus lent, du par exemple a des saturations du reseausous-jacent lors de rafraıchissements permanents.

– mode buffered : il est conforme a sa definition dans le modele concep-tuel ParCeL-6.


– mode hybride : il a ete agence comme un decoupage temporel des cycles.En fait, les cycles sont decoupes en sous-cycles, et au cours d’un sous-cycle, une partie des entrees des cellules est rafraıchie et une partie descellules est activee. Les cellules a activer et les entrees a rafraıchir sontdeterminees independamment, afin de s’eloigner du fonctionnement syn-chrone du mode buffered et de se rapprocher du mode direct. En revanche,les communications restent regroupees et planifiees comme en buffered.

FIG. 3.5 - Mode de communication hybride de ParCeL-6.2

Section 4

Strategie d’implantation deP6.2

A present que nous avons discute le modele de programmation de ParCeL-6.2, nous pouvons nous pencher vers les strategies d’implantation sous-jacentesaux choix arretes. Nous allons donc passer en revue les problemes causes parl’heterogeneite des machines et leurs solutions, ainsi que les gestions des donneesen parallele sur les differentes ressources, et finalement nous allons nous attardersur une etude de differentes synchronisations existantes.

4.1 Problemes d’heterogeneite des machines

Bien que ParCeL-6.2 vise les clusters de PCs plutot homogenes, il seraitinteressant de le faire evoluer sur grille dans un futur proche. Les machinespourront donc avoir des architectures ou des composants differents, imposantune certaine heterogeneite. De plus, il n’y a pas que les machines qui peuventajouter de l’heterogeneite, mais aussi les capacites et les rapidites des reseauxd’interconnexion utilises.

4.2 Gestion parallele des donnees

A present, il est interessant d’evoquer la maniere de gerer les donnees enparallele entre les differents processeurs, ou les differentes cellules qui se trouventsur n’importe lequel des processeurs.

4.2.1 Variables Globales

Premierement, il faut bien se remettre dans le contexte des architecturesdistribuees que l’on vise. Cela signifie que contrairement a une architecture amemoire partagee ou les variables sont facilement partagees, ici, il faut trouverle moyen d’avoir les memes variables sur les differentes machines, et maintenira jour les valeurs.

4.3 Librairies assurant la portabilite

Sous SSCRAP, le comportement vis a vis des variables globales est differentsuivant la librairie utilisee : MPI ou encore les Pthreads POSIX. Ainsi, lorsqueSSCRAP utilise MPI, chaque processeur dispose de sa variable, alors que siSSCRAP utilise les Pthreads POSIX, il n’y a qu’une variable pour l’ensembledes processeurs.

Au final, pour parer a ce petit probleme et rester portable, il a ete decided’eviter les variables globales et de creer une structure allouee dynamiquement,qui contient toutes les variables ”globales” a un processeur et qui est en faitallouee depuis la fonction principale du programme. Cette structure est passeede fonction en fonction de maniere a ce que l’on ait acces a toutes ces variablesa n’importe quelle etape.

4.2.2 Unicite des Cellules

Afin de ne pas se retrouver avec des cellules en double, et egalement desavoir router les informations vers des cellules, il etait imperatif de disposerd’un identificateur unique pour chaque cellule. Pour cela, la solution qui futtrouvee, est de generer un matricule pour chaque cellule. Chaque matricule esten fait constitue de 3 numeros qui sont :

– le numero du processeur qui a demande la creation de la cellule,– le numero du processeur cible ou la cellule doit etre creee,– le numero propre a la cellule sur le nombre total de cellules a creer.

Ceci garantit alors l’unicite de chaque cellule. Un mecanisme de hash tablepermet ensuite de retrouver facilement une cellule sur un processeur.

4.3 Librairies assurant la portabilite

4.3.1 MPI

MPI permet de s’affranchir d’un certain nombre de differences de plates-formes. Par exemple, MPI est operationnel sous Linux, Windows, Solaris... Parcontre, MPI ne gere pas le passage d’une machine 32bits a une machine 64bits.Il y aurait des pertes d’informations, et donc des problemes d’executions. Celareste donc a l’utilisateur de faire attention a ce genre de problemes.

4.3.2 SSCRAP

SSCRAP[10], pour rappel, est une bibliotheque developpee au LORIA aNancy par l’equipe Algorille. SSCRAP offre a l’utilisateur le choix entre lesbibliotheques MPI, PVM, et les threads POSIX pour assurer les fonctions decommunications de base. Ces outils de communication de bas niveau sont situesau niveau d’abstraction le plus profond de la bibliotheque et sont completementtransparents et inaccessibles a l’utilisateur. L’utilisation de bibliotheques por-tables telles que MPI, et les threads POSIX confere a SSCRAP une bonne

4.4 Techniques de communication et de synchronisation

portabilite. SSCRAP s’occupe alors, par exemple, d’optimiser les transactionsMPI de maniere a ce qu’elles soient regroupees efficacement.

FIG. 4.1 - Relations entre MPI, SSCRAP et ParCeL-6.2

4.4 Techniques de communication et de synchroni-sation

Dans cette section, nous allons nous attarder plus en profondeur sur lesdifferents moyens de communication et de synchronisation qui nous etaient of-ferts pour implanter ParCeL-6.2. Nous allons dans un premier temps discuterles deux modes les plus interessants proposes par MPI, puis nous allons evoquerce qui est propose dans SSCRAP.

4.4.1 Schema de communication sous MPI

Dans un premier temps, il fut decide d’experimenter une version de ParCeL-6.2 disposant de modes de communications completement ”synchrones non blo-quants” : ISSEND/IRECV. Ce type de mode de communications est senseparfois etre plus rapide qu’un mode bloquant. Cependant, nous avons rencontrequelques limitations de MPI qui ne voulait simplement pas se lancer pour unnombre trop important de communications non bloquantes simultanees. Il adonc fallu se contenter d’un mode de communication somme toute performant :BSEND/RECV (envoi bufferise bloquant).

Sous MPI lorsque l’on envoie de grosses donnees d’un point a un autre, ilfaut qu’a la reception les variables de receptions soient allouees a la bonnetaille pour pouvoir y stocker les informations recues. Pour cela, il faut doncenvoyer avant, un message d’information qui donne la taille des donnees a venirdans le prochain envoi. Ainsi, un envoi de donnees sous MPI se passe en deuxtemps dans ParCeL-6.2 :

– Envoi de messages entre processeurs, pour s’informer de la taille desdonnees qui seront transmises,

– Envoi des donnees.

4.4 Techniques de communication et de synchronisation

4.4.2 Les communications sous SSCRAP

Du cote de SSCRAP, nous avons deja montre qu’il pouvait apporter plusieurssimplifications par rapport a une implantation MPI. Nous allons encore icidecouvrir qu’il va meme parfois plus loin, en proposant d’autres types d’echangede donnees. Il existe, en SSCRAP 4, differents types de communications :

– les communications par passage de messages : communications point-a-point, de groupes...,

– les communications generales : elles offrent un plus haut niveau d’abstrac-tion que les routines habituelles. Elles decrivent l’ensemble des donneeslocales sous forme d’un tableau distribue sur les differents processeurs,

– le partage de donnees de controle en DRMA : cela permet a l’utilisateurde specifier les structures de donnees partagees utilisees pour rendre lesdonnees de controles accessibles a distance sans recours a un mecanismepar passage de message,

– la redistribution d’un vecteur reparti : SSCRAP offre la possibilite despecifier un vecteur de taille n reparti sur l’ensemble des processeurs etde le redefinir durant l’execution de sa distribution.

FIG. 4.2 - Redistribution d’un vecteur global en SSCRAP

Section 5

Experimentations et Mesuresde Performances de P6.2

Il est temps de presenter les experimentations qui ont pu etre menees a bienainsi que les mesures de performances qui ont ete realisees.

Il faut preciser que tous les tests que l’on va presenter ont ete executes sur uncluster de 32pcs Pentium4 3GHZ, 1Gb de memoire vive, reseau gigabit ethernet,2 switch DELL 16 ports gigabit.

Au niveau systemes d’exploitation, ParCeL-6.2 a ete teste de maniere concluantesur Windows et sur Linux RedHat Fedora Core3. Cependant la portabilite deMPI et de SSCRAP implique que ParCeL-6.2 est utilisable sur d’autres plates-formes comme IRIX, Solaris... Les tests presentes ont quant a eux ete faitsexclusivement sous Linux[6] RedHat Fedora Core3.

En ce qui concerne les versions de MPI et SSCRAP, ce fut respectivementles versions 1.2.6 et 0.8.1 qui furent utilisees pour realiser ces mesures de per-formances. SSCRAP fut interface avec MPI lorsqu’il etait utilise et ce, afind’optimiser les envois de messages, tout en gardant certains interets de MPI.

5.1 Cout de la mise en place de l’application

La premiere question a laquelle il faut naturellement repondre avant d’effec-tuer des tests de performances est la suivante : Le temps de mise en place dureseau cellulaire est-il negligeable ? En effet, il convient de s’assurer que le lan-cement d’une application avant qu’elle ne soit operationnelle reste negligeablecar on ne saurait se permettre d’avoir un temps cumule ”temps d’initialisationParCeL-6.2 - temps de mise en place du reseau - temps de finalisation ParCeL-6.2” plus important que la somme des temps de calcul et de communication.

5.1.1 Experimentations ParCeL-6.2 / MPI

La figure 5.1 ci-apres montre ainsi les differents temps que sont :


– le temps d’initialisation : il comprend les initialisations MPI ainsi quetoutes les preallocations suffisantes pour permettre la mise en place dureseau d’interconnexion,

– le temps de creation du reseau cellulaire : il represente le temps mis pourrepartir les cellules sur les differents processeurs, derniere phase avantl’utilisation des cellules et du reseau d’interconnexion.

FIG. 5.1 - Temps requis pour la mise en place d’un reseau de 850 000 cellulesen ParCeL-6.2 / MPI.

On y retrouve egalement le temps total comprenant a la fois le temps d’ini-tialisation et le temps de creation du reseau cellulaire. On voit tout d’abordici, que dans la majeure partie des cas nous restons en dessous de 4 secondes.De plus, le temps total demarre a a peine plus de 2 secondes pour croıtre treslegerement, ceci etant le signe d’un nombre de communications en hausse pourrepartir les cellules sur les differents processeurs.

Il est par contre possible de remarquer un probleme au dela de 16 processeurs.En effet, les temps d’executions s’envolent litteralement jusqu’a etre doubles.L’une des explications plausibles d’un tel overhead est que justement au-delade 16 processeurs, on passe d’un switch 16 ports a un autre. Cette hypothesesera renforcee dans la section 5.1.2 lors des mesures de performances sousParCeL-6.2 / SSCRAP.

Si l’on souhaite etre encore plus precis dans les mesures de performances decette implantation, il est interessant de mesurer egalement le temps de finali-sation de l’application qui desalloue les structures de donnees et qui comprendegalement la finalisation MPI. La figure 5.2 suivante illustre parfaitement ce casde figure.


FIG. 5.2 - Temps requis pour la mise en place d’un reseau de 850 000 cellulesen ParCeL-6.2 / MPI avec terminaison de l’application.

On remarque immediatement une grande difference entre la figure 5.1 et lafigure 5.2. Alors que le temps de finalisation est quasi-nul pour un seul proces-seur, il augmente fortement pour atteindre pratiquement 3 secondes pour deuxprocesseurs. Puis il decroıt pour redevenir quasiment nul. Ce pic a deux pro-cesseurs, est en fait une hausse de temps d’execution provoque par la directiveMPI Finalize. Le prejudice subit n’est alors pas a reporter sur la qualite del’implantation du modele de programmation ParCeL-6.2, mais il est probable-ment a mettre au credit d’un probleme d’installation de notre cluster.

Il est important de souligner egalement, que les mesures de performancespour le couple ParCeL-6.2 / MPI se sont arretees a 850 000 cellules maximumenviron, car au dela MPI n’arrivait plus a se lancer. Apres plusieurs recherches,en correlation avec d’autres laboratoires sur des forums scientifiques, il semble-rait que MPICH ne puisse pas operer correctement a partir d’un trop grandnombre de communications simultanees. Il faut ensuite regrouper et optimiserles communications. Nous arrivons donc a une premiere limitation de ParCeL-6.2.

5.1.2 Experimentations ParCeL-6.2 / SSCRAP

Apres avoir montre les principaux points relatifs aux temps de mise en placede reseau cellulaire sous ParCeL-6.2 / MPI, il est interessant d’operer les memesmesures de performances sur l’ensemble ParCeL-6.2 / SSCRAP. La figure 5.3presente l’ensemble des temps d’execution totaux pour differentes quantites decellules a creer. En fait, SSCRAP etant optimise pour permettre un portagea l’echelle, il se trouve facilement ”a l’aise”, contrairement a MPI, pour gererbeaucoup plus de 850 000 communications.

Les mesures de performances s’echelonnent donc de 850 000 cellules a 3 000000 de cellules ce qui montre entre autre une grande robustesse de SSCRAP


par rapport a la quantite de communications a effectuer.

FIG. 5.3 - Temps requis pour la mise en place d’un reseau cellulaire enParCeL-6.2 / SSCRAP.

Sur la figure precedente, nous disposons de temps d’execution pour 850 000,1 000 000 et 3 000 000 de cellules. Nous avons egalement ajoute le tempsd’execution de la version ParCeL-6.2 / MPI pour 850 000 cellules, afin de menerune etude comparative.

Tout d’abord, il est important de preciser que l’echelle du graphique de me-sures de performances est logarithmique. Concernant les courbes ParCeL-6.2/ SSCRAP, il est facile de remarquer que les courbes sont quasiment lineaire.Ceci signifie que l’on est en presence d’une acceleration tres reguliere (”exten-sible”). Il est interessant egalemement de souligner que les courbes ParCeL-6.2/ SSCRAP sont similaires dans leur evolution, la taille des donnees n’influantpas.

Par contre, il faut preciser imperativement que pour un meme nombre decellules a creer, la version SSCRAP est jusqu’a 20 fois plus lente que la versionMPI pour 1 processeur. Cet ecart, diminue avec l’augmentation du nombrede processeurs disponibles. On observe d’ailleurs qu’au dela de 8 processeurs,l’implantation SSCRAP se revele plus efficace. Ceci est en fait le resultats deplusieurs circonstances.

Premierement, l’implantation ParCeL-6.2 / MPI beneficie d’un passe d’im-plantation important sous C et MPI a travers les librairies ParCeL-1 a ParCeL-5. ParCeL-6.2 est donc le fruit de plusieurs annees de developpement. Il enresulte une bonne optimisation de ses structures des donnees, ce qui lui confereune tres bonne efficacite.

A l’inverse, l’implantation ParCeL-6.2 en C++ et SSCRAP est la premiere dugenre dans l’histoire de ParCeL, et elle peut eventuellement souffrir de quelques

5.2 Autres mesures de performances

defauts de jeunesse. Il se peut qu’il y ait eu un oubli de passage d’une donneepar reference, ce qui aurait occasionne une recopie des donnees et donc unralentissement de l’application.

5.1.3 Bilan des Analyse du cout de surcharge des couches MPIet SSCRAP

En conclusion, il apparaıt que le cout occasionne par l’utilisation de MPIest quasiment negligeable. Meme si l’on considere que le temps de finalisationMPI est important pour 2 processeurs, il reste en deca de 3 secondes, ce qui estraisonnable, d’autant plus que le plus important dans une application cellulairedistribuee est principalement le temps d’execution reel. SSCRAP, quant a elleet sous reserve d’une bonne implantation de ParCeL-6.2 l’utilisant, est un peuplus lourde, mais se fait vite oublier de part ses communications optimiseesqui lui conferent une bonne acceleration lors de l’augmentation du nombre deprocesseurs.

5.2 Autres mesures de performances

D’autres mesures de performances sont actuellement prevues :– etude de l’impact des communications basiques sur une application cellu-

laire– mesures de performances de ParCeL-6.2 sur des clusters ou des grilles de

clusters

Ces mesures commencent des la fin de redaction de ce rapport.

Conclusion

Alors que nous disposions deja d’un modele de programmation ParCeL-6.1,stable, efficace et valide, inspire du modele conceptuel ParCeL-6, ce dernierne pouvait aucunement etre utilise sur des architectures a memoire distribuee,puisque concu pour des machines a memoire partagee. Une etude fut meneeparallelement a ce sujet par un collegue, visant a determiner si l’utilisationd’une DSM1 pouvait permettre l’utilisation de ParCeL-6.1 sur une machinea memoire distribuee. Cependant les performances furent deraisonnables et iln’y avait plus aucun gain de performance. C’est pourquoi, mettre au pointune version de ParCeL-6, directement prevue pour des architectures a memoiredistribuee prend tout son sens. Nous avons d’ailleurs exhibe dans ce rapportdeux versions disponibles en MPI et SSCRAP, chacune des deux versions ayantses atouts ; a savoir que la version MPI est extremement rapide tant que lenombre de communications reste raisonnable, mais que la version SSCRAP estautrement plus portable a l’echelle, et beaucoup plus efficace lors de tres grandesquantites de communications.

La prochaine etape consistera a corriger l’implantation en C++ / SSCRAPpour eliminer le surplus d’execution par rapport a la version MPI, et pouvoirproposer ainsi une version completement optimisee. De plus, cette version of-frirait des perspectives de portage sur clusters et grilles de clusters a grandeechelle a l’instar de GdX2, ou encore Grid’5000.

1Systeme a memoire virtuelle partagee2Grid eXplorer, cluster d’environ 1000 processeurs

Bibliographie

[1] Cosma Rohilla Shalizi Cellular Automata, 2005, University of Michigan,http ://cscs.umich.edu/∼crshalizi/notebooks/cellular-automata.html.

[2] Paul-Jean Cagnard The Parallel Cellular Programming Model,Parallel and Distributed Processing, 19-21 Janvier 2000, 8th EuromicroWorkshop, pp.283-289.

[3] Zbigniew Skolicki Evolving desynchronized cellular automata, 2003,George Mason University,unpublished paper : http ://cs.gmu.edu/∼zskolick/pubs/skolicki03evolving.pdf.

[4] Martha Rosa Castaneda Retiz Etude quantitative des mecanismesd’equilibrage de charge dans les systemes de programmation pour le cal-cul parallele, 18 Fevrier 2004, INPG Grenoble, PhD thesis.

[5] Thomas E. Portegys An Abstraction of Intercellular Communication, Ar-tificial Life (MIT Press) (8) pp.75-78, 2002, Illinois State University.

[6] A. Agueev, B. Dane, W. Fengler Cellular Computing on a Linux Clus-ter, 04-06 Octobre 2000, 45th International Scientific Colloquium, IlmenauTechnical University.

[7] C. Lee, S. Matsuoka, D. Talia, A. Sussman, M. Mueller, G. Allen, J. SaltzA Grid Programming Primer, August 2001,Global Grid Forum, Advanced Programming Models Working Group.

[8] David J. Lilja A Multiprocessor Architecture Combining Fine-Grained andCoarse-Grained Parallelism Strategies, May 1994, Parallel Computing (Vol.20, No. 5) pp.729-751, University of Minnesota.

[9] Reiner Hartenstein Coarse Grain Reconfigurable Architectures, 02 Fevrier2001, Conference Center, Pacifico Yokohama, Yokohama, Japan.

[10] Isabelle Guerin Lassous, Mohammed Essaıdi, Jens Gustedt SSCRAP : SoftSynchronized Computing in Rounds for Adequate Parallelization

[11] F. Dehne, A. Ferreira, E. Caceres, S.W. Song, A. Roncato Efficient ParallelGraph Algorithms for Coarse-Grained Multicomputers and BSP, Janvier2002, Algorithmica, 33(2) pp.183-200.

[12] J. Gustedt, J.A. Telle, A.H. Gebremedhin, I. Guerin Lassous PRO : Amodel for parallel resource-optimal computation 2002, 16th Annual Inter-national Symposium on High Performance, pp.106-113 IEEE.

[13] Norman Margolus CAM-8 : a computer architecture based on cellular au-tomata, 15 Decembre 1993, Pattern Formation and Lattice-Gas Automata,edited by A. Lawniczak and R. Kapral.

BIBLIOGRAPHIE

[14] Norman Margolus An FPGA architecture for DRAM-based systoliccomputations, 16-18 April 1997, 5th IEEE Symposium on Field-Programmable Custom Computing Machines (FCCM ’97), Napa Valley,CA, USA.

[15] J. Dana Eckart Cellang 2.0 : Language reference manual, 1992, ACM SIG-PLAN Notices, 27(8).

[16] J. Dana Eckart A cellular automata simulation system : Version 2.0, 1992,ACM SIGPLAN Notices, 27(8).

[17] Domenico Talia Solving Problems on Parallel Computers by Cellular Pro-gramming, 2000, International Parallel and Distributed Processing Sym-posium Workshops, Mexico, pp.595-603.

[18] C. Veenhuis and M. Koppen Document Oriented Modeling of Cellular Au-tomata, 01-04 decembre 2002, 2nd Int. Conference on Hybrid IntelligentSystems (HIS02), Santiago, Chili.

[19] L. G. Valiant General purpose parallel architectures, 1990, In Handbook ofTheoretical Computer Science, (J. van Leeuwen, ed.), North Holland.

[20] J.Y. Rousselot, V. David, C. Fraboul, P. Siron Designing and program-ming a reconfigurable parallel architecture, 1992, Transputer’s92 Advancedresearch and Industrial applications, IOS Press pp.246-261, Amsterdam.

[21] Jose Piquer Parallelisme et Distribution en Lisp, 1991, Polytechnique, PhdThesis.

[22] Michel McGuigan Quantum Cellular Automata from Lattice Field Theo-ries, 31 Mai 2003, Simons Conference on Quantum and Reversible Com-putation, Stony Brook.

[23] Massimo Falcioni, Angelo Vulpiani, Giorgio Mantica, Simone PigolottiCoarse-grained probabilistic automata mimicking chaotic systems, 25Juillet 2003, Phys Rev Lett. 91(4) :044101. Epub, 24 Juillet 2003.

[24] Radu Kopetz Extension of a parallel library for cellular computing on acluster of PCs and on computer grids, 2004, Universitatea Politehnica Bu-caresti.

Ecole doctorale IAEM - DEA Informatique de Lorraine

Documents

Transcript of Ecole doctorale IAEM - DEA Informatique de Lorraine