Résolution de systèmes linéaires et non linéaires creux sur grappes de GPUs

(1)

HAL Id: tel-00947627

https://tel.archives-ouvertes.fr/tel-00947627

Submitted on 17 Feb 2014

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

sur grappes de GPUs

Lilia Ziane Khodja

To cite this version:

Lilia Ziane Khodja. Résolution de systèmes linéaires et non linéaires creux sur grappes de GPUs. Autre [cs.OH]. Université de Franche-Comté, 2013. Français. �NNT : 2013BESA2006�. �tel-00947627�

(2)

é c o l e d o c t o r a l e _{s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s}

U N I V E R S I T É D E F R A N C H E - C O M T É

■

R ésolution de syst èmes lin éaires et

non lin ´eaires creux sur grappes de

GPUs

(3)

(4)

é c o l e d o c t o r a l e _{s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s}

U N I V E R S I T É D E F R A N C H E - C O M T É

TH `

ESE pr ´esent ´ee par

Lilia

Z

IANE

K

HODJA

pour obtenir le

Grade de Docteur de

l’Universit ´e de Franche-Comt ´e

Sp ´ecialit ´e :Informatique

R ésolution de syst èmes lin éaires et non lin éaires

creux sur grappes de GPUs

Soutenue le 07 juin 2013 devant le Jury :

Jens GUSTEDT Rapporteur Directeur de recherche à l’INRIA Nancy - Grand Est Fr éd éricMAGOULES` Rapporteur Professeur à l’ École Centrale Paris

Pierre-CyrilleHEAM Examinateur Professeur à l’Universit é de Franche-Comt é

PierreSPITERI´ Examinateur Professeur à l’IRIT-ENSEEIHT Toulouse MingCHAU Examinateur Ing énieur-Chercheur à ASA Toulouse Rapha ëlCOUTURIER Directeur Professeur à l’Universit é de Franche-Comt é

JacquesBAHI Co-Directeur Professeur à l’Universit é de Franche-Comt é

(5)

(6)

Table des mati `eres 8

Liste des ﬁgures 11

Liste des tableaux 14

Liste des algorithmes 15

Remerciements 17

Introduction 21

1 Architectures de calcul parall `ele 25

1.1 Calcul parall `ele . . . 26

1.1.1 Classiﬁcation des architectures parall `eles . . . 26

1.1.1.1 Instruction unique, donn ´ee unique (SISD) . . . 27

1.1.1.2 Instructions multiples, donn ´ee unique (MISD) . . . 27

1.1.1.3 Instruction unique, donn ´ees multiples (SIMD) . . . 27

1.1.1.4 Instructions multiples, donn ´ees multiples (MIMD) . . . 27

1.1.2 M ´emoires des architectures parall `eles . . . 27

1.1.2.1 M ´emoire partag ´ee . . . 28

1.1.2.2 M ´emoire distribu ´ee . . . 28

1.1.3 Plateformes de calcul parall `ele distribu ´ees . . . 29

1.1.3.1 Grappes . . . 29

1.1.3.2 Grilles . . . 29

1.1.4 Environnement de programmation parall `ele MPI . . . 30

1.2 Unit ´e de traitement graphique GPU . . . 31

1.2.1 Architecture mat ´erielle GPU . . . 32

1.2.2 Programmation multithread ´ee CUDA . . . 36

1.2.3 Instructions d’optimisation des performances GPU . . . 38

(7)

1.2.3.2 Utilisation des m ´emoires GPU . . . 40

1.2.4 Plateformes de calcul parall `ele multi-GPUs . . . 41

1.3 Conclusion . . . 42

2 R ésolution de syst èmes lin éaires creux 45 2.1 M éthodes de r ésolution . . . 45

2.1.1 M ´ethodes directes . . . 46

2.1.2 M ´ethodes it ´eratives . . . 47

2.1.2.1 M ´ethodes stationnaires . . . 48

2.1.2.2 M ´ethodes non stationnaires . . . 49

2.1.2.3 M ´ethodes multigrilles . . . 50

2.2 Formats de stockage des matrices creuses . . . 52

2.2.1 COO . . . 53

2.2.2 CSR vs. CSC . . . 53

2.2.3 ELLPACK/ITPACK . . . 55

2.2.4 HYB . . . 56

2.3 Parall élisation des m éthodes it ératives . . . 58

2.3.1 M ´ethodes it ´eratives SISC . . . 58

2.3.2 M ´ethodes it ´eratives SIAC . . . 59

2.3.3 M ´ethodes it ´eratives AIAC . . . 60

3 Mise en œuvre de solveurs lin éaires creux sur des grappes GPU 63 3.1 M éthodes it ératives de Krylov . . . 63

3.1.1 Gradient conjugu ´e . . . 64

3.1.2 G én éralisation de la m éthode de minimisation du r ésidu . . . 65

3.2 Solveurs lin ´eaires creux sur un GPU . . . 68

3.2.1 Mise en œuvre sur un GPU . . . 68

3.2.2 Exp érimentations sur un CPU équip é d’un GPU . . . 71

3.3 Solveurs lin ´eaires creux sur une grappe GPU . . . 74

3.3.1 Mise en œuvre parall `ele sur une grappe GPU . . . 75

3.3.1.1 Partitionnement de donn ´ees . . . 75

3.3.1.2 Calcul des d ´ependances de donn ´ees . . . 76

3.3.1.3 R ´esolution parall `ele . . . 77

3.3.2 Exp ´erimentations sur une grappe GPU . . . 80

(8)

3.3.3.1 Format de stockage compress ´e des vecteurs creux partag ´es 85

3.3.3.2 Partitionnement hypergraphe . . . 89

3.3.4 Exp érimentations sur une grappe GPU h ét érog ène . . . 95

4 Mise œuvre de solveurs non lin éaires creux des probl èmes de l’obstacle sur des grappes GPU 101 4.1 Probl ème de l’obstacle . . . 102

4.1.1 Mod ´elisation . . . 102

4.1.2 Discr ´etisation . . . 102

4.2 M éthodes it ératives parall èles . . . 103

4.2.1 Pr ´eliminaires . . . 104

4.2.2 M éthode parall èle de Richardson projet ée . . . 105

4.2.3 M éthode parall èle de relaxation par blocs projet ée . . . 106

4.2.4 Convergence des m ´ethodes . . . 106

4.3 Mise en œuvre parall `ele sur une grappe GPU . . . 107

4.3.1 Mise en œuvre sur un GPU . . . 107

4.3.2 Parall ´elisation . . . 113

4.4 Exp ´erimentations sur une grappe GPU . . . 116

4.5 Utilisation de la m ´ethode de num ´erotation rouge-noir . . . 119

4.5.1 Mise œuvre sur une grappe GPU . . . 119

4.5.2 Exp ´erimentations . . . 122

5 M éthodes parall èles à deux niveaux sur GPUs 125 5.1 M éthodes de multi-d écomposition . . . 125

5.2 M ´ethode `a deux niveaux avec GMRES . . . 127

5.2.1 Formalisme math ´ematique . . . 127

5.2.2 Mise en œuvre parall `ele . . . 128

5.2.3 Exp ´erimentations . . . 130

(9)

Publications 137

(10)

1.1 Exemple d’architecture parall èle à m émoire partag ée . . . 28

1.2 Exemple d’architecture parall èle à m émoire distribu ée . . . 28

1.3 Exemple de grappe de calcul . . . 29

1.4 Exemple de grille de calcul . . . 30

1.5 Exemples de routines de communications collectives MPI . . . 32

1.6 Historique des architectures mat ´erielles GPU . . . 32

1.7 Exemple de CPU ´equip ´e d’un GPU . . . 33

1.8 Comparaison du nombre de cœurs dans un CPU et dans un GPU . . . 33

1.9 Hi ´erarchie de m ´emoires GPU . . . 33

1.10 Performance th éorique en Gflops/s des GPUs Tesla de diff érentes archi-tectures . . . 35

1.11 Bande passante m émoire th éorique en Go/s des GPUs Tesla de diff érentes architectures . . . 35

1.12 Rapport performance th éorique en double pr écision et consommation d’ énergie en Gflops/Watt . . . 36

1.13 Exemple d’ex écution des blocs de threads à deux dimensions sur un GPU à 3 multiprocesseurs ayant chacun 8 cœurs . . . 37

1.14 Exemple d’ex ´ecution d’un warp par un multiprocesseur `a 8 cœurs . . . 38

1.15 Exemples d’acc ès m émoire coalescent et non coalescent à la m émoire globale par un warp. Un mot m émoire de 4 octets par thread à partir de l’adresse 128 . . . 41

2.1 Format de stockage COO . . . 53

2.2 Format de stockage CSR et CSC . . . 54

2.3 Format de stockage ELL . . . 56

2.4 Format de stockage HYB . . . 57

2.5 Exemple de sch éma d’ex écution d’un solveur it ératif parall èle SISC avec deux processeurs . . . 59

2.6 Exemple de sch éma d’ex écution d’un solveur it ératif parall èle SIAC avec deux processeurs . . . 59

