Application `a la m´ethode multifrontale parall`ele

L’algorithme 5.3 d´ecrit le m´ecanisme bas´e sur des variations de charge. `A chaque variation de la charge d’un processus P<sub>i</sub>, P<sub>i</sub> diffuse la variation de charge vers tous les autres processus. Il est `a noter qu’un m´ecanisme de seuil est utilis´e pour limiter le nombre de messages de type maj charge ´echang´es. De plus, nous utilisons le mˆeme m´ecanisme que celui pr´esent´e dans l’algorithme 5.2 pour la gestion des informations relatives aux s´elections d’esclaves. En effet, apr`es chaque s´election d’esclaves, le processus maˆıtre envoie

`a tous les autres processus un message de typediffusion s´electioncontenant l’identit´e des esclaves ainsi que la quantit´e de travail/m´emoire assign´ees `a chacun d’eux. `A la r´eception d’un tel message, chaque processus met `a jour sa vue locale de la charge des processus concern´es par le message. Il est important de signaler que contrairement `a ce qui ´etait fait pour le m´ecanisme interm´ediaire, dans l’algorithme 5.3, quand un processus esclave commence le traitement d’une tˆache envoy´ee par un autre processus, il n’envoie pas la variation de sa charge induite par cette derni`ere (voir (1) dans l’algorithme 5.3). En effet, cette variation de charge a d´ej`a ´et´e envoy´ee par le maˆıtre dans un message de type diffusion s´election. Ainsi, avec ce nouveau sch´ema, il n’y a pas de perte d’information lorsqu’un commence le traitement d’une tˆache esclave.

5.5 Application ` a la m´ ethode multifrontale parall` ele

Dans cette section, nous allons ´etudier l’impact des m´ecanismes pr´esent´es dans les section pr´ec´edente sur le comportement de la m´ethode multifrontale parall`ele. Cependant, il est important de signaler que ces algorithmes peuvent ˆetre utilis´es/´etendus `a d’autres types d’applications ou d’algorithmes.

Nous allons commencer dans la section 5.5.1 par d´ecrire les strat´egies d’ordonnan-cement dynamiques utilis´ees pour l’´etude. Puis nous ´etudierons dans la section 5.5.2 le comportement de ces strat´egies d’ordonnancement lorsqu’elles sont utilis´ees avec chacun des m´ecanisme pr´esent´es dans les sections pr´ec´edentes.

5.5.1 Strat´ egies dynamiques d’ordonnancement

Les deux strat´egies d’ordonnancement d´ecrites dans cette section seront utilis´es pour illustrer le comportement des m´ecanisme d’´echanges d’informations pr´esent´es pr´ec´edem-ment. Nous avons choisi ces strat´egies parce qu’elles offrent beaucoup de libert´e aux ordonnanceurs dynamiques et seront donc plus sensibles `a la pr´ecision et la coh´erence des informations utilis´ees pour les choix dynamiques. Ainsi, nous les avons pr´ef´er´ees `a la stra-t´egie disponible dans la version publique de MUMPSqui a ´et´e d´ecrite dans la section 4.3.1.

5.5.1.1 Strat´egies bas´ees sur la m´emoire

Ces strat´egies seront d´ecrites plus en d´etail dans le chapitre 7. Elles consistent en une combinaison d’une strat´egie de s´election d’esclaves bas´ee sur la m´emoire et d’une

strat´egie de s´election de tˆaches avec contraintes m´emoire. Ainsi, les processeurs esclaves sont choisis de mani`ere `a avoir le meilleur ´equilibre m´emoire entre les processeurs. De plus les nœuds de type 2 (voir la section4.1), sont distribu´es par blocs de lignes de tailles irr´eguli`eres sur les processeurs esclaves (voir la section 7.1). Enfin, concernant la strat´egie de s´election des tˆaches, elle active la tˆache qui respecte des contraintes m´emoire li´ees `a l’occupation m´emoire (m´emoire libre, pic m´emoire,. . . ) sur le processeur. Signalons que ces strat´egies ont ´et´e impl´ement´ees dans le logiciel MUMPS.

Ces strat´egies dynamiques n´ecessitent une vue aussi correcte que possible de l’´etat de la m´emoire des autres processeurs. En effet, la strat´egie de s´election d’esclave se base sur les informations fournies par un des m´ecanismes d´ecrits dans les sections pr´ec´edentes. De plus, les contraintes m´emoire utilis´ees pour la s´election de la tˆache `a activer sont calcul´ees

`a partir de ces informations.

5.5.1.2 Strat´egie bas´ee sur la performance

Cette strat´egie est bas´ee sur la quantit´e de travail `a faire. De ce fait, chaque processeur prend en compte le coˆut d’une tˆache d`es qu’elle devient activable. De plus les processeurs ont comme charge initiale la charge de leurs sous-arbres.

La s´election des esclaves pour les nœuds de type 2 est faite de telle sorte la charge de travail est la mieux ´equilibr´ee possible entre les processeurs. Tout comme pour le cas des strat´egies bas´ees sur la m´emoire d´ecrites dans la section pr´ec´edente, le partitionnement de la matrice frontale correspondant au nœud de type 2 est irr´egulier. De plus, il y a des contraintes relatives `a la granularit´e des tˆaches esclaves li´ees notamment `a la taille des tampons de communication. Enfin, cette strat´egie calcule dynamiquement des contraintes m´emoire telles que la m´emoire disponible sur chacun des processeurs pour contraindre les choix des ordonnanceurs. Cette strat´egie est proche de celle qui sera d´ecrite dans le chapitre 8.

