Dans ce chapitre, nous avons classifi´e les solutions existantes pour la programma- tion des architectures parall`eles hybrides selon le niveau d’abstraction par rapport `a l’architecture cible. La liste des solutions ´etudi´ees n’est bien sˆure pas exhaustive, mais est repr´esentative des probl`emes pos´es `a chaque niveau d’abstraction et des solutions envisag´ees pour les r´esoudre.
Aucune des approches et solutions existantes n’apporte de solution globale au probl`eme de la programmation des architectures hybrides selon les crit`eres ´enum´er´es dans les bilans de comparaison. Les biblioth`eques de bas niveau telles que MPI et GASNet permettent de cibler la m´emoire distribu´ee `a un niveau de d´etail tr`es fin mais demandent en cons´equence un effort de programmation et de d´eboggage ´elev´es, tout en restant restreintes aux m´emoire distribu´ees. Les PGAS incorporent les fonc- tionnalit´es n´ecessaires `a la programmation des m´emoires distribu´ees directement au niveau du langage, et offrent pour certains un support pour la m´emoire partag´ee et les GPUs. Cependant, ces langages, qui ne sont pas des standards, demandent un effort de programmation important `a l’utilisateur qui doit notamment g´erer les synchronisa- tions des acc`es aux donn´ees distribu´ees afin de garantir leur coh´erence. Les approches de haut niveau se heurtent `a des probl`emes de d´ecidabilit´e pour la distribution au- tomatique et `a des probl`emes de pr´edictibilit´e des performances pour les SDSM. Les approches de haut niveau bas´ees sur le mod`ele poly´edrique impl´ementent des analyses math´ematiques sophistiqu´ees pour l’extraction du parall´elisme et la transformation de code pour les architectures hybrides. Cependant, elles restent limit´ees `a des codes `a contrˆole statique et la gestion de la distribution des donn´ees pour la globalit´e d’un programme ne semble pas encore effective dans ce mod`ele.
Nous pensons qu’une approche `a base de directives pour la programmation des architectures hybrides est `a la fois pratique et viable. En effet, en se basant sur un langage de base standardis´e et largement utilis´e par la communaut´e du calcul scientifique, les codes existants peuvent ˆetre port´es sans r´e´ecriture compl`ete. Des applications nouvelles peuvent ´egalement ˆetre ´ecrites dans cette solution sans avoir `a apprendre un nouveau langage ou les fonctionalit´es d’une nouvelle biblioth`eque. Enfin, l’insertion de directives permet de maintenir un seul programme source, et de pouvoir le compiler vers plusieurs types de cible d`es que les informations essentielles telles que le parall´elisme et le placement des donn´ees sont uniform´ement exprim´es. Il est `a noter qu’une solution `a base de directives n’exclut pas l’interaction avec d’autres approches, les directives pouvant en effet provenir d’une autre solution telle que le mod`ele poly´edrique pour l’extraction du parall´elisme.
Nous avons montr´e que les approches existantes `a base de directives ne proposaient pas une solution unifi´ee pour la programmation des machines parall`eles hybrides. Dans le chapitre suivant nous proposons dSTEP, une solution `a base de directives pour la programmation des architectures hybrides qui a pour objectif d’offrir un mod`ele de programmation unifi´e pour les architectures hybride, l’efficacit´e et la facilit´e de programmation.
Chapitre 3
dSTEP : directives pour la
distribution des calculs et des
donn´ees
Dans ce chapitre, nous proposons dSTEP, une solution `a base de directives pour la programmation des architectures parall`eles hybrides. Nous avons trois objectifs :
1. l’unification de la programmation pour architectures parall`eles hybrides dans un seul mod`ele de programmation, exploitant tous les niveaux de parall´elisme of- ferts par l’architecture de fa¸con transparente pour le programmeur. Le mod`ele de programmation doit ˆetre `a la fois expressif et simple `a utiliser pour per- mettre au programmeur, ou `a d’autres outils d’analyse en amont, de passer au compilateur les informations de haut niveau sur l’application ;
2. l’efficacit´e de la programmation : il s’agit `a la fois d’atteindre des performances ´elev´ees, de passer `a l’´echelle en nombre de ressources de calcul et de pouvoir traiter des probl`emes de tr`es grande taille ;
3. la facilit´e de programmation : requ´erir un effort de programmation raisonnable de la part du programmeur.
3.1
Contexte
Nous nous pla¸cons dans le contexte de la programmation d’applications scienti- fiques denses `a parall´elisme de donn´ees sur architectures hybrides. Ces applications, telles que les probl`emes de diff´erences finies, sont largement pr´esentes en calcul scien- tifique et en simulation num´erique. Des exemples repr´esentatifs de telles applications sont les benchmarks NAS [11] BT, SP et LU mais surtout des applications industrielles de traitement du signal telle que l’application industrielle LDPC de communication radio, impl´ementant les algorithmes d’encodage d’information du mˆeme nom [82].
dSTEP vise la parall´elisation d’un programme dans sa globalit´e. La distribution des tableaux est sp´ecifi´ee au niveau de leurs d´eclarations et reste fixe tout au long du programme. La sp´ecification du parall´elisme et de la distribution des nids de boucles est ensuite indiqu´ee pour tous les nids de boucles acc´edant `a des tableaux distribu´es.
La s´eparation de la sp´ecification de la distribution des calculs et des donn´ees constitue une diff´erence majeure par rapport `a HPF [51]. Le programmeur a ainsi le contrˆole sur ces deux aspects de la parall´elisation d’un programme, ce qui permet au compilateur de dSTEP de g´en´erer un code avec un flot de contrˆole et des com- munications plus simples que HPF car il n’existe pas de notion de propri´etaire de donn´ees. Contrairement `a XcalableMP [73], dSTEP ne place pas la responsabilit´e de la sp´ecification des communications sur le programmeur.
Exemple de code g´en´er´e par un compilateur HPF. Les exemples de codes montr´es ici sont tir´es de la documentation en ligne du compilateur dHPF1. Le lis-
ting 3.1 montre un programme HPF simple avec une boucle parall`ele qui implique une communication sur le tableau b (lignes 15-17). Le listing 3.2 montre une partie du code g´en´er´e pour ce programme correspondant `a la boucle parall`ele. On constate que, mˆeme pour ce programme simple, les acc`es locaux sont distingu´es des acc`es non locaux, qui sont r´esolus s´epar´ement (ligne 8). Le flot de contrˆole d’un programme g´en´er´e par un compilateur HPF est d’autant plus complexe que plusieurs r´ef´erences en ´ecriture sont pr´esentes dans un nid de boucles.
1 p r o g r a m s i m p l e t e s t 2 i n t e g e r i 3 double p r e c i s i o n a (100) , b (100) 4 5 CHPF$ p r o c e s s o r s p (4) 6 CHPF$ t e m p l a t e t (100) 7 CHPF$ align a ( i ) with t ( i ) 8 CHPF$ align b ( i ) with t ( i ) 9 CHPF$ d i s t r i b u t e t ( block ) onto p 10 11 C -- I n i t i a l i z a t i o n s -- 12 13 a (1) = 0 14 15 do i = 2 , 100 - 1 16 a ( i ) = 0.25 * b (i -1) 17 enddo 18 19 end
Listing 3.1 – Exemple d’un code simple en HPF