La biblioth`eque de squelettes

Les squelettes d´efinis dans EKTRAN sont au nombre de trois : - map,

- fold,

- compose.

Ils correspondent directement aux fonctions d’ordre sup´erieur du mˆeme nom du langage. Ce sont des squelettes `a usage g´en´eral et non d´edi´es `a un domaine applicatif, contrairement `a ceux propos´es dans le projet SKiPPER.

Le squelette map (parall´elisme de donn´ees) applique une fonction `a chaque ´el´ement de la liste qui lui est fournie en argument. Sa d´efinition est la suivante : =\?]A  V

 V  V n BV  BV   LV  ; soit en Caml :

> let map f [] = [] | map f (h::t) = (f h) :: map f t # map : (’a -> ’b) -> ’a list -> ’b list

Son implantation en tant que squelette fonctionne sch´ematiquement de la sorte. Trois pro-cessus sont mis en œuvre pour faire fonctionner ce squelette :

- un processus de supervision du squelette, - un processus esclave,

- un processus esclave sp´ecial pour les cas d’imbrication.

Le processus de supervision se charge de cr´eer les sous-groupes n´ecessaires `a une ´eventuelle prise en charge d’une imbrication en son sein, et de r´ealiser les allocations de processeurs. En-suite, il ex´ecute l’algorithme esclave soit sous la forme du processus esclave s’il n’y a pas d’imbrication, soit sous celle du processus esclave sp´ecial en vue de l’imbrication. Ce dernier a pour rˆole de g´erer la relation du squelette avec le squelette imbriqu´e apr`es l’avoir d´emarr´e. Dans son approche dynamique, SKiPPER-II se distingue par l’absence de processus sp´eciaux de gestion des imbrications. Contrairement `a EKTRAN, il ne fait aucune diff´erence entre la mise en œuvre d’un squelette imbriqu´e et celle d’un squelette non imbriqu´e : aucun processus suppl´ementaire, ou sp´ecifique, n’a besoin d’ˆetre activ´e pour g´erer, ou communiquer avec, un squelette imbriqu´e. De plus, la technique d’imbrication utilis´ee par EKTRAN s’appuie sur les m´ecanismes MPI pour cloisonner les squelettes qui sont imbriqu´es. De ce fait, elle conc`ede une partie de la gestion de l’imbrication `a MPI. Par rapport `a SKiPPER-II, ce choix pr´esente le d´esavantage de n´ecessiter plus de fonctionnalit´es de la norme MPI (portage moins ais´e sur des architectures d´edi´ees). Qui plus est, il occasionne aussi un l´eger surcoˆut dans la gestion des communciations par la biblioth`eque (tri des communications).

Le squelettefoldapplique une fonction sur la liste qui lui est donn´ee en argument suivant la d´efinition :5!Jk` V  V  V  DV4 +DVO  BV kX$ $ $ ; soit en Caml :

> let fold f b [] = b | fold f b (h::t) = f h (fold f b t) # fold : (’a -> ’b -> ’b) -> ’b -> ’a list -> ’b

Ce squelette est implant´e sous la forme d’un sch´ema de type divide and conquer binaire. Ainsi, le processus maˆıtre d´ecoupe la liste initiale en deux sous-listes, dont une est transmise `a un processus esclave et l’autre est conserv´ee pour traitement imm´ediat4. Le processus esclave r´ep`ete la proc´edure.

Le squelettecomposeest con¸cu comme une pipeline (parall´elisme de tˆaches).

3.5.2 La gestion de l’imbrication

Avec EKTRAN, l’imbrication de squelettes est support´ee jusqu’`a n’importe quel niveau de profondeur. Le m´ecanisme est directement int´egr´e dans celui de gestion de chaque squelette. Il est mis en œuvre en exploitant les fonctions ´evolu´ees de MPI de gestion des groupes de

commu-nication. L’id´ee qui guide le m´ecanisme est de proc´eder `a l’allocation des processus n´ecessaires

aux squelettes `a des sous-groupes MPI au fur et `a mesure que des squelettes imbriqu´es sont identifi´es dans les fonctions d’ordre sup´erieur, en commen¸cant par celle la plus FFenglobanteGG

(de plus au niveau). Plus pr´ecis´ement, lorsqu’un programme commence son ex´ecution, seul un unique groupe MPI existe. Il contient d´ej`a la totalit´e des processus (non encore instanci´es) qui pourront servir `a l’ex´ecution des squelettes. Lorsqu’il y a n´ecessit´e d’imbrication, alors un nouveau sous-groupe est activ´e pour le squelette imbriqu´e. Le squelette englobant r´ealloue les processus de son groupe de mani`ere `a ce que le squelette imbriqu´e puisse s’ex´ecuter. Ce m´e-canisme est corr´el´e `a l’utilisation des groupes MPI. C’est une diff´erence de fonctionnement importante avec SKiPPER-II. Dans notre cas, les ressources appartiennent `a un squelette et ce dernier, en cas d’imbrication en son sein, n’a pas `a en lib´erer pour les donner `a un autre. Le squelette imbriqu´e FFse sertGG dans les ressources encore libres. On ´evite ainsi le surcoˆut in-duit par l’allocation (en quelque sorte) puis la r´eallocation successive d’une mˆeme ressource `a deux squelettes diff´erents. De plus, avec SKiPPER-II, les ressources ne sont pas allou´ees d´e-finitivement `a un squelette, mais en fonction de ses besoins au cours du temps. Ainsi, s’il n’a plus besoin de certaines d’entre elles, elles peuvent ˆetre lib´er´ees au fur et `a mesure ; un autre squelette peut alors se les approprier. EKTRAN met de plus en place un groupe de supervision (reliant tous les sous-groupes cr´ees) pour les relier et assurer leur gestion (voir figure 3.2). Ce processus se poursuit de mani`ere r´ecursive formant un arbre de sous-groupes MPI. L`a encore, par sa technique d’imbrication, SKiPPER-II s’affranchit de processus de gestion sp´ecifiques : les seuls processus `a ˆetre ex´ecut´es font partie int´egrante des squelettes et de leurs sch´emas. Dans SKiPPER-II, les ressources sont enti`erement d´edi´ees aux squelettes, et ces derniers sont auto-suffisants pour leur propre gestion et celle des squelettes qui leur sont imbriqu´es.

