code SML
Chapitre 4 SKiPPER-II : une solution `a l’imbrication
4.6.3 Gestion du parall´ elisme dans les cas `a faible nombre de ressources
Comme nous l’avons vu, un atout majeur de SKiPPER-II est de pouvoir g´erer indiff´erem-ment les cas o`u le nombre de ressources pour l’ex´ecution de l’application est suffisant et ceux dans lesquels il ne l’est pas, notamment celui o`u une unique ressource est disponible (´emulation s´equentielle).
Malheureusement cette souplesse se paie lorsque le nombre de processeurs physiquement disponibles est faible (de l’ordre de 2 `a 4) et qu’ils ne disposent pas de possibilit´es de multi-tˆache. En effet, dans ce cas, certains processus maˆıtres vont monopoliser des unit´es de traite-ment pour leur seul fonctionnetraite-ment sans que celles-ci puissent ˆetre affect´ees `a un traitetraite-ment r´eel (fonction utilisateur de calcul). La figure 4.14 montre ainsi ce qui se passe sur un petit exemple. L’arbre qui y est repr´esent´e est le sch´ema de l’application. Deux squelettes TF/II y sont imbri-qu´es (les deux instances du squelette imbriqu´e ont ´et´e distingu´ees par des numeros diff´erents pour plus de lisibilit´e). L’architecture propos´ee est constitu´ee de seulement 4 processeurs. Sur chacun d’eux est install´ee une unique copie du noyau. Le sch´ema montre, sous chaque proces-seur symbolis´e, la liste des processus affect´es `a chaque copie du noyau. On a suppos´e pour les besoins de l’exemple que l’ex´ecution de l’esclave S2A est presque aussi longue que l’ex´ecution des esclaves S3A et S3B r´eunis (cas le plus d´efavorable). S2B est mis entre parenth`eses pour indiquer que son ex´ecution n’a pas lieu en mˆeme temps que les trois autres esclaves : S2A, S3A et S3B ont une ex´ecution quasi-simultan´ee, alors que S2B est pratiquement seul a s’ex´ecuter au moment de son activation. La figure 4.15 donne le diagramme temporel de l’activation de ces processus. Ces figures montrent clairement que les deux processeurs auquels sont affect´es les processus maˆıtres (Mx) passent leur temps `a attendre la fin d’ex´ecution de leurs esclaves, et donc ne participent pas v´eritablement au travail proprement dit ; alors que dans le mˆeme temps l’ex´ecution des esclaves (Sxy) en vient `a ˆetre, en partie, s´equentialis´ee.
Dans le cas de processeurs disposant de capacit´es de multi-tˆache, le probl`eme persiste mais ne se pose pas dans les mˆemes termes. Ici l’ex´ecution d’un maˆıtre peut ˆetre recouverte par l’ex´ecution d’un esclave, mais dans ce cas le point d´elicat est le choix du nombre d’esclaves qu’on souhaite pouvoir affecter `a chaque processeur et du nombre de ressources qui lui sont affect´ees. Normalement, un seul esclave devrait ˆetre autoris´e `a s’ex´ecuter sur un mˆeme proces-seur, ce qui peut ˆetre d´ecid´e par le PLServer, mais il n’en reste pas moins que la distribution optimum des esclaves et des maˆıtres sur les processeurs disposants de plusieurs ressources est un probl`eme difficile, non pris en compte actuellement par SKiPPER-II. De ce fait, le nombre de ressources allou´ees `a chaque processeur est laiss´e `a la discr´etion de l’utilisateur qui peut la modifier directement au moment de l’ex´ecution de son application (sans recompilation ou modi-fication du code). Mais cette possibilit´e reste cependant un param`etre d´elicat `a r´egler. La figure 4.16 illustre le cas du multi-tˆache sur le mˆeme sch´ema d’application que pour l’exemple pr´ec´e-dent. Ici aussi les deux instances du TF/II imbriqu´e sont num´erot´ees diff´eremment afin de les distinguer. L’utilisation dans cet exemple du mˆeme nombre de processeurs que pr´ec´edemment, mais de deux copies du noyau par processeur, fait qu’il y a suffisamment de copies disponibles pour que tous les squelettes (3 au total) puissent se d´eployer compl`etement et simultan´ement. Ainsi, sur la figure, on peut voir que trois copies jouent le rˆole des trois processus maˆıtres, et que quatre autres servent d’esclaves. Les esclaves sont ici affect´es `a des copies qui se trouvent sur des processeurs dont les autres copies ne supportent pas l’ex´ecution d’autres esclaves, tout au plus celles de processus maˆıtres. La figure 4.17 donne quant `a elle le diagramme d’activation des processus en question pour la configuration choisie.
Liste des processus affectes a chaque copie du noyau M1
M2 M3
S2A S2B S3A S3B
Architecture utilisee : 4 processeurs
Configuration du noyau : 1 copie par processeur
M1 M2 M3 S2A
S3A S3B
( S2B ) Sxy : processus esclave Mx : processus maitre Schema de l’application
Temps M1 M1 M2 M3 S3A S2A M1 M3 M3 M2 M2 S2B S3B
Copie Copie Copie Copie
processeur 1 processeur 2 processeur 3 processeur 4
FIG. 4.15 – Diagramme temporel d’activation des processus pour un nombre de ressources tr`es
Schema de l’application M1
M2 M3
S2A S2B S3A S3B
Architecture utilisee : 4 processeurs
Configuration du noyau : 2 copies par processeur
Sxy : processus esclave Mx : processus maitre
M1 M2 M3 S2A
S3B
S3A S2B
FIG. 4.16 – Placement des processus pour un nombre de processeurs limit´es, mais avec
M3
M3
M1
M1
M1
Temps
S3A
M1
M2
S2B
M3
S3B
S2A
M2
M2
copie 1
copie 5 copie 6 copie 7 copie 8
copie 4
copie 3
copie 2
processeur 1 processeur 2 processeur 3 processeur 4
FIG. 4.17 – Diagramme temporel d’activation des processus pour un nombre de processeurs
4.7 Conclusion
Le d´eveloppement de SKiPPER-II d´ecoule de la volont´e de proposer une version de l’en-vironnement pouvant prendre en charge l’imbrication de squelettes algorithmiques. Pour ce faire, le mod`ele d’ex´ecution essentiellement statique de la version pr´ec´edente a ´et´e aban-donn´e au profit d’un mod`ele compl`etement dynamique. En effet, SKiPPER-I diff´erenciait les squelettes statiques des squelettes dynamiques parce qu’il fonctionnait avec un mod`ele sta-tique d’ex´ecution, alors que certains des squelettes ont un comportement par nature dynamique. SKiPPER-II ´elimine cet aspect pour ne g´erer qu’un seul et unique mod`ele d’ex´ecution : le mo-d`ele dynamique. Nous avons choisi ce momo-d`ele car le momo-d`ele statique ne permettait pas `a lui seul de rendre compte du comportement de tous nos squelettes, et empˆechait de ce fait l’obtention d’une repr´esentation homog`ene des squelettes. Or cette repr´esentation est n´ecessaire pour au-toriser une composition r´eguli`ere des squelettes, c’est-`a-dire se faisant toujours de la mˆeme fa¸con quelles que soient la composition et les types de squelettes qui interviennent, en l’absence de toute exception dans la description d’une composition particuli`ere.
Un m´eta-squelette (TF/II) a ainsi ´et´e propos´e afin de facilit´e l’imbrication en rendant les aspects de composition plus homog`enes. SKiPPER-II se fonde de ce fait sur un noyau charg´e d’ex´ecuter les squelettes des applications apr`es leur mise sous la forme de TF/II.
Bien entendu le revers de cette approche est d’ajouter aux squelettes intrins´equement sta-tiques (comme le SCM) un certain coˆut dˆu `a leur gestion `a la vol´ee qui pourrait ˆetre supprim´ee puisque leur comportement au cours du temps (et spatialement) peut ˆetre compl`etement pr´edit. Mais cette surcharge peut ˆetre r´eduite en utilisant un sch´ema de communication ad´equat comme cela est fait dans SKiPPER-II.
Les avantages principaux de cette approche sont donc :
- une gestion identique de tous les squelettes ( statiques et dynamiques), - des possibilit´es de composition syst´ematiques des squelettes,
- la gestion dynamique des processeurs disponibles14,
- une ´emulation s´equentielle directe (plus de distinction avec une ex´ecution parall`ele), - une grande portabilit´e de l’environnement,
- une extensibilit´e de la base des squelettes facilit´e,
- la compatibilit´e avec la version pr´ec´edente de SKiPPER.
Le chapitre suivant illustre et valide l’approche retenue pour SKiPPER-II `a travers l’ex-p´erimentation d’applications de complexit´e variable. Le comportement de SKiPPER-II y est quantifi´e et compar´e `a celui de SKiPPER-I.
Cette caract´eristique offre notamment, par l’interm´ediaire du PLServer (voir la section 4.3.4.1 page 103), la possibilit´e d’envisager `a terme un certain niveau de tol´erance aux fautes pour SKiPPER-II.