Technique de simulation

L'evaluation d'une architecture multiprocesseur n'est pas une chose aisee. En l'absence d'architecture reelle, elle ne peut ^etre realisee que par simulation ou modelisation. La mode-lisation est generalement employee lorsque le comportement de l'architecture est previsible.

Dans notre cas, la simulation semble plus indiquee car l'inuence du protocole sur le com-portement des memoires attractives n'est pas connu.

Un simulateur d'architecture se compose generalement de trois composants. Un genera-teur d'adresses charge de produire les references memoire, un modele de l'architecture qui modelise le fonctionnement, les operations et les interconnexions entre les composants, et un noyau de simulation qui synchronise la consommation des references memoire produites par le generateur.

VII.1.1 Generateur d'adresses

Le choix de la charge de travail utilisee pour evaluer les performances d'une architec-ture intervient pour une part importante dans la validite et l'extrapolation des resultats de

90 Evaluation du protocole simulation permettant de predire le comportement general de la machine. En l'absence de ge-nerateur de references memoire synthetiques adaptees a des architectures multiprocesseurs, notre etude est menee a l'aide de traces d'adresses d'applications paralleles reelles.

L'evaluation que nous presentons dans ce chapitre est realisee a l'aide du noyau de simu-lation SPAM Ge#aut & Joubert 96]. SPAM assure le tracage des applications paralleles, et permet egalement de mettre en uvre de facon ecace une technique de

simulation coor-donnee a l'execution

(Execution Driven Simulation) Covington et al.88, Daviset al. 91].

Ce type de technique de simulation corrige les defauts des techniques consistant a collecter une trace d'adresse sur une machine puis a l'utiliser pour en simuler une autre (Trace Driven Simulation). En eet, si ces dernieres techniques sont valides dans le cas sequentiel, elles se heurtent dans le cas parallele au probleme de

decalage de traces

(Trace Shifting) Du-bois et al. 86]. Ce probleme appara^t lorsque les traces des processus ne sont plus en phase avec l'execution que l'on devrait obtenir sur l'architecture simulee. Il est engendre par les dierences existant dans les executions possibles d'une m^eme application parallele sur des machines possedant des caracteristiques dierentes. Une technique de simulation coordonnee a l'execution inhibe le decalage de trace et permet d'obtenir des resultats de simulation plus realistes.

Avec une technique de simulation coordonnee a l'execution, la production des traces et l'execution de l'application, s'eectuent sous le contr^ole du simulateur, de facon simultanee a la simulation de l'architecture cible. A chaque fois qu'un processus de l'application tracee desire eectuer une operation pouvant avoir un impact sur la trace generee, l'execution du processus et donc la production de sa trace d'adresse est arr^etee avant l'execution de l'operation. Lorsque la trace du processus a ete simuleejusqu'a cette operation, l'operation est eectuee par le simulateur qui libere alors le processus. L'execution parallele etant controlee par le simulateur, la trace d'adresse obtenue est exactement celle qui serait produite si l'application avait ete reellement executee sur la machine simulee.

Le noyau SPAM fournit toutes les primitives necessaires au contr^ole de l'execution des processus d'une application parallele s'executant sur une station de travail de type SUN. Il permet donc de simuler de facon realiste des architectures multiprocesseur a partir d'une machine monoprocesseur.

VII.1.2 Simulateur et noyau de simulation

Le corps du simulateur utilise est ecrit en C++ et utilise une librairie de simulation a evenements discrets Schwetman 92]. Cette librairie fournit un ensemble de primitives permettant la creation, la gestion et la synchronisation de processus legers au sein d'un m^eme processus UNIX. Chacun des composants de l'architecture cible (processeur, cache, memoire attractive...) est modelise par un objet C++. Chaque objet est independant et possede une interface qui lui permet d'envoyer ou de recevoir des requ^etes. Un objet n'a pas connaissance des composants auxquels il est connecte, lorsqu'il desire envoyer un message

Technique de simulation 91

Évènements

Simulateur Contrôle de l’exécution

Caractéristiques de l’architecture

Résultats de simulation Processus

Processus Processus

Application parallèle Exécution +

génération trace

Figure VII.1 Simulation coordonnee a l'execution

son interface se charge de delivrer le message a l'objet auquel il est connecte. Il est ainsi fort simple d'ajouter de nouveaux composants dans l'architecture simulee.

Chaque nud de l'architecture est simule gr^ace a un processus leger interagissant avec l'ensemble des composants de l'architecture. L'interfacage entre le simulateur et le noyau de simulation SPAM est realisee de facon simple gr^ace aux primitives oertes par SPAM.

Chacun des objets processeur est connecte a un des processus de l'application tracee de sorte que chacun des nuds de l'architecture correspond a un des processus de l'application.

Aucune migration de processus n'est consideree pendant les simulations.

VII.1.3 Charge de travail