2.7 Exemple de sch éma d’ex écution d’un solveur it ératif parall èle AIAC avec deux processeurs . . . 60

(11)

3.1 Exemple de programme CUDA pour le calcul d’un produit scalaire-vecteur . 69 3.2 Routines CUBLAS utilis ´ees pour la mise en œuvre sur un GPU . . . 71 3.3 Structures des matrices creuses choisies dans la collection de l’universit ´e

de Floride . . . 72 3.4 Exemple de partitionnement de la matrice creuse A, le vecteur solution x

et le vecteur second membre b en quatre portions . . . 75 3.5 Code de la fonction des ´echanges de donn ´ees entre nœuds voisins dans

la grappe GPU . . . 80 3.6 Sch éma g én éral de la grappe GPU de tests . . . 81 3.7 Exemple de g én ération de matrices creuses à structures bandes par

quatre nœuds de calcul . . . 83 3.8 Exemple d’ échange de donn ées entre un nœud 1 et ses trois voisins 0, 2 et 3 86 3.9 Code de la nouvelle fonction des échanges de donn ées entre nœuds

voi-sins dans une grappe GPU . . . 87 3.10 R éorganisation des colonnes d’une sous-matrice creuse locale . . . 88 3.11 Exemple de g én ération de matrices creuses ayant cinq bandes par quatre

nœuds de calcul . . . 90 3.12 Exemple de partitionnement hypergraphe d’une matrice creuse d ´ecoup ´ee

entre trois nœuds de calcul . . . 92 3.13 Passage à l’ échelle des algorithmes parall èles CG et GMRES sur une

grappe GPU pour la r ésolution des syst èmes lin éaires creux . . . 97 4.1 D écomposition d’un sous-probl ème en nz portions . . . 109 4.2 Squelettes des codes d’un kernel GPU et d’une Fonction CPU . . . 110 4.3 Coefficients de la matrice de discr étisation A dans un domaine

tridimen-sionnel . . . 110 4.4 Kernels GPU du solveur Richardson projet é . . . 112 4.5 Calcul d’un él ément de vecteur par la m éthode Richardson projet ée . . . . 113 4.6 Kernels GPU du solveur de relaxation par blocs projet é . . . 114 4.7 Calcul d’un él ément de vecteur par la m éthode de relaxation par blocs

projet ée . . . 115 4.8 Partitionnement de donn ées d’un probl ème de l’obstacle tridimensionnel

en N = 3 × 4 sous-probl èmes . . . 115 4.9 Num érotation rouge-noir pour le calcul des él éments de vecteur dans un

domaine tridimensionnel . . . 120 4.10 Kernels GPU modifi és du solveur Richardson projet ée . . . 121 4.11 Passage à l’ échelle des algorithmes parall èles synchrone et asynchrone

de la m éthode Richardson rouge-noir projet ée . . . 123 5.1 Exemple de multi-d écomposition sans recouvrement entre trois processeurs.126

(12)

(13)

(14)

3.1 Principales caract éristiques des matrices choisies de la collection de l’uni-versit é de Floride . . . 73 3.2 Performances du solveur CG sur un cœur CPU vs. sur un GPU . . . 73 3.3 Performances du solveur GMRES sur un cœur CPU vs. sur un GPU . . . . 73 3.4 Performances du solveur parall èle CG sur une grappe de 24 cœurs CPU

vs. sur une grappe de 12 GPUs . . . 81 3.5 Performances du solveur parall `ele GMRES sur une grappe de 24 cœurs

CPU vs. sur une grappe de 12 GPUs . . . 82 3.6 Principales caract éristiques des matrices creuses g én ér ées à structure

bande . . . 84 3.7 Performances du solveur parall èle CG pour la r ésolution des syst èmes

lin éaires creux à matrices bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs . . . 84 3.8 Performances du solveur parall èle GMRES pour la r ésolution des

syst èmes lin éaires creux à matrices bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs . . . 84 3.9 Performances du solveur parall èle CG utilisant le format de stockage

com-press é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux à matrices bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs . . . 88 3.10 Performances du solveur parall èle GMRES utilisant un format de stockage

compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux à matrices bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs . . . 89 3.11 Principales caract éristiques des matrices creuses de tests ayant cinq bandes 90 3.12 Performances du solveur parall èle CG utilisant un format de stockage

com-press é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à cinq bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs . . . 90 3.13 Performances du solveur parall èle GMRES utilisant un format de stockage

compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à cinq bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs . . . 91

(15)

3.14 Performances du solveur parall èle CG utilisant un partitionnement hyper-graphe et un format de stockage compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à cinq bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs 93 3.15 Performances du solveur parall èle GMRES utilisant un partitionnement

hy-pergraphe et un format de stockage compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à cinq bandes sur une grappe de 24 cœurs CPU vs. sur une grappe de 12 GPUs 94 3.16 Volume total de communications entre 12 nœuds de calcul sans et avec

utilisation de la m ´ethode de partitionnement hypergraphe . . . 94 3.17 Performances du solveur parall `ele CG utilisant un format de stockage

com-press é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à structure bande sur une grappe de 32 cœurs CPU vs. sur une grappe de 14 GPUs . . . 96 3.18 Performances du solveur parall èle GMRES utilisant un format de stockage

compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à structure bande sur une grappe de 32 cœurs CPU vs. sur une grappe de 14 GPUs . . . 96 3.19 Performances du solveur parall èle CG utilisant un partitionnement

hyper-graphe et un format de stockage compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à cinq bandes sur une grappe de 32 cœurs CPU vs. sur une grappe de 14 GPUs 96 3.20 Performances du solveur parall èle GMRES utilisant un partitionnement

hy-pergraphe et un format de stockage compress é des vecteurs creux pour la r ésolution des syst èmes lin éaires creux associ és à des matrices à cinq bandes sur une grappe de 32 cœurs CPU vs. sur une grappe de 14 GPUs 97 3.21 Caract éristiques principales de la matrice de tests utilis ée pour étudier le

passage à l’ échelle des algorithmes parall èles CG et GMRES . . . 97 4.1 Temps d’ex écution en secondes des algorithmes parall èles des m éthodes

Richardson projet ée et de relaxation par blocs projet ée sur une grappe de 24cœurs CPU . . . 117 4.2 Temps d’ex écution en secondes des algorithmes parall èles des m éthodes

Richardson projet ée et de relaxation par blocs projet ée sur une grappe de 12GPUs . . . 117 4.3 Ratios entre le temps d’ex écution sur un grappe de 24 cœurs CPU et le

temps d’ex écution sur une grappe de 12 GPUs . . . 118 4.4 Temps d’ex écution en secondes du solveur parall èle Richardson projet ée

utilisant la num ´erotation rouge-noir sur une grappe de 12 GPUs . . . 122 5.1 Performances des algorithmes synchrone et asynchrone de la m ´ethode

