Limitations de SKiPPER-I

2.3.6.1 La question de l’imbrication

La principale limitation de SKiPPER-I tient dans l’impossibilit´e de combiner de mani`ere syst´ematique plusieurs squelettes dans une mˆeme application autrement qu’en les s´equen¸cant. Elle ne permet pas en particulier l’imbrication. En effet, hormis les squelettes SCM⁹ et ITER-MEM, aucun des autres (les squelettes dynamiques) n’autorise l’utilisation d’un autre squelette comme fonction

de calcul. L’utilisateur ne peut donc pas construire librement un sch´ema de parall´elisation plus complexe que ceux disponibles imm´ediatement avec les trois squelettes qui lui sont propos´es autrement qu’en les enchaˆınant s´equentiellement.

L’imbrication de squelettes est la composition la plus difficile `a traiter car elle rend les squelettes inter-d´ependants et cr´ee une hi´erarchie entre eux. Bien que le besoin de disposer de possibilit´es d’imbrication n’ait jamais ´et´e d´emontr´e d´efinitivement [Col99]10, il apparaˆıt que l’augmentation r´eguli`ere de la complexit´e des applications pourrait contribuer `a le faire ´emerger. C’est la cas par exemple de l’application de suivi de visages que nous pr´esentons au chapitre 5. Qui plus est, le probl`eme de l’imbrication est toujours apparu comme un d´efi `a relever du fait de sa complexit´e d’implantation pour la communaut´e de chercheurs s’int´eressant aux squelettes algorithmiques. En fait, mˆeme dans le cas o`u l’imbrication ne serait pas r´eellement n´ecessaire, il peut s’av´erer qu’elle soit malgr´e tout utile dans la sp´ecification du parall´elisme par l’utilisateur. En effet, consid´erons le cas o`u, en programmation imp´erative s´equentielle, on est en pr´esence d’une fonction r´ecursive. On peut choisir de l’´ecrire telle qu’elle, ou de la d´e-r´ecursifier

. Si la seconde solution est g´en´eralement plus efficace lors de l’ex´ecution, il n’en reste pas moins que son obtention peut ˆetre fastidieuse et source d’incompr´ehension. De mˆeme, il peut s’av´e-rer que le sch´ema de parall´elisation d’un algorithme se trouve plus efficacement d´ecrit par le choix d’une imbrication de squelettes plutˆot que par l’obtention d’une combinaison ´equivalente mais non imbriqu´ee. Une autre justification `a l’imbrication de squelettes provient de la ma-ni`ere dont est construit l’environnement d’aide `a la programmation parall`ele. Bien souvent il ne donne pas la possibilit´e `a l’utilisateur de cr´eer de nouveaux squelettes. C’est le cas notamment de SKiPPER. L’utilisateur doit se contenter de ceux propos´es dans la biblioth`eque de l’envi-ronnement, qui est fig´ee. Dans ce cas, il peut ˆetre n´ecessaire de combiner ces squelettes afin d’obtenir un sch´ema de parall´elisation plus complexe que ceux propos´es individuellement par chaque squelette mais qui rend mieux compte du parall´elisme potentiel de l’application. C’est d’ailleurs aussi le cas avec des environnements extensibles en termes de squelettes (comme Pro-teus [NP92], FrameWorks [SSS98] ou PASM [GSP98] [GSP99] [GSP00] [GSP01]). Dans ce dernier cas, il peut ˆetre plus facile, voire plus efficace, de combiner plusieurs squelettes entre eux pour en former un nouveau

plutˆot que de programmer un nouveau sch´ema ex nihilo.



Le squelette SCM autorise l’imbrication d’un autre squelette du mˆeme type car sa d´efinition est suffisante pour produire un Graphe Flot de Donn´ees Conditionn´e valide pour SynDEx.