Il existe a l'heure actuelle assez peu d'applications pour des multiprocesseurs a memoire partagee permettant de construire un ensemble d'applications representatif et coherent. La suite d'applications SPLASH (Stanford Parallel Applications for Shared Memory) Singh et al. 91] a ete developpee an de servir de base aux evaluations de performance des multipro-cesseurs a memoire partagee. Elle est constituee de sept applications scientiques provenant de domaines varies tels que le calcul mathematique, l'aeronautique, l'oceanographie ou la CAO de circuits. Cet ensemble d'applications a deja ete utilise dans un tres grand nombre d'etudes de performances Joe & Hennessy 94, Hagersten et al.91, Gupta & Weber 92, Wil-kinson 93, Stenstr!omet al.92] et tend a devenir un standard dans le domaine de l'evaluation des multiprocesseurs a memoire partagee.

92 Evaluation du protocole

VII.1.3.1 Applications choisies

Dans notre evaluation, nous retenons quatre applications de SPLASH :

Barnes-Hut

,

Cholesky

,

Mp3d

et

Water

. Ces applications paralleles fournissent un panel de comporte-ment vis a vis de la memoire partagee qui donne a notre evaluation toute sa validite. Toutes ces applications sont ecrites en C et utilisent les macro-instructions du Argonne National Laboratory (ANL) pour la gestion de la memoire partagee et de la synchronisation. Elles ont ete initialement developpees pour des machines a base de bus garantissant un temps d'acces uniforme a la memoire (UMA). Elles ne font donc aucune hypothese sur le place-ment des donnees par rapport aux processeurs. Les applications se composent d'un ensemble de processus travaillant sur un espace memoire partage. Un processus

pere

est charge de l'initialisation des structures de donnees et du lancement d'un nombre parametrable de pro-cessus

ls

identiques. Les dierents processus d'une application se synchronisent a l'aide de verrous d'exclusion mutuelle (locks) et de barrieres assurant des

rendez-vous

.

VII.1.3.2 Description des applications

Ce paragraphe decrit brievement les applications retenues pour notre evaluation. Il donne aussi leur comportement et les parametres d'entree utilises dans les simulations.

Barnes-Hut

simule l'evolution d'un systeme de corps sous l'inuence de forces de gravitation. C'est une simulation de N corps classique, ou chacun des corps est modelise par un point et une masse, et exerce des forces sur l'ensemble des autres corps du systeme. L'execution se divise en etapes de calcul des forces suivie d'une mise a jour des positions des dierents corps. Pour limiter les recherches des corps, l'algorithme utilise une representation hierarchique de l'espace sous la forme d'un arbre. Les etapes de l'execution sont separees par des barrieres. Au debut de chaque etape, les corps sont repartis selon les processeurs an d'ameliorer l'equilibrage de charge. Les simulations utilisent 1536 corps durant 11 etapes de simulation.

Cholesky

realise la factorisation d'une matrice creuse. La repartition du travail entre les processeurs est dynamique et est realisee a l'aide d'une le de travaux partages protegee par des verrous d'exclusion mutuelle. Les simulations utilisent la matrice bcsstk14 de taille 512x512.

Mp3d

simule les contraintes de pression et de temperature s'exercant sur un objet volant a grande vitesse dans les couches hautes de l'atmosphere. Le programme simule le deplacement et les collisions d'un ensemble de molecules d'air dans un "tunnel"

represente par un ensemble de cellules. Les collisions peuvent se produire avec les autres molecules, le vehicule ou contre les bords du tunnel. L'algorithme est parallelise en divisant statiquement les molecules suivant les processeurs qui se synchronisent a chaque etape de calcul. Nous utilisons 50000 particules dans un espace de taille 14x24x7 cellules durant 8 etapes de calcul.

Parametres de simulation 93

Water

simule les interactions a l'interieur d'un systeme de molecules d'eau a l'etat liquide. La repartition des moleculesentre les processeurs est realisee statiquement.Des barrieres synchronisent les etapes de calcul. Le temps d'execution de cette application variant enO(n²) en nombre de molecules, les simulations sont lancees avec un ensemble de travail reduit variant de 120 a 144 molecules suivant le nombre de processeurs, pendant 2 pas de simulation.

Le choix des parametres d'entree des applications est essentiellement dicte par le temps necessaire aux simulations. Les simulations les plus longues (Mp3d) prennent en moyenne 13 heures sur une station SUN SS10.

Les caracteristiques des applications utilisees sont presentees dans la table VII.1. Leur comportement vis a vis des caches est etudie notamment dans Gupta & Weber 92].

Applications Parametres Instructions Lectures Ecritures Lectures Ecritures

(millions) partagees partagees

Barnes-Hut 1536 corps 190 49,5 (18,4%) 28,7 (10,7%) 11,1 (4,2%) 0,27 (0,1%) 11 iterations

Cholesky bcsstk14 53,1 17.6 (23,3%) 4.7 (6,2%) 14,2 (18,8%) 2,5 (3,3%) Mp3d 50 K molecules 48,3 10,6 (16,3%) 6,3 (9,7%) 8,6 (13,1%) 5,4 (8,3%)

8 pas

Water 120/144 molecules 78,6 26,8 (23,7%) 7,8 (6,9%) 4,9 (4,3%) 0,58 (0,5%) 2 iterations

Table VII.1 Caracteristiques des applications simulees

Dans le document THESE. presentee devant. pour obtenir. Le Titre de Docteur de l'universite de Rennes I. par. Alain GEFFLAUT. Titre de la these (Page 93-97)