`a deux niveaux avec GMRES sur diff ´erentes architectures de grappes de GPUs . . . 131

(16)

1 Algorithme g én éral d’un solveur it ératif stationnaire . . . 48

2 Algorithme g én éral d’une m éthode bigrille . . . 52

3 Multiplication matrice-vecteur avec le format COO . . . 54

4 Multiplication matrice-vecteur avec le format CSR . . . 55

5 Multiplication matrice-vecteur avec le format CSC . . . 55

6 Multiplication matrice-vecteur avec le format ELL . . . 56

7 Multiplication matrice-vecteur avec le format HYB . . . 57

8 Algorithme du gradient conjugu é pr éconditionn é . . . 65

9 Algorithme du GMRES pr ´econditionn ´e . . . 67

10 Algorithme parall èle du gradient conjugu é pr éconditionn é . . . 78

11 Algorithme parall èle du GMRES pr éconditionn é . . . 79

12 Algorithme g én éral pour la r ésolution des syst èmes non lin éaires du probl ème de l’obstacle . . . 107

13 Algorithme global de la fonction Resoudre . . . 108

14 Algorithme de la m ´ethode de multi-d ´ecomposition . . . 126

(17)

(18)

A l’issue de ce travail, je tiens à exprimer toute ma gratitude à l’ensemble des per-sonnes qui ont contribu é, chacune à sa mani ère, à l’accomplissement de cette th èse.

Je tiens à exprimer mes plus vifs remerciements à mes Directeurs Rapha ël Cou-turier et Jacques Bahi. Les mots me manquent pour exprimer ma gratitude. Leurs comp étences, leurs rigueurs scientifiques et leurs clairvoyances m’ont beaucoup appris. Je les remercie pour leurs encadrements et conseils avis és qu’ils ont su me prodiguer tout au long de ces trois ann ées et aussi pour leurs qualit és humaines chaleureuses, et surtout pour la confiance qu’ils m’ont accord ée.

Je remercie vivement Pierre Spit éri, Professeur à l’IRIT-ENSEEIHT, et Ming Chau, Ing énieur-Chercheur à ASA de Toulouse, pour leur collaboration dans mes travaux de recherche. Je souhaite n éanmoins remercier plus particuli èrement Pierre pour son ind éfectible soutien et encouragements aussi bien sur le plan humain que scientifique.

J’adresse également mes sinc ères remerciements à Jens Gustetd, Directeur de Re-cherche Inria Lorraine, et Fr éd éric Magoul ès, Professeur à l’ École Centrale de Paris, pour m’avoir fait l’honneur d’accepter d’ être rapporteurs de cette th èse. Je voudrais aussi re-mercier Pierre-Cyrille Heam, Professeur à l’Universit é de Franche-Comt é, qui m’a fait l’honneur de pr ésider le jury de cette th èse.

J’adresse mes vifs remerciements à la R égion de Franche-Comt é qui a financ é cette th èse.

Ma reconnaissance et mes remerciements vont aux membres de l’ équipe AND (Algo-rithmique Num érique et Distribu ée) pour le climat sympathique et chaleureux dans lequel il m’ont permis de travailler. Merci donc à Bassam Alkindy, Claude Charr, Jean-François Couchot, Karine Deschinkel, Huu Quan Do, St éphane Domas, Nicolas Friot, Arnaud Giersch, Christophe Guyeux, Mourad Hakem, Ali Kadhum Idrees, David Laiya-mani, Abdallah Makhoul, Ahmed Mostefaoui, Gilles Perrot et Michel Salomon. Je voudrais aussi exprimer mes remerciements et amiti és à Fabrice Ambert, Jean-Luc Anthoine, In-grid Couturier, B éatrice Domenge, Kamel Mazouzi et Patricia Py pour leur bonne humeur et leur disponibilit é.

Avant de terminer, je tiens à remercier notamment mes chers amis : Marie-Antoinette et David Jamin, C écile et Alain Mignot, S ébastien Miqu ée et Maria Delia Valera Castro qui ont partag é mes espoirs et mes inqui études, qui m’ont r éconfort ée dans les moments difficiles et avec qui j’ai partag é d’inoubliables moments de d étente. Je vous remercie tous chaleureusement.

Enfin, les mots les plus simples étant les plus forts, j’adresse toute mon affection à ma famille et, en particulier, à mes parents pour leurs soutien et encouragements au cours de ces longues ann ées d’ études. Malgr é les milliers de kilom ètres qui nous s éparent, leur amour, leur tendresse et leur confiance me portent et me guident tous les jours. Merci, Maman, Papa, pour avoir fait de moi ce que je suis aujourd’hui.

(19)

(20)

help of its mahout, will come to the idea of generating the sequence x0, x1= g(x0), x2 = g(x1), etc. I will not be far from thinking, me too, at the possibility of making the computers to “think”.

Jean Dieudonn ´e

L’esprit qui invente est toujours m écontent de ses progr ès, parce qu’il voit au-del à.

Jean Le Rond d’Alembert

Un chercheur doit avoir conscience du peu de ce qu’il a trouv ´e ; mais il a droit d’estimer que ce peu est im-mense.

(21)

(22)

L

ES syst èmes d’ équations lin éaires ou non lin éaires creux de tr ès grandes tailles apparaissent souvent au cœur des simulations num ériques scientifiques ou indus-trielles. Ils permettent de mod éliser de nombreux probl èmes complexes dans diff érents domaines, tels que la biologie, la finance, la physique ou la climatologie. Cependant, la r ésolution de ce type de syst èmes est un processus tr ès co ûteux en termes de temps d’ex écution et de consommation d’espace m émoire. En effet, les syst èmes lin éaires ou non lin éaires trait és par ces applications sont de tr ès grandes tailles et poss èdent beau-coup de coefficients nuls, et cet aspect creux engendre des acc ès irr éguliers à la m émoire pour la lecture des coefficients non nuls.

Il existe dans le jargon de l’analyse num érique diff érentes m éthodes de r ésolution qui peuvent être class ées en deux grandes familles : directes et it ératives. Cependant, le choix d’une m éthode est g én éralement guid é par les propri ét és du syst ème à r ésoudre, la pr écision de calcul et la vitesse de r ésolution souhait ées. Les m éthodes directes ont sou-vent ét é pr éf ér ées aux m éthodes it ératives, en raison de leur robustesse et de leur com-portement pr évisible. Cependant, depuis les ann ées quatre vingt, les m éthodes it ératives ont rapidement gagn é en popularit é dans de nombreux domaines du calcul scientifique. Ceci est d û en grande partie à la complexit é accrue et à la taille croissante de la nouvelle g én ération de syst èmes d’ équations creux pour lesquels les m éthodes directes sont sou-vent inefficaces. De plus, les m éthodes it ératives sont beaucoup plus faciles à mettre en œuvre et supportent mieux le passage à l’ échelle sur les ordinateurs parall èles que les m éthodes directes.

Aujourd’hui, le calcul parall èle est devenu un enjeu majeur pour la r ésolution de syst èmes lin éaires et non lin éaires creux de tr ès grandes tailles. Ceci gr âce à la puis-sance de calcul et à la capacit é de stockage des ordinateurs parall èles actuels, ainsi qu’ à la disponibilit é de diff érents langages et environnements de programmation parall èle tel que le standard de communication MPI. Il existe diff érents types d’architectures de calculateurs parall èles, à commencer par les processeurs multicœurs jusqu’ à l’intercon-nexion de plusieurs ordinateurs physiquement adjacents ou g éographiquement distants par un r éseau de communication. Au cours des derni ères ann ées, les nouvelles architec-tures comportant des acc él érateurs mat ériels (GPU, FPGA, Xeon Phi, etc) sont devenues tr ès attractives pour le calcul parall èle haute performance. Plus particuli èrement, celles équip ées de processeurs graphiques GPUs qui sont dot és d’une architecture mat érielle massivement parall èle. En effet, l’ évolution de la technologie GPGPU (General-Purpose computing on Graphics Processing Units) a permis d’exploiter la puissance de calcul des GPUs pour le traitement des t âches intensives. Cependant, les calculateurs parall èles équip és de GPUs pr ésentent de nouvelles difficult és de programmation et d’adaptation des algorithmes de r ésolution à leurs architectures.

Dans cette th èse, nous nous int éressons à la conception d’algorithmes parall èles pour les grappes de calcul équip ées de processeurs graphiques GPUs. Pour cela, nous utili-sons une programmation parall èle h ét érog ène GPGPU CUDA/MPI. Cette th èse est

(23)

orga-nis ´ee comme suit.

Dans le Chapitre 1, nous pr ésentons les diff érentes architectures parall èles de

pro-cesseurs classiques, ainsi que celles des nouveaux calculateurs parall èles équip és de GPUs. De plus, nous d écrivons le standard de communication MPI et l’environnement de programmation CUDA pour les GPUs.

Dans le Chapitre 2, nous pr ésentons les diff érentes m éthodes num ériques de

r ésolution, les formats de stockage des matrices creuses et la parall élisation des m éthodes it ératives sur des calculateurs parall èles.

Les trois chapitres suivants pr ésentent nos contributions à la mise en œuvre des algorithmes parall èles, synchrones ou asynchrones, des m éthodes it ératives pour la r ésolution de syst èmes lin éaires ou non lin éaires creux de tr ès grandes tailles sur des grappes de GPUs.

Dans leChapitre 3, nous proposons des mises en œuvre des algorithmes it ´eratifs

pa-rall èles pour la r ésolution de syst èmes lin éaires creux sur une grappe GPU. Nous utilisons les m éthodes it ératives de Krylov suivantes : le gradient conjugu é (CG) qui donne de bons r ésultats de r ésolution pour les syst èmes lin éaires sym étriques et la g én éralisation de la m éthode de minimisation du r ésidu (GMRES) qui est plus adapt ée aux syst èmes lin éaires asym étriques. La mise en œuvre des deux m éthodes sur une grappe GPU impose la pa-rall élisation de leurs algorithmes et la gestion des interactions entre les diff érents nœuds de calcul de la grappe. En fait, toutes les op érations parall èles sont ex écut ées par les GPUs et la synchronisation des calculs locaux est assur ée par les CPUs via les routines de communications MPI. L’op ération la plus importante des m éthodes CG et GMRES est la multiplication parall èle matrice creuse-vecteur. Elle n écessite un temps de calcul im-portant et des communications de donn ées entre les nœuds GPUs pour la construction du vecteur global requis pour la multiplication. Toutefois, il est indispensable de minimiser le nombre de communications qui s’av èrent tr ès co ûteuses sur une grappe GPU. Pour minimiser les co ûts de communication, nous proposons d’utiliser un format de stockage compress é pour les vecteurs de donn ées partag ées et un partitionnement hypergraphe pour r éduire le nombre de d épendances de donn ées entre les nœuds GPUs de la grappe. LeChapitre 4 pr ésente nos travaux sur la r ésolution de syst èmes non lin éaires creux

issus de la discr étisation spatiale des probl èmes de l’obstacle. Ce type de probl èmes intervient, par exemple, dans les math ématiques financi ères ( évaluation des options am éricaines) ou dans la simulation des ph énom ènes physiques (m écanique des fluides). Pour la r ésolution de ces syst èmes, nous utilisons les m éthodes it ératives : Richard-son et relaxation par blocs projet ées. La m éthode RichardRichard-son projet ée est bas ée sur les it érations de la m éthode Jacobi par points, tandis que celle de relaxation par blocs pro-jet ée est bas ée sur les it érations de la m éthode Gauss-Seidel par blocs. Par le biais de ces diff érentes m éthodes, nous voulons étudier le comportement de deux algorithmes it ératifs, plus ou moins, oppos és sur une grappe GPU. Pour chacune de ces m éthodes, nous d éveloppons deux algorithmes parall èles, synchrone et asynchrone, adapt és aux grappes GPUs. Notre objectif est d’ étudier le passage à l’ échelle des deux versions pa-rall èles (synchrone et asynchrone) sur une grappe de GPUs. Afin d’am éliorer les per-formances de r ésolution des probl èmes de l’obstacle, nous proposons de combiner les approches de r ésolution des deux m éthodes Richardson et relaxation par blocs projet ées. Nous appliquons une technique de num érotation rouge-noir aux algorithmes parall èles de la m éthode Richardson projet ée. En effet, cette technique est une variante de la m éthode Gauss-Seidel moins stricte (plus facile à parall éliser) qui permet d’acc él érer la

(24)

conver-gence (effectuer moins d’it ´erations) sur la grappe GPU.

Dans leChapitre 5, nous nous int ´eressons aux grappes g ´eographiquement distantes

pour la r ésolution de syst èmes lin éaires creux de tr ès grandes tailles. Dans ce contexte, nous utilisons des m éthodes de multi-d écomposition à deux niveaux. En se basant sur ces m éthodes, nous pouvons construire des algorithmes parall èles à gros grains permet-tant de r éduire les échanges de donn ées entre les nœuds de calcul. Ceci est un avantage pour les architectures distribu ées compos ées de nœuds de calcul g éographiquement dis-tants et interconnect és par un r éseau de communication à forte latence. Nous proposons des mises en œuvre synchrone et asynchrone pour une m éthode de multi-d écomposition à deux niveaux utilisant la m éthode it érative parall èle GMRES adapt ée aux grappes GPUs. Nous utilisons une m éthode de multi-d écomposition qui consiste à d écouper le syst ème lin éaire creux en sous-syst èmes de plus petites tailles disjoints et sans recou-vrement. Notre objectif est de combiner la performance des it érations synchrones dans un contexte local pour la r ésolution des sous-syst èmes lin éaires et la souplesse des it érations asynchrones entre les grappes GPUs pour r ésoudre la globalit é du syst ème lin éaire creux.

Enfin, nous concluons et donnons les perspectives aux travaux de recherche men és dans cette th èse.

(25)

(26)

1

A

RCHITECTURES DE CALCUL

PARALL

ELE

`