5.5.2 Etude exp´ ´ erimentale des m´ ecanismes de maintien de la vue de l’´ etat du syst` eme

Nous devons tout d’abord mentionner le fait que les m´ecanismes d´ecrits dans les algorithmes5.2 et5.3 ont ´et´e impl´ement´es dansMUMPSalors que le m´ecanisme donn´e par l’algorithme 5.1 ´etait le m´ecanisme existant. De plus, il est `a noter que le m´ecanisme correspondant `a l’algorithme 5.3 est maintenant utilis´e par d´efaut dans la version 4.3 de MUMPS.

Dans le but d’´etudier l’impact des m´ecanismes propos´es, nous les avons exp´eriment´es sur plusieurs probl`emes tests (voir le tableau 5.1 et l’annexe C pour plus de d´etails).

Les tests ont ´et´e effectu´es sur la plate-forme IBM SP de l’IDRIS¹ qui est d´ecrite dans l’annexe C.

1Institut du D´eveloppement et des Ressources en Informatique Scientifique

5.5. APPLICATION `A LA M ´ETHODE MULTIFRONTALE PARALL `ELE 77

Tab. 5.1 – Probl`emes de test.

Nous avons test´e nos m´ecanismes d’´echange d’information de charge sur 32 et 64 processeurs de la plate-forme d´ecrite ci-dessus. De plus, nous avons utilis´e le logiciel METIS [37] comme technique de renum´erotation. Les r´esultats obtenus sont donn´es dans les figures 5.3 et 5.4 pour les strat´egies dynamiques bas´ees sur la m´emoire et sur la performance respectivement. Il est `a noter que nous n’avons pas pu exp´erimenter nos m´ecanismes avec le probl`eme CONV3D64 sur 32 processeurs pour des raisons de manque de m´emoire sur les nœuds de calcul. Concernant les strat´egies bas´ees sur la m´emoire, nous mesurons le pic de m´emoire active observ´e pendant la factorisation. Pour la la strat´egie bas´ee sur les performances, nous mesurons le temps n´ecessaire `a la factorisation de la matrice. Dans les deux cas, le r´esultat est divis´e par le r´esultat (pic m´emoire ou temps de factorisation) obtenu par le m´ecanisme bas´e sur les variations de charge pr´esent´e dans la section5.4. Ainsi les graphiques sont normalis´es, et la valeur associ´ee au m´ecanisme bas´e sur les variations de charge est toujours ´egal `a 1.

0

Fig.5.3 – Strat´egies dynamiques bas´ees sur la m´emoire : Impact du m´ecanisme d’´echange des informations de charge sur le pic de m´emoire active sur 32 et 64 processeurs (les r´esul-tats sont normalis´es par rapport `a ceux obtenus par le m´ecanisme bas´e sur les variations de charge).

Sur 32 processeurs (voir la figure 5.3(a)), nous pouvons observer que le pic de m´e-moire active est g´en´eralement plus petit en utilisant le m´ecanisme bas´e sur les variations de charge except´e pour GUPTA3. De plus, nous observons qu’il n’y a pas de gains pour

certaines matrices sym´etriques (MSDOOR et SHIP 003 en l’occurrence). Pour ces ma-trices, le pic m´emoire est atteint pendant le traitement d’un sous-arbre alors qu’aucune d´ecision dynamique n’a encore ´et´e prise. De ce fait, nous ne pouvons pas voir d’effet li´e

`a nos m´ecanismes.

En ce qui concerne le m´ecanisme interm´ediaire, les r´esultats sont parfois meilleurs et parfois moins bons que ceux obtenus avec le m´ecanisme na¨ıf.

Sur 64 processeurs (figure5.3(b)), les r´esultats sont moins significatifs alors qu’on au-rait pu s’attendre `a de meilleurs gains de par le fait qu’il y a plus de d´ecisions dynamiques

`a prendre. Ceci est dˆu au fait que pour tous les cas o`u il n’y a pas de gains, le pic m´emoire est atteint avant qu’aucune d´ecision dynamique n’ait ´et´e prise (par exemple PRE2 sur 64 processeurs). Il est `a signaler que sur un des probl`emes de taille relativement importante, en l’occurrence ULTRASOUND3, les rapports obtenus par le m´ecanisme bas´e sur les va-riations de charge atteignent 1.5 et 2.1 en comparaison avec le m´ecanisme interm´ediaire et le m´ecanisme na¨ıf respectivement.

Fig. 5.4 – Strat´egies dynamiques bas´ees sur la charge de travail : Impact du m´ecanisme d’´echange des information de charge sur le temps de factorisation sur 32 et 64 processeurs (les r´esultats sont normalis´es par rapport `a ceux obtenus par le m´ecanisme bas´e sur les variations de charge).

En ce qui concerne l’impact des m´ecanismes d’´echange des informations de charge sur le temps d’ex´ecution, les r´esultats sont donn´es dans la figure 5.4. Nous observons que le m´ecanisme bas´e sur les variations de charge donne presque toujours les meilleures performances (except´e pour TWOTONE sur 32 processeurs et BMWCRA 1 sur 64 pro-cesseurs). Ceci illustre le fait que les d´ecisions dynamiques (s´elections d’esclaves) sont faites avec des informations coh´erentes.

Enfin, nous avons exp´eriment´e les trois strat´egies avec notre plus gros probl`eme de test (CONV3D64) sur 64 processeurs. Le temps de factorisation pour les trois m´eca-nismes sont donn´es dans le tableau 5.2. Nous observons que pour ce probl`eme de test, le m´ecanisme bas´e sur les variations de charge permet d’obtenir une r´eduction de 46 et