3.6 Travaux de Michaelson et coll.

Les travaux de Michaelson et coll. ayant d´ej`a fait l’objet d’une pr´esentation `a la section 1.5.3.2 page 50, nous ne nous int´eressons ici qu’aux possibilit´es d’imbrication.

Ce compilateur autorise l’imbrication de squelettes, qui peut ˆetre faite pour une profondeur ind´etermin´ee, en ce sens qu’elle n’est pas fix´ee a priori par l’impl´ementation du compilateur elle-mˆeme. L’imbrication est obtenue lorsque une fonction d’ordre sup´erieur ayant un ´equi-valent squelette est pla¸c´ee comme argument d’une autre fonction de ce type. Il est important de noter que l’imbrication de deux squelettes ´ecrite, et donc sollicit´ee, par l’utilisateur au niveau



Sous-groupe 1 0 1 2 3 4 5 0 1 2 3 4 5 Groupe initial Sous-groupe 2 Groupe de supervision 0 1 0 0 3 1 2 3 dans le groupe initial

Numero du processus Numero du processus

dans le sous-groupe Numero du processus

dans le groupe de supervision

Communications possibles (entre processus d’un meme groupe)

7 6 1 2 6 7

FIG. 3.2 – Exemple de division d’un groupe MPI en sous-groupes.

de son code source ne se traduira pas forc´ement par l’imbrication effective de ces deux sque-lettes au moment de l’ex´ecution. En effet, le compilateur est capable de choisir entre maintenir l’imbrication ou non (c’est-`a-dire d’instancier ou non la fonction d’ordre sup´erieurFFinterneGG en squelette) en fonction des informations donn´ees par le module charg´e de faire du FFprofilingGG

5. L’imbrication ne sera maintenue que si le gain en temps d’ex´ecution justifie la surcharge en communications due `a l’imbrication elle-mˆeme.

Il faut noter enfin que le compilateur a ´et´e construit en grande partie en utilisant des outils lo-giciels d´ej`a existants (analyse syntaxique, g´en´erateurs de code,...). Seules les parties sp´ecifiques au parall´elisme ont ´et´e d´evelopp´ees.

Une des limitations annonc´ee par les concepteurs [MSBK00] est la surcharge due `a la ges-tion de certaines communicages-tions sous MPI. C’est le cas par exemple lors de diffusions de type

FFbroadcastGG qui sont impl´ement´ees dans l’environnement par des boucles utilisant des fonc-tions Send alors que la fonction native sp´ecialis´ee de MPI aurait pu, potentiellement, donner de meilleurs r´esultats. Le probl`eme est que cette derni`ere reste limit´ee `a un seul communicateur. On notera aussi que les exemples fournis font apparaˆıtre des imbrications FFartificiellesGG dont le seul but est d’´evaluer le comportement du compilateur (les algorithmes choisis ne n´ecessitent pas r´eellement d’imbrication pour leur parall´elisation). On note enfin l’absence de baisse signi-ficative de performance entre les mˆemes algorithmes pris dans leurs versions imbriqu´ee et non imbriqu´ee. Cela n’est d’ailleurs pas une surprise puisque les sch´emas de parall´elisation utilis´es sont r´eguliers, ce qui est le cas dans les exemples de [SBMK98]. En effet, dans ces algorithmes, l’imbrication n’´etait pas une n´ecessit´e en soi, les traitements ne sont pas r´epartis diff´eremment dans la version imbriqu´ee (l’imbrication sert essentiellement `a distribuer et op´erer des partitions diff´erentes sur les donn´ees initiales que ne l’aurait fait une parall´elisation sans imbrication). Il s’en suit que la version imbriqu´ee n’ajoute qu’un surcoˆut initial, mais aucun en terme de trai-tement effectif suppl´ementaire des donn´ees du probl`eme. Les auteurs notent aussi que l’imbri-cation de squelettes repr´esente essentiellement un d´efi dans la gestion et la coordination des squelettes lorsqu’il faut optimiser la distribution des donn´ees entre les processeurs.



Le module de

profiling est bas´e sur le kit de d´eveloppement ML Kit evaluator dans lequel est pass´e un jeu de tests connu pour r´ealiser les mesures d’efficacit´e [Bra95].