A

U cours de ces derni ères ann ées, le calcul haute performance (HPC) est devenu un enjeu majeur dans diff érents domaines de recherche, par exemple l’imagerie et les diagnostics m édicaux, les math ématiques financi ères ou l’exploration p étroli ère. Il fait r éf érence aux calculs intensifs des applications n écessitant des quantit és énormes en ressources de calcul (puissance de calcul, d ébit m émoire, espace de stockage, etc), pour une r ésolution efficace et rapide de diff érents probl èmes scientifiques ou industriels. Ainsi, ceci se traduit par l’ex écution de ces applications sur des architectures parall èles, faisant coop érer plusieurs calculateurs et fonctionnant au-dessus de 1015 _{op érations à}

virgule flottante par seconde (ou un p étaflops).

Plusieurs architectures parall èles ont ét é conçues pour la r ésolution des probl èmes scientifiques, commerciaux ou d’ing énierie complexes, reconnus gourmands en res-sources de calcul. Il y a, globalement, deux types d’architectures parall èles. Le premier concerne les multiprocesseurs qui permettent de rassembler plusieurs processeurs dans une m ême machine. Le deuxi ème type concerne les plateformes distribu ées qui per-mettent de faire coop érer plusieurs ordinateurs de type PC via un r éseau de communica-tion. Cependant, depuis quelques ann ées, les plateformes distribu ées connaissent une forte utilisation par rapport aux multiprocesseurs. Ceci est d û au fait que ces derniers sont plus chers et souvent difficilement extensibles.

Au cours de la derni ère d écennie, l’ évolution de la technologie GPGPU (General-Purpose computing on Graphics Processing Units) a permis d’exploiter la puissance de calcul des processeurs graphiques GPUs pour le traitement des t âches massivement parall èles. Initialement conçus pour des applications graphiques, les GPUs sont aujour-d’hui capables d’ex écuter des algorithmes parall èles beaucoup plus rapidement que les processeurs classiques CPUs. Ceci a incit é de nombreux scientifiques et industriels à int égrer des GPUs dans leurs plateformes de calcul parall èle qui leur permettent, ainsi, d’adresser de nouveaux probl èmes de plus en plus complexes.

Ce chapitre est organis é en deux principales sections. La section 1.1 d écrit les diff érentes architectures parall èles de processeurs classiques. Nous donnons deux clas-sifications des architectures parall èles : une classification selon Flynn et une autre selon l’organisation de la m émoire. Ensuite, nous pr ésentons deux types d’architectures dis-tribu ées et nous donnons les principaux points cl és de la programmation parall èle avec l’environnement MPI. La section 1.2 est consacr ée à la description des unit és de calcul graphiques. Dans cette section, nous d écrivons l’architecture mat érielle des GPUs ainsi que, leur environnement de programmation GPGPU CUDA d évelopp é par la soci ét é

(27)

nVI-DIA. Enfin, nous pr ésentons les architectures parall èles multi-GPUs.

1.1/

C

ALCUL PARALLELE

`

Avant de d éfinir le principe d’un calcul parall èle, nous avons jug é utile de d éfinir, tout d’abord, celui de son oppos é, à savoir le calcul s équentiel et ce, pour mieux cerner la diff érence entre eux. Un calcul s équentiel consiste à ex écuter un programme, instruction par instruction, par un seul processeur (unit é de calcul) et de façon à ce qu’une seule instruction soit ex écut ée à la fois. En revanche, un calcul parall èle est d éfini comme l’ex écution d’un ou plusieurs programmes, simultan ément, par plusieurs processeurs. Nous avons, en g én éral, deux mani ères de r éaliser un calcul parall èle. La premi ère consiste à d écouper le programme en plusieurs t âches de calcul puis, ex écuter toutes ces t âches en parall èle par diff érents processeurs. La seconde n écessite le partitionne-ment des donn ées du probl ème à traiter, de mani ère à ce que chaque partie de donn ées soit attribu ée à un processeur diff érent. Ensuite, tous les processeurs ex écutent en pa-rall èle les instructions du m ême programme mais en op érant sur des donn ées diff érentes. Cette derni ère m éthode, appel ée la parall élisation de donn ées, est celle retenue dans nos travaux.

En outre, les calculs parall èles n écessitent aussi une gestion des d épendances de donn ées entre les diff érents processeurs. Les calculs locaux de deux processeurs sont dits d épendants lorsque l’ex écution de l’un affecte le r ésultat de l’autre. Une d épendance de donn ées implique une utilisation de la valeur d’une m ême variable par les calculs locaux de deux ou plusieurs processeurs. Les d épendances de donn ées peuvent être g ér ées par la synchronisation des lectures/ écritures dans une m ême m émoire (syst èmes à m émoire partag ée) ou par la communication de donn ées entre processeurs via des messages (syst èmes à m émoire distribu ée).

Le calcul parall èle a pour objectif d’exploiter la grande quantit é de ressources (pro-cesseurs, m émoires, espaces de stockage, etc) qu’offrent les calculateurs parall èles ; ceci, dans le but de r éduire le temps d’ex écution des applications n écessitant un long traitement et/ou pour pouvoir ex écuter celles portant sur des volumes de donn ées tr ès importants. Tout cela nous permet d’aborder de nouveaux probl èmes, de plus en plus, complexes et de tailles toujours croissantes.

1.1.1/ CLASSIFICATION DES ARCHITECTURES PARALLELES`

Un calculateur parall èle peut être : un processeur multicœurs poss édant au moins deux unit és de calcul physiques grav ées sur la m ême puce ou un supercalculateur qui permet de rassembler les composantes de plusieurs ordinateurs (processeurs et m émoires) dans une seule machine ou une plateforme distribu ée compos ée de plusieurs machines ind épendantes, homog ènes ou h ét érog ènes, reli ées entre elles par un r éseau de communication.

Il existe dans la litt érature plusieurs classifications portant sur les architectures de cal-culateurs parall èles et bas ées sur diff érents crit ères de classification [37, 46, 48, 67]. Dans cette section, nous pr ésentons la classification la plus largement utilis ée dans le domaine du calcul parall èle, à savoir : la taxonomie de Flynn [37]. Elle est bas ée sur deux crit ères : le nombre d’instructions et le nombre de donn ées qui peuvent être

(28)