2.3.6.2 Origine du probl`eme

La principale raison aux limitations de SKiPPER-I en termes de composition de squelettes tient `a l’usage de l’outil SynDEx comme dorsal ( backend

). Ce choix parfaitement justifi´e pour les premiers squelettes introduits dans SKiPPER (le SCM en particulier qui poss`ede une interpr´etation imm´ediate sous la forme d’un GFDC [GSD98]) conduit `a un probl`eme de d´efini-tion de squelettes qui s’expriment plus naturellement sous la forme d’un graphe de processus. C’est le cas en particulier de ceux fond´es sur la mise en œuvre d’une ferme de processeurs (DF et TF). Le mod`ele d’ex´ecution de ces squelettes est par essence dynamique : l’ordonnancement de la plupart des communications qu’ils mettent en jeu ne peut ˆetre d´ecid´e qu’`a l’ex´ecution. Or SynDEx ne peut mettre en œuvre que des mod`eles d’ex´ecution statiques, les seuls qui peuvent ˆetre formul´es sous la forme d’un GFDC.

Pour contourner cette difficult´e, D. Ginhac [Gin99] confine les communications dynamiques des squelettes DF et TF entre deux barri`eres de synchronisation dans le GFDC. Elles sont alors masqu´ees

du point de vue de SynDEx. Cet artifice donne alors toute libert´e de les impl´emen-ter pour les int´egrer `a l’ex´ecutif produit par SynDEx.

Cette solution soul`eve toutefois plusieurs probl`emes [CSD00].

Premi`erement, SynDEx ne peut plus g´erer la partie de l’application qui a ´et´e pla¸c´ee entre ces barri`eres de synchronisation. Donc toutes les communications et l’ordonnancement des proces-sus des squelettes DF et TF ´echappent `a son contrˆole. Il n’est alors plus en mesure d’optimiser cette partie de l’application.

Deuxi`emement, des communications ´etrang`eres

`a celles ordonnanc´ees statiquement par SynDEx sont introduites volontairement. Il faut donc veiller `a ce qu’elles n’interf`erent pas avec les m´ecanismes de communication natifs de SynDEx. C’est d’ailleurs la raison pour laquelles des barri`eres de synchronisation sont mises en place. Elles ont pour objet de confiner toutes les op´erations ext´erieures `a celles g´er´ees par SynDEx. Tant que l’imbrication de squelettes n’est pas autoris´ee, cette mani`ere de proc´eder se r´ev`ele efficace et ne pose pas de probl`emes d’interactions entre les deux gestions des communications (l’une statique par SynDEx, l’autre dynamique par les processus auxiliaires d´edi´es des squelettes DF et TF11). Mais le probl`eme devient plus difficile `a traiter lorsque l’imbrication de deux squelettes est permise. En effet, imbriquer un squelette SCM dans un squelette DF par exemple revient alors `a interdir `a SynDEx de g´erer le squelette SCM (puisque masqu´e). Aucun des modules de SKiPPER-I n’est pr´evu pour pallier ce manque.

Troisi`emement, la description du sch´ema de parall´elisation des squelettes DF et TF, apr`es ce que nous venons d’en dire, ne peut ˆetre faite que de mani`ere ad hoc, c’est-`a-dire qu’elle est sp´ecifique `a la machine cible : elle ne peut ˆetre fournie sous forme d’un GFDC ind´ependant de la cible. Pour ces deux squelettes, il n’existe donc pas de repr´esentation interm´ediaire ind´epen-dante de la machine cible. Qui plus est, ce dernier point donne une sp´ecification des squelettes qui n’est pas homog`ene, ce qui entraˆıne une difficult´e de principe dans la mise en œuvre d’une composition de ces squelettes, encore plus pour une imbrication.

 

Ces processus prennent en charge les communications dynamiques li´ees au fonctionnement interne des sque-lettes dynamique qui ne peut ˆetre directement d´ecrit avec SynDEx, `a savoir : envoi des donn´ees `a traiter du maˆıtre aux esclaves et des r´esultats interm´ediaires des esclaves vers le maˆıtre. Ils sont encapsul´es

dans les fonctions associ´ees aux nœuds du GFDC.

2.3.6.3 Une premi`ere approche du probl`eme sous SKiPPER-I

Pour solutionner le probl`eme de la repr´esentation statique de squelettes dynamiques sous SynDEx `a l’aide d’un GFDC, nous avons propos´e en 1999 une voie originale destin´ee `a conser-ver le fonctionnement de la premi`ere conser-version de SKiPPER tout en la pr´eparant `a int´egrer la notion de composition de squelettes [CSD00]. La repr´esentation d’un squelette dynamique de type DF ou TF est alors la mˆeme que celle utilis´ee pour un SCM, `a la diff´erence pr`es qu’on fait apparaˆıtre une m´emoire d’´etat liant la distribution des donn´ees aux esclaves et leur collecte (voir figure 2.10).

FIG. 2.10 – Repr´esentation du squelette Data Farming statique.

Dans ce mod`ele d’ex´ecution, les fonctions utilisateurs servant d’esclaves ne sont pas ex´e-cut´ees enti`erement, mais en partie seulement. Plus pr´ecis´ement elles sont ex´eex´e-cut´ees durant un quota de temps donn´e (m´ecanisme similaire `a celui utilis´e dans les syst`emes d’exploitation pour le temps partag´e). On ex´ecute donc en boucle le GFDC du squelette jusqu’`a ce que toutes les donn´ees initiales aient ´et´e trait´ees par les esclaves. Grˆace `a l’ex´ecution par quota de temps des esclaves, le DF et le TF peuvent ˆetre d´ecrits sous SynDEx sans qu’il y ait attente de fin d’ex´ecu-tion d’une foncd’ex´ecu-tion de calcul assign´ee `a un esclave pour pouvoir en alimenter un autre. On peut donc consid´erer les squelettes dynamiques ainsi d´ecrits comme des squelettes SCM `a grain fin it´er´es. L’annexe B et l’article [CSD00] d´ecrivent plus en d´etail le mod`ele d’ex´ecution que nous venons bri`evement d’exposer.

Malgr´e le fait que cette approche permettait une repr´esentation statique de squelettes dyna-miques – et nous rapprochait ainsi d’une repr´esentation interm´ediaire beaucoup plus homog`ene (`a d´efaut d’ˆetre unique) en consid´erant la repr´esentation des squelettes dynamiques comme une g´en´eralisation de tous les autres – elle a dˆu ˆetre abandonn´ee. L’une des principales raisons est qu’elle n´ecessitait l’introduction de la notion de boucle d’it´eration localis´ee dans le temps sous SynDEx. Cette boucle d’it´eration temporelle, ou d´epliage temporel

, est la possibilit´e de r´e-p´eter un nombre de fois d´etermin´e un motif (une fonction, une communication,...) `a l’int´erieur mˆeme d’un GFDC. Cette possibilit´e ´etant indisponible dans la version de SynDEx (v4) que nous utilisions, et n’´etant pas vou´ee `a ˆetre int´egr´ee `a court terme¹² dans de futures ´evolutions du logiciel, nous nous sommes tourn´es vers une autre approche (cf. chapitre 4).