trait ées, simultan ément, par les diff érents processeurs du calculateur parall èle. Les quatre cat égories possibles de la taxonomie de Flynn sont d écrites ci-apr ès.

1.1.1.1/ INSTRUCTION UNIQUE,DONNEE UNIQUE´ (SISD)

La classe SISD (Single Instruction, Single Data) repr ésente l’ensemble des teurs s équentiels à une seule unit é de calcul (ou monoprocesseur). Ce sont les calcula-teurs qui ne sont capables de traiter qu’une seule instruction sur une seule donn ée, par cycle d’horloge. Bien évidemment, cette cat égorie n’est pas une architecture parall èle.

1.1.1.2/ INSTRUCTIONS MULTIPLES,DONNEE UNIQUE´ (MISD)

La classe MISD (Multiple Instruction, Single Data) correspond aux calculateurs pa-rall èles pouvant ex écuter plusieurs instructions, simultan ément, sur la m ême donn ée. Peu de calculateurs MISD ont exist é en pratique, vu le nombre r éduit des applications qui peuvent être mises en œuvre sur ce type d’architecture. Un exemple de calculateur parall èle exp érimental MISD a ét é d évelopp é à l’universit é de Carnegie Mellon [13].

1.1.1.3/ INSTRUCTION UNIQUE,DONNEES MULTIPLES´ (SIMD)

La classe SIMD (Single Instruction, Multiple Data) correspond aux processeurs vec-toriels et, plus g én éralement, aux calculateurs compos és d’un grand nombre d’unit és de calcul. Á chaque cycle d’horloge, tous les processeurs d’un calculateur SIMD ex écutent, simultan ément, la m ême instruction mais op érant sur des donn ées diff érentes. Cette ar-chitecture parall èle est bien adapt ée aux traitements des probl èmes à structure r éguli ère o ù la m ême instruction est appliqu ée à un ensemble de donn ées (ex écution des op érations sur des vecteurs ou des tableaux).

1.1.1.4/ INSTRUCTIONS MULTIPLES,DONNEES MULTIPLES´ (MIMD)

La classe MIMD (Multiple Instruction, Multiple Data) repr ésente la cat égorie la plus g én érale dans cette taxonomie. Les calculateurs parall èles MIMD poss èdent plusieurs processeurs interconnect és entre eux, tels que chaque processeur soit capable de suivre son propre chemin d’ex écution. En effet, à chaque cycle d’horloge, les proces-seurs peuvent ex écuter, simultan ément, des instructions diff érentes sur des donn ées diff érentes.

1.1.2/ M ´EMOIRES DES ARCHITECTURES PARALLELES`

Nous pouvons distinguer, en g én éral, deux mod èles de gestion de la m émoire des cal-culateurs parall èles : la m émoire partag ée et la m émoire distribu ée. Ces deux mod èles de m émoire permettent de d éfinir les modalit és d’acc ès aux donn ées des autres proces-seurs dans un calcul parall èle.

(29)

1.1.2.1/ M ´EMOIRE PARTAGEE´

Dans ce type d’architecture, les processeurs du calculateur parall èle ont un acc ès di-rect au m ême espace m émoire physique via des liens de communication performants, avec un temps d’acc ès rapide et équitable. En effet, les processeurs peuvent op érer ind épendamment mais toutes les donn ées du calcul parall èle sont plac ées dans une m émoire commune et ce, de façon à ce que les changements établis dans la m émoire par un processeur soient imm édiatement visibles par les autres processeurs. Dans ce cas, les échanges de donn ées entre processeurs sont effectu és via la synchronisation des lectures/ écritures dans la m émoire partag ée. La figure 1.1 montre un exemple d’ar-chitecture parall èle à m émoire partag ée.

...

Mémoire

Processeur Processeur Processeur Processeur

Bus d’interconnexion

FIGURE1.1 – Exemple d’architecture parall èle à m émoire partag ée

1.1.2.2/ M ´EMOIRE DISTRIBUEE´

Nous pouvons trouver ce type de m émoire, plus particuli èrement, sur les plateformes de calcul parall èle à ressources distribu ées, par exemple les grappes et les grilles de calcul (voir section 1.1.3). Dans ce cas, chaque processeur de la plateforme parall èle poss ède sa propre m émoire locale dans laquelle les changements ne sont pas visibles depuis les autres processeurs. Par cons équent, l’acc ès aux donn ées des m émoires dis-tantes (m émoires des processeurs voisins) est assur é par des envois de messages entre processeurs via un r éseau de communication. La figure 1.2 illustre un exemple d’archi-tecture parall èle à m émoire distribu ée.

...

Processeur Processeur Processeur Processeur

Mémoire Mémoire Mémoire Mémoire

Réseau de communication

(30)

1.1.3/ PLATEFORMES DE CALCUL PARALLELE DISTRIBU` EES´

Depuis les ann ées quatre-vingt-dix, les plateformes distribu ées connaissent un essor tr ès important dans le domaine du calcul haute performance. Ceci est rendu possible gr âce à l’ évolution des processeurs classiques et des r éseaux de communication. En effet, une plateforme distribu ée est constitu ée, g én éralement, de calculateurs standards peu on éreux (typiquement, des ordinateurs de bureau) reli és entre eux par un r éseau de communication. De plus, sa configuration mat érielle peut être facilement mise à jour car l’ajout ou le renouvellement de quelques calculateurs sont faciles à r éaliser et peu co ûteux. Enfin, elle peut fournir des performances équivalentes ou sup érieures à celles d’un supercalculateur pour un co ût inf érieur. Nous pouvons classifier les plateformes dis-tribu ées en deux cat égories : les grappes et les grilles de calcul.

1.1.3.1/ GRAPPES

Une grappe de calcul, appel ée commun ément cluster en anglais, est constitu ée de deux ou plusieurs calculateurs, plus ou moins, homog ènes interconnect és par un r éseau local, souvent, à haut d ébit (par exemple, un r éseau InfiniBand). Chaque calculateur fai-sant partie d’une grappe est appel é nœud de calcul et il poss ède une ou plusieurs unit és de calcul et une m émoire locale. Tous les nœuds de calcul d’une grappe travaillent en-semble comme un seul calculateur parall èle. En g én éral, une grappe de calcul dispose d’un nœud, dit frontal, qui a pour r ôle la gestion des ressources et la distribution des cal-culs sur les nœuds. La figure 1.3 montre un exemple de grappe de calcul compos ée de six nœuds, ayant chacun quatre unit és de calcul.

Proc Proc Proc Proc Mémoire Proc Proc Proc Proc Mémoire Proc Proc Proc Proc Mémoire Proc Proc Proc Proc Mémoire Proc Proc Proc Proc Mémoire Proc Proc Proc Proc Mémoire Réseau local

Noeud 0 Noeud 1 Noeud 2 Noeud 3 Noeud 4 Noeud 5

FIGURE1.3 – Exemple de grappe de calcul

1.1.3.2/ GRILLES

Une grille de calcul a une architecture plus distribu ée que celle d’une grappe de cal-cul. Elle est compos ée d’un grand nombre de calculateurs autonomes, h ét érog ènes, g éographiquement distants et interconnect és par des r éseaux de communication h ét érog ènes. Le principal objectif d’une grille est d’exploiter les ressources de calcul (processeurs, m émoire, espace disque, etc) de milliers de calculateurs, quelques soient leurs placements g éographiques, pour r ésoudre des probl èmes de calcul n écessitant des temps d’ex écution et/ou des espaces de stockage ph énom énaux en environnements

(31)

classiques. Ceci est devenu possible gr âce à l’ évolution des r éseaux longue distance (par exemple, r éseau Ethernet), qui permettent d’acc éder efficacement aux ressources distantes. Les calculateurs constituant une grille de calcul peuvent être de diff érents types d’architectures mat érielles et logicielles : monoprocesseurs, supercalculateurs, grappes de calcul, etc. Par exemple, la figure 1.4 illustre une grille de calcul compos ée de trois sites de grappes de calcul g éographiquement distants et communiquant entre eux via le r éseau Internet. A la diff érence des grappes de calcul, les sites d’une grille de calcul ne sont pas sous une administration commune et, ainsi, la gestion des ressources et des t âches de calcul est effectu ée d’une façon distribu ée.

Grappe de calcul Grappe de calcul Site 0 Site 1 Site 2 Grappe de calcul Réseau Internet

FIGURE1.4 – Exemple de grille de calcul

1.1.4/ ENVIRONNEMENT DE PROGRAMMATION PARALLELE` MPI

MPI (Message Passing Interface) est un standard d éfinissant un ensemble de routines pour le calcul parall èle par échange de messages [45] dont la premi ère version est ap-parue en 1993. Il est le fruit d’une collaboration entre des universitaires et des industriels de diff érents domaines scientifiques [38]. Le principal objectif vis é par le standard MPI est de pouvoir d évelopper des applications parall èles efficaces et portables qui peuvent être mises en œuvre et ex écut ées sur n’importe quelle architecture de calcul parall èle. De ce fait, les fonctions MPI peuvent fournir de bonnes performances aussi bien sur des multiprocesseurs à m émoire partag ée (supercalculateurs) que sur des plateformes de calculateurs distants et à m émoire distribu ée (grappes et grilles de calcul).

Les biblioth èques classiques MPI, telles que OpenMPI [42] et MPICH [56], fournissent des routines MPI qui peuvent être utilis ées depuis un programme écrit en C, en Fortran ou en C++. Par ailleurs, il existe aussi des biblioth èques MPI conçues pour d’autres lan-gages de programmation, par exemple Java [20], OCaml [53] et Python [63]. Une appli-cation MPI est un ensemble de processus ind épendants ex écutant en parall èle le m ême

(32)

code de programme sur leurs propres donn ées et communicant entre eux via des ap-pels aux routines de la biblioth èque MPI. En g én éral, un programme MPI commence par un appel de la fonction MPI_Init() pour initialiser l’environnement MPI n écessaire pour l’ex écution de l’application et il se termine par un appel de la fonction MPI_Finalize() pour d ésactiver cet environnement. De plus, MPI d éfinit des groupes de processus nomm és communicateurs, tels que deux processus ne puissent communiquer entre eux que s’ils appartiennent au m ême communicateur. Initialement, un communicateur global MPI_COMM_WORLD est utilis é pour r éunir tous les processus et il peut être subdivis é en plusieurs communicateurs plus petits avec la fonction MPI_Comm_split(). Enfin, chaque processus impliqu é dans l’ex écution d’un programme MPI est identifi é par un rang au sein de son groupe qui peut être d étermin é par la fonction MPI_Comm_rank().

Dans un programme parall èle MPI, un processus dispose de ses propres donn ées sans acc ès direct aux donn ées des autres processus. De ce fait, MPI utilise des échanges explicites de donn ées entre processus par passage de messages. Il contient plusieurs routines de communication entre processus que nous pouvons classer en deux cat égories : les routines de communications point- à-point et les routines de communi-cations collectives. Les premi ères consistent en diff érents types d’op érations d’envoi et de r éception de messages entre deux, et seulement deux, processus au sein du m ême communicateur. Il existe deux types de communications point- à-point : bloquantes et non bloquantes. Une communication d’envoi bloquante signifie que le processus émetteur est bloqu é tant que les donn ées à envoyer ne sont pas toutes transmises (par exemple, MPI_Send()). De la m ême façon, une communication de r éception bloquante signifie que le processus r écepteur reste bloqu é tant que les donn ées à recevoir ne sont pas toutes accessibles (par exemple, MPI_Recv()). Par contre, les communications non blo-quantes permettent au processus émetteur ou r écepteur de poursuivre l’ex écution de son code sans que la communication d’envoi ou de r éception soit r éellement effectu ée. Nous avons, par exemple, les routines MPI_Isend() et MPI_Irecv() pour les op érations d’envoi et de r éception non bloquantes, respectivement. Les routines de communication non bloquantes ont pour but de r éduire les temps d’attente dus aux envois et r éceptions de messages.

Les communications collectives sont des communications bloquantes impliquant l’en-semble des processus appartenant au m ême communicateur. MPI propose plusieurs routines de communication collectives qui peuvent être class ées, g én éralement, en trois cat égories selon leurs fonctionnalit és : synchronisation (par exemple, MPI_Barrier() et MPI_Wait()), échanges de donn ées (par exemple, MPI_Alltoallv()) et op érations de r éduction sur les donn ées (par exemple, MPI_Allreduce()). La figure 1.5 montre un exemple des échanges de donn ées (figure (a)) et un exemple d’op érations de r éduction (figure (b)), tel que, le calcul de la somme des donn ées de tous les processus. En plus des routines de communication, MPI propose aussi des routines de gestion de l’environ-nement d’ex écution MPI, des structures de donn ées et des topologies de processus (par exemple, grille de processus).

1.2/

U

NITE DE TRAITEMENT GRAPHIQUE

´

GPU

L’architecture et l’environnement de programmation GPU utilis és dans ce docu-ment sont ceux bas és sur la plateforme CUDA (Compute Unified Device Architecture) d évelopp ée par l’un des plus grands fournisseurs de GPUs : nVIDIA [28].

(33)

Processus 0 Processus 1 Processus 2 Processus 0 Processus 1 Processus 2

(a) Echanges de donn ées (MPI_Alltoallv()) (b) Op ération de r éduction (MPI_Allreduce()) FIGURE1.5 – Exemples de routines de communications collectives MPI

1.2.1/ ARCHITECTURE MATERIELLE´ GPU

Les processeurs graphiques GPUs ont ét é, initialement, conçus pour le traitement des applications graphiques et de la visualisation 3D. Nous pouvons citer, par exemple, les produits GeForce et Quadro, deux gammes de GPUs propos ées par nVIDIA, qui sont destin és, respectivement, au graphisme grand public et à la visualisation professionnelle. Depuis quelques ann ées, les GPUs sont devenus des outils tr ès attrayants pour le cal-cul haute performance (HPC). La gamme de produits Tesla a ét é conçue par nVIDIA pour offrir des capacit és de calcul parall èle élev ées et assister les processeurs dans les calculs intensifs des applications scientifiques et/ou industrielles. La figure 1.6 montre les diff érentes architectures mat érielles GPU d évelopp ées par nVIDIA ainsi que celles à d évelopper dans un futur proche.

Fermi Kepler Maxwell Einstein

2010 2012 2014 2016 G80 2008 GT200 2007 Tesla Année

FIGURE1.6 – Historique des architectures mat ´erielles GPU

Un GPU est un processeur graphique reli é à un processeur traditionnel (CPU) via un PCI-Express (voir figure 1.7). Il est souvent consid ér é comme un acc él érateur d’op érations arithm étiques intensives d’une application ex écut ée sur un CPU. Il puise sa puissance de calcul de son architecture mat érielle et logicielle massivement parall èle. En effet, à la diff érence d’une architecture CPU, un GPU est compos é de centaines (voire de milliers) de processeurs (SP), appel és commun ément cœurs, organis és en plusieurs blocs de processeurs appel és multiprocesseurs (SM ou SMX). La figure 1.8 montre une comparaison entre l’architecture mat érielle d’un CPU et celle d’un GPU Fermi. Les pro-cesseurs d’un GPU sont regroup és par 8 (Tesla), 32 (Fermi) ou 192 (Kepler) dans un multiprocesseur, selon le type de son architecture mat érielle. De la m ême mani ère, les multiprocesseurs sont eux-m êmes regroup és par 2 (G80) ou 3 (GT200) dans un TPC (Texture Processing Cluster) pour l’architecture Tesla et par 4 (Fermi) ou 2 (Kepler) dans un GPC (Graphics Processing Cluster) pour les nouvelles architectures.

En plus de la hi érarchie de processeurs, un GPU est dot é d’une hi érarchie de m émoires de diff érentes tailles et de diff érentes bandes passantes m émoires. Nous dis-tinguons, au total, six m émoires diff érentes (voir figure 1.9) :

(34)

(a) Carte graphique GPU (b) Un GPU reli é à un CPU FIGURE1.7 – Exemple de CPU équip é d’un GPU

RAM Coeur 0 Coeur 1 Coeur 2 Coeur 3 Coeur 4 Coeur 5 Coeur 6 Coeur 7

.

..

.

..

RAM Multiprocesseur 0 32 coeurs 32 coeurs Multiprocesseur 2 32 coeurs Multiprocesseur 3 32 coeurs Multiprocesseur 4 32 coeurs Multiprocesseur 5 32 coeurs Multiprocesseur 14 32 coeurs Multiprocesseur 15 32 coeurs Multiprocesseur 1

(a) Un CPU `a 8 cœurs (b) Un GPU Fermi `a 512 cœurs

FIGURE1.8 – Comparaison du nombre de cœurs dans un CPU et dans un GPU

Multiprocesseur m

Multiprocesseur 1

Multiprocesseur 0

Processeur 0 Processeur 1 Processeur n Registres Registres Registres

partagee Mémoire constantecache Mémoire Mémoire texturecache

Mémoire globale (locale, constante et texture)

Multiprocesseur m Multiprocesseur 1

Multiprocesseur 0

Registres Registres Registres

Processeur 0 Processeur 1 Processeur n

partagée Mémoire Mémoire cache L1 constantecache Mémoire Mémoire texturecache cache L2 Mémoire

Mémoire globale (locale, constante et texture)

(a) Architecture Tesla (b) Architecture Fermi ou Kepler FIGURE1.9 – Hi ´erarchie de m ´emoires GPU

– Registres : chaque multiprocesseur a 8K à 65K registres à 32-bit, r épartis entre tous ses processeurs. Ce sont des m émoires rapides, accessibles en lecture/ écriture et avec une faible latence (environ 1 cycle).

(35)

– M émoire partag ée : de 16 à 48 Ko de m émoire par multiprocesseur. C’est une petite m émoire extr êmement rapide. Elle est dot ée d’une large bande passante m émoire (plus d’un To/s) et d’une faible latence (environ 1 à 2 cycles). Elle est accessible en lecture/ écriture par tous les processeurs du m ême multiprocesseur. – M émoire globale : chaque GPU est équip é de sa propre RAM (GDDR3 ou GDDR5)

de 1 à 6 Go. C’est une m émoire accessible en lecture/ écriture et partag ée entre tous les multiprocesseurs au sein d’un m ême GPU. Elle est dot ée d’une large bande passante m émoire (jusqu’ à 288 Go/s pour la nouvelle g én ération Kepler). Cependant, elle poss ède un temps d’acc ès plus lent par rapport aux autres m émoires (200 à 600 cycles).

– M émoire locale : de 16 à 512 Ko par processeur. C’est une zone m émoire, acces-sible en lecture/ écriture, dans la m émoire globale. Elle est allou ée à un processeur dans le cas o ù un programme, en cours d’ex écution, n écessite plus de registres que ceux disponibles. Bien évidemment, elle poss ède les m êmes caract éristiques que la m émoire globale.

– M émoire constante : c’est un espace m émoire de 64 Ko qui r éside dans la m émoire globale. Il permet de sauvegarder les donn ées dont les valeurs restent constantes au cours de l’ex écution d’un programme sur le GPU. De plus, chaque multiprocesseur poss ède une petite m émoire cache constante (environ 8 Ko par multiprocesseur), accessible en lecture seule par tous ses processeurs. Cette m émoire cache constante permet de mettre en cache la m émoire constante afin d’acc él érer les acc ès m émoires en lecture aux donn ées constantes stock ées dans la m émoire constante.

– M émoire texture : n’importe quelle partie de la m émoire globale peut être d éfinie comme une m émoire texture. Elle permet d’am éliorer le temps des acc ès irr éguliers à la m émoire globale. Elle peut prendre en charge des tableaux de diff érents types de donn ées à un, deux ou trois dimensions. Comme pour la m émoire constante, la m émoire texture est mise en cache dans une m émoire cache texture, de 6 à 8 Ko par multiprocesseur. Cette m émoire cache texture est accessible en lecture seule par tous les processeurs d’un m ême multiprocesseur.

Etant donn é que l’espace de la m émoire locale r éside dans la m émoire globale, les acc ès en lecture/ écriture à celle-ci ont une latence élev ée et une bande passante m émoire faible par rapport à ceux effectu és sur la m émoire partag ée. Les nouvelles ar-chitectures (Fermi, Kepler, etc) ont 64 Ko de m émoire par multiprocesseur qui peut être configur ée de trois façons : en 16 Ko de m émoire partag ée et 48 Ko de m émoire cache L1, en 48 Ko de m émoire partag ée et 16 Ko de m émoire cache L1 ou 32 Ko de m émoire partag ée et 32 Ko de m émoire cache L1. De plus, elles poss èdent aussi une m émoire cache L2 de 768 Ko (Fermi) ou de 1538 Ko (Kepler), partag ée entre tous les multipro-cesseurs du GPU. Ces deux m émoires caches sont souvent utilis ées pour am éliorer les performances des acc ès aux m émoires locale et globale. La seule m émoire GPU acces-sible par le CPU est la m émoire globale. Tous les échanges de donn ées entre un CPU et son GPU sont effectu és via l’interface de communication PCI-Express de la RAM CPU vers la m émoire globale GPU et vice versa. Ainsi, le CPU peut acc éder en lecture/ écriture aux m émoires globale, texture et constante.

(36)

2007 2008 1000 2000 3000 2010 2011 2012 4000 5000 (G80) C870 (GT200) C1060 (Fermi) C2070 (Fermi) M2090 (Kepler)K20 0 6000 Année

Performance théorique en GFlops/s

Simple précision Double précision

FIGURE1.10 – Performance th éorique en Gflops/s des GPUs Tesla de diff érentes archi-tectures 2007 2008 2010 2011 2012 100 150 200 250 300 50 (G80) C870 K20 (Kepler) (GT200) C1060 (Fermi) C2070 (Fermi)M2090

Bande passante mémoie théorique en Go/s

Année

FIGURE 1.11 – Bande passante m émoire th éorique en Go/s des GPUs Tesla de diff érentes architectures

Dans le monde du calcul haute performance, les architectures massivement parall èles des GPUs offrent des performances et des capacit és de calcul tr ès int éressantes pour r ésoudre de nouveaux probl èmes complexes de tailles toujours croissantes. Les deux fi-gures 1.10 et 1.11 montrent, respectivement, la puissance de calcul et la bande passante m émoire th éoriques des GPUs Tesla de diff érentes architectures. La puissance de calcul d’un GPU est repr ésent ée par le nombre d’op érations à virgule flottante ex écut ées par seconde (flops/s). La figure 1.10 montre qu’un seul GPU peut fournir une puissance de calcul d épassant les 1 Tflops/s en simple pr écision (1012 _{flops/s) et les 500 Gflops/s en}

double pr écision (5×1011_{flops/s). Par ailleurs, une bande passante m émoire exprim ée en}

nombre d’octets par seconde (o/s) d ésigne le d ébit de lecture/ écriture des donn ées dans la m émoire globale par les processeurs du GPU. La figure 1.11 montre que les bandes passantes m émoires GPU sont tr ès élev ées, variant entre 177 et 288 Go/s, permettant ainsi de diminuer les attentes dues aux acc ès à la m émoire et augmenter la puissance de calcul.

Un autre param ètre de performance int éressant des GPUs est leur efficacit é énerg étique. Dans les derni ères ann ées, l’architecture des nouveaux produits GPU a ét é

(37)

Nvidia Nvidia Nvidia Nvidia 0 2 4 6 8 10 12 14 16 2008 2010 2012 2014 (GT200) Tesla Fermi Kepler Maxwell

Performance double précision par watt GFlops/Watt

Année

FIGURE 1.12 – Rapport performance th éorique en double pr écision et consommation d’ énergie en Gflops/Watt

optimis ée afin d’augmenter leurs puissances de calcul tout en r éduisant leurs consomma-tions d’ énergie. La figure 1.12 illustre le rapport entre la puissance de calcul th éorique et la consommation énerg étique des GPUs de diff érentes architectures. Ce rapport est ex-prim é en nombre d’op érations à virgule flottante en double pr écision ex écut ées par Watt (flops/Watt). Nous pouvons remarquer que les GPUs des deux premi ères g én érations Tesla et Fermi ex écutent au maximum 2 Gflops/Watt alors que ceux des nouvelles g én érations Kepler et Maxwell, sortie en 2012 et pr évue pour 2014, pourront ex écuter, respectivement, jusqu’ à 6 Gflops/Watt et 16 Gflops/Watt en double pr écision. De quoi int éresser les entreprises et les industries pour r éduire les co ûts de consommation

´energ ´etique de leurs applications.

1.2.2/ PROGRAMMATION MULTITHREADEE´ CUDA

CUDA est un environnement de programmation GPU d évelopp é par nVIDIA [28] dont la premi ère version a ét é publi ée durant l’ann ée 2007. Il est bas é sur le langage de programmation C/C++ avec quelques extensions permettant aux GPUs d’ex écuter des calculs g én éraux GPGPU (applications graphiques et/ou non-graphiques), qui sont ha-bituellement ex écut és par les CPUs. Une application écrite en CUDA est un programme h ét érog ène qui s’ex écute sur un processeur (CPU) équip é d’une carte graphique (GPU). En effet, dans un programme CUDA, les codes à ex écuter par le CPU sont d éfinis s épar ément de ceux à ex écuter par le GPU. Toutes les op érations de calculs intensifs et faciles à parall éliser sont ex écut ées par le GPU sous formes de kernels. Un kernel est une proc édure écrite en CUDA et d éfinie par un ent ête __global__, qui est destin ée à être ex écut ée par le GPU. Par ailleurs, le CPU ex écute toutes les op érations s équentielles qui ne peuvent pas être ex écut ées en parall èle et contr ôle l’ex écution des kernels sur le GPU ainsi que les communications de donn ées entre la m émoire CPU et la m émoire globale GPU.

CUDA est bas é sur le mod èle de programmation parall èle instruction unique, threads multiples SIMT (Single Instruction, Multiple Thread), tel que chaque kernel est ex écut é en parall èle par des milliers, voire des millions, de threads. Au niveau d’un GPU, les threads

(38)

SM 2

GPU avec 3 multiprocesseurs

SM 0 SM 1

Bloc (1,1) Bloc (2,1)

Bloc (1,0)

Bloc (0,0) Bloc (2,0)

Bloc (0,1)

Grille de blocs de threads

SP 0 SP 1 SP 2 SP 3 SP 4 SP 5 SP 6 SP 7 Multiprocesseur à 8 coeurs Thread (0,0) Thread (0,1) Thread (1,0) Thread (2,0) Thread (3,0) Thread (4,0) Thread (5,0) Thread (6,0) Thread (7,0) Thread (1,1) Thread (2,1) Thread (3,1) Thread (0,2) Thread (4,1) Thread (5,1) Thread (6,1) Thread (7,1) Thread (7,2) Thread (5,2) Thread (6,2) Thread (4,2) Thread (3,2) Thread (2,2) Thread (1,2) Thread (0,3) Thread (1,3) Thread (2,3) Thread (3,3) Thread (4,3) Thread (5,3) Thread (6,3) Thread (7,3) Temps Temps

FIGURE1.13 – Exemple d’ex écution des blocs de threads à deux dimensions sur un GPU à 3 multiprocesseurs ayant chacun 8 cœurs

d’un m ême kernel sont organis és en grille de plusieurs blocs de threads qui sont dis-tribu és, plus ou moins équitablement, sur l’ensemble des multiprocesseurs du GPU (voir figure 1.13). En effet, CUDA utilise une organisation hi érarchique des threads GPU. Au plus haut niveau, un GPU ex écute une grille de blocs de threads o ù tous les threads ex écutent, simultan ément, le m ême code (kernel) mais en op érant sur des donn ées diff érentes. Au niveau interm édiaire, chaque multiprocesseur de GPU ex écute un ou plu-sieurs blocs de threads. La position d’un bloc de threads dans la grille est rep ér ée par ses coordonn ées à une, deux ou trois dimensions. Au plus bas niveau, chaque cœur d’un multiprocesseur ex écute un ou plusieurs threads appartenant au m ême bloc de threads. A ce niveau, le mod èle parall èle SIMT est appliqu é de façon à ce que chaque instruction d’un kernel soit ex écut ée, simultan ément, par de multiples threads ind épendants (mul-tiples cœurs GPU) op érant sur des donn ées diff érentes. De m ême que pour les blocs de threads dans une grille, la position d’un thread au sein du bloc, auquel il appartient, est rep ér ée par ses coordonn ées à une, deux ou trois dimensions.

Les threads CUDA peuvent acc éder aux diff érentes m émoires GPU (d éfinies dans la section 1.2.1) de mani ère hi érarchique. Chaque thread a sa propre m émoire locale et ses propres registres. Ensuite, chaque bloc de threads a une m émoire partag ée visible par tous ses threads dont la dur ée de vie des donn ées est la m ême que celle du bloc de threads. Enfin, tous les threads d’un kernel ont acc ès à la m ême m émoire globale et, ainsi, aux m êmes m émoires texture et constante. De plus, dans les nouvelles architec-tures GPU, tous les threads d’un m ême bloc partagent une m émoire cache L1 commune et tous les blocs de threads ont acc ès à la m ême m émoire cache L2.

(39)

Thread 0 Thread 1 Thread 2 Thread 3 Thread 8 Thread 9 Thread 10 Thread 11 Thread 16 Thread 17 Thread 18 Thread 19 Thread 24 Thread 25 Thread 26 Thread 27

..

Instruction 0 Instruction 1 Temps

Thread 1 Thread 2 Thread 3 Thread 8 Thread 10 Thread 11 Thread 16 Thread 17 Thread 18 Thread 19 Thread 24 Thread 25 Thread 26 Thread 27

Thread 0 Thread 9 SP 7 SP 6 SP 5 SP 4 SP 3 SP 2 SP 1 SP 0 Multiprocesseur à 8 coeurs

FIGURE1.14 – Exemple d’ex ´ecution d’un warp par un multiprocesseur `a 8 cœurs

Au niveau d’un multiprocesseur GPU, les threads d’un m ême bloc sont ex écut és par groupe de 32 threads cons écutifs, appel é warp. Les threads d’un m ême warp sont ex écut és ensemble, instruction par instruction, jusqu’ à la fin du kernel (voir figure 1.14) et ils sont libres de suivre des chemins d’ex écution identiques ou diff érents, sans aucun point de synchronisation. Au sein d’un m ême bloc, les threads peuvent coop érer entre eux via la m émoire partag ée et synchroniser leurs ex écutions en utilisant des barri ères de synchronisation (__syncthreads() en CUDA). En revanche, dans la grille de threads d’un kernel, il n’y a aucun moyen de synchronisation entre les diff érents blocs de threads, si ce n’est qu’ils peuvent seulement lire/ écrire dans la m ême m émoire globale.

Le contexte d’ex écution (compteurs d’instructions, registres, etc) de chaque warp ac-tif (n’ayant pas encore atteint la fin du kernel) est sauvegard é et maintenu sur le mul-tiprocesseur durant toute la dur ée de vie du warp. Cela implique que le changement de contexte d’ex écution d’un warp à un autre n’a aucune cons équence p énalisant le temps d’ex écution d’un kernel. Cependant, cela signifie aussi que tous les warps actifs ex écut és par un multiprocesseur partagent les m êmes ressources. Par cons équent, les nombres de threads par bloc et de blocs de threads par grille d’un kernel sont limit és par la quantit é de ressources disponibles sur un GPU. Un kernel ne peut pas être ex écut é sur un GPU lorsque le nombre de threads par bloc, sp écifi é par le CPU dans la confi-guration d’ex écution du kernel, est au-dessus du nombre maximum de threads par bloc (512 threads pour Tesla et 1024 threads pour Fermi) ou n écessite plus de registres et/ou d’espace m émoire partag ée que disponibles.

1.2.3/ INSTRUCTIONS D’OPTIMISATION DES PERFORMANCES GPU

Pour pouvoir exploiter les performances des GPUs, il est n écessaire, tout d’abord et avant tout, de bien connaˆıtre les propri ét és de l’architecture mat érielle et de

(40)

l’envi-ronnement de programmation des cartes graphiques GPUs utilis ées. Par ailleurs, une mise en œuvre efficace d’une application sur les GPUs n écessite de bien d éterminer les t âches s équentielles et les t âches parall èles de cette application. En effet, toutes les op érations qui sont faciles à ex écuter en parall èle doivent être effectu ées par le GPU afin d’acc él érer l’ex écution de l’application. Par contre, toutes les op érations s équentielles et les op érations qui n écessitent des d épendances de donn ées entre threads ou à effectuer des calculs r écursifs doivent être ex écut ées par un seul thread CUDA ou par le CPU, se-lon la taille du probl ème à traiter. En fait, l’attente d’un thread pour les r ésultats de calculs des autres threads affecte consid érablement les performances des GPUs.

L’efficacit é d’un algorithme mis en œuvre sur un GPU est étroitement li ée à la mani ère dont les ressources GPU ont ét é utilis ées. Pour optimiser les performances d’un algo-rithme sur un GPU, il est n écessaire de maximiser l’utilisation des cœurs GPU (maximi-ser le nombre de threads ex écut és en parall èle) et d’optimi(maximi-ser l’utilisation des diff érentes m émoires GPU.

1.2.3.1/ UTILISATION DES CŒURS GPU

Comme nous l’avons d éj à pr ésent é dans la section 1.2.2, les diff érents blocs de threads d’un m ême kernel sont ex écut és en parall èle par les diff érents multiprocesseurs d’un GPU. Afin d’optimiser l’utilisation de ces multiprocesseurs, il convient donc que le nombre de blocs de threads soit un multiple du nombre de multiprocesseurs du GPU utilis é. Ensuite, chaque bloc de threads est partitionn é en warps car un multiproces-seur utilise des warps de 32 threads pour ex écuter chaque instruction d’un kernel. Pour maximiser l’utilisation du multiprocesseur, il est n écessaire d’utiliser des multiples de 32 threads pour la taille d’un bloc de threads (32, 64, 128, etc), dans la limite du nombre maximum de threads par bloc.

Au niveau d’un multiprocesseur GPU, les diff érents warps d’un m ême bloc de threads ne sont pas ex écut és en parall èle. Toutefois, lorsqu’un warp actif doit attendre les donn ées ou le r ésultat d’une longue op ération (par exemple, l’acc ès à la m émoire glo-bale), il sera mis dans une file d’attente et un autre warp dans la liste des warps pr êts (ayant toutes les donn ées n écessaires pour leurs ex écutions) sera ex écut é. Le nombre de cycles d’horloge n écessaire pour qu’un warp soit pr êt à l’ex écution est appel é la la-tence. Pour masquer les op érations de grande latence, plus particuli èrement les acc ès à la m émoire globale, un bloc de threads doit avoir plus de 32 threads et donc, au moins deux warps.

En outre, les 32 threads d’un m ême warp ex écutent, simultan ément, la m ême ins-truction d’un kernel (voir section 1.2.2). Donc, l’ex écution optimale d’un kernel sur un GPU est assur ée lorsque tous les threads d’un m ême warp suivent le m ême che-min d’ex écution. Dans le cas de divergence d’un warp qui se produit lors des struc-tures conditionnelles (if(conditions) ... else ...), le mod èle parall èle SIMT force l’ évaluation s équentielle des chemins d’ex écution des deux branches conditionnelles. En effet, les threads n’entrant pas dans l’une des branches conditionnelles doivent at-tendre la fin d’ex écution des autres threads qui eux, sont entr és dans cette branche. Par cons équence, le temps d’ex écution d’une structure conditionnelle est la somme de ceux des chemins d’ex écution des diff érentes branches conditionnelles.