Vous êtes sur la page 1sur 102

Etude et implmentation de lalgorithme e du simplexe standard sur GPUs

Xavier Meyer
<meyerxa0@etu.unige.ch>

Memoire prsent ` la Facult de sciences de lUniversit de Gen`ve e ea e e e pour lobtention dune ma trise en sciences informatiques Professeurs responsables : Prof. Bastien Chopard (CUI, UNIGE) Prof. Paul Albuquerque (hepia, HES-SO//Gen`ve) e

Gen`ve, le 4 fvrier 2011 e e

Table des mati`res e


Glossary 1 Introduction 1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Algorithme du simplexe 2.1 Gnralits . . . . . . . . . . . . . . e e e 2.2 Programmation linaire . . . . . . . e 2.3 Reprsentation gomtrique . . . . . e e e 2.3.1 Reprsentation . . . . . . . . e 2.3.2 Exemple . . . . . . . . . . . . 2.3.3 Gnralisation . . . . . . . . e e 2.4 Mthode standard . . . . . . . . . . e 2.4.1 Initialisation . . . . . . . . . 2.4.2 Recherche de loptimum . . . 2.4.3 Exemple . . . . . . . . . . . . 2.4.4 Cas particuliers . . . . . . . . 2.5 Mthode du simplexe rvis . . . . . e e e 2.5.1 Gnralits . . . . . . . . . . e e e 2.5.2 Dcomposition du probl`me . e e 2.5.3 Choix de la variable entrante 2.5.4 Choix de la variable sortante 2.5.5 Mise ` jour du probl`me . . . a e 2.5.6 Optimisation importante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1 1 2 4 4 4 5 5 6 7 8 8 10 13 13 17 17 17 18 19 19 19 21 21 22 22 22 25 27 27 28 28 30 30

3 CUDA 3.1 Introduction . . . . . . . . . . . . . . . . . . . 3.2 Architecture . . . . . . . . . . . . . . . . . . . 3.2.1 Vue globale . . . . . . . . . . . . . . . 3.2.2 Organisation des tches . . . . . . . . a 3.2.3 Mmoires . . . . . . . . . . . . . . . . e 3.3 Mod`le de programmation . . . . . . . . . . . e 3.3.1 Gnralits . . . . . . . . . . . . . . . e e e 3.3.2 Branchements . . . . . . . . . . . . . . 3.3.3 Coopration entre les tches . . . . . . e a 3.3.4 Cycle pour une instruction et latence . 3.3.5 Occupation . . . . . . . . . . . . . . .

4 Implmentations e 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 4.2 Choix de la mthode du simplexe . . . . . . . . . . e 4.2.1 Gnralits . . . . . . . . . . . . . . . . . . e e e 4.2.2 Simplexe standard . . . . . . . . . . . . . . 4.2.3 Simplexe rvis . . . . . . . . . . . . . . . . e e 4.2.4 Choix de la mthode . . . . . . . . . . . . . e 4.3 Etude de performance de CUDA . . . . . . . . . . 4.3.1 Oprations principales . . . . . . . . . . . . e 4.3.2 Recherche du maximum . . . . . . . . . . . 4.3.3 Pivotage . . . . . . . . . . . . . . . . . . . . 4.4 Implmentation sur un GPU . . . . . . . . . . . . e 4.4.1 Gnralits . . . . . . . . . . . . . . . . . . e e e 4.4.2 Algorithme principal . . . . . . . . . . . . . 4.4.3 Recherche dune solution initiale faisable . . 4.4.4 Recherche de la solution optimale . . . . . . 4.4.5 Communications CPU - GPU . . . . . . . . 4.5 Amliorations de limplmentation . . . . . . . . . e e 4.5.1 Dicults rencontres . . . . . . . . . . . . e e 4.5.2 Amliorations de lalgorithme du simplexe . e 4.5.3 Optimisations des kernel . . . . . . . . . . 4.6 Implmentation multi-GPU . . . . . . . . . . . . . e 4.6.1 Introduction . . . . . . . . . . . . . . . . . 4.6.2 Dcoupe du probl`me . . . . . . . . . . . . e e 4.6.3 Architecture et communication multi-GPU 4.6.4 Algorithme . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 31 31 31 32 33 33 34 34 35 36 36 36 37 40 41 41 45 45 47 50 53 53 53 58 59 65 65 65 65 66 68 68 69 70 71 72 72 73 73 74 74 74 74 75 75 76

5 Mod`les de performance e 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Particularit li ` CUDA . . . . . . . . . . . . . . . . . . e ea 5.2.1 Echanges de donnes CPU-GPU . . . . . . . . . e 5.2.2 Modliser un Kernel . . . . . . . . . . . . . . . . e 5.3 Simplexe sur un GPU . . . . . . . . . . . . . . . . . . . 5.3.1 Recherche de la variable entrante : steepest edge 5.3.2 Recherche de la variable sortante : expand . . . . 5.3.3 Mise ` jour de la matrice : pivotage . . . . . . . a 5.3.4 Mod`le de performance gnral . . . . . . . . . . e e e 5.4 Simplexe multi-GPU . . . . . . . . . . . . . . . . . . . . 5.4.1 Gnralits . . . . . . . . . . . . . . . . . . . . . e e e 5.4.2 Recherche de la variable entrante : steepest-edge 5.4.3 Recherche de la variable sortante : expand . . . . 5.4.4 Mise ` jour de la matrice : pivotage . . . . . . . a 5.4.5 Mod`le de performance gnral . . . . . . . . . . e e e 5.5 Application du mod`le : mesures thoriques . . . . . . . e e 5.5.1 Gnralits . . . . . . . . . . . . . . . . . . . . . e e e 5.5.2 Temps par itration . . . . . . . . . . . . . . . . e 5.5.3 Temps pour rsoudre un probl`me . . . . . . . . e e 5.5.4 Speedup . . . . . . . . . . . . . . . . . . . . . . .

6 Mesures 6.1 Introduction . . . . . . . . . . . . . . . . . . . . 6.2 Implmentation de rfrence . . . . . . . . . . . e ee 6.3 Mesures de fonctionnement . . . . . . . . . . . 6.3.1 Objectif . . . . . . . . . . . . . . . . . . 6.3.2 Ensemble de donns . . . . . . . . . . . e 6.3.3 Rsultats . . . . . . . . . . . . . . . . . e 6.4 Mesures de performance . . . . . . . . . . . . . 6.4.1 Objectif . . . . . . . . . . . . . . . . . . 6.4.2 Environnement de mesures . . . . . . . 6.4.3 Ensemble de donnes . . . . . . . . . . . e 6.4.4 Rsultats . . . . . . . . . . . . . . . . . e 6.5 Analyse des rsultats . . . . . . . . . . . . . . . e 6.5.1 Inuence de la densit . . . . . . . . . . e 6.5.2 Comparaison du mod`le et des rsultats e e 6.5.3 Gain apport par lutilisation de GPUs e 7 Conclusion 7.1 Rsum du travail ralis . . e e e e 7.2 Discussion . . . . . . . . . . . 7.2.1 CUDA . . . . . . . . . 7.2.2 Simplexe . . . . . . . 7.2.3 Choix . . . . . . . . . 7.2.4 Rsultats et mod`le de e e 7.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . performance . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

78 78 78 79 79 79 79 80 80 80 81 81 85 85 86 88 90 90 91 91 92 92 93 94

Glossaire
block Groupe de tches excut sur un streaming multiprocessor (CUDA). 24 a e e 27, 29, 30, 35, 42, 48, 6165, 69 CC Compute Capabilities - version dun device (CUDA). 22 CLP COIN-OR Linear Programming - implmentation du simplexe rvis. 73 e e e 78, 80, 82, 84 COIN-OR Computational Infrastructure for Operations Research - projet open source. 73, 84 CUBLAS Basic Linear Algebra Subprograms for CUDA - librairie pour CUDA. 32, 35, 42, 65 device unit de calcul graphique (CUDA). 22, 25, 35, 37, 40, 49, 55, 56, 60, 67 e expand EXPanding-tolerance ANti-Degeneracy procedure - mthode de choix e de la variable sortante. 52, 53, 55, 64, 68, 70, 74, 85 FLOPS Floating point operations Per Second - mesure de vitesse dun syst`me e informatique. 21, 75, 87 GPGPU General-Purpose Computing on Graphics Processing Units - calcul sur GPU. 2, 3, 21, 33, 60, 70, 83, 86 grid Groupe de blocks (CUDA). 25 kernel Fonction CUDA. 22, 23, 31, 32, 35, 37, 4042, 48, 49, 6067, 69, 70, 75, 80, 84, 85 latence Temps mis par une lecture en mmoire globale (CUDA). 27, 29, 30, e 48, 49, 62, 63, 65, 66, 84, 87 SIMD Simple Instruction Multiple Data - type de paralllisme. 1, 27 e SIMT Simple Instruction Multiple Thread - type de paralllisme. 1, 21, 27, 33, e 83 SM Streaming multiprocessor - multiprocesseur dun GPU grant 8 curs. 61 e 64, 75 speedup Acclration - mesure de paralllisme. 2, 70, 77, 82, 84, 86 ee e steepest edge mthode de choix de la variable entrante. 46, 48, 5153, 63, 68, e 74, 77, 85 warp Sous-ensemble de tches (CUDA). 2430, 43, 48, 6163, 65 a

Rsum e e Lalgorithme du simplexe est une des mthodes les plus utilises dans le cadre e e de la recherche oprationnelle. La complexit des probl`mes ` rsoudre volue e e e a e e constamment, de telle sorte que les implmentations existantes sav`rent pare e fois trop lente. En parall`le, la technologie volue et met ` notre disposition de e e a nouveaux outils. Nous nous intressons, dans ce travail, ` limplmentation de e a e lalgorithme du simplexe sur unit de calcul graphique. Ces units de calcul dise e posent dune architecture particuli`re qui permet de parallliser des oprations e e e matricielles ou vectorielles principalement. Ces dirents sujets sont tudis, e e e an dorir la base ncessaire ` la comprhension de notre implmentation du e a e e simplexe standard sur une ou plusieurs units de calcul graphique. Les perfore mances thoriques de cette implmentation sont analyses ` laide dun mod`le e e e a e de performance. Les mesures relles obtenues lors de notre exprience conrment e e lexactitude de notre mod`le. Pour des probl`mes de moyenne ` grande tailles, e e a ces mesures dmontrent des gains importants lorsquelles sont compares ` celles e e a dune implmentation squentielle rpute de lalgorithme du simplexe rvis. e e e e e e

Chapitre 1

Introduction
1.1 Motivations

Le simplexe est un algorithme doptimisation utilis depuis de nombreuses e annes an de rsoudre des probl`mes de programmation linaire. Ces probl`mes e e e e e sont utiliss dans la majorit des cas pour modliser des probl`mes de recherche e e e e oprationnelle. Le simplexe est souvent employ dans direntes industries pour e e e des probl`mes de planications, distributions, agencements. Par exemple, la proe duction de ptrole ou encore la planication de vols commerciaux sont gnrae e e lement optimiss ` laide de cet algorithme. e a Celui-ci a t conu par George B. Dantzig en 1947. Outre la version stanee c dard de lalgorithme, base sur une volution de la matrice compl`te modlisant e e e e le probl`me, une seconde version appele simplexe rvis a rapidement fait ses e e e e preuves. Cette version utilise une dcomposition de la matrice initiale dans lope tique de diminuer la quantit de calcul ncessaire an de faire voluer la matrice e e e vers une solution optimale. Elle sest rvle particuli`rement performante pour e ee e les matrices creuses. Cette version adjointe ` une utilisation de structures de a donnes spciales pour les matrices creuses a t la mthode majoritairement e e ee e choisie pour limplmentation du simplexe. e La complexit croissante des probl`mes ` optimiser ainsi que lvolution teche e a e nologique orent de nouvelles perspectives ` limplmentation de cet algorithme. a e En eet, J. A. J. Hall [8] a fait une tude des direntes possibilits quant ` la e e e a paralllisation de celui-ci. Parmi ces derni`res, on peut notamment citer celle e e de Thomadakis et al. [16] dont le but est de parallliser le simplexe sur une e machine de type SIMD (Singe Instruction Multiple Data). Ceci dans loptique de rduire le temps de calcul des probl`mes ayant des matrices denses ou de e e taille consquente. e La rcente volution des cartes graphiques en tant quunits de calcul ore e e e un bon compromis entre une puissance de calcul accrue et un prix modr. ee Larchitecture de type SIMT 1 (Single Instruction Multiple Threads) des units e de calcul graphique, optimise pour les calculs matriciels, semble bien adapte ` e e a lalgorithme du simplexe. En eet, ce dernier ncessite de nombreuses oprations e e dalg`bre linaire sur la matrice modlisant le probl`me. e e e e Nous nous intresserons ` la paralllisation du simplexe sur GPU (Graphic e a e
1. Concept propre ` CUDA. a

Processing Unit). Cette approche innovante na t le sujet que dune seule ee tude ` notre connaissance. Seuls J. Bieling et al. [10] ont tudi ce sujet en e a e e paralllisant le simplexe rvis sur un GPU. Les rsultats obtenus lors de cette e e e e tude laisse prsager des gains intressants grce ` lutilisation dun GPU pour e e e a a des probl`mes de moyenne ` grande taille. e a Le but de ce travail sera de parallliser lalgorithme du simplexe standard e sur des GPUs. Une premi`re implmentation consistera en une couche unique e e de paralllisme sur un GPU. Une fois cette premi`re phase fonctionnelle, une see e conde implmentation multi-GPU sera mise au point dans loptique damliorer e e les performances sur les probl`mes de grande taille. e Les performances de ces implmentations seront tudies sur de nombreux e e e probl`mes, par exemple : des probl`mes de grande taille modlisant laectation e e e davions ` des routes commerciales ou la conception dhoraire dquipages ; qui a e nous sont fournis par la compagnie APM Technologies [2].

1.2

Plan

Nous allons dbuter par une tude compl`te des variantes de lalgorithme du e e e simplexe. Cet algorithme va tout dabord tre dcrit sous sa forme gomtrique e e e e an dorir une premi`re approche ` son fonctionnement. Ensuite, nous verrons e a le fonctionnement, du point de vue algorithmique et algbrique, de la mthode e e standard. A partir de la description de cette mthode, nous examinerons les e particularits de la variante du simplexe rvis. Ces deux mthodes fonctionnent e e e e selon le mme principe, seule lvolution du probl`me est traite diremment. e e e e e Apr`s cette tude, nous nous intresserons au GPGPU (General-Purpose e e e Computing on Graphics Processing Units), plus prcisment ` larchitecture e e a CUDA (Compute Unied Device Architecture) propose par NVIDIA. Les pere formances de cette architecture repose sur deux lments fondamentaux : la ee mmoire et la dcomposition du travail en tches. Ces deux axes vont tre e e a e approfondis de faon ` permettre la comprhension des points cruciaux de ce c a e mod`le de programmation. e Avant de dbuter limplmentation de lalgorithme, il sera ncessaire de choie e e sir une des deux variantes du simplexe. Les avantages et inconvnients de chae cune seront analyss. Lorsque le choix sera fait, nous comparerons les oprations e e cls composant lalgorithme avec leur quivalent squentiel. Ceci an destimer e e e quel type de gains nous pourrons attendre de cette implmentation. La paralle e lisation de la mthode du simplexe sur un GPU sera alors dcrite. An dobtenir e e un algorithme comptitif avec ceux existants, cette implmentation sera amlioe e e re par des mthodes trouves dans la littrature scientique. A partir de cette e e e e version amliore, une version multi-GPU sera mise en place. Nous tudierons e e e alors les modications apportes ` lalgorithme et ` la structure du probl`me. e a a e Le mod`le de performance de nos implmentations sera alors tabli. Pour e e e cela, il sera ncessaire dtudier la modlisation de programme sur GPGPU e e e tant donn que larchitecture di`re fortement des CPUs conventionnels. Les e e e rsultats thoriques, obtenus grce au mod`le, nous permettront deectuer une e e a e premi`re analyse du comportement des implmentations face ` une variation de e e a la taille des probl`mes ` rsoudre. Le speedup thorique sera aussi examin an e a e e e de mesurer limpact quaurait lajout dautres units de calcul. e Nous nous intresserons alors aux rsultats rels produits par nos implmene e e e

tations. Ces rsultats seront compars avec une implmentation existante que e e e nous aurons slectionne au pralable. Il faudra donc sassurer que nos imple e e e mentations fonctionnent tout aussi bien que celle de rfrence. Pour cela, elles ee seront testes sur un benchmark. Apr`s cela, les performances des direntes e e e implmentations seront mesures. A partir des rsultats obtenus, leur compore e e tement face ` des variations de la taille et de la densit des probl`mes sera a e e analys. e Finalement, nous rcapitulerons les direntes tapes, choix et rsultats e e e e ayant t traits durant ce travail. Suite ` ce rsum, nous discuterons des ee e a e e lments importants dont limplmentation du simplexe, la programmation sur ee e GPGPU, les choix eectus ainsi que le mod`le de performance et les rsultats e e e obtenus. Pour terminer, nous voquerons les perspectives quouvrent ce travail. e

Chapitre 2

Algorithme du simplexe
2.1 Gnralits e e e

Lalgorithme du simplexe est une des mthodes les plus communment utie e lise pour rsoudre les probl`mes de programmation linaire. Cette mthode a e e e e e t conue en 1947 par George Dantzig. Par la suite, elle a t sujette ` de ee c ee a nombreux travaux de recherche qui ont aboutis sur plusieurs amliorations en e terme de performance et de stabilit. Ltude de cet algorithme est base sur les e e e travaux de V. Chvatal [6] ainsi que F. Hillier et G. J. Liberman [9]. Il existe deux versions principales du simplexe. La premi`re mthode dite e e standard o` lalgorithme est appliqu sur une version non modie du probl`me. u e e e Cette mthode est aussi appele full tableau (tableau complet). La seconde e e mthode est la mthode rvise. Cette derni`re utilise une dcomposition du e e e e e e probl`me de base en sous-matrices. Cette modlisation du probl`me, ` laide de e e e a quelques astuces, permet de rduire les calculs ` eectuer pour les probl`mes e a e ayant une faible densit de coecients non nul. e Dans un premier temps, nous verrons ce quest un probl`me de programmae tion linaire. Les bases tant poses, nous tudierons lalgorithme du simplexe en e e e e commenant par sa reprsentation gomtrique. Cette derni`re permet dillusc e e e e trer le fonctionnement de lalgorithme. La mthode standard sera alors dcrite e e et servira ` expliquer les concepts fondamentaux du simplexe. Finalement, nous a verrons quelles sont les particularits de lalgorithme du simplexe rvis. e e e

2.2

Programmation linaire e

La programmation linaire est un domaine central de loptimisation. Les e probl`mes de programmation linaire sont les probl`mes doptimisation les plus e e e faciles ` rsoudre : les contraintes ainsi que la fonction objectif tant linaires. a e e e La forme normale pour ce type de probl`mes est la suivante : e
n

Maximiser
j=1 n

c j xj aij xj bi
j=1

Sujet ` a

(i = 1, 2, ..., m)

xj 0

(j = 1, 2, ..., n)

Les contraintes peuvent tre de types plus petit ou gal, plus grand ou gal e e e ou encore gal. Ces dirents types dgalits ou dingalits peuvent tre transe e e e e e e poss sans autre en forme normale. Une version plus gnrale des probl`mes de e e e e programmation linaire ajoute une limite individuelle sur les variables : e
n

Maximiser
j=1 n

c j xj aij xj bi
j=1

Sujet ` a

(i = 1, 2, ..., m) (j = 1, 2, ..., n)

lj xj uj

o` lj et uj sont les bornes infrieures, respectivement suprieures, des vau e e riables. Ces derni`res peuvent prendre nimporte quelle valeur entre et +. e Cependant, dans un premier temps, nous allons uniquement considrer le cas o` e u les direntes variables du probl`me ne disposent pas de limites individuelles, e e ceci an de simplier la comprhension de lalgorithme. e Dun point de vue gomtrique ce type de probl`me dnit un polytope, e e e e dont les cas particuliers les plus connus sont le polygone dans un espace ` deux a dimensions et le poly`dre dans un espace ` trois dimensions. Lintrieur de ce e a e polytope dnit lensemble de recherche et le but serait donc de trouver le point e se trouvant dans le polytope, qui maximise ou minimise la fonction objectif. Il est important de remarquer que du fait des contraintes linaires, le polytope est e convexe et ne peut donc possder des optima locaux. e Pour nir, voici un exemple type dun probl`me linaire. e e Maximiser Z = 5x1 +4x2 +3x3 Sujet ` a 2x1 +3x2 +x3 5 4x1 +x2 +2x3 11 3x1 +4x2 +2x3 8 x 1 , x2 , x3 0

2.3
2.3.1

Reprsentation gomtrique e e e
Reprsentation e

An de se donner une premi`re ide du fonctionnement de lalgorithme, e e reprenons la reprsentation gomtrique dun probl`me de programmation lie e e e naire. Nous avons donc un polytope dont nous dsirons trouver le point maxie e misant (ou minimisant) une fonction objectif. Lalgorithme du simplexe consiste ` se placer sur une des intersections du a polytope (un coin, en quelque sorte). Ensuite, il va sagir de se dplacer le long e dune arte jusqu` la prochaine intersection. Ce dplacement doit garantir le e a e maintien ou lamlioration du rsultat de la fonction objectif. De telle sorte que e e ces dplacements ne nous loignent jamais du point optimal. Cette tape est e e e ensuite rpte jusqu` ce que le point optimal du polytope soit atteint. e ee a

2.3.2

Exemple

An dillustrer cette mthode de mani`re parlante, nous allons reprendre un e e des exemples dcrit dans le livre Introduction to Operations Research [9]. Nous e allons dsormais appliquer lalgorithme du simplexe sur un polytope de degr e e 2, soit un polygone. Nous avons le probl`me de programmation linaire suivant : e e Maximiser Z = 3x1 +5x2 Sujet ` a x1 4 +2x2 12 3x1 +2x2 18 x 1 , x2 0 La reprsentation gomtrique correspond au polygone ` la gure 2.1. e e e a

Figure 2.1 Reprsentation gomtrique e e e Lintrieur du polygone, la surface grise, reprsente la zone admissible. Nime e porte quelles valeurs des variables x1 et x2 rsultant en un point de cette zone e est donc une solution pour notre probl`me. e Nous allons dbuter au point (0, 0). Ce point a comme valeur de la fonction e objectif Z = 0. An de dterminer si cette solution est optimale, regardons les e points adjacents. Les points (4, 0) et (0, 6) orent un gain de la fonction objectif. Nous allons alors choisir la direction de notre dplacement. e 6

Le gain potentiel sur Z dpend en partie de la valeur des coecients de e la fonction objectif. Etant donn que le coecient de x2 est le plus grand, e nous allons choisir cette direction car elle ore le plus grand gain thorique. e Nous sommes dsormais au point (0, 6) avec pour valeur de la fonction objectif e Z = 30. Avons-nous atteint le point orant la solution optimale de notre polygone ? Pour savoir cela, il sut ` nouveau de contrler les points adjacents. Il se trouve a o que le point (2, 6) am`ne ` une amlioration de Z. e a e Nous voil` au point (2, 6) avec Z = 36. Aucune des intersections adjacentes a nam`nent ` une amlioration de Z. Nous avons donc atteint le point optimal. e a e Le chemin eectu est dcrit par la gure 2.2. e e

Figure 2.2 Chemin eectu e

2.3.3

Gnralisation e e

A partir de ces observations, il est intressant de dterminer une version e e grossi`re de notre algorithme (algo. 1). e Algorithm 1 Algorithme du simplexe Choix de lintersection initiale Tant que la solution optimale nest pas atteinte Choisir une ar^te se rapprochant du sommet e Se dplacer jusqu` lintersection suivante e a

Cette gnralisation nous permet donc dapprocher lalgorithme standard du e e simplexe avec une ide globale du fonctionnement de ce dernier. e

2.4
2.4.1

Mthode standard e
Initialisation

Variables de jeu La premi`re tape va tre de modier lg`rement le probl`me de programe e e e e e mation linaire. Le but ici est de transformer les ingalits en galits. Pour e e e e e cela, il est ncessaire dajouter ` chaque inquation, une variable dite de jeu. e a e Cette variable est un nombre entier positif. Ces valeurs sont comprises entre 0 et +. De ce fait, elle permet, comme son nom lindique, de combler lespace entre linquation et lquation. Les variables du probl`me initial sont appeles e e e e variables de dcision et le probl`me modi est appel forme augmente. e e e e e Reprenons le probl`me donn en exemple de la section 2.2 : e e Maximiser Z = 5x1 +4x2 +3x3 Sujet ` a 2x1 +3x2 +x3 5 4x1 +x2 +2x3 11 3x1 +4x2 +2x3 8 x 1 , x2 , x3 0 Et ajoutons les variables de jeu x4 , x5 , x6 : Maximiser Z = 5x1 +4x2 +3x3 Sujet ` a 2x1 +3x2 +x3 +x4 4x1 +x2 +2x3 3x1 +4x2 +2x3 x 1 , x 2 , x 3 , x 4 , x5 , x6 0 Terminologie Rappelons que le but de lalgorithme du simplexe est de faire voluer les e valeurs des variables x de telle sorte ` amliorer (ou maintenir) la valeur de a e la fonction objectif. Le vecteur compos des valeurs pour chaque variable x est e alors appel solution. Une solution est dite faisable si, apr`s substitution de cette e e derni`re dans le probl`me, lensemble des quations et des bornes individuelles e e e sur les variables ne sont pas violes. Dans le cas contraire, la solution est dite e infaisable. Le probl`me est exprim sous la forme suivante : e e
n

+x5 +x6

=5 = 11 =8

Maximiser
j=1 n

c j xj aij xj bi
j=1

Sujet ` a

(i = 1, 2, ..., m) (j = 1, 2, ..., n)

xj 0

Les variables de jeu xn+i (i = 1, 2, ..., m) sont ajoutes et la fonction objectif e est dnote par z. Ensuite, la forme augmente est retranscrite de la mani`re e e e e suivante :
n

xn+i

= =

bi
j=1 n

aij xj bi c j xj
j=1

(i = 1, 2, ..., m)

Cette reprsentation du probl`me dnit un dictionnaire. Un dictionnaire est e e e en quelque sorte un snapshot ` une itration donne de lalgorithme. Ce snapa e e shot est compos des quations contenant les variables de la forme augmente e e e ainsi que de Z qui reprsente la valeur de la fonction objectif. Le fait que les e variables de jeu se trouvent initialement uniquement dans une quation est mis e en vidence par le fait quelles se situent seules dans le membre de gauche des e quations. e Un dictionnaire doit capturer linterdpendance entre les variables. Autree ment dit, une solution lie ` un dictionnaire doit tre une solution pour la totalit e a e e des autres dictionnaires et vice versa. Exemple : x4 x5 x6 Z = = = = 5 11 8 2x1 4x1 3x1 5x1 3x2 x2 4x2 +4x2 x3 2x3 2x3 +3x3

Finalement, il est intressant de noter une distinction entre deux ensembles e de variables. Le premier est compos de lensemble des variables se trouvant e dans le membre de gauche dun dictionnaire. Cet ensemble est appel la base e et de ce fait, les variables de cet ensemble sont dites basiques. La particularit e de ces variables rside dans le fait quelles ne sont prsentes que dans une des e e quations de notre dictionnaire. Le second ensemble contient les variables ne se e trouvant pas dans la base. Ces derni`res sont donc dites non basiques. e Solution initiale An dappliquer lalgorithme du simplexe, il nous faut donc crer notre pree mier dictionnaire. Comme nous lavons vu prcdemment, il est assez intuitif et e e simple de placer les variables de jeu dans la base. Cependant, le probl`me de la e solution initiale demeure. Pour obtenir cette derni`re, il sut, dans un premier e temps, de xer arbitrairement la valeur des variables non basiques en respectant leurs bornes individuelles. Ensuite il sagit de calculer la valeur des variables basiques en substituant les variables non basiques au sein des quations. e Il est important de noter que la solution obtenue lors de cette manipulation peut alors tre infaisable. Il est dans ce cas ncessaire dutiliser la mthode du e e e simplexe en deux phases. Cette derni`re permet de dterminer si une solution e e faisable existe pour un probl`me donn. Cette mthode est dcrite dans la section e e e e 2.4.4. Dans un premier temps, admettons que la solution que nous avons obtenue est faisable. 9

2.4.2
Procd e e

Recherche de loptimum

A ce stade nous disposons donc dun dictionnaire ainsi que dune solution faisable. An de faire voluer Z, il est ncessaire de modier les valeurs de notre e e solution tout en garantissant que cette derni`re reste faisable. e Pour cela, nous allons dans un premier temps rechercher quelle variable est susceptible damliorer Z de faon signicative. Cette tape correspond, dans e c e la reprsentation gomtrique, ` la recherche de la direction permettant de se e e e a rapprocher du point optimal. La recherche de la direction est plus communment e appele choix de la variable entrante, car nous allons ici slectionner une variable e e non basique qui va entrer dans la base. Ensuite, il est ncessaire de rechercher le gain maximal, max possible sur e cette variable. Ce gain est limit par limpact que cette modication a sur les e autres variables. Il faut alors trouver la premi`re variable basique a atteindre ses e ` bornes pour un gain . Gomtriquement, cette tape correspond ` dterminer e e e a e le dplacement maximal dans la direction trouve ` ltape prcdente ainsi e e a e e e que lintersection limitant cette progression. La recherche de cette variable est appele choix de la variable sortante car nous cherchons la variable la plus e contraignante au sein de la base an de la remplacer par la variable entrante. Finalement, il est ncessaire de pivoter les deux variables, de telle sorte ` e a obtenir un nouveau dictionnaire et une nouvelle solution plus proche de la valeur optimale. Cette tape correspond au dplacement dun point au point suivant e e dans la reprsentation gomtrique. e e e Choix de la variable entrante Lobjectif est de trouver la variable non basique orant le gain potentiellement le plus grand. La mthode standard de choix de la variable entrante est de e rechercher la variable possdant le plus grand coecient positif dans la fonction e objectif. Pour le dictionnaire : x4 x5 x6 Z = = = = 5 11 8 2x1 4x1 3x1 5x1 3x2 x2 4x2 +4x2 x3 2x3 2x3 +3x3

il sagirait donc de la variable x1 car son coecient (5) est le plus grand des coecients positifs de la fonction objectif. Le gain nal sur z dpend de deux choses : du gain max sur la variable ainsi e que du coecient de cette derni`re dans la fonction objectif. De ce fait, choisir e la variable en fonction de ce coecient pourrait amener un gain important sur Z. La solution est dclare optimale dans le cas o` il ny aurait aucun coecient e e u positif non nul dans la fonction objectif. Cette mthode est de complexit O(m). Cependant dans les cas rels elle est e e e relativement peu eciente et rarement utilise. En eet, tant donn quelle ne e e e prend pas en compte le gain possible sur la variable, il est totalement possible que la valeur de Z augmente faiblement, voire pas du tout. Ceci risque daugmenter fortement le nombre ditrations ncessaires ` lalgorithme pour dterminer la e e a e valeur optimale. Il existe de nombreuses mthodes an de dterminer la variable e e entrante. Certaines de ces mthodes seront dcrites dans la section 4.5.2 . e e

10

Choix de la variable sortante Le choix de la variable sortante sert ` dterminer la variable basique la a e plus contraignante. Il sagit de dterminer pour chaque variable basique le gain e maximum que cette derni`re peut orir ` la variable entrante. e a La variable la plus contraignante est celle qui va retourner ` sa borne infa e rieure la premi`re. Cette variable est celle qui dispose du plus petit ratio positif e s r , o` s est la constante de lquation et r le coecient de la variable entrante u e dans cette quation. Le coecient r doit tre ngatif et non nul an dviter e e e e davoir un gain ngatif ainsi que des divisions par 0. e Le ratio obtenu correspond au gain maximal que la variable basique permet a ` la variable entrante avant de sortir de ses bornes. Recherchons la variable sortante pour lexemple de la section prcdente. e e Nous avons choisi comme variable entrante x1 . Pour la premi`re quation, o` la variable basique est x4 , calculons le ratio : e e u s 5 s = 5, r = 2 ratio1 = = = 2.5 r 2 Pour la seconde quation ayant comme variable basique x5 : e 11 s = 2.75 s = 11, r = 4 ratio2 = = r 4 Et nalement la derni`re quation qui a pour variable basique x6 : e e s 8 s = 8, r = 3 ratio3 = = = 2.667 r 3 Le ratio le plus petit est ratio1 = 2.5 et donc la variable sortante sera x4 . Dans le cas o` aucun coecient r serait ngatif et non nul, le probl`me seu e e rait alors non born. Cest-`-dire que la valeur optimum serait innie et quil e a existerait donc une innit de solutions possibles. Il surait dimaginer un proe bl`me dnissant un rectangle (cas particulier de polygone) dont il manque un e e des cts. oe La complexit de cette mthode est de O(n). Chacun des calculs de cette e e tape est obligatoire. Il nexiste donc pas dheuristiques pour amliorer ses pere e formances (temps de calculs, meilleurs choix). Cependant, nous verrons dans la section 4.5.2 que cette fonction ` une importance cruciale en ce qui concerne la a stabilit de lalgorithme. e Pivotage Une fois les variables entrante et sortante dtermines, il est ncessaire defe e e fectuer le pivotage. Ceci consiste ` placer la variable entrante dans la base et a den retirer la variable sortante. La premi`re tape consiste ` pivoter la variable entrante et la variable sore e a tante. Le pivot est donc le coecient de la variable entrante dans lquation o` e u la variable sortante est basique. La variable entrante va entrer dans la base dans le membre gauche de lquae tion. La variable sortante va quitter la base et donc rejoindre le membre droit de lquation. e

11

Cette quation va ensuite tre divise par le pivot. Cette opration normae e e e lise le coecient de la variable entrante an quelle puisse tre dans la base. e Nanmoins, avant que cette variable ne soit considre comme basique, il est e ee ncessaire de substituer cette variable dans les autres quations ainsi que dans e e la fonction objectif. Ceci an quelle soit uniquement prsente dans lquation e e o` elle est basique. u A lissue du pivotage, la variable entrante est prsente dans lquation o` la e e u variable sortante tait basique et uniquement dans cette quation. De mme, la e e e variable sortante a repris sa place dans les autres quations ainsi que dans la e fonction objectif. Appliquons x4 = x5 = x6 = Z = donc le pivotage ` a 5 2x1 3x2 11 4x1 x2 8 3x1 4x2 5x1 +4x2 notre exemple, que nous rappelons ici : x3 2x3 2x3 +3x3

La variable entrante est les deux variables : 2x1 = 5 x5 = 11 4x1 x6 = 8 3x1 Z = 5x1

x1 et la variable sortante x4 . Commenons par pivoter c 3x2 x2 4x2 +4x2 x3 2x3 2x3 +3x3 x4

La variable x1 est alors normalise dans lquation o` elle va devenir basique, e e u soit la premi`re quation : e e x1 = 2.5 1.5x2 0.5x3 0.5x4 x5 = 11 4x1 x2 2x3 x6 = 8 3x1 4x2 2x3 Z = 5x1 +4x2 +3x3 Finalement, il sut de substituer la variable x1 dans les autres quations, y e compris la fonction objectif. Dtaillons le procd pour la deuxi`me quation : e e e e e x5 = 11 4x1 x2 2x3 x5 = 11 4(2.5 1.5x2 0.5x3 0.5x4 ) x2 2x3 x5 = (11 10) + (6 1)x2 + (2 2)x3 + 2x4 x5 = 1 + 5x2 + 2x4 En eectuant aussi la substitution dans la troisi`me quation ainsi que dans la e e fonction objectif, nous obtenons au nal le dictionnaire suivant : x1 x5 x6 Z = = = = 2.5 1.5x2 1 +5x2 0.5 0.5x2 12.5 3.5x2 0.5x3 0.5x3 +0.5x3 0.5x4 +2x4 +1.5x4 2.5x4

La solution lie ` ce dictionnaire est x1 = 2.5, x2 = 0, x3 = 0, x4 = 0, x5 = e a 1, x6 = 0.5 et z = 12.5. Cependant, la valeur optimale nest pas encore trouve e car il demeure un coecient positif dans la fonction objectif.

12

2.4.3

Exemple
rsoudre notre exemple. Nous sommes partis du e x3 2x3 2x3 +3x3

Nous allons donc terminer de dictionnaire suivant : x4 = 5 2x1 3x2 x5 = 11 4x1 x2 x6 = 8 3x1 4x2 Z = 5x1 +4x2

Apr`s un pivotage sur la variable entrante x1 et la variable sortante x4 (voir e sections prcdentes) nous avons obtenu ce dictionnaire : e e x1 = 2.5 1.5x2 0.5x3 0.5x4 x5 = 1 +5x2 +2x4 x6 = 0.5 0.5x2 0.5x3 +1.5x4 Z = 12.5 3.5x2 +0.5x3 2.5x4 La seule variable entrante ligible est x3 car cest la seule ` possder un e a e coecient positif non nul dans la fonction objectif. Seule la premi`re et la troie si`me quations disposent dun coecient ngatif non nul dans la colonne de la e e e variable entrante : 2.5 s =5 Premi`re quation : s = 2.5, r = 0.5 ratio1 = = e e r 0.5 0.5 s =1 Troisi`me quation :s = 0.5, r = 0.5 ratio3 = = e e r 0.5 La variable sortante est donc x6 car le plus petit ratio est ratio3 . Apr`s le pivotage sur la variable entrante x3 et la variable sortante x6 , nous e obtenons le dictionnaire suivant : x1 = 2 2x2 2x4 +x6 x5 = 1 +5x2 +2x4 x3 = 1 x2 +3x4 2x6 Z = 13 3x2 1x4 x6 Ce dictionnaire ne comporte plus de variable entrante ligible. Nous avons e donc trouv la solution optimale. La solution de ce probl`me est x1 = 2, x2 = e e 0, x3 = 1, x4 = 0, x5 = 1, x6 = 0 et z = 13. Nous pouvons nalement vrier notre rsultat en prenant la fonction obe e jectif initiale de notre probl`me et en y substituant la solution trouve. e e Soit, maximiser 5x1 + 4x2 + 3x3 5 2 + 4 0 + 3 1 = 13 La valeur obtenue est la mme que celle trouve ` la derni`re itration du sime e a e e plexe. Le rsultat est donc correct. e

2.4.4

Cas particuliers

Solution initiale infaisable Le but de cette section est de dcrire la mthode ` appliquer an de dtere e a e miner sil existe une solution initiale faisable pour un probl`me. Cette mthode e e sappelle le simplexe en deux phases. Elle consiste ` appliquer la mthode du a e simplexe, dans un premier temps, sur un probl`me modi an de trouver une e e solution faisable. Ce probl`me modi sappelle probl`me auxiliaire et consiste e e e

13

a minimiser les infaisabilits sur les variables. La seconde phase correspond ` ` e a la rsolution du probl`me selon la mthode que nous avons vu prcdemment ` e e e e e a partir de la solution initiale faisable trouve lors de ltape prcdente. e e e e Il existe direntes mthodes pour mettre la main sur une solution faisable. e e Une premi`re mthode consiste ` ajouter des variables articielles an de dbue e a e ter avec une solution initiale faisable. Ces variables ont pour but dannuler les infaisabilits. e Prenons un probl`me de programmation linaire sous sa forme augmente : e e e
n

Maximiser
j=1 n

c j xj aij xj = bi
j=1

Sujet ` a

(i = 1, 2, ..., m) (j = 1, 2, ..., n)

lj xj uj

Nous allons donc ajouter les variables articielles xn+i et donc modier le probl`me original : e
n

aij xj + xn+i = bi
j=1

(i = 1, 2, ..., m) (j = 1, 2, ..., n + m)

lj xj uj

Il est donc dsormais ncessaire de dterminer les bornes ln+i et un+i pour les e e e variables articielles. Pour cela, il sut de xer les valeurs des autres variables xj ` une de leurs bornes, ou ` 0 si les variables ne sont pas bornes, de telle sorte a a e que les variables soient initialement faisable. Il faut alors utiliser cette solution partielle pour calculer la valeur des variables articielles : xn+i = bi aij xj A laide des valeurs calcules prcdemment pour xn+i , nous pouvons xer e e e les bornes de ces variables articielles. Celles ayant une valeur ngative auront e pour bornes ln+i = et un+i = 0 alors que celles possdant une valeur e positive auront pour bornes ln+i = 0 et un+i = . Les variables articielles dterminent la magnitude de linfaisabilit pour e e chaque quation. Il est alors possible de mesurer linfaisibilit du dictionnaire e e courant en sommant les variables articielles : n wn+i xn+i
i=1

1 si xn+i < 0 1 si xn+i 0 Lastuce est alors dappliquer lalgorithme du simplexe avec cette fonction comme fonction objectif. Elle est souvent appele fonction objectif auxiliaire. e Logiquement, si le rsultat de la minimisation de cette fonction se trouve tre e e la valeur optimale, Z = 0, alors lensemble des variables articielles sont nulles et donc le probl`me est faisable. Il sagit donc de rsoudre le probl`me suivant : e e e Minimiser wn+i xn+i o` wn+i = u
n

Sujet ` a
j=1

aij xj + xn+i = bi lj xj uj

(i = 1, 2, ..., m) (j = 1, 2, ..., n + m)

14

Si la solution ` ce probl`me nest pas 0, alors il nexiste pas de solution a e faisable pour ce probl`me et ce dernier est donc infaisable. e Sinon, avant de dbuter la seconde phase, il est ncessaire de soccuper des e e variables articielles qui ne sont plus ncessaires. Une premi`re possibilit est e e e de modier leurs bornes ` ln+i = 0 et un+i = 0. Linconvnient est que le a e probl`me va contenir de nombreuses variables inutiles. La seconde possibilit e e est donc de supprimer ces variables. Celles qui ne sont pas dans la base peuvent tre supprimes sans autre, alors que celles qui y sont requi`rent des pivotages e e e ne modiant pas Z an de les y sortir avant de les supprimer. Une fois cette opration faite, il sut alors dappliquer lalgorithme du sime plexe ` partir du dernier dictionnaire en reprenant la fonction objectif du proa bl`me initial. e Linconvnient de cette mthode rside dans le fait quil est ncessaire dajoue e e e ter une variable articielle ` chaque quation infaisable. La taille du probl`me a e e peut de se fait grandement cro tre. Il est possible alors dutiliser une mthode e lg`rement dirente. e e e An de rendre le probl`me temporairement faisable, les bornes des variables e infaisables vont tre largies de telle sorte ` les rendre faisables : e e a li = ui = li si sinon x i li x i ui

ui si sinon

Les variables plus petites que leur borne initiale li vont former lensemble P tandis que celles qui sont plus grandes que ui formeront lensemble Q. Soit, Q = {i | xi > ui } P = {i | xi < li } Il est alors possible de dnir les infaisabilits comme la dirence entre les e e e variables infaisables et leurs bornes initiales la plus proche. La somme des infaisabilits scrit donc : e e (li xi ) +
iP iQ

(xi ui )

An de simplier le calcul de cette mesure dinfaisabilit, il est possible e dignorer les constantes qui nont aucune inuence sur lvolution de lestimae tion de linfaisabilit globale : e xi
iQ iP

xi

Il est dsormais possible dappliquer lalgorithme du simplexe ` cette vere a sion modie du probl`me en utilisant la mesure dinfaisabilit comme fonction e e e objectif. Cependant, il sera ncessaire ` chaque itration de vrier les ensembles P e a e e et Q. En eet, si une variable infaisable rentre dans ses bornes initiales et donc devient faisable, il est ncessaire de corriger ses bornes et de mettre ` jour la e a mesure dinfaisabilit. Si ` force ditrations, lalgorithme arrive ` rendre toutes e a e a

15

les variables faisables, alors nous avons une solution initiale faisable. Autrement, il nexiste pas de solution faisable. Il ne reste plus qu` appliquer la mthode du simplexe sur le mme probl`me, a e e e mais avec la fonction objectif initiale. Cette mthode ncessite plus de calculs que la mthode prcdente du fait e e e e e de la vrication ` chaque itration de ltat du probl`me mais rduit la taille e a e e e e du probl`me auxiliaire de faon signicative. e c Cycles et itrations dgnratives e e e e Il est possible que lalgorithme cycle sur des itrations dgnratives. Ces e e e e derni`res sont des itrations o` la valeur de Z stagne. Les mthodes de slection e e u e e des variables entrantes et sortantes peuvent alors crer des cycles ne garane tissant pas la terminaison de lalgorithme. Il existe deux mthodes thoriques e e permettant dviter les cycles. e La premi`re, smallest subscribt rule, consiste ` dterminer un seuil sur le e a e nombre ditrations dgnratives ` partir duquel lalgorithme est considr e e e e a ee comme tant dans un cycle. e A partir de l`, il sut dappliquer une version modie des fonctions de choix a e des variables. Ces fonctions sont bases sur le mme principe que celles que nous e e avons vu prcdemment ` lexception quelles vont choisir la variable possdant e e a e le plus petit indice parmi les variables ligibles et non pas forcment la variable e e orant le plus grand gain potentiel. D`s lors que la valeur de lobjectif change, e il sut de reprendre lutilisation des fonctions standards. Cette mthode est simple et peu coteuse en calcul mais risque dengendrer e u un nombre important ditrations supplmentaires. En eet, lalgorithme va e e eectuer plusieurs cycles en fonction de la taille du seuil avant de dterminer quil e est probablement dans un cycle. Ensuite, il devra encore eectuer un nombre non ngligeable ditrations dgnratives avant de modier la valeur de lobjectif. e e e e e Il existe une autre mthode, perturbation method, qui consiste ` ajouter une e a valeur ` chaque quation de lalgorithme. Le probl`me est alors dni comme a e e e suit :
n

Maximiser
j=1 n

c j xj aij xj = bi + i
j=1

Sujet ` a

(i = 1, 2, ..., m)

lj xj uj (j = 1, 2, ..., n) 0 < m m1 .... 1 1 Cette mthode permet dviter les cycles car il nexiste plus rellement dite e e e ration dgnrative, tant donn que les dirents biaisent le choix des vae e e e e e riables. Bornes individuelles Lalgorithme du simplexe a t dni uniquement pour des variables posiee e tives jusqu` prsent. Nanmoins, il est possible que les bornes des variables a e e soient dnies par nimporte quelle valeur relle, comme nous lavons vu dans e e le simplexe ` deux phases. a 16

Il est alors ncessaire de modier le probl`me ou lalgorithme pour rsoudre e e e ce type de probl`me. e Modier le probl`me consiste ` ajouter des quations pour limiter chaque e a e variable possdant des bornes individuelles autres que li = 0 et ui = . Cette e solution, bien que facile ` mettre en place, nest pas du tout eciente. Rappelons a que chaque nouvelle quation ncessite une variable de jeu et potentiellement e e une variable articielle. Dans le pire des cas, le probl`me de taille initiale e m (n + m) = mn + m2 deviendrait un probl`me de taille e (m + 2n) (n + (m + 2n)) = (m + 2n) (3n + m) = m2 + 6n2 + 5mn La modication de lalgorithme requiert de changer les mthodes de choix e des variables an de prendre en compte les bornes des variables en plus des contraintes des quations. Ces changements ne modient pas la structure de base e de lalgorithme mais ncessitent un peu plus de calculs, ce qui reste nettement e plus ecient que de modier le probl`me. e

2.5
2.5.1

Mthode du simplexe rvis e e e


Gnralits e e e

La mthode du simplexe rvis est la mthode la plus communment imple e e e e e mente grce ` ses performances sur les probl`mes creux. Elle est base sur le e a a e e mme principe que celui du simplexe standard. Lajout des variables de jeux, e linitialisation, la mthode du simplexe en deux phases, etc. sont aussi utiliss e e dans cette mthode. e La dirence entre ces deux mthodes est que la mthode du simplexe rvis e e e e e nutilise pas les dictionnaires. En eet, seulement une petite partie du dictionnaire est utilise ` chaque itration an de calculer la solution suivante. La partie e a e du dictionnaire utile est reconstruite ` chaque itration ` partir du probl`me a e a e initial. Cette reconstruction demande deectuer deux rsolutions de syst`mes e e dquations linaires par itration. e e e Dans un premier temps, nous allons voir comment le probl`me est dcome e pos. Ensuite, les mthodes de choix des variables ainsi que celles de mise ` e e a jour du probl`me seront dcrites. Finalement, certaines techniques optimisant e e la rsolution des syst`mes dquations linaires seront rapidement cites. Ces e e e e e derni`res sont dune importance cruciale, les performances accrues de lalgoe rithme en dpendent totalement. e

2.5.2

Dcomposition du probl`me e e
n

En utilisant le probl`me initial sous sa forme augmente : e e Maximiser


j=1 n

c j xj aij xj = bi
j=1

Sujet ` a

(i = 1, 2, ..., m)

xj 0 il est possible dexprimer un dictionnaire sous la forme dun syst`me dquations e e

17

linaires ` rsoudre. Exprimons dabord ce probl`me sous forme de vecteurs et e a e e matrices Maximiser cx Sujet ` a Ax = b x0 Ax = b exprime donc un syst`me dquations linaires o` les seules inconnues e e e u sont les lments du vecteur xB composs des variables basiques. Nous pouvons ee e donc dcomposer le probl`me en deux sous-ensembles : la partie basique et la e e partie non-basique. Soit, Ax = AB xB + AN xN Nous pouvons rcrire le syst`me dquations sous la forme suivante : e e e AB x B = b AN x N AB tant une matrice inversible, il est possible de diviser le syst`me dquations e e e par cette derni`re. e B = AB xB = B1 b B1 AN xN En suivant le mme procd pour la fonction objectif cx nous obtenons : e e e z = cx = cB xB + cN xN Et apr`s substitution de xB e z = cB B1 b + (cN cB B1 AN )xN Finalement, nous pouvons exprimer un dictionnaire ` partir du probl`me a e initial comme suit : xB = B1 b B1 AN xN z = cB B1 b + (cN cB B1 AN )xN Le vecteur rsultant x = B1 b contient les valeurs des variables basiques e B lies ` ce dictionnaire. e a Maintenant que nous avons vu comment il est possible de trouver un dictionnaire ` partir du probl`me initial, nous allons voir comment trouver les variables a e entrante et sortante.

2.5.3

Choix de la variable entrante

Etant donn que nous navons pas le dictionnaire en mmoire, il est ncessaire e e e de calculer les coecients des variables non basiques de la fonction objectif, dnis par cN cB B1 AN . Ces derniers vont tre calculs en deux tapes. e e e e Premi`rement, nous voulons dterminer le vecteur y = cB B1 . Pour cela, il e e faut rsoudre le syst`me dquations yB = cB . e e e Ensuite, nous pouvons calculer cN yAN . Il est dsormais possible, comme e dans lalgorithme standard, de slectionner la variable non-basique possdant le e e coecient positif le plus grand parmi ceux que nous venons de calculer. Cependant, il est judicieux de remarquer que les coecients de la fonction objectif sont calculables de mani`re individuelle, cj ya o` a est la colonne e u de AN correspondant ` cj . Dans ce cas-l`, nimporte quelle valeur garantit que a a

18

ya < cj est ligible (sans garantie sur le gain produit par le choix de cette e variable).

2.5.4

Choix de la variable sortante

Lors de ltape prcdente, nous avons donc choisi la variable entrante xj e e e ainsi que sa colonne a. Il nous faut dsormais dterminer quelle variable basique e e est la plus contraignante. Une fois de plus, nous devons calculer les dirents e coecients ncessaires ` cette tape tant donn que le dictionnaire courant e a e e e nest pas disponible. Reprenons donc le syst`me dquations linaires xB = B1 b B1 AN xN . e e e Nous allons tout dabord calculer la colonne correspondant ` la variable entrante. a Cette colonne, d, se trouve dans la matrice B1 AN . Pour trouver sa valeur, il nest pas ncessaire de calculer toute la matrice, il sut dutiliser la colonne a, e soit d = B1 a. Nous devons donc rsoudre le syst`me dquations Bd = a. e e e Ensuite, nous devons dterminer le gain t maximal des variables basiques e x garantissant que x td > 0. La variable sortante est celle qui correspond B B a la variable du vecteur x tant la plus contraignante (correspondant au t ` B e maximal).

2.5.5

Mise ` jour du probl`me a e

Il est dsormais ncessaire de mettre ` jour le probl`me. Cest cette tape e e a e e qui ore un gain important par rapport ` la mthode du simplexe standard. a e Jusqu` prsent le choix des variables ncessite plus de calculs que la mthode a e e e standard tant donn quil faut rsoudre des syst`mes dquations linaires. e e e e e Il sut dans cette tape de placer la valeur de la variable entrante a t et e ` de remplacer les valeurs de x par x td. Finalement, il faut remplacer la B B colonne de la variable sortante dans B par celle de la variable entrante.

2.5.6

Optimisation importante

La mthode du simplexe rvis nest pas eciente si les syst`mes dquae e e e e tions yB = cB et Bd = a sont calculs enti`rement ` chaque quation car la e e a e complexit de cette tche augmente au fur et ` mesure que B volue au l des e a a e itrations. Il existe cependant des techniques qui permettent de dcomposer la e e matrice B en une suite de matrice simple ` rsoudre. a e Factorisation eta de la base Une de ces techniques sappelle factorisation eta de la base. Elle dcoule e de lobservation qu` chaque tape, la matrice B na quune colonne qui est a e modie. Il est donc possible de dcrire cette matrice ` ltape k, Bk comme e e a e tant Bk = Bk1 Ek o` Ek est la matrice unit dont la colonne de la variable e u e entrante a t remplace par le vecteur d calcul prcdemment dans lalgorithme ee e e e e ( Bk1 d = a). La matrice Bk peut donc tre factorise par une suite de matrice E, e e B1 = E1 , B2 = E1 E2 , BK = E1 E2 ...Ek Cette factorisation permet alors de rsoudre les syst`mes dquations yBk = cB e e e

19

en k tapes, (((yE1 )E2 )..)Ek = cB . Il sagit donc de rsoudre yk Ek = cB, puis e e yk1 Ek1 = yk , ..., yE1 = y2 . Cette technique est eciente car il est bien plus facile de rsoudre les syse t`mes dquations contenus dans les matrices E que dans une matrice Bk come e plexe. De plus, les matrices eta sont faciles ` stocker car uniquement une de a leur colonne est dirente de la matrice identit. Il sut donc de stocker cette e e colonne ainsi que sa position dans la matrice eta. Cette technique sapplique de faon similaire an de rsoudre le syst`mes c e e dquations Bd = a, soit rsoudre les k matrices eta de la dcomposition suie e e vante, E1 (E2 (..(Ek d))) = a.

Dcomposition LU e Il est alors possible de tirer prot dune dcomposition en matrices triane gulaires. Ce type de dcomposition consiste ` exprimer une matrice comme le e a produit dune matrice triangulaire infrieure et dune matrice triangulaire supe e rieure : B = LU. Cette dcomposition est utilise an de rsoudre des syst`mes e e e e dquations linaires, Bx = LUx = b. Il sagit alors de rsoudre dans un pree e e mier temps Ly = b an de trouver y, puis de rsoudre Ux = y an de trouver e x. Cette technique est intressante lorsque le syst`me dquations doit tre re e e e e solu plusieurs fois car il sut de substituer progressivement les valeurs dans la matrice L (de haut en bas) et dans la matrice U (de bas en haut) pour rsoudre e le syst`me dquations. e e Nous allons donc utiliser une dcomposition LU an de rsoudre les dirents e e e syst`mes dquations lis aux matrices eta qui sont les mmes ` chaque itration e e e e a e (mis ` part la nouvelle matrice eta lie ` la derni`re itration). Nous avons notre a e a e e matrice basique exprime sous la forme Bk = B0 E1 E2 ...Ek o` B0 est la matrice e u de base initiale et nous devons rsoudre ((((yB0 )E1 )E2 )..)Ek = cB ainsi que e B0 (E1 (E2 (..(Ek d)))) = a. Commenons par eectuer la dcomposition LU de la matrice de base initiale c e B0 . Cette dcomposition est exprime par Lm Pm ...L1 P1 B0 = Um ...U1 (o` e e u P est la matrice de permutation). A litration k, en conjonction avec lajout e de matrice eta, nous obtenons alors Lm Pm ...L1 P1 Bk = Um ...U1 E1 ...Ek . Ces matrices peuvent donc tre mmorises et ` chaque itration, seule la nouvelle e e e a e matrice Ek+1 doit tre ajoute ` leur suite. e e a An de rsoudre yBk = cB , il sagit alors deectuer lopration BTRAN e e (backward transformation) qui consiste ` rsoudre les dirents syst`mes dquaa e e e e tions de la n au dbut de la suite de matrice, soit : rsoudre dans un premier e e temps (((y Um )Um1 )...)Ek = cB puis ` calculer y = (((y Lm Pm )...)L1 P1 ). a Lopration FTRAN (forward tranformation) est lopration inverse et pere e met de rsoudre Bd = a, soit : calculer a = ((Lm Pm )...)L1 P1 a puis rsoudre e e Um (Um1 (...(Ek d))) = a . Cette opration consiste donc ` une utilisation de e a la suite de matrice allant du dbut ` la n de cette derni`re. e a e Finalement, il est important de noter que cette structure va cro ` chaque tre a itration. An dviter que la structure de matrices mmorises devienne trop e e e e importante et que les imprcisions de calcul ne saccumulent, il est ncessaire, e e priodiquement, de repartir depuis zro. Pour cela, il faut dcomposer la matrice e e e Bk an de pouvoir eacer les matrices eta.

20

Chapitre 3

CUDA
3.1 Introduction

Nous allons dans ce chapitre tudier le concept de programmation sur GPU, e plus communment appel GPGPU pour General-Purpose Computing on Grae e phics Processing Units. Plus prcisment, nous allons nous intresser ` CUDA e e e a (Compute Unied Device Architecture). CUDA est larchitecture de calcul dvee lopp par NVIDIA pour ses GPU. Les informations utilises an de dcrire cette e e e architecture sont tires du manuel de programmation [1] fourni par NVIDIA. e Tout comme les CPU, les GPU ont vu leur puissance de calcul grandement cro durant ces derni`res annes. Cependant, le traitement dimages a amen tre e e e larchitecture des cartes graphiques ` tirer prot du paralllisme de donnes et a e e dinstructions. En eet, les images tant mmorises sous forme de matrices, e e e il est gnralement ncessaire dappliquer une modication a lensemble de la e e e ` matrice. Ces modications peuvent typiquement tre des translations, homoe thties, rotations, des combinaisons de ces oprations ou encore dautres calculs e e bien plus complexes. Cette architecture parall`le est de type Single Instruction Multiple Threads e (SIMT) qui est proche dune architecture Single Instruction Multiple Data (SIMD). La dirence majeure entre ces deux architectures est la gestion avance de e e tches permettant des changements de contexte rapides dans larchitecture de a type SIMT. Cette derni`re est capable dexcuter plusieurs tches eectuant la e e a mme opration en mme temps. La derni`re famille de carte graphique, tesla, e e e e ddie au calcul, approche les performances de supercalculateurs pour un prix e e comptitif. Le nombre doprations pour des nombres rels en simple prcision e e e e varient de 600 ` 1000 GFLOPS, pour des nombres rels en double prcision, de a e e 80 ` 512 GFLOPS par GPU selon le mod`le. a e La programmation CUDA se fait en C ou en fortran. Cependant, de nombreux wrappers permettant le dveloppement en python, perl, matlab, sont dise ponibles. Il est important de noter quun GPU nest pas une unit indpendante e e en soi. Il est ncessaire de disposer dune machine standard (CPU) commandant e le GPU. Cette machine bncie de lacc`s ` la mmoire du GPU an dchane e e a e e ger avec lui des donnes et doit aussi initier lexcution des fonctions de calculs e e (routines) sur le GPU. Cette technologie, aide par une communaut importante, volue de mae e e

21

ni`re continue. An dassurer des performances intressantes, NVIDIA fournit e e un ensemble de librairies pour les oprations essentielles telles que celles dale g`bre linaire, les transformes de Fourier, la gnration de nombres alatoires e e e e e e ou encore les rendus graphiques. Dans un premier temps, nous allons tudier larchitecture globale dun GPU. e Nous allons nous intresser ` la mani`re dont est paralllis un travail sur CUDA, e a e e e depuis un programme jusqu` la plus petite unit de calcul, un processeur. a e Ensuite, nous verrons un des points cruciaux de cette technologie : la me moire. En eet, ce type darchitecture dpend fortement de lacc`s aux donnes e e e ainsi que de leur rpartition. Nous verrons donc, comment ces derni`res peuvent e e tre mmorises ` chaque niveau de larchitecture. e e e a Finalement, nous nous intresserons ` plusieurs crit`res importants lors de e a e la programmation sur GPU. Il est ncessaire de faire attention ` certaines r`gles e a e an dobtenir des performances comptitives avec des syst`mes plus standards e e (CPU).

3.2
3.2.1

Architecture
Vue globale

Larchitecture dun GPU, plus communment appel device, est relativement e e complexe. De plus, les divers mod`les de GPU poss`dent des architectures le e e g`rement direntes. Par exemple, la derni`re famille de GPU NVIDIA, fermi, e e e dispose dune organisation dirente des processeurs ainsi que quelques amlioe e rations au niveau de la mmoire. e Chaque famille de GPU dispose dun identiant de capacits, appel come e pute capability (CC ). Les GPUs possdant un CC plus petit que 1.3 ne sont e pas capables deectuer des calculs en double prcision. La derni`re gnration, e e e e fermi, est identie par un CC de type 2.x car son architecture est plus adapte e e au calcul en double prcision et quelle est capable deectuer des contrles et e o corrections derreurs sur la mmoire. e Cette tude portera principalement sur larchitecture utilise dans le cadre e e de ce travail. Cette architecture est caractrise par un CC gal ` 1.3. Les archie e e a tectures disposant dun CC plus petit que 1.3 sont conut de faon similaire. Par c c la suite, nous distinguerons les dirents mod`les de GPU et donc darchitecture e e en utilisant leur CC si ncessaire. e La gure 3.1 dcrit lensemble de larchitecture. Nous pouvons voir quil e existe dirents niveaux de mmoire. Ces derniers sont reprsents en orange e e e e sur la gure. De mme, les units de calculs ont leur architecture propre : un e e device est compos de multiprocesseurs eux-mmes composs de processeurs. e e e Ces dirents niveaux vont tre dcrits dans les sections suivantes. Nous e e e dbuterons par la rpartition des tches ainsi que par lorganisation des procese e a seurs. Il sera ensuite plus ais de comprendre larchitecture de la mmoire. e e

3.2.2
Kernel

Organisation des tches a

Le device est lunit la plus grossi`re du syst`me et elle est accessible depuis e e e un ordinateur standard. Un programme CUDA, kernel, est excut sur un device. e e 22

Figure 3.1 Architecture globale Ce dernier ne peut excuter quun seul kernel ` la fois, ` lexception du plus e a a rcent mod`le de GPU, fermi, qui peut en excuter plusieurs ` la fois. e e e a Un kernel est compos dune multitude de tches. Ces derni`res sont orgae a e nises en units abstraites, ceci an de les rpartir de faon eciente sur les e e e c dirents multiprocesseurs, puis processeurs. e La gure 3.2 reprsente lorganisation des tches au sein dun kernel. e a Tche a Les tches sont excutes sur les processeurs. Comme nous pouvons le remara e e quer dans la gure 3.1, les processeurs appartenant ` un mme multiprocesseur a e sont contrls par une unit dinstructions. Cette derni`re va mettre ` chaque oe e e e a cycle une instruction que chaque processeur devra eectuer en utilisant les registres ` sa disposition. Dans le cas optimal, les tches devraient faire exactement a a le mme travail ` chaque cycle. La dirence entre deux tches va se trouver e a e a dans les donnes contenues dans les registres. Le choix de donnes direntes est e e e possible grce ` lidentiant des tches. En eet, chaque tche poss`de un idena a a a e tiant propre. Ce dernier rend alors possible la lecture et lcriture de donnes e e particuli`res pour chaque tche. e a

23

Figure 3.2 Rpartition des tches e a Une premi`re illustration simple serait une addition de deux vecteurs. Chaque e tche aurait pour mission, de charger un lment de chacun des vecteurs, de les a ee additionner et de placer le rsultat dans un troisi`me vecteur. En admettant e e quil y ait autant de tches que le vecteur poss`de dlments, chaque procesa e ee seur eectuerait exactement les mmes instructions, seule ladresse des donnes e e dans la mmoire serait dirente. e e Block Les tches sont alors rparties dans des blocks. Lidentiant des tches est a e a compos de deux variables idX et idY , de mani`re ` permettre des organisations e e a en deux dimensions au sein dun block. Ceci peut tre fortement utile lors de e calculs sur des matrices an de maintenir une organisation similaire entre les donnes et les tches. Le nombre maximal de tches par block est de 512 (1024 e a a pour les CC 2.0 ). Un block va tre excut sur un multiprocesseur (streaming multiprocessor) e e e compos de 8 processeurs (2x16 pour les CC 2.0). Les tches vont tre de a e e composes en groupe de 32 tches, appel warp. Un warp est la plus petite unit e a e e excutable par un multiprocesseur. e Etant donn que le changement de contexte sur les processeurs est extre e mement rapide, lide va tre de tirer prot dun pipeline compos de 4 tches e e e a minimum par processeur, do` la dcomposition en warp (8 processeurs fois 4 u e 24

tches). Lutilisation de pipelines permet dmettre une nouvelle srie dinstruca e e tions pendant quun groupe de tches est en train deectuer son instruction et a dattendre le rsultat. e Par exemple, les instructions dacc`s ` la mmoire sont gnralement tr`s e a e e e e lentes et donc attendre larrive des donnes bloquerait le processeur inutilee e ment. Un multiprocesseur peut stocker jusqu` 8 blocks dirents ` la fois, crant a e a e de la sorte un pipeline important. Admettons que nous ayons des blocks de 512 tches, nous pourrions avoir dans le pipeline 8 blocks composs de 16 warps, a e soit 512 tches dans le pipeline de chaque processeur. Ceci permettrait un ot a continu dinstructions mme si une partie des tches est en attente sur leurs e a donnes. e Ces dirents degrs de paralllisme seront traits plus en dtail dans les e e e e e section 5.2 et 4.5.3. Grid Les blocks forment ensuite une grille (grid ). Ce niveau dorganisation supplmentaire est ncessaire an de placer en attente les blocks ne pouvant tre e e e excuts. Ceci se produit lorsque la totalit des multiprocesseurs sont saturs e e e e de blocks. De ce fait, il est uniquement possible de synchroniser des tches au a sein dun mme block. e Un block poss`de un identiant en trois dimensions reprsentant sa position e e dans la grille. An de crer un identiant unique pour chaque tche, il est alors e a ncessaire de combiner la position de la tche dans son block ` la position de ce e a a dernier dans la grille.

3.2.3
Schma e

Mmoires e

Nous allons dsormais voir la dcomposition de la mmoire dans un device. e e e Chaque niveau de larchitecture dispose despaces mmoire quil peut accder e e de mani`re plus ou moins eciente. La gure 3.3 dcrit les niveaux de mmoire e e e en fonction de leur accessibilit. e Mmoire globale e La mmoire globale est la mmoire de base du device. Cet espace permet e e lchange de donnes entre un CPU et un GPU. Les donnes ncessaires ` un e e e e a calcul sont places dans cette espace et les rsultats aussi. Cette mmoire est e e e accessible depuis chaque niveau de larchitecture, cependant son acc`s est lent. e Les instructions de chargement et dcriture dans cette mmoire ncessitent e e e plusieurs centaines de cycles avant dtre excutes. De plus, lchange de done e e e nes entre les tches via cette mmoire nest gnralement pas utilis ou alors e a e e e e dans de tr`s rares cas. En eet, les tches des dirents blocks tant asynchrones, e a e e il est dicile de grer les acc`s ` cette mmoire et de garantir lintgrit des done e a e e e nes. e Il existe cependant certaines solutions permettant de synchroniser les blocks. Ces solutions ncessitent dutiliser des oprations atomiques sur la mmoire e e e globale, ce qui est premi`rement lent et deuxi`mement possible uniquement si e e

25

Figure 3.3 Dcomposition de la mmoire e e aucun block ne se trouve en attente dexcution. Ce dernier cas risquerait de e gnrer des deadlocks. e e Finalement, il est intressant de citer quelques particularits de la mmoire e e e globale. Il existe deux types spciaux de mmoire globale : les textures et lespace e e rserv aux constantes. Ces mmoires orent des performances bien meilleures e e e que la mmoire globale car elles disposent de caches permettant des acc`s bien e e plus rapides. Leur inconvnient est quelles sont accessibles depuis les tches en e a lecture uniquement. Seules des critures diriges par le CPU sont possibles. De e e plus, leur taille est limite. Lespace rserv aux constantes ne peut dpasser e e e e quelques kB et les textures sont contraintes ` des limites de tailles qui varient a selon son nombre de dimensions (voir [1] appendix A). Mmoire partage e e Chaque block dispose dune mmoire partage an de communiquer en ine e terne. Cette mmoire est tr`s performante lorsquelle est utilise correctement. e e e Cest-`-dire quil est ncessaire de grer correctement les acc`s ` cette derni`re. a e e e a e Les direntes tches dun block doivent tre coordonnes correctement an e a e e quelles acc`dent ` cette mmoire sans eectuer de collisions. Si deux tches e a e a tentent daccder ` la mme adresse mmoire, alors les dlais dacc`s ` celle-ci e a e e e e a

26

saccumuleraient et ralentiraient la totalit des tches du block. e a Finalement, cet espace de mmoire est de taille limite. Comme son nom e e lindique, elle est partage par les tches dun block. Si le calcul ncessitait que e a e les tches disposent de beaucoup de mmoire partage, il serait possible que la a e e totalit des warps dun block ne puisse tre excut parall`lement (pipeline). e e e e e Ceci an de garantir que chaque tche dispose de susamment de mmoire. Le a e pipeline serait alors moins plein, masquant moins bien les instructions dacc`s e a la mmoire. ` e Mmoire locale e Les tches disposent dune mmoire locale se situant dans la mmoire globale. a e e Cette mmoire est donc lente, mais permet de mmoriser un nombre important e e de donnes. Dans la majorit des cas, la mmoire partage est utilise en priorit e e e e e e en raison de ses performances. Cependant, si une tche ncessitait un espace a e mmoire an de stocker temporairement un nombre important de valeurs, cette e mmoire pourrait tre utilise. e e e Registres Outre la mmoire locale, les tches disposent de registres. Ces derniers sont e a donc llment en bas de la cha de mmoire. Ils sont tr`s rapides dacc`s ee ne e e e et sont bien entendu utiliss lors des calculs. Similairement ` la mmoire pare a e tage, chaque block dispose dun nombre ni de registres. Les tches du block e a doivent donc se partager ces registres. Dans le cas o` les tches ncessiteraient u a e un nombre important de registres, la totalit des warps du block ne pourrait pas e tre maintenue dans le pipeline. Ceci pour garantir que chaque tche dispose du e a nombre de registres ncessaire ` son excution. Leur rapidit dacc`s ainsi que e a e e e leur nombre limit fait des registres une des ressources les plus importantes. e

3.3
3.3.1

Mod`le de programmation e
Gnralits e e e

Dans cette section nous allons nous pencher sur certains points importants de la programmation sur GPU. Comme nous lavons vu, larchitecture est complexe. Il est alors ncessaire de faire attention ` certains points an den optimiser e a lutilisation. Nous nous pencherons dans un premier temps sur le probl`me que peuvent e poser les instructions conditionnelles sur les architectures de type SIMT et SIMD. Ensuite, nous allons nous pencher sur la coopration entre les tches. Cette e a coopration est principalement ncessaire an doptimiser les acc`s ` la me e e a e moire. Cependant, elle est aussi ncessaire an deectuer certaines oprations, e e typiquement des rductions. e Finalement, nous nous pencherons sur loccupation des GPUs ainsi que la latence des oprations dacc`s ` la mmoire. e e a e

27

3.3.2

Branchements

Les processeurs dun multiprocesseur doivent eectuer les mmes instruce tions an quelles puissent sexcuter en parall`le. Si ` la suite dune instruction e e a conditionnelle une ou plusieurs tches dun warp avaient des instructions dia e rentes ` excuter, les instructions de chaque tches de ce warp sexcuteraient a e a e de faon squentielle. c e Lide est alors dviter ` tout prix les branchements amenant ` des inse e a a tructions direntes. Au cas o` cela ne serait pas possible, il est important de e u minimiser la taille des codes divergents ainsi que de synchroniser lensemble des tches ` la n de la portion de code divergent. a a La technique de programmation gnralement utilise est donc de relguer e e e e les dcisions au CPU et dutiliser le GPU pour eectuer les calculs paralllisables e e comme dcrit dans la gure 3.4. e

Figure 3.4 Excution typique de programme GPGPU e

3.3.3

Coopration entre les tches e a

La coopration entre les tches est tr`s importante dans CUDA : les acc`s e a e e a ` la mmoire doivent se faire de faon cooprative an dviter les conits et e c e e doptimiser les lectures. La coopration est aussi importante an dchanger des e e donnes via la mmoire partage. Ceci an dviter des calculs redondants et e e e e dobtenir de bonnes performances pour des mthodes de rductions par exemple. e e Etudions les acc`s aux mmoires globale et partage. Il est important dans e e e un premier temps de savoir que les acc`s ` ces mmoires se font par moiti e a e e de warp, soit 16 tches. Il existe deux types dacc`s dirents : le premier est a e e un acc`s conscutif (coalescent 1 , soit un acc`s ` une suite dadresses dans la e e e a mmoire et le second un acc`s alatoire, soit ` des adresses rparties ` dirents e e e a e a e
1. Concept propre ` CUDA. a

28

endroits de la mmoire. Ces deux types dacc`s sont reprsents dans la gure e e e e 3.5.

Figure 3.5 Acc`s conscutif et alatoire ` la mmoire e e e a e Il est important dutiliser le plus souvent possible des acc`s conscutifs car e e ils sont bien plus rapides que les acc`s alatoires. Dans le meilleur des cas, il e e est possible de lire en une instruction la totalit des donnes ncessaires pour e e e un warp si les adresses sont adjacentes. Un multiprocesseur peut accder ` la e a mmoire par mot de 128 octets au maximum. La lecture dun mot de 128 octets e permettrait dobtenir 16 nombres de double prcision en une lecture ou encore e 32 nombres de simple prcision. e Les acc`s alatoires sont nettement plus coteux. Si les adresses ne sont pas e e u adjacentes, chaque tche doit excuter sa propre instruction de lecture. Ce qui a e veut dire que 16 instructions sont ncessaires an daccder aux donnes pour e e e un demi warp. De plus la taille minimale dacc`s aux donnes est de 32 octets. e e Nous avons donc dans ce cas 16 instructions direntes dacc`s ` la mmoire. e e a e Qui plus est, seul un faible pourcentage de ces donnes seront utilises, ce qui e e nest pas du tout ecient. Les performances lies ` la mmoire partage sont particuli`rement dpene a e e e e dantes des acc`s conscutifs et sans collisions. Les collisions sur les acc`s ` e e e a la mmoire font chuter les performances de faon critique car les instructions e c concurrentes sur une adresse mmoire seectuent squentiellement. Il est donc e e ncessaire de prter une attention particuli`re ` la stratgie dchanges dinfore e e a e e mations via la mmoire partage. e e

29

3.3.4

Cycle pour une instruction et latence

Chaque instruction dans CUDA ncessite un nombre dirent de cycles e e avant dtre excute. Les instructions arithmtiques sur les nombres ottants e e e e prennent 4 cycles pour les multiplications et additions et 36 pour les divisions, par exemple. Le dbit dinstructions pour les nombres ottants en double pre e cision est 8 fois plus lent que pour les nombres en simple prcision. e Les instructions dacc`s ` la mmoire globale fonctionnent diremment. e a e e Elles cotent dans un premier temps un nombre xe de cycles an dmettre u e linstruction de lecture (rciproquement dcriture). Cependant ` ce cot initial e e a u vient sajouter une latence de 400 ` 600 cycles avant que les donnes soient a e disponibles. Lorsquune tche dun block est en attente sur une donne en cours a e dacc`s, le warp de cette derni`re est remis en attente dans une queue. Le schee e duler choisit un autre warp qui peut tre excut an de masquer au mieux la e e e latence. Cest pour cela quil est intressant de choisir un nombre important de tches e a par block. Plus le nombre de warps est important, plus il est facile de cacher les latences lies aux instructions dacc`s ` la mmoire. Plus un probl`me est e e a e e grand, plus il est facile de bien rpartir les tches sur les direntes units de e a e e calculs an de cacher les eets de la latence.

3.3.5

Occupation

Ceci nous am`ne ` la notion doccupation. Loccupation est le nombre de e a warps quun multiprocesseur peut excuter en mme temps. Il est important de e e maximiser loccupation an de garantir que la latence est bien cache. e Loccupation est dnie dans un premier temps par le nombre de tches se e a trouvant dans un block et donc de warps. Cependant, il est ncessaire de rappeler e que le nombre de registres disponibles (ou de mmoire partage) par block est e e partag par les direntes tches de celui-ci. De ce fait, il est ncessaire de faire e e a e un compromis entre loccupation et le nombre de registres par tche. a Dans le guide de programmation de CUDA [1], il est spci que pour obtenir e e les meilleurs performances possibles, il est ncessaire de maximiser loccupation. e Cependant, nous verrons dans la section 4.5.3 quil est parfois prfrable de ee rduire loccupation pour augmenter le nombre de registres disponibles. e

30

Chapitre 4

Implmentations e
4.1 Introduction

Maintenant que les bases thoriques ont t tablies, nous allons nous inte eee e resser ` la mani`re dont lalgorithme a t implment 1 . a e ee e e Nous allons tout dabord choisir la variante du simplexe qui sera implmene te. Le simplexe standard et le simplexe rvis vont tre passs en revue de faon e e e e e c a dnir leurs avantages et inconvnients dans le cadre dune paralllisation sur ` e e e GPUs. Une fois la mthode du simplexe choisie, nous tudierons les gains de pere e formance possibles sur les oprations principales ncessaires ` une itration du e e a e simplexe. Une version squentielle des oprations sur CPU sera compare ` son e e e a quivalent sur GPU e Nous verrons ensuite comment le simplexe a t implment sur un GPU. La ee e e structure du probl`me en mmoire sera dcrite. Lalgorithme utilis ainsi que les e e e e dirents changes de messages entre le CPU et le GPU seront alors dtaills. e e e e Les probl`mes principaux rencontrs durant cette tape seront noncs. Les e e e e e direntes amliorations apportes ` la version initiale de lalgorithme seront e e e a alors dcrites. Nous nous intresserons aussi plus en dtail au fonctionnement des e e e kernels. Une technique permettant damliorer les performances de ces derniers e sera aborde. e Finalement, limplmentation sur plusieurs GPUs clturera ce chapitre. Les e o direntes possibilits de dcoupe du probl`me seront tudies. Nous verrons e e e e e e aussi comment les GPUs communiquent entre eux et quelles sont les modications ` apporter ` lalgorithme. a a

4.2
4.2.1

Choix de la mthode du simplexe e


Gnralits e e e

Dans cette partie nous allons tudier les deux mthodes du simplexe que nous e e avons vues dans le chapitre 2. Ces derni`res vont tre analyses dans le cadre e e e dune implmentation sur GPU. Cette analyse va porter sur plusieurs points. e
1. Les implmentations dcrites durant ce chapitre sont disponibles sur le site du groupe e e SPC du dpartement dinformatique de lUniversit de Gen`ve [11]. e e e

31

Nous allons nous interroger sur la disponibilit de fonctions optimises ncese e e saires ` notre algorithme. En eet, les implmentations squentielles existantes a e e utilisent des librairies optimises telles que CBLAS (Basic Linear Algebra Sube programs for C ). Il est donc ncessaire de disposer doutils comptitifs avec ce e e type de librairies. Dautant plus quobtenir des kernels optimiss pour CUDA e reprsente un d en soi. Les librairies CUDA tant en pleine volution, il est e e e e probable que de nouvelles fonctionnalits deviennent disponibles par la suite. De e ce fait certains arguments cits dans ce mmoire pourraient tre dsuets dans e e e e le futur. Nous tudierons aussi lespace pris en mmoire par une instance de lalgoe e rithme. Les types de mmorisations rendues possibles par CUDA seront aussi e revus selon lutilisation faite des donnes. e Un autre point important sera la dcoupe du probl`me dans le cadre dune e e implmentation sur plusieurs GPUs. En eet, la mthode choisie devra pere e mettre une sparation avantageuse du probl`me en plusieurs sous-probl`mes. e e e Ces sous-probl`mes devront tre le plus indpendant possible an dviter des e e e e communications trop nombreuses entre les GPUs.

4.2.2

Simplexe standard

La mthode du simplexe standard est base sur la mmorisation du dictione e e naire complet. Les fonctions principales an de rsoudre ce probl`me sont les e e recherches de variables et lopration de pivotage. e Les oprations de recherches peuvent tre paralllises de mani`re eciente e e e e e sous forme de rduction. Cependant, ces oprations seront aussi ncessaires dans e e e le cadre du simplexe rvis. Ces derni`res ne permettront donc pas de distinguer e e e les deux mthodes quant ` leur implmentation sur GPU. e a e Le pivotage consiste en une opration dalg`bre linaire basique. NVIDIA e e fournit aux utilisateurs de CUDA une librairie optimise pour lalg`bre linaire e e e appele CUBLAS (Basic Linear Algebra Subprograms for CUDA). Les oprae e tions fournies par cette librairie sont dcomposes en 3 catgories : les oprae e e e tions sur les vecteurs, les oprations matrice-vecteur et nalement les oprations e e matrice-matrice. Les gains lis ` cette librairie croissent avec la complexit de e a e lopration. Celle dont nous avons besoin pour le pivotage fait partie de la see conde catgorie (matrice-vecteur). Nous pouvons donc nous attendre ` de bons e a gains. La mmorisation du probl`me est simple : il faut mmoriser lensemble du e e e probl`me sous la forme dune matrice. Cette derni`re volue ` chaque itration. e e e a e Il nest donc pas possible dutiliser les textures car elles sont uniquement en lecture depuis les kernels (seul le CPU peut crire dedans). e La dcoupe du probl`me semble aise au premier abord. Il surait de divie e e ser la matrice contenant le probl`me en plusieurs sous-matrices. Chaque unit e e devrait alors eectuer sont choix de variable localement avant deectuer une rduction globale entre les GPUs. Ensuite, les donnes requises au pivotage see e raient communiques ` lensemble des GPUs. Ces donnes devraient tre dans e a e e le pire des cas une ligne et une colonne : la ligne de la variable sortante et la colonne de la variable entrante, parfois appeles ligne pivot, respectivement e colonne pivot.

32

4.2.3

Simplexe rvis e e

La mthode du simplexe rvis ` pour particularit dorir des gains sube e e a e stantiels sur les probl`mes creux. Les syst`mes dquations forms de matrices e e e e creuses sont plus faciles ` rsoudre gnralement. De plus, les matrices creuses a e e e peuvent tre compresses an de rduire leur taille. Cette compression consiste e e e a mmoriser uniquement les coecients non-nuls. ` e Les oprations ncessaires ` cette variante du simplexe sont plus complexes. e e a Les oprations de recherches des variables sont les mmes que dans le cas du e e simplexe standard. Par contre, il faut eectuer une dcomposition triangulaire e de la matrice contenant la base. Cette opration nest pas disponible dans les e librairies mise ` disposition par NVIDIA. Certaines versions de cette opration a e sont distribues par la communaut GPGPU. Elles promettent des gains intrese e e sants, malheureusement dans la majorit des cas, que pour les nombres ottant e en simple prcision. Le probl`me est similaire en ce qui concerne la rsolution e e e de syst`mes dquations linaires, ces deux mthodes tant lies. e e e e e e En ce qui concerne les besoins en mmoire de cette mthode, le probl`me e e e initial ainsi que la structure de matrices compose de E, P, L, U doivent tre e e stocks. Les techniques spciales de mmorisation de ces matrices, cites dans e e e e le chapitre 2, pourraient tre appliques. Nanmoins, ce type de mmorisation e e e e pourrait entra ner des chutes de performance. Les oprations algbriques sur ce e e type de structures ncessitent des schmas de lectures ne convenant pas force e e ment ` une architecture SIMT. Utiliser ces structures baisserait les performances a de lalgorithme, ne pas le faire limiterait la taille maximale des probl`mes. e Certaines parties du probl`me pourraient tre mmorises dans les textures e e e e tant donn quelles ne sont pas mises ` jour depuis les GPUs ` chaque itration. e e a a e Ceci orirait un acc`s rapide en lecture, mais une fois de plus limiterait la taille e maximale du probl`me car les textures sont de tailles limites. e e La dcoupe du probl`me semble fort complexe au premier abord. La structure e e des matrices eta devrait tre partage sur plusieurs GPUs an de distribuer le e e calcul ncessaire aux phases BTRAN et FTRAN (voir section 2.5.6). Ces deux e phases ncessitent de rsoudre des syst`mes dquations. Pour ce faire, il faut e e e e pouvoir accder et modier le syst`me dquations dans son enti`ret. Ce qui e e e e e sous-entend un nombre important de communications entre les GPUs. Cette opration tant ncessaire plusieurs fois par itration, lajout de GPUs ne serait e e e e pas forcment ecace. e

4.2.4

Choix de la mthode e

Nous allons ici comparer les deux mthodes sur les dirents aspects discuts e e e dans les sections prcdentes. e e Les oprations ncessaires ` une itration du simplexe standard sont relatie e a e vement simples. Lopration la plus complexe, celle dalg`bre linaire, est dispoe e e nible et optimise pour toutes les architectures CUDA. En contre-partie, pour la e mthode du simplexe rvis, certaines des oprations ne sont pas ociellement e e e e disponibles et optimises. La dcomposition de matrices ainsi que la rsolution e e e de syst`mes dquations linaires font parties de ces oprations. La mthode du e e e e e simplexe standard lemporte ici, car les oprations complexes lies ` celle-ci sont e e a optimises et fonctionnelles. e Du point de vue de la mmoire, la mthode du simplexe standard ncessite e e e

33

de mmoriser la matrice enti`re. Il en est de mme pour la mthode du simplexe e e e e rvis initialement. Nanmoins, les matrices eta doivent aussi tre stockes par la e e e e e suite. Ces matrices comme nous lavons vu peuvent tre mmorises de mani`re e e e e a minimiser leur taille au prix sans doute dune perte de performance. Sur ce ` point, lalgorithme du simplexe standard aurait un avantage pour les probl`mes e de grande taille, cependant lalgorithme rvis pourrait tre plus performant sur e e e les probl`mes de petite ` moyenne taille, grce ` lutilisation de textures. e a a a Le dcoupage du probl`me en vue dune implmentation sur plusieurs GPUs e e e serait nettement plus ais dans le cadre du simplexe standard. En eet, le proe bl`me est facilement dcoupable et les tapes principales dune itration peuvent e e e e tre calcules de mani`re indpendante une fois que la colonne et la ligne pie e e e vot ont t communiques ` tous les GPUs. Dans le cadre du simplexe rvis, ee e a e e un nombre plus lev de communications serait ncessaire ` chaque itration e e e a e principalement ` cause de la rsolution des syst`mes dquations linaires. a e e e e Le simplexe rvis semble avoir certains avantages dans le cadre dune ime e plmentation sur un GPU et pour des probl`mes de taille modre. Cependant, e e ee pour une implmentation sur plusieurs GPUs et pour des probl`mes de grande e e taille, le simplexe standard semble plus adapt. e Le but de ce travail portant sur la paralllisation du simplexe an de re e soudre des probl`mes de grande taille, la mthode du simplexe standard va tre e e e choisie pour limplmentation. De plus, il existe dj` de nombreuses implmene ea e tations squentielles du simplexe rvis orant de bonnes performances sur des e e e probl`mes de petite taille. e

4.3
4.3.1

Etude de performance de CUDA


Oprations principales e

Nous avons dsormais choisi la mthode du simplexe ` implmenter : le e e a e simplexe standard. Avant dimplmenter cette mthode, nous allons tudier les e e e gains potentiels apports par CUDA sur les oprations principales prsentes e e e dans une itration de lalgorithme. Ces oprations sont la recherche de variables e e ainsi que le pivotage. La premi`re opration consiste ` trouver la variable possdant le plus grand e e a e coecient dans le cas de la variable entrante. Pour la variable sortante, cela consiste ` dterminer celle qui est la plus contraignante, cest-`-dire celle dont a e a le rsultat dun ratio entre deux coecients est le plus petit. Ces oprations e e reviennent donc ` trouver le plus petit ou le plus grand lment dun vecteur. a ee Ce type de recherche peut tre paralllis sous forme de rduction. La rduction e e e e e consiste ` distribuer le travail sur les direntes units de calcul travaillant en a e e parall`le. Chacune devra dnir un premier rsultat local sur un sous-ensemble e e e des donnes. Ensuite elles devront cooprer an de rduire les rsultats locaux e e e e en un rsultat global. e La seconde opration est le pivotage. Comme nous lavons vu dans la sece tion 2.4.2, cette opration consiste ` substituer une variable dans lensemble des e a quations. Autrement dit, il sagit de supprimer la variable de toutes les quae e tions sauf celle o` elle est basique. Pour cela, il sut de soustraire lquation u e o` la variable en question est basique aux autres quations. An de supprimer u e la variable, il est nanmoins ncessaire de pondrer cette quation par le coefe e e e

34

cient de la variable entrante avant la soustraction. Cette opration quivaut ` e e a lopration DGER de la libriairie BLAS, soit : e A = x y + A o` x est la colonne pivot, y lquation (ligne) pivot et A la matrice contenant u e les quations. e Les mesures sont eectues sur le syst`me dcrit ` la section 6.4.2. e e e a

4.3.2

Recherche du maximum

La recherche de la variable entrante ainsi que celle de la variable sortante consistent ` rechercher la valeur la plus grande ou la plus petite dans un vecteur. a Il est ncessaire de rappeler une partie de larchitecture de CUDA an de e comprendre son fonctionnement. Les tches peuvent communiquer entre elles a uniquement au sein dun mme block. De plus, il est ncessaire dutiliser plue e sieurs blocks an dobtenir de bonnes performances. Il nest donc pas possible deectuer la rduction en un seul kernel. e Il existe deux possibilits pour rsoudre ce probl`me. La premi`re est deece e e e tuer deux passes du kernel, la premi`re passe sur le vecteur initiale et la seconde e sur les n rsultats issus des n blocks. La seconde possibilit est dutiliser le CPU e e pour la seconde passe. Il nest pas forcment ncessaire dutiliser un nombre de blocks tr`s lev pour e e e e e russir ` remplir susamment les pipelines dun device. De ce fait, la seconde e a passe se fait gnralement sur un nombre faible de valeurs. Utiliser un kernel e e pour si peu de valeurs ne serait pas ecient. Il est alors plus intressant de faire e la seconde passe sur le CPU dautant plus si le rsultat est ncessaire sur ce e e dernier pour une dcision. e

Figure 4.1 Performance dune rduction : CPU vs GPU e

35

Les mesures de temps ncessaires ` une recherche de maximum sont repre a e sentes dans la gure 4.1. Cette gure dmontre que les gains peuvent tre e e e importants lorsque le vecteur dpasse une certaine taille (environ 20000 vae riables). Les probl`mes ` traiter natteindront pas toujours des tailles de cet e a ordre de grandeur. Les mthodes ecaces de recherche de variables seront nanmoins plus come e plexes quune simple recherche de la valeur maximum ou minimum. Plusieurs oprations seront ncessaires avant cela. Cette mesure dcrit donc le pire cas e e e possible.

4.3.3

Pivotage

Lopration de pivotage sur GPU est une opration de la librairie CUBLAS, e e plus prcisment lopration cublasDger. Cette opration est compare ` lope e e e e a e ration quivalente sur CPU en langage C, disponible dans la librairie CBLAS. e

Figure 4.2 Performance dun pivotage : CPU vs GPU La gure 4.2 reprsente le temps ncessaire ` cette opration pour des tailles e e a e de matrices variables. La mise ` jour de la matrice sur GPU ore de bons gains a par rapport ` son quivalent CPU. Les gains sont dj` intressants pour des a e ea e matrices de taille modeste. La plus petite taille de matrices testes (1000) est e dj` lg`rement plus rapide sur GPU. ea e e

4.4
4.4.1

Implmentation sur un GPU e


Gnralits e e e

Nous allons voir dans cette section comment le simplexe a t implment ee e e sur un GPU. 36

La mthode implmente est celle du simplexe standard (dcrite ` la section e e e e a 2.4). La mthode du simplexe en deux phases (2.4.4) est utilise. Ceci an de e e dterminer une solution initiale lors de la premi`re phase an de pouvoir rechere e cher la solution optimale lors de la seconde phase. Le langage de programmation C++/CUDA a t utilis pour cela. ee e Limplmentation obtenue est la suite dune multitude damliorations suce e cessives. En eet, la premi`re implmentation tait base sur la mthode dcrite e e e e e e dans le livre crit par V. Chvatal [6]. La structure de lalgorithme est demeure e e la mme que celle dcrite dans ce livre. Cependant les mthodes de choix des e e e variables ne sont pas celles qui y sont dcrites, car ces derni`res ne sont pas e e celles qui am`nent les meilleures performances. e Suite ` cette premi`re version, une tude plus approfondie sur les direntes a e e e heuristiques existantes pour le simplexe a t mene. Un ensemble de ces mee e e thodes a t slectionn et implment de telle sorte ` amliorer la stabilit et les ee e e e e a e e performances de cette algorithme. En parall`le, la structure de donnes utilise e e e pour mmoriser le probl`me a subi des modications visant ` rduire sa taille e e a e et les dirents kernels ont t optimiss pour approcher des performances de e ee e pointe de CUDA. Il serait dicile dexpliquer ` la fois lalgorithme ainsi que ses direntes a e volutions. Nous allons donc prsenter dans cette section la structure de lalgoe e rithme nal et par la suite, dans la section 4.5, nous nous pencherons plus en dtail sur les direntes mthodes utilises ainsi que les raisons ayant motives e e e e e leur utilisation. Avant de dbuter, il est nanmoins intressant de soulever deux points qui e e e ont jou un rle important dans lapproche qui va tre dcrite par la suite. e o e e Le premier point consiste ` minimiser les changes dinformations entre le a e CPU et le GPU. Ces changes de donnes sont en eet lents compars a ceux e e e ` qui se font sur le GPU. La stratgie a donc t de mmoriser la totalit du e ee e e probl`me dans la mmoire du device et de ly laisser jusqu` la n de lalgorithme. e e a Les transferts dinformations sont aussi limits aux variables ncessaires aux e e instructions de dcisions qui sont excutes par le CPU. e e e Le second point ncessite une petite analyse de lalgorithme et de sa paralle e lisation. Il existe deux facteurs prdominants concernant le temps de calcul dun e probl`me : le nombre ditrations ncessaires pour rsoudre un probl`me ainsi e e e e e que le temps dune de ces itrations. Chaque itration est dpendante du rsule e e e tat obtenu dans litration prcdente. Il nest donc pas possible de parallliser e e e e les itrations entre elles. Notre eort va donc tre concentr sur la paralllisation e e e e des direntes oprations formant une itration. e e e

4.4.2

Algorithme principal

Lalgorithme principal, dcrit dans lalgorithme 2, peut tre dcompos en e e e e plusieurs parties bien distinctes. La premi`re est la lecture du probl`me depuis un chier et sa mise sous e e forme normale. Cette tape est troitement lie ` la structure du probl`me en e e e a e mmoire. e Ensuite vient lalgorithme du simplexe en deux phases : la recherche dune solution faisable puis la recherche de la solution optimale. Il est important de direncier ces deux phases, car la mthode choisie pour rsoudre la premi`re e e e e phase ncessite un peu plus de calculs que la seconde phase. e 37

Algorithm 2 Algorithme global Input: f ile {MPS le containing the problem} Output: prob {Data structure containing the resulting solution} 1: prob read problem(f ile) 2: probdev init device(prob) 3: for i = 0 to 2 do 4: if not feasible(probdev ) then 5: solve auxiliary(probdev ) 6: end if 7: solve problem(probdev ) 8: clean problem(probdev ) 9: end for 10: prob get solution(probdev )

Finalement, avant de rcuprer les donnes lies ` la solution trouve, une e e e e a e tape de nettoyage du probl`me est ncessaire. En eet, au l des itrations e e e e certaines variables peuvent se trouver tr`s lg`rement en dehors de leurs bornes, e e e principalement ` cause des erreurs de calcul sur les nombres ottants (voir seca tion 4.5.1 et 4.5.2). Il est alors ncessaire de corriger ces erreurs et de vrier la e e faisabilit et loptimalit de la solution nale. e e Lecture et modlisation du probl`me e e Cette partie est la seule partie compl`tement squentielle de lalgorithme. Le e e standard de chier MPS [3] dcrivant les probl`mes de programmation linaire e e e a t utilis an de garantir une compatibilit avec dautres algorithmes ainsi ee e e que les ensembles de donnes existants. e La lecture du chier seectue en deux tapes de telle sorte ` orir de bonnes e a performances. La premi`re lecture sert ` dterminer le nombre de variables et e a e le nombre dquations formant le probl`me. Durant cette tape la syntaxe du e e e chier est vrie. Une fois cette lecture nie, la structure de donnes contenant e e e le probl`me est cre. e ee Il faut ensuite eectuer la seconde passe qui consiste ` remplir cette structure a de donnes. Les quations sont alors modies an dobtenir un dictionnaire. e e e Pour cela le probl`me est tout dabord mis dans sa forme normale. Les variables e de jeu sont ajoutes et les valeurs des variables sont xes de faon arbitraire e e c an dobtenir une premi`re solution. e Structure de donnes e La structure de donnes a t pense selon plusieurs crit`res. Le premier e ee e e est la taille, pour des questions despace mmoire bien entendu mais aussi pour e minimiser les calculs sur la matrice. En eet, plus cette derni`re est petite plus e les oprations matricielles seront rapides. e Lautre crit`re est lordre dans lequel la matrice est stocke (par colonne ou e e par ligne). Ceci est li ` lutilisation de CUDA. En eet, il est important de e a rappeler que pour obtenir de bonnes performances avec CUDA, il est ncessaire e deectuer des acc`s en mmoire de type conscutif. e e e

38

An de garantir ce type dacc`s lors de la recherche de la variable sortante, e la matrice est mmorise par colonnes. Nanmoins, cette structure ne favorise e e e pas le choix de la variable entrante. Cest pour cela que la fonction objectif a t spare des autres quations et place dans un vecteur. Ainsi, tous les acc`s ee e e e e e sur les coecients se font de mani`re conscutive dans les deux mthodes. e e e

Figure 4.3 Structure de donnes e La structure de donnes dcrite dans la gure 4.3 est compose de la matrice, e e e de taille m n, contenant les quations (zone bleue, g. 4.3). La base nest e cependant pas mmorise dans cette matrice. En eet, les colonnes de la base e e forment la matrice identit, il est donc inutile de la stocker enti`rement. Il sut e e de mmoriser les variables basiques. e Cest pour cela que les variables ont t scindes en deux sous-ensembles : ee e les n variables basiques (zone verte, g. 4.3) et les m variables non-basiques (zone violette, g. 4.3). Chacune des variables xk de ces ensembles dispose de plusieurs informations : sa valeur et son indice k (vecteurs valeurs, indices, g. 4.3) ses bornes uk et lk (vecteurs bornes lo, up, g. 4.3) Il est ncessaire de mmoriser les indices des variables, car elles vont changer e e e leur place au l des itrations (variable entrante variable sortante). e Finalement, la structure de donnes contient la fonction objectif du probl`me e e (zone rouge, g. 4.3). Selon la phase du simplexe, ce sera soit la fonction objectif auxiliaire, soit la fonction du probl`me original. e

39

4.4.3

Recherche dune solution initiale faisable

Cette premi`re phase de lalgorithme est utilise lorsque la solution initiale e e nest pas faisable. Elle peut aussi tre utilise apr`s ltape de nettoyage de la e e e e solution, survenant ` la n dun cycle de rsolution du probl`me (premi`re et a e e e seconde phase), si jamais la solution nale venait ` tre infaisable. La mthode ae e implmente correspond ` la seconde mthode dcrite ` la section 2.4.4. Aucune e e a e e a variable articielle nest ajoute. Le probl`me auxiliaire doit alors possder ces e e e propres bornes pour chaque variable an de rendre la solution faisable. La fonction objectif auxiliaire a pour but de ramener les variables dans leurs bornes initiales. Algorithm 3 Auxiliary problem (1st phase) Input: probdev {Data structure containing the problem on the GPU} Output: f easible, inf easible {Feasibility of the problem} 1: create auxiliaryProblem(probdev ) {GPU} 2: while exists(xin ) do 3: xin nd entering(probdev ) {GPU} 4: xout nd leavingVar(xin , probdev ) {GPU} 5: if not exists(xout ) then 6: return inf easible 7: end if 8: pivoting(xin , xout , probdev ) {GPU} 9: update feasability(probdev ) {GPU} 10: if feasible(probdev ) then 11: return f easible 12: end if 13: end while 14: return inf easible Lalgorithme 3 dbute par la cration du probl`me auxiliaire sur le device. Les e e e bornes propres ` cette premi`re phase doivent tre copies des bornes initiales a e e e pour les variables faisables et ajustes pour celles qui sont infaisables. Cette e tape permet de rendre temporairement la solution faisable. La fonction objectif e est cre en fonction des variables dont les bornes ont t modies lors de ltape ee ee e e prcdente. e e Il est alors possible dexcuter la mthode du simplexe standard sur ce proe e bl`me auxiliaire. Le choix des variables entrante et sortante, ainsi que lopration e e de pivotage, se font sur le GPU sous forme de kernel. Le travail du CPU consiste a ` appeler ces kernels et ` rcuprer les rsultats des mthodes de choix de vaa e e e e riables. Ces rsultats permettent alors au CPU deectuer les dcisions lies ` e e e a lalgorithme. Ensuite, il est ncessaire de vrier quune ou plusieurs des variables ont e e t ramenes dans leurs bornes initiales ` la n dune itration. Cette tape ee e a e e seectue aussi sur le GPU. Dans un premier temps, un kernel vrie lensemble e des variables. Si des variables sont devenues faisables, il est alors ncessaire de les e retirer de la fonction objectif an de ne pas fausser la recherche dune solution faisable. Dans le cas o` la totalit des variables seraient devenues faisables, la premi`re u e e phase se termine. Il est cependant possible que la premi`re phase trouve une e 40

Algorithm 4 Optimum search (2nd phase) Input: probdev {Data structure containing the problem on the GPU} Output: f easible, inf easible {Feasibility of the problem} 1: while exists(xin ) do 2: xin nd entering(pdev ) {GPU} 3: xout nd leavingVar(xin , pdev ) {GPU} 4: if not exists(xout ) then 5: return inf easible 6: end if 7: pivoting(xin , xout , pdev ) {GPU} 8: end while 9: return f easible

solution optimale alors que toutes les variables ne sont pas encore faisables. Dans ce cas, il nexiste pas de solution initiale faisable.

4.4.4

Recherche de la solution optimale

La seconde phase du simplexe dcrite dans lalgorithme 4 est similaire ` e a la premi`re phase. A lexception quil ny a pas besoin de crer le probl`me e e e auxiliaire ainsi que de corriger la fonction objectif. En guise dillustration, le listing 4.1 comprend le code simplif correspondant ` cet algorithme. e a

4.4.5

Communications CPU - GPU

Maintenant que nous connaissons le fonctionnement global de lalgorithme, nous allons nous pencher sur les communications entre le CPU et le GPU. Elles se passent sous la forme de lancement de kernels depuis le CPU ou dchanges e de donnes entre le CPU et le GPU. e Le lancement dun kernel doit se faire depuis le CPU. Les param`tres du e kernel sont passs du CPU au GPU durant son appel. Ces param`tres sont e e gnralement des pointeurs sur des structures de donnes prsentes dans la me e e e e moire globale. Cependant, il est possible que ce soit des constantes prsentes sur e le CPU qui sont alors envoyes sur le GPU durant la mise en place du contexte e du kernel. Les changes de donnes entre le CPU et le GPU sont ncessaires an dace e e cder au probl`me, ce qui se produit lors de son initialisation ainsi que lors de la e e rcupration de la solution nale. Ces changes surviennent aussi ` la n dun e e e a kernel pour rcuprer ses rsultats en mmoire globale e e e e La gure 4.4 reprsente les changes de donnes ayant lieu durant une itrae e e e tion de la seconde phase du simplexe. Pour le choix des variables le programme sur le CPU lance lexcution des e kernels sur le GPU. Il leur fournit les param`tres contenant les pointeurs sur la e structure du probl`me stocks en mmoire globale du GPU. Une fois le calcul e e e termin, le CPU rcup`re les donnes rsultant de la rduction eectue par e e e e e e e chaque block du kernel. Le CPU doit donc lire NBlocks variables depuis la me moire globale du GPU. Ensuite, il doit eectuer la rduction de ces variables. e Un exemple simpli dappel de kernel se trouve dans le listing 4.2. e

41

Listing 4.1 Optimum search


1 .Solver 3 . 5 . 7 .

: : r e s u l t t Solver : : SolveSimplex () { r e d r e s u l t t pColResult ; r o w r e s u l t t expandRowRes ;

// While m a x i t e r n o t r e a c h e d while ( c o u n t e r < MAX ITER) { p C o l R e s u l t = kw>s e F i n d C o l ( p ) ;

9 . 11 . 13 .

// I f t h e r e i s a p o t e n t i a l column i f ( p C o l R e s u l t . i n d e x >= 0 ) { // Get t h e p i v o t row expandRowRes = kw>expandFindRow ( p C o l R e s u l t . index , p C o l R e s u l t . v a l u e , deltaK , EXPAND TAU, p ) ; deltaK += EXPAND TAU; i f ( expandRowRes . i n d e x == 1){ return INFEASIBLE ; } e l s e i f ( expandRowRes . mode == M UNBOUNDED) { return UNBOUNDED; } e l s e i f ( expandRowRes . mode == M BASIC TO BOUND) { kw>nonBasicToBound ( p C o l R e s u l t . index , expandRowRes . alpha , expandRowRes . absP , p ) ; nTobound++; } e l s e i f ( expandRowRes . mode == M PIVOT) { kw>updatingBasisWS ( expandRowRes . index , p C o l R e s u l t . index , expandRowRes . alpha , p ) ; kw>pivotingWS ( expandRowRes . index , p C o l R e s u l t . index , p ) ; } c o u n t e r ++; // expand s t a t e , d o e s we need a r e s e t ? i f ( i t e r K == EXPAND K) { iterK = 0; re setExpan d ( ) ; i f ( p>n I n f > 0 ) return GOTO PHASE1; } else { i t e r K ++; } } else { return SUCCESS ; } } return MAX ITER REACHED; }

15 . 17 . 19 . 21 .

23 . 25 .

27 . 29 . 31 . 33 . 35 . 37 . 39 . 41 . 43 .

42

Figure 4.4 Communications CPU - GPU Pour ce qui est de ltape de pivotage, le procd est quelque peu plus come e e plexe. La premi`re partie consiste ` eectuer les dirents swap de mmoire e a e e correspondant au passage de la variable entrante (non-basique) dans la base et de la variable sortante (basique) dans lensemble des variables non-basiques. La variable entrante prend la place de la variable sortante dans notre structure de donnes et vice-versa. Les bornes, les indices, les valeurs sont interverties. e Finalement, le kernel cublasDger est appel an deectuer la mise ` jour de la e a matrice. Dans limplmentation nale, les changes sont plus complexes que la me e e thode dcrite ci-dessus. Le choix de la variable sortante fait appel ` deux ou trois e a kernels, selon la phase, avant de slectionner la variable adquate. Le pivotage e e ncessite une prparation de la matrice cotant quelques critures et lectures e e u e en mmoire globale. La mise ` jour de la fonction objectif se fait sparment e a e e de la matrice dquations. Il est donc ncessaire dappeler une autre fonction de e e CUBLAS pour eectuer cette opration. e Cependant ces dirences nont quune faible importance. Si nous analysons e la quantit de donnes changes, nous pouvons constater que cette derni`re e e e e e est indpendante de la taille du probl`me. Les mthodes de choix des variables e e e ncessitent au maximum lchange NKernels NBlocks variables. NBlocks tant e e e plus petit ou gal ` 64 et NKernels est au maximum gal ` 4 dans notre ime a e a plmentation. Le pivotage requiert un nombre constant dacc`s ` la mmoire e e a e globale portant sur la lecture ou la modication dune seule variable (variable pivot). Pour des probl`mes de grande taille, qui est le cas qui nous intresse partie e culi`rement, nous devrions avoir des temps de communication CPU-GPU nglie e geables compars aux temps dexcution des dirents kernels. e e e

43

Listing 4.2 Kernel call : entering variable research


r e d r e s u l t t KernelWrapper : : pSEValExpandW ( i n t m, i n t n , VAR TYPE obj , f l o a t 2 bounds ) { . red result t gpu result ; g p u r e s u l t . i n d e x = 1; . gpu result . value = 0; // I n i t . o f t h e g r i d and b l o c k s i z e i n t t h r e a d s = (m < MAX THREADS 2 ) ? nextPow2 ( (m + 1 ) / 2 ) : MAX THREADS; i n t b l o c k s = MIN( n , MAX BLOCKS) ; // Kernel c a l l pSEValExpand<b l o c k s ><<< dimGrid , dimBlock , smemSize >>>( b l o c k s , m, n , obj , eqs , p i tc hE q s , x , bounds , r e s u l t ) ; // R e s u l t r e t r i e v i n g cudaMemcpy ( hRes , dRes , b l o c k s s i z e o f ( r e d r e s u l t t ) , cudaMemcpyDeviceToHost ) ; // CPU r e d u c t i o n f o r ( i n t i =0; i <b l o c k s ; i ++) { SET( r e s u l t , MAX ABS R( r e s u l t , hRes [ i ] ) ) ; } return r e s u l t ;
22 . }

2 4

6 .

8 . 10 .

12 . 14 .

16 . 18 . 20 .

44

4.5
4.5.1

Amliorations de limplmentation e e
Dicults rencontres e e

Dans cette section nous allons examiner les dirents probl`mes rencontrs e e e durant limplmentation du simplexe selon le livre de V. Chvatal [6]. e Borne individuelle Le premier probl`me rencontr a t la prise en compte de bornes indivie e ee duelles sur les variable de dcisions. Lalgorithme thorique dcrit dans le chae e e pitre 2 consid`re que les variables de dcisions peuvent prendre nimporte quelle e e valeur entre zro (compris) et linni, soit des valeurs relles positives. Si les e e variables poss`dent des bornes individuelles, il est alors ncessaire dadapter le e e probl`me ou lalgorithme an de prendre en compte ces nouvelles contraintes. e Ce probl`me a dj` t dcrit en partie ` la section 2.4.4. Comme nous e ea ee e a lavions vu dans cette section, la technique visant ` modier le probl`me de a e programmation linaire ne semble pas eciente. En eet, cette modication peut e amener le probl`me ` cro de faon exponentielle. Il convient alors dutiliser e a tre c la seconde technique qui vise ` modier les mthodes de choix de variables an a e de prendre en compte les contraintes individuelles de ces derni`res. e Lors du choix de la variable entrante, qui est quivalent au choix de la direce tion dans la reprsentation gomtrique, il est ncessaire de contrler la totalit e e e e o e des variables pouvant amener une amlioration du rsultat de la fonction objece e tif. Dans le cas o` les variables ne possdaient pas de bornes individuelles, cela u e correspondait ` slectionner les variables dont le coecient tait positif dans la a e e fonction objectif. Avec les bornes individuelles, il est ncessaire de considrer e e toutes les variables dont le coecient est non-nul dans la fonction objectif et dont les bornes permettent un gain sur la variable. Cette modication doit aussi tre applique au choix de la variable sortante. e e En fonction du sens de la direction choisie (signe du coecient de la variable entrante dans la fonction objectif), il est ncessaire dsormais dutiliser la borne e e individuelle limitante de chacune des variables se trouvant dans la base an de dterminer leur contrainte sur le gain apport par la variable entrante. Le calcul e e de la contrainte dpend dsormais de la valeur de la variable basique potentiele e lement sortante xout , du sens de la direction choisie, du signe du coecient de la variable entrante dans lquation o` xout est basique et nalement des bornes e u de xout . Les calculs supplmentaires apports par ces modications ne sont pas trop e e problmatiques. Les dicults amenes par ces derni`res sont lies ` la prise en e e e e e a compte du sens de la direction. Il est donc ncessaire de direncier certaines e e variables en fonction de leur signe an de dterminer la borne ` utiliser. Ce qui e a sous-entend la possibilit dinstructions non synchronises au sein de warps et e e donc de la perte du paralllisme. e Cycles et itrations dgnratives e e e e Un probl`me rcurrent dans la rsolution des probl`mes de programmation e e e e linaire est lapparition de cycles comme nous lavons dj` dcrit dans la section e ea e 2.4.4. Les mthodes dcrites dans cette section fonctionnent correctement, mais e e ne sont gnralement pas tr`s eciente. La mthode du smallest subscript est e e e e 45

simple ` implmenter mais peut mener ` un nombre tr`s important ditrations a e a e e avant de sortir dun cycle, tandis que la mthode de perturbation est eciente e mais ncessite une implmentation robuste ce qui peut savrer complexe. e e e Nous verrons dans la section 4.5.2, une heuristique implmentant certains e principes de la mthode de perturbation an dviter de tomber dans des cycles. e e Instabilits numriques e e Les nombres utiliss dans lalgorithme du simplexe sont des nombres rels. e e Lors de limplmentation, il est alors ncessaire dutiliser des nombres ` vire e a gule ottante. Il est important de rappeler que ces nombres ` virgule ottante a poss`dent une prcision limite en fonction du nombre de bits utiliss pour les e e e e reprsenter. Mme en choisissant des nombres en double prcision (cods sur 64 e e e e bits, 8 octets), des erreurs de calculs font leur apparition. Ces erreurs tant inmes sur une opration arithmtique, sont gnralement e e e e e ngligeables. Cependant dans le cadre du simplexe, les erreurs se propagent e ditration en itration, augmentant ainsi progressivement leur magnitude. e e Le premier probl`me que cela pose, est une perte de prcision sur le rsultat e e e obtenu ` la n du calcul. Cette perte est dpendante du nombre ditrations a e e eectues. Il est donc ncessaire, apr`s un nombre important ditrations, de e e e e reprendre le dictionnaire obtenu du probl`me initial et dy adjoindre la derni`re e e solution trouve, an de repartir sur des bases saines. Cette opration est tr`s e e e coteuse car elle ncessite de recrer la derni`re base obtenue. Cependant, elle est u e e e rarement ncessaire tant donn que le nombre critique ditrations est rarement e e e e atteint. En eet, ce nombre est estim ` environ 100000 itrations ea e Un autre probl`me est li au nombre zro. Lorsquil est sujet ` des erreurs e e e a dues ` limprcision des nombres ` virgule ottante, le nombre zro devient un a e a e nombre inniment petit. Le premier probl`me que cela pose est que les calculs e sur ces nombres tr`s petits sont gnralement beaucoup plus lent que les calculs e e e sur des nombres de taille normale. Le second probl`me est que le nombre zro e e joue un rle important dans la slection des variables. En eet, gnralement o e e e nous recherchons des coecients non-nuls. Il devient alors important de pouvoir dterminer si une petite valeur est un zro ou un coecient de faible valeur. e e Il est alors ncessaire de xer des tolrances sur les comparaisons avec le e e nombre zro. Le choix de ces tolrances est critique. Si elles sont choisies trop e e grandes, elles ne nous permettent pas datteindre ` tous les coups la solution a optimale car certaines variables de faible valeur ne sont pas slectionnes alors e e quelles ne sont pourtant pas gales ` zro. Au contraire, si elles sont choisies trop e a e petites, alors un zro ayant dgnr pourrait tre choisi comme valeur pivot. Un e e e ee e pivotage sur une telle valeur am`nerait ` un dictionnaire erron. Lalgorithme e a e deviendrait alors instable et produirait des rsultats incorrects. e Il est possible de minimiser ce probl`me en utilisant loption de compilation e -ftz=true oerte par le compilateur CUDA. Cette derni`re permet de usher les e nombres extrmement petits, plus communment appel nombres dnormaliss. e e e e e Cette manipulation vite que ces nombres ralentissent nos calculs. Cependant, e elle ne permet pas de garantir que lalgorithme vitera des instabilits nume e e riques car certaines erreurs sont trop grandes pour tre ushes de cette mani`re. e e e

46

4.5.2

Amliorations de lalgorithme du simplexe e

Nous allons dsormais nous intresser aux direntes amliorations apportes e e e e e a lalgorithme thorique vu au chapitre 2. Ces amliorations ont t principale` e e ee ment trouve dans la littrature scientique sur le simplexe. Cette documentae e tion est assez consquente, particuli`rement en ce qui concerne le simplexe rvis. e e e e Ceci na pas facilit limplmentation des mthodes dcrites dans les articles se e e e e lectionns vu quil ntait pas directement adaptable au simplexe standard. e e Structure du probl`me en mmoire e e Premi`rement, la structure du probl`me en mmoire a t pense de telle e e e ee e faon ` garantir des acc`s conscutifs ` la mmoire globale comme nous lavons c a e e a e vu dans la section 4.4.2. Les algorithmes implments pour le choix des variables parcourent la mae e trice par colonnes. La matrice des quations est donc mmorise colonne par e e e colonne plutt que ligne par ligne. Aussi, la fonction objectif a t spare de la o ee e e matrice des quations an de garantir des acc`s conscutifs lors du choix de la e e e variable entrante. Ensuite, lalgorithme a t adapt de telle sorte ` ne ncessiter la mmorisaee e a e e tion daucunes variables supplmentaires aux variables de dcision. Les parties e e de lalgorithme ncessitant une implmentation particuli`re permettant dviter e e e e lajout de variables sont la premi`re phase du simplexe, la gestion des bornes e individuelles et la mmorisation de la base (initialement des variables de jeux). e Etant donn quuniquement les variables de dcision sont mmorises, le e e e e probl`me en mmoire est de taille : e e m n + k (m + n) o` m est le nombre dquations, n le nombre de variables de dcisions et k la u e e taille de la structure lie ` une variable (valeur, indice, bornes). e a Une implmentation moins attentive ` ces dtails aurait pu mener a une e a e ` structure de forte taille. Les variables de jeu et les variables articielles augmentent le nombre de variables de 2m. Tandis que la modication du probl`me e an de prendre en compte les bornes individuelles des variables peut rajouter jusqu` 2n quations dans le pire des cas. Nous pourrions alors avoir une a e structure dont la taille serait proche de : (m + 2n) (n + 2m) + k (3n + 3m) Bien quune telle implmentation ncessite un peu moins de calculs, elle e e ne serait certainement pas plus rapide. Rappelons que le temps de calcul est dpendant de la taille de la matrice. Il est donc important de maintenir cette e derni`re aussi petite que possible. e Normalisation du probl`me initial e An daugmenter la stabilit de lalgorithme, la matrice de base est nore malise de telle sorte ` ce que la valeur des coecients de la matrice soient e a comprises entre -1 et 1. Les quations (lignes) et les variables (colonnes) sont e donc normalises. e Dans le cas de la normalisation des variables (colonnes), il est ncessaire de e mettre ` jour leurs bornes en fonction du facteur de normalisation. A la n de a 47

lalgorithme, il est alors ncessaire deectuer ltape inverse an de leur rendre e e leur vraie valeur. Ces normalisations de la matrice permettent dviter que de grands carts e e subsistes entre les variables. Ce type dcart augmentent les risques de ne pas e atteindre la solution optimale ` cause de la perte de prcision due aux nombres a e ottants. Cette normalisation permet aussi de rduire les risques dinstabilit e e qui pourrait survenir suite ` la slection dun zro dgnr pour coecient a e e e e ee pivot. Choix de la variable entrante Il existe de nombreuses mthodes an de choisir la variable entrante. Le e nombre ditrations ncessaires ` lalgorithme an de rsoudre un probl`me de e a e e e pend enti`rement de ce choix. Il convient alors de choisir une mthode orant e e une rduction importante du nombre ditrations ainsi que des possibilits de e e e paralllisation. e Il existe deux axes de recherche pour les heuristiques visant ` eectuer cette a opration. Le premier axe vise ` rduire le temps de calcul de cette derni`re en e a e e utilisant des recherches partielles [14]. Ces techniques ne rduisent que sensiblee ment le nombre ditrations et sont dicilement paralllisables. e e Le second axe englobe les mthodes qui tentent de rduire le nombre dite e e rations ncessaires ` lalgorithme. A la base, il existe deux mthodes direntes. e a e e La premi`re est de considrer toutes les possibilits de pivots et de slectionner e e e e celui qui ore le meilleur gain. Cette mthode, bien que la meilleure thoriquee e ment, nest quasiment jamais implmente tant donn la quantit de calculs e e e e e ncessaires. En eet, cela revient ` appliquer la recherche de la variable sortante e a en considrant toutes les variables non-basiques comme variable entrante. e La seconde mthode sappelle steepest edge (bord le plus abrupte) [15]. Cette e mthode choisit la variable qui ore le plus grand gain de la fonction objectif e par unit de mouvement le long du bord de notre polytope. Les calculs quelle e ncessite sont importants. Il est ncessaire de calculer la norme euclidienne de e e toutes les colonnes correspondant ` une variable entrante potentielle. Ensuite la a pente peut tre calcule, e e cj cl = min sel = j 1..n (4.1) m l 1+ x2
i=1 ij

o` cl est le coecient de la variable dans la fonction objectif et l la colonne u de la variable xl . Cette mthode, malgr son cot lev, est souvent utilise, e e u e e e car elle ore une rduction importante du nombre ditrations. De plus, elle se e e prte bien ` une paralllisation sur GPU tant donn quil sagit deectuer un e a e e e calcul consquent sur la majorit des colonnes suivi de la recherche du meilleur e e rsultat. e Il existe plusieurs mthodes, principalement conue pour le simplexe rvis, e c e e base sur la mthode steepest edge qui orent des rductions ditrations proches e e e e de celle-ci en utilisant des estimations de la norme euclidienne an de rduire le e temps de calcul (approximate steepest edge, DEVEX [12]). Ces mthodes orent e un bon compromis entre les deux, mais ne sont pas aisment paralllisables. De e e plus la rduction du nombre ditrations est moindre que celle rsultant de e e e lapplication du steepest edge. 48

La mthode standard, une mthode partielle ainsi que le steepest edge ont e e t implmentes et compares. De ces trois mthodes, la version paralllise ee e e e e e e du steepest edge a oert les meilleures performances (voir section 6.4.4). Malgr e lajout considrable de calculs que demande cette mthode, elle sest avre plus e e ee rapide que les deux autres. Le fait que le nombre ditrations soit rduit est non e e seulement intressant du point de vue des performances mais aussi de celui de e la stabilit. En eet, si le nombre ditrations est rduit alors la propagation des e e e erreurs darrondi est moindre. Choix de la variable sortante Le choix de la variable sortante est cruciale quant ` la stabilit de lalgoa e rithme. Elle ne laisse cependant pas beaucoup de choix en ce qui concerne son implmentation. Il est en eet ncessaire de choisir la variable la plus contraie e gnante an de ne pas rendre des variables basiques infaisables. Nanmoins, le e choix du coecient pivot, qui se trouve ` lintersection de la variable sortante a et entrante dans la matrice dquations, est dune grande importance. En eet, e dans les cas o` le choix se porte sur plusieurs variables sortantes, il est alors imu portant de choisir le pivot le plus grand an de minimiser le risque dinstabilit e numrique. e De plus la recherche de la variable sortante permet dutiliser la mthode de e perturbation (voir section 2.4.4) qui sert ` viter de tomber dans des cycles. a e La procdure propose par E. Gill et al. [13] ore une mthode de choix de la e e e variable sortante permettant dviter les cycles. De plus, cette mthode prend en e e compte la valeur du coecient pivot dans la mesure du possible an damliorer e la stabilit de lalgorithme. e Cette procdure sappelle EXPAND pour EXPanding-tolerance ANti-Degene eracy procedure. Le principe est de tolrer un cart inme sur la faisabilit de e e e notre solution. A chaque itration, cette tolrance sur la faisabilit est lg`rement e e e e e augmente. Cette modication du probl`me permet de garantir qu` chaque e e a itration la valeur de la fonction objectif volue positivement. Si cette derni`re e e e ne stagne pas, alors il nest pas possible de tomber dans un cycle, car ceux-ci surviennent lorsque les itrations sont dgnres. e e e ee Le choix de la variable sortante se fait en deux passes, voire trois pour la premi`re phase du simplexe. Lors de la premi`re passe, les bornes individuelles e e des variables sont largies, ` litration k, dune valeur k . Cette valeur est e a e strictement croissante au l des itrations, k1 < k < k+1 . Ensuite, le gain e maximal sur la variable entrante, max , que permet la variable basique la plus contraignante est dtermin. e e La seconde passe utilise les bornes non-largies an de dterminer la variable e e sortante. Cette derni`re est la variable basique, possdant un gain j plus petit e e ou gal ` max et qui prsente le coecient pivot le plus grand parmi ceux e a e possibles. Lors de la premi`re phase du simplexe, une passe spciale vient se glisser e e entre les deux prcdemment cites. Cette derni`re va essayer de trouver une e e e e variable basique infaisable qui pourrait rentrer dans ses bornes initiales et donc devenir faisable. Cette variable doit garantir un gain j sur la variable entrante plus petit que max comme lors de la seconde passe. Si une variable basique infaisable correspond au crit`re prcdent et est rendue faisable par ce pivotage, e e e alors cette derni`re est slectionne comme variable sortante. Si aucune variable e e e 49

ne correspond ` ce crit`re, la seconde passe est applique. a e e Bien que la tolrance sur la faisabilit du probl`me soit tr`s faible, il est e e e e tout de mme ncessaire deectuer une rinitialisation de cette derni`re ` deux e e e e a occasions. La premi`re est apr`s un nombre consquent ditrations. Ceci est e e e e ncessaire an de ne pas trop modier le probl`me. Le but est uniquement de e e perturber lg`rement ce dernier. e e La seconde occasion survient lorsquon a trouv une solution infaisable ou e optimale. Il est alors ncessaire de rinitialiser la tolrance, an de garantir que la e e e solution est toujours infaisable ou optimale apr`s que les bornes aient retrouv e e leur valeur initiale. A lissue de cette opration, la mthode du simplexe est e e relance sur le probl`me rinitialis. Il est videment ncessaire de xer une e e e e e e limite au nombre de fois que cette opration est applique. e e La rinitialisation consiste ` ramener les variables qui sont en dehors de leurs e a bornes initiales ` lintrieur de celle-ci, si cette opration est juge triviale. Cette a e e e derni`re est dtermine comme telle si la variable se trouve en de` dune cere e e ca taine valeur, xe au pralable, de sa borne la plus proche. Si ce nest pas le cas, e e la variable est alors considre comme tant infaisable. Quand ce cas survient ee e lors de la seconde phase de lalgorithme du simplexe, il est alors ncessaire de e retourner ` la premi`re phase an de rendre cette variable faisable ` nouveau. a e a

4.5.3

Optimisations des kernel

Loptimisation de kernels est dpendante de trois facteurs, comme nous e lavons vu dans le chapitre 3. Le premier est de maximiser loccupation des multiprocesseurs an de tirer un prot maximal des direntes units de calculs. e e Ensuite, il est important de cacher la latence des oprations lentes telles que la e lecture en fournissant assez de tches an de remplir les pipelines. Finalement, a il est ncessaire de garantir un acc`s correct aux donnes. e e e Nos kernels ont t optimiss an de garantir de bonnes performances. Nous ee e allons voir un exemple pour le cas du kernel choisissant la variable entrante selon la mthode du steepest edge. e Ce kernel va eectuer un calcul consquent. Il est ncessaire pour un certain e e pourcentage des colonnes (celles dont la variable peut tre lue) de calculer la e e norme euclidienne. Tous les coecients de la colonne doivent tre mis au carr e e puis somms. Chaque colonne est traite dans un block : premi`rement chaque e e e tche calcule une somme partielle, puis une rduction a lieu pour sommer les a e rsultats locaux. e Si on se base sur les observations faites prcdemment et selon la documene e tation de NVIDIA [1], il est crucial dutiliser un nombre important de tches a par block et de garantir une occupation maximale pour cacher la latence. Cependant, comme le soul`ve V. Volkov [17], ceci nest pas forcment optimal. En e e eet, rappelons que les registres sont partags par les tches dun block. Plus il y e a a de tches dans un block, moins elles disposent de registres pour eectuer leurs a calculs. De plus les tches sont forces dutiliser une partie de leurs registres pour a e mmoriser les param`tres, leur identiant et dautres informations. Ce qui fait e e que le ratio de registres utilisables pour les calculs diminue proportionnellement au nombre de tches par block. a Lastuce va consister ` forcer une tche ` utiliser plus de registres. Ceci dia a a minuera lg`rement loccupation, cest-`-dire quun multiprocesseur disposera e e a

50

de moins de warps dans le pipeline pour cacher la latence. Nanmoins, les pere formances sont meilleures dans ce cas. Les tches disposent de plus de registres a utiles et peuvent donc mieux cacher la latence en lanant plusieurs instructions c de lecture successives. En rsum, selon NVIDIA, lobjectif est de viser une occupation de 100% e e ainsi que de fournir un nombre important de tches pour remplir les pipelines et a obtenir de bonnes performances. Cependant, ceci se fait au dpend du nombre de e registres utiles par tche. Pour viter cela, V.Volkov propose de crer un pipeline a e e implicite dans le code du kernel en eectuant plusieurs lectures successives. Ceci requiert dutiliser plus de registres par tche au dpend de loccupation. a e Nous allons comparer les performances de deux kernels dirents : le premier, e SE1, est bas sur les observations de V. Volkov et va donc utiliser plus de e registres par tche que le second, SE2, qui suit les directives de NVIDIA en a maximisant loccupation du kernel. Commenons par le kernel SE2, dont le pseudo-code se trouve dans le lisc ting 4.3. Ce kernel lit premi`rement un coecient depuis la mmoire globale. e e Cette variable est rfrence par le tableau eqs[...] et stocke dans la variable ee e e coe. Une fois lue, cette derni`re est mise au carr puis somme. La tche lance e e e a une instruction de lecture, passe dans le pipeline en attente que la lecture soit eectue et nalement fait le calcul. Et ainsi de suite. e Listing 4.3 Kernel 2 : latency not hidden
2 . 4 . 6 .

[...] while ( i < m) { c o e f f = e q s [ INDEX( i , j ) ] ; mySum += c o e f f c o e f f ; i ++; } [...]

Dans le code simpli du kernel SE1 dcrit par le listing 4.4, on peut remare e quer que la tche utilise plusieurs registres pour lire les donnes successivement. a e En eet, les instructions de lecture ne sont pas bloquantes. De ce fait, ce kernel va mettre quatre instructions de lectures concurrentes ce qui permet de cacher e implicitement la latence. Listing 4.4 Kernel 1 : latency hidden
1 . 3 . 5 . 7 . 9 . 11 . 13 .

[...] while ( i +3 < m) { coeff1 = coeff2 = coeff3 = coeff4 = mySum += mySum += mySum += mySum += i +=4; } [...]

e q s [ INDEX( i , j ) ] ; e q s [ INDEX( i +1 , j ) ] ; e q s [ INDEX( i +2 , j ) ] ; e q s [ INDEX( i +3 , j ) ] ; coeff1 coeff1 ; coeff2 coeff2 ; coeff3 coeff3 ; coeff4 coeff4 ;

51

La gure 4.5 dmontre la bande passante utilise par les kernels en fonction e e de la taille du probl`me. Les performances du kernel SE1 en terme de bande e passante sont meilleures ce qui conrme la thorie de V. Volkov. Cette simple e modication ore un gain de bande passante de plus de 10% pour quasi toutes les tailles de matrices. Il est possible dapporter plusieurs amliorations de ce e type ` un kernel an datteindre au plus vite les performances de pointes dun a device.

Figure 4.5 Optimisation du kernel steepest edge

52

4.6
4.6.1

Implmentation multi-GPU e
Introduction

A partir de limplmentation sur un GPU que nous venons de dcrire, nous e e allons tudier et raliser limplmentation du simplexe sur plusieurs GPUs. Ceci e e e ncessite dans un premier temps de sparer la structure du probl`me en me e e e moire en plusieurs sous-structures permettant de parallliser le calcul tout en e minimisant les communications entre les dirents GPUs. e Nous verrons ensuite comment les GPUs font pour communiquer. Ces derniers ne pouvant pas directement interagir entre eux, il est ncessaire dutiliser e les CPUs pour faire le relais. Finalement, nous verrons quelles sont les modications ` apporter ` notre a a implmentation sur un GPU du point de vue algorithmique. e

4.6.2

Dcoupe du probl`me e e

La mthode du simplexe standard se prte volontiers ` la paralllisation. e e a e Les direntes tapes, le choix des variables ainsi que le pivotage, peuvent tre e e e faites sur des ensembles partiels de la matrice sans probl`me. Il est nanmoins e e ncessaire pour certaines de ces tapes de rduire les rsultats locaux avant e e e e dobtenir le rsultat nal. e An de dterminer sur quelle partie du probl`me chaque GPU va travailler, il e e est ncessaire dtudier les alternatives de dcoupes du probl`me. Ces dcoupes e e e e e poss`dent chacune leurs avantages et inconvnients. En eet, il est possible de e e dcouper le probl`me de mani`re ` assurer une bonne scalabilit au dpend du e e e a e e nombre de communications ncessaires par exemple. Inversement, il est possible e de viser une dcoupe vitant de nombreux changes de messages mais dont les e e e performances ne seront garanties que pour un nombre restreint de GPUs. Le choix de la dcoupe devient alors dpendant de lenvironnement sur lequel e e lalgorithme va tre paralllis. Les clusters de GPUs, ` lexception de quelques e e e a rares cas, disposent de quelques dizaines de GPUs (ordre de grandeur 20 ` 50). a Dans notre cas, nous disposons dune NVIDIA tesla S1070 qui est compose de e quatre GPUs. Nous allons chercher une dcoupe du probl`me orant de bonnes e e performances pour un nombre limit dunits de calcul. e e Il est aussi intressant de remarquer que gnralement les probl`mes de proe e e e grammation linaire disposent dun nombre plus lev de variables que dquae e e e tions : soit n >> m. Cependant, si la tendance tait inverse, il serait possible e dutiliser la dualit des probl`mes de programmation linaire an dobtenir une e e e matrice correspondant ` nos attentes (voir Linear Programming [6]). a Selon la dcoupe envisage, la taille et la forme de la matrice aura une grande e e inuence sur la quantit de donnes ` changer. Cest pour cela que certaines e e ae dcoupes ne favorisent pas un nombre tr`s lev de GPUs. En eet, celle-ci e e e e ncessite une quantit de communications qui demeure constante malgr lajout e e e de GPUs. Nous allons voir plus en dtail dans les sections suivantes comment e ces dirents crit`res inuent sur les dirents types de dcoupe. e e e e Dcoupe horizontale e La premi`re dcoupe du probl`me est une approche horizontale. Nous allons e e e donc sparer le probl`me en sous-ensembles dquations comme dcrit dans la e e e e 53

gure 4.6. Du point de vue des variables et de leurs informations respectives : les variables basiques sont distribues alors que les variables non-basiques doivent e tre copies sur chaque GPU. Il en est de mme pour la fonction objectif. e e e

Figure 4.6 Dcoupe horizontale e Pour la recherche de la variable entrante, il est ncessaire dappliquer la e mthode du steepest edge qui doit eectuer la norme des colonnes dont la variable e est ligible pour tre entrante. Avec cette dcoupe, chaque GPU doit calculer e e e une somme local pour chaque variable quil doit par la suite communiquer aux autres GPUs. Chaque GPU doit donc communiquer n informations an que le choix de la variable entrante puisse tre fait. e La recherche de la variable sortante ncessite que chaque GPU fasse une e rduction locale pour chaque tape de la mthode expand. A la suite de chacune e e e de ces rductions locales, il faut calculer le rsultat nal ` partir du rsultat e e a e local de chaque GPU. Il est donc ncessaire davoir autant de synchronisation e quil y a dtapes ` expand, soit deux ou trois selon la phase. Chaque GPU ne e a communique quune variable ` la suite de sa rduction locale. a e Il est nanmoins important de souligner que le nombre de donnes utilises e e e lors de la recherche de la variable sortante est relativement faible, uniquement m variables sont vries. Sur un seul GPU, il faudrait dj` que m soit tr`s grand e e ea e an datteindre de bonnes performances. Le fait de parallliser cette mthode e e najoute donc pas grand chose en terme de performances. An deectuer le pivotage, chaque GPU doit possder la colonne ainsi que e la ligne du coecient pivot. Avec cette dcoupe, il est donc ncessaire que le e e GPU qui dispose de la variable sortante communique aux autres la ligne pivot

54

ainsi que les informations concernant la variable sortante. Ces informations sont ncessaires an deectuer le swap entre la variable entrante et la variable sore tante. Il faut donc communiquer environ m donnes an de prparer le pivotage. e e Une fois les donnes partages, chaque GPU peut eectuer le pivotage de faon e e c indpendante. e Dcoupe verticale e La dcoupe verticale dcrite dans la gure 4.7 est semblable ` lhorizone e a tale dans lapproche. Nous allons donc sparer les coecients de la matrice e dquations en plusieurs sous-ensembles de variables. Les variables non-basiques e et leurs informations seront partages, tandis que les variables basiques seront e copies dans chaque GPU. Dans cette dcoupe, la fonction objectif est partage. e e e

Figure 4.7 Dcoupe verticale e Pour la recherche de la variable entrante, chaque GPU peut eectuer la mthode du steepest edge localement et slectionner une variable. Il est alors e e ncessaire par la suite deectuer une rduction de ces rsultats locaux an e e e dobtenir la variable entrante nale. Il est donc ncessaire pour chaque GPU de e communiquer une seule variable ` la n de son calcul local. a La recherche de la variable sortante ne va seectuer que sur un seul GPU. En eet, cette recherche ne ncessite que les variables basiques ainsi que la colonne e de la variable entrante. Cette derni`re ntant pas partage, seul un GPU peut e e e eectuer la slection de cette variable. Nanmoins, comme nous lavons fait e e remarquer dans la dcoupe horizontale, chaque tape de la mthode expand e e e

55

consiste ` faire une rduction sur m variables. An de tirer prot de plusieurs a e GPUs m devrait tre tr`s grand. e e Finalement, la prparation du pivotage ncessite que le GPU, o` la variable e e u entrante se situe, communique les informations de cette derni`re ainsi que sa e colonne aux autres GPUs. Apr`s quoi chaque GPU peut eectuer le pivotage e de faon indpendante. Cette tape ncessite quun GPU communique approxic e e e mativement n informations aux autres. Dcoupe mixte (tuiles) e Cette dcoupe est un peu plus complexe que les deux prcdentes. Le but e e e est ici de dcomposer la matrice des quations en k l tuiles comme le dcrit la e e e gure 4.8. Chaque GPU va disposer dune sous-matrice ainsi que des variables qui lui sont associes, soit un sous-ensemble des variables basiques et un souse ensemble des variables non-basiques. La fonction objectif est dcoupe de la e e mme mani`re que les quations de la matrice. e e e

Figure 4.8 Dcoupe en tuiles e Cette dcoupe est en quelque sorte un mlange des deux dcoupes que nous e e e avons vu prcdemment. Il est donc ncessaire de copier plusieurs fois chaque e e e sous-ensemble de variables ainsi que chaque partie de la fonction objectif. En ce qui concerne les mthodes du simplexe, il faudra appliquer les communications e ncessaires aux deux autres dcoupes. e e Pour la recherche de la variable entrante, chaque GPU va appliquer la me thode steepest edge localement. Suite ` quoi, les GPUs, dont la sous-matrice a

56

appartient ` une colonne de tuiles, participent ` une seconde rduction ncesa a e e e e a e sitant lenvoi de n variables. Cette tape est quivalente ` celle de la dcoupe l horizontale. Finalement, la rduction nale est eectue sur le rsultat de ltape e e e e prcdente. Cette tape correspond ` celle de la dcoupe verticale : chaque GPU e e e a e devra communiquer une variable an deectuer la rduction. e La recherche de la variable sortante va seectuer sur les k GPUs contenant la colonne de la variable entrante. Pour chaque tape de la mthode expand, les e e GPUs en question vont eectuer une recherche locale avant de communiquer leur rsultat an de dterminer le rsultat nal. Cette tape correspond enti`rement e e e e e a ` celle de la dcoupe horizontale. e Finalement, la prparation du pivotage ncessite deux envois de coecients. e e Le premier est lenvoi de la colonne de la variable entrante. Les k GPUs la posse dant doivent communiquer les coecients aux autres GPUs possdant le mme e e sous-ensemble de variables basiques. En rsum, la colonne pivot est diuse e e e horizontalement du point de vue des tuiles. Il en va de mme concernant les e coecients de la ligne de la variable sortante. Les l GPUs possdant ces coee cients doivent les communiquer aux GPUs possdant le mme sous-ensemble de e e variables non-basiques. Ce qui correspond ` une diusion verticale de la ligne a pivot. Analyse et choix Nous allons maintenant analyser les avantages et les inconvnients des die e rentes dcoupes vues prcdemment. e e e Premi`rement, une analyse globale permet de distinguer les mthodes de de e e coupes horizontale et verticale, de la dcoupe en tuiles. Les deux premi`res de e e coupes sont intressantes pour un nombre restreint de GPUs. En eet, la matrice e tant dcoupe selon un axe uniquement, les sous-matrices deviendraient fortee e e ment oblongue pour un nombre important de GPUs et les donnes redondantes e prendraient un espace considrable par rapport ` la taille de la sous-matrice ` e a a traiter. Par contre, la dcoupe en tuiles ore une bonne scalabilit. Les matrices e e gardent une proportion semblable ` la matrice initiale. a Nous allons donc dans en premier temps comparer les deux mthodes de e dcoupes sur un axe an de dterminer si une des deux se prte mieux ` notre e e e a algorithme. Rappelons que les probl`mes disposent gnralement de plus de e e e variables que dquations (m << n). e Le choix de la variable entrante ncessite moins de communications dans le e cas de la dcoupe verticale. Cette derni`re ncessite que chaque GPU commue e e nique un rsultat alors que la dcoupe horizontale en ncessite n. e e e Le choix de la variable sortante est uniquement paralllis dans le cas de e e la dcoupe horizontale. Cependant, comme nous lavons vu, la mthode expand e e nest eectue que sur m variables. Ce nombre de donnes est relativement faible e e et donc ne ncessite pas de paralllisation, ` moins davoir un probl`me de tr`s e e a e e grande taille. Lajout de synchronisation et dchanges de donnes lis ` une e e e a paralllisation pourrait rendre cette opration plus longue que dans le cas dune e e excution sur un seul GPU. e La prparation du pivotage ncessite dans les deux cas lchange dune ligne, e e e respectivement colonne de la matrice. Etant donn la structure habituelle des e probl`mes, la dcoupe verticale est lg`rement gagnante tant donn que le e e e e e e

57

nombre de variables ` communiquer est cens tre moindre que pour la dcoupe a ee e horizontale. La dcoupe verticale semble plus adapte que la dcoupe horizontale du point e e e de vue de la paralllisation des direntes mthodes. De plus, la structure des e e e probl`mes se prte mieux ` une dcoupe de ce type. e e a e Maintenant que nous avons dtermin quelle mthode est plus adapte entre e e e e la verticale et lhorizontale, revenons ` la dcoupe en tuile. Cette derni`re dispose a e e dune partie des inconvnients de la dcoupe horizontale. En eet, le choix de e e la variable sortante est aussi paralllis et le nombre de communications semble e e plus important que dans le cas de la dcoupe verticale. Cependant, pour des e probl`mes de tr`s grande taille, ncessitant un nombre consquent de GPUs, e e e e ces inconvnients tendent ` seacer. e a Il en ressort que la dcoupe verticale est adapte ` un nombre restreint de e e a GPUs tandis que la dcoupe en tuile est plus scalable et pourrait tirer prot e dun nombre plus consquent de GPUs. Etant donn que nous disposons unie e quement de quatre GPUs, nous allons parallliser notre algorithme en utilisant e une dcoupe verticale. e

4.6.3

Architecture et communication multi-GPU

Les GPUs ne pouvant pas communiquer entre eux, il est ncessaire dutiliser e les CPUs pour tablir la communication ainsi que pour synchroniser les GPUs. e Chaque device doit tre dirig par une tche CPU dirente. Il est donc ncese e a e e saire dtablir un degr de paralllisme supplmentaire par le biais des CPUs. e e e e Pour ce faire, nous disposons de deux possibilits : MPI ou POSIX. MPI e (message passing interface) est un standard de communication pour les applications parall`le alors que POSIX (portable operating system interface) est une e standardisation des API de bases fournies par un syst`me dexploitation. MPI e ore une mthode de communication simple et robuste, ce qui est fort appre e ci dans le cas dun rseau de communication complexe. Cependant, le choix e e de dcoupe que nous avons fait ` ltape prcdente est bas sur un nombre e a e e e e rduit de GPUs. Nous allons continuer dans cette direction en choisissant dutie liser POSIX. Ce choix ore un contrle plus n sur la technique dchange de o e messages. Dans notre cas, les dirents GPUs sont grs par un syst`me CPU multie ee e cur (voir section 6.4.2). Ces processeurs disposent donc de la mme mmoire e e CPU globale qui leur permettra de communiquer entre eux. Etant donn que e POSIX fournit les primitives ncessaires ` la synchronisation de tches (bare a a ri`res) ainsi qu` la gestion de sections critiques (smaphores), nous disposons e a e donc de la totalit des outils quil nous faut. e La technique de communication que nous allons mettre en place consiste ` a crer une zone de mmoire partage entre les tches CPUs an quelles puissent e e e a y changer les donnes ncessaires aux direntes tapes de notre algorithme. e e e e e An dviter les conits sur cette mmoire, les processeurs disposent chacun e e dune zone de mmoire en criture. Les lectures sont alors synchronises ` laide e e e a de barri`res. e

58

4.6.4

Algorithme

Le but de cette section est de sintresser principalement aux modications e induites par limplmentation multi-GPU. e Initialisation Lalgorithme 5 dcrit la phase dinitialisation de lalgorithme multi-GPU. La e tche CPU principale lit le probl`me dans un premier temps, tout comme dans a e limplmentation sur un GPU. Par la suite, elle cre la structure de donnes e e e qui sera partage entre les dirents CPUs an de permettre la communication e e par la suite. Les direntes tches CPU sont alors cres, comme dcrit dans le e a ee e listing 4.5. Ces derni`res reoivent le pointeur sur le probl`me complet ainsi que e c e sur la zone de mmoire partage. e e Algorithm 5 Multi-GPUs : Initialisation des tches a Input: f ile {MPS le containing the problem} 1: prob read problem(f ile) 2: shared init shared(prob) 3: for id = 1 to nGP U do 4: init GPU(id, prob, share) 5: end for

Algorithme principal Lalgorithme 6 dcrit le cur de lalgorithme que chaque GPU doit eectuer. e Chaque tche ddie ` un GPU doit dterminer le sous-probl`me sur lequel il a e e a e e va travailler. Le device est alors initialis et ce sous-probl`me est charg dans la e e e mmoire globale du GPU. La suite de cet algorithme est sensiblement la mme e e que dans limplmentation sur un GPU. La seule exception est la mthode pere e mettant de dtecter linfaisabilit du probl`me. Cette derni`re ncessite une cole e e e e laboration des dirents GPUs car les variables non-basiques sont partages sur e e ceux-ci. Cette tape se fait dabord localement sur chaque GPU et les rsultats e e locaux sont ensuite partags dans la zone mmoire ddie aux changes. e e e e e Algorithm 6 Multi-GPUs : Algorithme principal Input: id {GPU Id} Input: prob {Data structure containing the problem (CPU)} 1: problocal init problem(id, prob) 2: localP robdev init device(problocal ) 3: for i = 0 to 2 do 4: if not feasible(localP robdev ) then 5: solve auxiliary(localP robdev ) 6: end if 7: solve problem(localP robdev ) 8: reset problem(localP robdev ) 9: end for 10: problocal get solution(localP robdev )

59

Listing 4.5 Task initialisation


1 . void 3 . 5 . 7 . 9 . 11 . 13 .

MultiGPU : : s o l v e ( b o o l maximize , b o o l debug ) { c p u s e t t cpusetp ; c p u s e t p = CPU ALLOC( 1 0 2 4 ) ; i f ( ! maximize ) p>changeToMinimize ( ) ;

15 . 17 . 19 . 21 . 23 .

s o l v e r s = new S o l v e r [mGPU. nbGPU ] ; f o r ( i n t i =0; i < mGPU. nbGPU ; i ++){ s o l v e r s [ i ] = S o l v e r ( maximize , p , & mGPU) ; s o l v e r s [ i ] . s o l v e ( i , debug ) ; CPU ZERO( c p u s e t p ) ; CPU SET( i +2 , c p u s e t p ) ; p t h r e a d s e t a f f i n i t y n p ( s o l v e r s [ i ] . getPThread ( ) , s i z e o f ( c p u s e t t ) , cpusetp ) ; } f o r ( i n t i =0; i < mGPU. nbGPU ; i ++){ p t h r e a d j o i n ( s o l v e r s [ i ] . getPThread ( ) , NULL) ; } CPU FREE( c p u s e t p ) ; delete [ ] } solvers ;

60

Premi`re phase : recherche dune solution faisable e Si ncessaire, la premi`re phase du simplexe (dcrite dans lalgorithme 7) est e e e applique an de dterminer si une solution faisable existe. Chaque tche cre e e a e son probl`me auxiliaire local. Cette tape ne ncessite pas de communications e e e entre les direntes tches CPU. e a Ensuite, comme le dcrit le listing 4.6, il est ncessaire de dterminer locae e e lement quelle est la variable potentiellement entrante. Cette variable est place e dans la mmoire partage. Apr`s une synchronisation, chaque tche CPU va e e e a lire une mme variable entrante parmi les direntes variables proposes dans e e e e la mmoire partage. e e La tche ayant propos la variable entrante va alors dterminer la variable a e e sortante. Si cette derni`re existe, la tche va alors la placer en mmoire partage e a e e ainsi que les informations ncessaires au pivotage des autres sous-probl`mes. e e Ces informations comprennent la colonne pivot ainsi que les informations de la variable entrante. Les informations de celle-ci sont ncessaires tant donn e e e quelle va devenir basique et que lensemble des variables basiques nest pas partag mais copi dans chaque GPU. e e Apr`s la synchronisation chaque GPU peut alors eectuer son pivotage ` e a laide des donnes derni`rement places en mmoire partage. e e e e e Finalement, chaque tche met ` jour la faisabilit de son sous-probl`me et va a e e e rie sil est devenu faisable suite ` cette mise ` jour. Le rsultat de cette derni`re a a e e tape est alors partag dans lemplacement ddi. Les tches se synchronisent e e e e a et vrient alors la faisabilit globale du probl`me auxiliaire. e e e Seconde phase : recherche de loptimum La recherche de loptimum fonctionne de la mme faon que la premi`re e c e phase. La seule dirence, comme on peut le constater dans lalgorithme 8, est e quil ny a pas besoin de crer le probl`me auxiliaire ainsi que de vrier la e e e faisabilit. e

61

Algorithm 7 Multi-GPU : Auxiliary problem (1st phase) Input: localP robdev {Data structure containing the local problem (GPU)} Input: shared {Shared data structure used for communication (CPU)} Output: f easible, inf easible {Feasibility of the problem} 1: create auxiliaryProblem(localP robdev ) {GPU} 2: while exists(xin ) do 3: // xin 4: localXin nd localEntering(localP robdev ) {GPU} 5: share in(shared, localXin ) {msg size : 1} 6: synchronize() 7: xin nd globalEntering(shared) 8: // xout 9: if localXin == xin ) then 10: xout nd leavingVar(xin , localP robdev ) {GPU} 11: if not exists(xout ) then 12: return inf easible 13: end if 14: share out(shared, xout ) {msg size : 1} 15: share pivoting(shared, column, variable) {msg size : m + 1} 16: end if 17: synchronize() 18: // pivoting 19: init pivoting(shared) 20: pivoting(xin , xout , localP robdev ) {GPU} 21: // feasability check 22: localF eas update feasability(localP robdev ) {GPU} 23: share feas(shared, localF eas) {msg size : 1} 24: synchronize() 25: if feasible(shared) then 26: return f easible 27: end if 28: end while 29: return inf easible

62

Listing 4.6 Multi-GPU communication : entering variable search


2 . 4 . 6 . 8 . 10 . 12 . 14 . 16 . 18 . 20 . 22 . 24 . 26 .

r e d r e s u l t t S o l v e r : : f i n d C o l ( i n t &colDev ) { r e d r e s u l t t myCol ; r e d r e s u l t t resCol ; // Get t h e p i v o t column myCol = kw . s e F i n d C o l (&lP ) ; // Put r e s u l t i n s h a r e d CPU memory SET(mGPU >exSE [ d e v i c e ] , myCol ) ; // Synchro b a r r i e r p t h r e a d b a r r i e r w a i t (&mGPU >b a r r i e r ) ; colDev = 1; r e s C o l . i n d e x = 1; resCol . value = 0 . 0 ; // R e d u c t i o n f o r ( i n t i =0; i < mGPU >nbGPU ; i ++){ i f ( f a b s ( r e s C o l . v a l u e ) < f a b s (mGPU >exSE [ i ] . v a l u e ) ) { r e s C o l . i n d e x = mGPU >exSE [ i ] . i n d e x ; r e s C o l . v a l u e = mGPU >exSE [ i ] . v a l u e ; colDev = i ; } } return r e s C o l ; }

63

Algorithm 8 Multi-GPU : Optimum search (2nd phase) Input: localP robdev {Data structure containing the local problem (GPU)} Input: shared {Shared data structure used for communication (CPU)} Output: f easible, inf easible {Feasibility of the problem} 1: while exists(xin ) do 2: // xin 3: localXin nd localEntering(localPdev ) {GPU} 4: share in(shared, localXin ) {msg size : 1} 5: synchronize() 6: xin nd globalEntering(shared) 7: // xout 8: if isLocal(xin ) then 9: xout nd leavingVar(xin , localPdev ) {GPU} 10: if not exists(xout ) then 11: return inf easible 12: end if 13: share out(shared, xout ) {msg size : 1} 14: share pivoting(shared, column, variable) {msg size : m + 1} 15: end if 16: synchronize() 17: // pivoting 18: init pivoting(shared) 19: pivoting(xin , xout , localPdev ) {GPU} 20: end while 21: return f easible

64

Chapitre 5

Mod`les de performance e
5.1 Introduction

Dans ce chapitre, nous allons tudier les performances thoriques des die e e rentes implmentations vues au chapitre prcdent. Pour cela des mod`les de e e e e performances vont tre tablis pour chacune des implmentations. Ces mod`les e e e e mathmatiques ont pour but de simuler le comportement dune implmentation. e e Ceci est fort utile lors de la paralllisation dun algorithme car il est ainsi pose sible destimer les gains apports par lajout dunits de calcul supplmentaires, e e e ou encore danalyser la scalabilit de limplmentation en question. e e Dans un premier temps, nous allons nous intresser ` la modlisation dun e a e kernel. Linteraction avec les kernels se dcompose gnralement en deux phases. e e e Une phase dchange entre le CPU et le GPU an de placer ou rcuprer les e e e donnes et une phase de calcul parall`le sur le device. e e Ensuite, nous tablirons les mod`les des direntes oprations prsentes dans e e e e e limplmentation du simplexe sur un GPU. An de garantir un mod`le compre e e hensible, nous allons nous baser sur la seconde phase du simplexe. Les oprations e dans cette phase sont le choix des variables ainsi que le pivotage. Une fois que les dirents mod`les seront dnis, nous pourrons alors tablir le mod`le global e e e e e de lalgorithme. Finalement, nous allons dcrire le mod`le de limplmentation multi-GPU. e e e Pour ce faire, les mod`les de limplmentation sur un GPU seront rcuprs et e e e ee adapts en fonction de la dcoupe verticale du probl`me vue en section 4.6.2. e e e

5.2
5.2.1

Particularit li ` CUDA e ea
Echanges de donnes CPU-GPU e

Une implmentation GPGPU est base sur une interaction entre un CPU et e e un GPU. Le CPU eectue les dcisions lis ` lalgorithme et ordonne lexcution e e a e des calculs parall`les sur le GPU. An deectuer les dcisions, le CPU doit e e lire dans la mmoire globale du GPU les informations rsultant des calculs e e pralablement excuts. Il lui est aussi ncessaire de fournir dans cette mme e e e e e mmoire les informations ncessaires ` lexcution des kernels. e e a e Les GPUs communiquent avec les CPUs par des bus PCI (8x ou 16x pour les

65

tesla S1070 ). Ces changes sont relativement lents compars aux autres oprae e e tions dacc`s aux donnes dun GPU. En eet, la bande passante maximale pour e e un GPU de type tesla S1070 lors dacc`s ` sa mmoire globale est de lordre de e a e 100GB/s. Alors que la bande passante maximal dun bus PCI 8x est de 2GB/s (respectivement 4GB/s pour un bus PCI 16x). De ce fait, il sera ncessaire dtre particuli`rement attentif ` ce type dchanges e e e a e de donnes dans les mod`les de performance. e e

5.2.2

Modliser un Kernel e

Gnralits e e e Comme nous lavons prcdemment vu dans le chapitre 3, larchitecture e e CUDA est relativement complexe. Chaque kernel est dcompos en plusieurs e e blocks sexcutant en parall`le sur dirents multiprocesseurs. Il est important e e e de prendre correctement en compte ces dirents niveaux de paralllisme ainsi e e que les pipelines qui leur sont ddis. e e Il est cependant dicile dtablir un mod`le comprenant lensemble des sube e tilits de larchitecture CUDA. Un tel mod`le serait trop complexe et donc e e incomprhensible. Nous allons nous baser sur lapproche dcrite par K. Kishore e e et al. [7] qui tablit un mod`le comprhensible. De plus, leur mod`le obtient des e e e e rsultats proches des performances relles. e e Niveaux de paralllisme e Un kernel peut tre dcompos en une phase dinitialisation suivie dune e e e phase de calcul. La phase dinitialisation est assez rapide. Elle consiste ` mettre a en place le contexte dexcution du kernel. Cette derni`re tant constante et tr`s e e e e rapide, il nest pas intressant de linclure dans notre mod`le. e e La phase de calcul est plus complexe et son temps dexcution dpend du e e travail ` eectuer. Elle sera donc au cur de notre mod`le. Le paralllisme dun a e e kernel se situe ` plusieurs niveaux. a Le premier niveau consiste en la dcomposition du travail total en souse parties, les blocks. Ces derniers sont alors rpartis sur les dirents multiproe e cesseurs. Le temps dexcution dun kernel est donc li au nombre de blocks e e NB par multiprocesseur (Symetric Multiprocessor, SM ), ainsi que du nombre de ceux-ci par GPU, NSM . Le second niveau consiste ` partager le travail dun block sur les dirents a e curs du multiprocesseur. Pour ce faire, un block est dcompos en groupe de e e tches, les warps. Un warp contient plusieurs sous-groupes de tches qui sont a a excuts en parall`le sur les curs du multiprocesseur. Le temps dexcution e e e e dun block est donc dpendant du nombre de warp par block Nw , du nombre de e tches par warp Nt ainsi que du nombre de curs par multiprocesseur NC . a Le troisi`me et dernier niveau de paralllisme est un pipeline. Ce pipeline e e permet une excution pseudo-parall`le de chaque sous-groupe de tches se troue e a vant dans un warp. Le gain apport par ce pipeline est exprim par sa profondeur e e D.

66

Travail fourni par une tche a Maintenant que nous avons vu les dirents niveaux de paralllisme, il est e e ncessaire de dterminer le travail quune tche doit fournir. Ce travail dpend e e a e du nombre et du type dinstructions que la tche doit eectuer. Chaque instruca tion cote un nombre de cycles dirent comme nous lavons vu dans la section u e 3.3.4. Par exemple, une addition de nombres ottants (simple prcision) cote e u 4 cycles alors quune division cote environ 36 cycles. u Ensuite, il est ncessaire de direncier les instructions dacc`s ` la mmoire e e e a e globale des instructions arithmtiques. En eet, les instructions dacc`s ` la e e a mmoire globale cotent 4 cycles initialement auxquels sont ajouts entre 400 e u e et 600 cycles de latence avant que les donnes soient disponibles. Durant cette e latence, des instructions arithmtiques (indpendantes des donnes qui sont en e e e attente dacc`s) peuvent tre excutes an de cacher cette derni`re. e e e e e Lordonnanceur semploie ` cacher la latence des acc`s mmoire autant que a e e possible. Une partie est dj` cache par le pipeline de tches dans un warp. ea e a Lordonnanceur eectue ensuite des rotations de warps an de ne pas gaspiller de temps lorsque les tches sont bloques sur des donnes qui sont en attente a e e dacc`s. e Il existe ensuite deux possibilits pour estimer le travail total dune tche. La e a premi`re consiste ` considrer que la structure du code des kernels ne permet e a e pas aux instructions arithmtiques dtre caches par la latence dacc`s ` la e e e e a mmoire. Dans ce cas, il est ncessaire deectuer la somme des deux types e e dinstructions (arithmtique et acc`s ` la mmoire). La seconde possibilit est e e a e e la situation inverse. En admettant que les instructions arithmtiques se trouvent e tre caches par la latence dacc`s aux donnes, il faut alors considrer le travail e e e e e total comme tant le maximum des deux types dinstructions. Ceci car ces deux e types dinstructions se font en parall`le. e Le choix de la variante approprie est dicile ` dterminer. Il dpend de e a e e nombreux facteurs dont la dpendance entre les deux types dinstructions, mais e aussi lecacit des pipelines. Cette derni`re est dautant plus dicile ` estimer e e a tant donn quelle dpend de la stratgie mis en place par lordonnanceur. e e e e Le nombre de cycles pour une tche CT peut alors tre dni comme la a e e somme, respectivement le maximum, des instructions dacc`s ` la mmoire et e a e des instructions arithmtiques. De plus, nous allons prendre la tche ncessitant e a e le plus de calculs parmi lensemble des tches du kernel an dtablir le worst a e case scenario. Mod`le de performance global e An dtablir le mod`le de performance global pour un kernel, il est ne e e cessaire dtablir le travail quun SM (Streaming Multiprocessor ) doit eectuer. e En eet, chaque SM dispose du mme nombre de blocks ` traiter, et donc ils e a devraient tous terminer en mme temps leur excution. e e Le travail dun cur Ccore peut sexprimer, en cycles, par : Ccore = NB Nw Nt CT 1 NC D (5.1)

soit, le produit entre le nombre de blocks par SM NB , le nombre de warps par block Nw , le nombre de tches par warp Nt et le nombre de cycles par tche a a 67

CT . Le tout divis par le nombre de curs par SM NC et par la profondeur D e du pipeline existant lors du traitement dun warp. Finalement, le temps pour un kernel TK dpend de la frquence F dun e e cur : Ccore TK = (5.2) F

5.3
5.3.1

Simplexe sur un GPU


Recherche de la variable entrante : steepest edge

La premi`re opration consquente de lalgorithme 4 (section 4.4.4) consiste e e e a ` trouver la variable entrante. Cette opration est principalement excute dans e e e un kernel mis ` part la phase nale qui se fait sur le CPU. a La mthode du steepest edge consiste ` trouver la variable donc le ratio sej e a est le plus petit. Rappelons que ce ratio se calcule de la mani`re suivante : e sej = cj j
2

+1

j 1..n

(5.3)

o` cj est le coecient de la variable dans la fonction objectif et j la colonne u de la matrice correspondant ` la variable non-basique xj . Toutes les variables a non-basiques ne sont pas ligibles pour entrer dans la base. Certaines se trouvent e dj` ` leur valeur optimale. Ce calcul doit donc uniquement se faire sur un ratio eaa des colonnes. Le kernel divise cette tche en allouant ` chaque block un sous-ensemble de a a colonnes a calculer. Dans limplmentation, le nombre de blocks est dni en e e fonction du nombre de colonnes ` traiter, jusqu` un maximum denviron deux a a blocks par SM. Cependant an de simplier le mod`le, le nombre de blocks par e SM sera toujours de deux, NB = 2. Un block calcule une colonne ` la fois. Pour ce faire, chaque tche du block a a doit calculer une partie de la norme j 2 . Une fois que chaque tche a calcul a e sa norme locale, lensemble de celles-ci collaborent an de rduire leur somme e partielle en une somme globale. La somme nale se trouve sur la tche 0, cette a derni`re calcule sej et le mmorise si cest le plus petit rsultat trouv jusqu` e e e e a prsent. e Le nombre dlment est donc le suivant : ee Nel = m NT askP erBlock (5.4)

Nel lments doivent tre calculs avant deectuer la rduction. Cette derni`re ee e e e e ncessite NRed = log2(NT askP erBlock ) tapes pour sommer les normes partielles. e e Dans le pire des cas une tche doit lire Nel valeurs depuis la mmoire globale a e ainsi que le coecient cj , soit : Cmem = (Nel + 1) Cload Nw (5.5)

o` Cload quivaut ` la latence dune lecture. Nw intervient dans le dnominateur u e a e an de modliser la rotation des warps mise en place par lordonnanceur an de e cacher la latence.

68

Cette tche doit ensuite multiplier et sommer chacune des valeurs, eectuer a la rduction, diviser cj par le rsultat de la rduction et contrler si le rsultat e e e o e obtenu est le meilleur jusqu` prsent. Soit : a e Ccalc = Nel (Cadd + Cmul ) + NRed Cadd + Cdiv + Ccmp o` Cins est le nombre de cycles que prend linstruction ins. u Le nombre de colonnes par block est dni par : e Ncol = n NB NSM (5.7) (5.6)

Un block doit donc traiter Ncol colonnes et mmoriser le rsultat obtenu ` la e e a n. Le nombre nal de cycles par tche est exprim par : a e CT = max(Ncol Cmem + Cstore , Ncol Ccalc ) (5.8)

ou par la somme de ces deux termes selon le type de modlisation utilis. Il ne e e nous reste plus qu` appliquer les formules 5.1 et 5.2 pour obtenir le temps pour a ce kernel. Au temps du kernel TKse , il est encore ncessaire dajouter le temps TCPUse e de lecture des rsultats depuis le CPU ainsi que de la recherche sur ces dere niers. Le nombre de rsultats ` lire est gal au nombre total de blocks, NBtot = e a e NB NSM . Soit, TCPUse = NBtot (BPP CI + CcmpCP U ) FCP U (5.9)

o` BPP CI est la bande passante de la connexion PCI entre le GPU et le u CPU. Cependant, lorsque m et n sont grand, NBtot qui est constant devient nglie geable par rapport ` ceux-ci. Il en est de mme pour TCPUse car le temps de a e calcul du kernel est nettement plus long que cette opration. e

5.3.2

Recherche de la variable sortante : expand

La seconde opration de lalgorithme 4 (section 4.4.4) est la recherche de la e variable sortante. Ce choix ncessite nettement moins de calculs que les deux e autres oprations. En eet, cette derni`re est de complexit O(m) alors que la e e e recherche de la variable entrante et le pivotage sont de complexit O(mn). Nous e allons tout de mme tablir son mod`le tant donn quil nous sera utile pour e e e e e le mod`le de limplmentation multi-GPU. e e Le choix de la variable sortante se fait par la mthode expand. Cette mthode e e consiste ` eectuer deux (ou trois pour la phase 1) passes sur la colonne de la a variable sortante. Chaque passe consiste ` calculer pour chaque quation la a e contrainte de gain sur la variable entrante. Ceci consiste, grossi`rement, ` lire e a plusieurs valeurs de la mmoire globale ainsi qu` calculer la contrainte. Quelques e a additions et une division sont ncessaires pour cela. Il faut nalement rduire le e e rsultat local de chaque tche en un rsultat nal. e a e Le schma de partage des donnes ressemble en partie au kernel prcdent. e e e e Nous avons deux blocks maximum par SM, soit NB = 2. Le nombre total de

69

blocks est donc NBtot = NB NSM . Ce qui fait que le nombre dlments par ee block est le suivant : m Nel = (5.10) NT askP erBlock NBtot Le nombre dtapes ncessaires ` la rduction est le mme que dans le kernel e e a e e prcdent, soit NRed = log2(NT askP erBlock ). e e Chaque tche doit lire pour chaque variable lui tant attribue (Nel ) : la a e e valeur de la variable, ses bornes et le coecient pivot potentiel. Les oprations e dacc`s ` la mmoire ntant pas bloquantes, il est ncessaire dattendre une fois e a e e e le temps de latence dun acc`s. Une fois la meilleure valeur tablie pour le block, e e apr`s la rduction, la tche 0 doit mmoriser le rsultat. La latence est rduite e e a e e e par la rotation de warps gre par lordonnanceur, soit : ee Cmem = (Nel Cload + Cstore ) Nw (5.11)

La tche doit dnir pour chacune de ses Nel variables la contrainte que a e celles-ci imposent au gain de la variable entrante. Ensuite, les tche doivent a cooprer pour dnir la variable la plus contraignante. Soit le nombre dinstruce e tions suivant : Ccalc = Nel (2 (Cadd + Ccmp ) + Cdiv ) + NRed Ccmp Et donc le nombre de cycles pour une tche est le suivant, a CT = max(Ccalc , Cmem ) (5.13) (5.12)

An dobtenir TKexp , il sut une fois de plus dappliquer les quations 5.1 e et 5.2. Etant donn que le nombre de blocks est le mme que dans le kernel e e prcdent, il nest pas non plus ncessaire de dnir le temps pris par le CPU e e e e TCPUexp . En eet, d`s que m devient grand NBtot devient ngligeable. e e

5.3.3

Mise ` jour de la matrice : pivotage a

La troisi`me et derni`re opration de lalgorithme 4 (section 4.4.4) est le pie e e votage. An deectuer cette opration, il faut tout dabord changer la variable e e basique et la variable non-basique. Ensuite, le CPU doit accder ` quelques done a nes du GPU an de prparer la mise ` jour de la matrice. Celle-ci consiste ` e e a a eectuer la multiplication matricielle dun vecteur de taille m par un vecteur de taille n et de sommer la matrice rsultante de taille n m ` notre matrice e a dquations. e Les quelques swap sur le GPU et changes de donnes entre le CPU et le GPU e e sont constants, faibles et indpendants de m et n. Ils sont donc ngligeables dans e e le mod`le. Par contre lopration de mise ` jour est de complexit O(mn). Un e e a e kernel disponible dans la librairie CUBLAS permet deectuer cette opration e de mani`re optimise. e e Les codes source de cette librairie ne sont pas facilement disponibles. Nous allons donc estimer le fonctionnement de ce kernel. Pour ce faire, nous allons modliser le cas optimal o` tous les acc`s aux donnes se font sans collisions et e u e e o` la latence est masque de faon optimale. u e c Le travail dune tche va tre de lire trois valeurs : un coecient pour chaque a e vecteur, soit vi et wj . Le coecient correspondant dans la matrice dquations e 70

aij sera aussi rcupr. Ensuite, les deux coecients des vecteurs vont tre e ee e multiplis et le rsultat sera somm au coecient, soit rij = aij + vi wj . Le e e e rsultat rij doit nalement tre crit dans la mmoire globale. e e e e An de cacher au mieux la latence des lectures et critures, il est ncessaire e e de fournir autant dlments ` calculer que possible ` une tche. En eet, nous ee a a a pouvons proter du fait que les instructions de lecture et criture ne sont pas e bloquantes. Cependant, la prochaine instruction ncessitant la donne en cours e e dacc`s lest. Ce qui fait que si une tche traite un seul lment de la matrice, il e a ee y aura deux latences ` attendre : celle de la lecture des informations et celle de a lcriture, soit : e 2 Cload (5.14) Cmem = Nw Tandis que si une tche traite une multitude dlments, disons k lments, a ee ee ` alors la tche va eectuer k itrations contenant les lectures et lcriture. A a e e chaque itration, mis ` part la derni`re, les lectures de litration i se feront e a e e juste apr`s lcriture de litration i 1 cachant ainsi la latence de lcriture. e e e e Nous avons donc k1 itrations ncessitant dattendre une fois la latence vu que e e les lectures et lcriture sont couples. Pour la derni`re itration, il est ncessaire e e e e e dattendre deux fois la latence vu que les oprations ne peuvent tre couples. e e e Soit : (k + 1) Cload Cmem = (5.15) Nw Lorsque k >> 1, nous avons environ k latences pour k itrations, soit une seule e latence par lment ` traiter. ee a Nous allons utiliser la mme technique de rpartition des donnes que dans e e e les cas prcdents, soit NB = 2 et NBtot = NB NSM . Ce qui nous am`ne au e e e nombre suivant dlments ` traiter par tche : ee a a Nel = mn NT askP erBlock NBtot (5.16)

Le nombre de cycles ncessaires pour accder aux donnes est exprim par e e e e lquation 5.15 avec k = Nel . An deectuer le calcul, il est ncessaire deece e tuer un produit et une addition par lment ` traiter, soit : ee a Ccalc = Nel (Cadd + Cmul ) Le nombre total de cycles pour une tche est alors le suivant : a CT = max (Nel + 1) Cload , Ccalc Nw (5.18) (5.17)

Finalement, an dobtenir TKpivo , il est ncessaire dappliquer les quations e e 5.1 et 5.2. Comme nous lavons mentionn pralablement, TCPUpivo est nglie e e geable.

5.3.4

Mod`le de performance gnral e e e

Les direntes oprations de lalgorithme 4 (section 4.4.4) sont dsormais e e e dnies. Il ne nous reste plus qua eectuer la somme des temps pour chaque e kernel an dobtenir une estimation du temps que prendrait une itration. Soit : e Titeration = TKse + TKexp + TKpivo 71 (5.19)

Le mod`le pour la rsolution dun probl`me ncessite une initialisation du e e e e GPU et de sa mmoire, suivi de plusieurs itrations et nalement de la lecture e e de la solution, soit : Tprob = Tinit + r Titeration + Tsolution (5.20)

La complexit de Tinit est de lordre de O(mn) car il est ncessaire de lire e e toutes les donnes depuis un chier, puis de les placer dans la mmoire globale e e ` du GPU. A cela vient sajouter un temps dinitialisation du device. La lecture de la solution consiste ` lire la valeur des n variables de dcision. a e Etant donn sa faible complexit, O(n), Tsolution est ngligeable compar ` e e e e a Tinit et Titeration . Le nombre ditrations r est dicile ` dterminer. Il dpend de la mthode e a e e e de choix de la variable entrante, de la complexit du probl`me et de sa taille. e e V. Chvatal [6] cite nanmoins des tudes sur le nombre ditrations ncessaires e e e e pour rsoudre un probl`me. Ces dirents travaux tablissent que la croissance e e e e du nombre ditrations est proportionnelle ` celle de m. Limpact dune auge a mentation de n pour un m xe serait proportionnel ` log(n). La phase de calcul a r Titeration serait donc de complexit O(n log(n) m2 ). e Tinit est alors ngligeable par rapport ` la phase de calcul lorsque m est e a grand. Cependant, lorsque m est petit, limpact de linitialisation est important a ` cause du temps de prparation dun device qui prend entre 0.2[s] et 0.4[s]. e Le temps pris pour linitialisation sera estim ` Tinit = 0.3[s] tant donn ea e e que pour de petits m et n la lecture du probl`me est ngligeable par rapport e e au temps dinitialisation du device. Pour de grands n et m, le temps de calcul r Titeration est alors nettement plus important que le temps de la lecture du probl`me ce qui nous permet une fois de plus de le ngliger. e e

5.4
5.4.1

Simplexe multi-GPU
Gnralits e e e

Le principe de cette section est de reprendre le mod`le vu dans la section e prcdente et de ladapter ` la dcoupe du probl`me dcrite dans la section e e a e e e 4.6.2. La dcoupe nous permet dutiliser les mmes kernels que dans limplmentae e e tion sur un GPU. Leur mod`le de performance ne sera donc pas modi, seul le e e nombre de donnes ` traiter va varier en fonction du nombre de GPUs, NGP U . e a Vu que nous avons choisi dappliquer une dcoupe verticale du probl`me, un e e n sous-probl`me sera de taille msp nsp o` msp = m et nsp = NGP U . e u Pour dterminer les dirences propres ` limplmentation sur plusieurs e e a e GPUs, nous allons nous baser sur lalgorithme 8. Premi`rement, nous pouvons e observer que dans cet algorithme tous les GPUs ne font pas exactement le mme e travail. An de modliser cela correctement, le travail le plus consquent de e e chaque tape sera modlis. e e e Ensuite, ` chaque kernel de lalgorithme que nous avons modlis prcdema e e e e ment vient sajouter une phase de synchronisation et dchange de donnes entre e e CPUs et entre CPU-GPU. Il est ncessaire de modliser ces phases car dans la e e majorit des cas leur complexit dpend de la taille du probl`me ou du nombre e e e e de GPUs. 72

Les changes de donnes eectus par les CPUs vont tre modliss selon la e e e e e e bande passante des dirents bus utiliss par le CPU. Lorsque le CPU accdera e e e aux donnes du GPU, la bande passante sera celle du bus PCI. Tandis que e lorsquil modiera la mmoire partage entre les CPUs, la bande passante du e e bus de la RAM (Random Access Memory) sera utilise. e Ces direntes modlisations vont tre le sujet des prochaines sections. e e e

5.4.2

Recherche de la variable entrante : steepest-edge

Cette tape est compose du temps TKse que nous savons dj` calculer ainsi e e ea que du temps de synchronisation TSse , soit : Tse = TKse + TSse (5.21)

Le temps de synchronisation et dchange de donnes TSse dpend pour e e e cette phase du nombre de GPUs, NGP U . En eet, chaque GPU va tablir le e rsultat local pour la mthode steepest edge et placer la meilleure valeur obe e tenue en mmoire partage. Apr`s la synchronisation, chaque GPU va lire les e e e NGP U donnes et dnir quelle est la variable entrante. Cette rduction se fait e e e localement sur chaque GPU tant donn que le nombre de GPUs est faible. e e Le temps de synchronisation ainsi que celui dcriture dune variable en me e moire partage sont constants et a priori faibles. Il nest donc pas ncessaire de e e les inclure dans le mod`le. Par contre les temps de lecture et de rduction locale e e sont importants ` incorporer dans le mod`le, car ils sont dpendants de NGP U . a e e Soit, N2 sizedouble TSse = GP U (5.22) BPRAM Le nombre de GPU est au carr, car la bande passante de la RAM est e partage par les dirents CPUs devant rcuprer ces donnes. e e e e e

5.4.3

Recherche de la variable sortante : expand

La recherche de la variable sortante tait ngligeable dans le cas de limple e e mentation sur un GPU, comme nous lavons vu. Cependant, il est dsormais e important de prendre en compte cette opration. Plus le nombre de GPUs sera e important, plus cette mthode sera longue compare aux autres tant donn que e e e e sa complexit est O(m). De plus, la phase de synchronisation et dchanges de e e messages ncessitent que le GPU, qui dtermine la variable sortante, partage la e e colonne pivot avec les autres GPUs. Le temps le plus long est dni par celui du GPU qui va eectuer la mthode e e expand, soit : Texp = TKexp + TSexp (5.23) Le calcul de TKexp est dj` dni dans la section prcdente. Il ne reste plus ea e e e qu` dnir TSexp . Ce dernier consiste dans un premier temps ` la lecture de a e a la colonne pivot se trouvant sur le GPU, depuis le CPU, ainsi que les informations lies ` la variable sortante. Ces informations sont nanmoins ngligeables e a e e car elles sont constantes et de petites tailles. Une fois que la colonne pivot est rcupre, elle doit tre place en mmoire partage. An de signaler que son e ee e e e e travail est termin, le CPU eectuera ensuite ltape de synchronisation (que e e nous pouvons ngliger), soit : e 73

TSExp = msp sizedouble

1 1 + BPP CI BPRAM

(5.24)

5.4.4

Mise ` jour de la matrice : pivotage a

La mise ` jour de la matrice consiste ` prparer la matrice pour le pivotage a a e avant de leectuer. Le kernel de pivotage est le mme que dans limplmentae e tion sur un GPU. Il est donc uniquement ncessaire de dterminer le temps de e e synchronisation et dchange de donnes TSpivo et de lajouter, soit : e e Tpivo = TKpivo + TSpivo (5.25)

Avant deectuer le pivotage, les GPUs ne possdant pas encore la colonne e pivot doivent la lire depuis la mmoire partage et la charger dans la mmoire e e e globale du GPU, soit : TSpivo = msp sizedouble 1 (NGP U 1) + BPRAM BPP CI (5.26)

Le nombre de GPUs, NGP U appara dans cette quation car tous ces dert e niers, sauf celui qui a dtermin la variable sortante, font un acc`s ` la mmoire e e e a e partage. Il est alors ncessaire de faire le rapport entre la bande passante de la e e RAM et le nombre de tches CPU y accdant. a e

5.4.5

Mod`le de performance gnral e e e

Le mod`le de performance gnral est semblable ` celui de limplmentation e e e a e sur un GPU. Le temps dexcution dune itration quivaut ` la somme du e e e a temps pris par chaque opration, soit : e Titeration = Tse + Texp + Tpivo (5.27)

Le temps pour rsoudre un probl`me demeure le mme que celui que nous e e e avons dni au pralable dans lquation 5.20. e e e

5.5
5.5.1

Application du mod`le : mesures thoriques e e


Gnralits e e e

An dobtenir des graphes simulant le temps que prendront nos implmene tations, il est ncessaire de dterminer les valeurs lies au matriel utilis (voir e e e e e section 6.4.2) ainsi quaux kernels. Pour les caractristiques des GPUs, le manuel e de rfrence de CUDA [1] dtaille toutes les informations lies ` un GPU. Les ee e e a bandes passantes des bus PCI et RAM sont dnies par leur standard respectif e en fonction de la version de ces derniers. Les kernels dvelopps pour nos implmentations ont un nombre de tches e e e a par block x ` 128. Le ratio de variables non-basiques ligibles pour le choix de ea e la variable entrante est x arbitrairement ` 80%, soit = 0.8. Le ratio sera e a cependant x de mani`re empirique par la suite (section 6.5.2). e e

74

5.5.2

Temps par itration e

Dans un premier temps, nous allons modliser le temps dexcution pour une e e itration sur un GPU an de comparer le travail de chaque kernel. e

Figure 5.1 Mod`le : temps dexcution pour une itration sur un GPU e e e La gure 5.1 contient le temps par itration de chaque kernel ainsi que le e temps total pour une itration. Les kernels prenant le plus de temps sont ceux e eectuant le pivotage ainsi que la recherche de la variable entrante. Comme nous lavions prvu lors de la modlisation, le kernel expand prend un temps e e ngligeable compar ` celui des deux autres. e ea

5.5.3

Temps pour rsoudre un probl`me e e

Nous allons dsormais nous intresser ` la modlisation du temps ncessaire e e a e e a ` un ou plusieurs GPUs pour rsoudre un probl`me entier. Le nombre de GPUs e e a t choisi an de dmontrer lutilisation dune, deux ou quatre tesla s1070, ee e chaque tesla tant compose de quatre GPUs. e e Le gain en performance dcrit par la gure 5.2 semble tre proportionnel au e e nombre de GPUs ce qui laisse prsager un assez bon speedup pour des probl`mes e e de taille considrable. Lallure des courbes obtenues correspond relativement e bien ` la complexit thorique de lalgorithme O(log(n)nm2 ) dnie ` la section a e e e a 5.3.4.

75

Figure 5.2 Mod`le : temps dexcution pour un probl`me sur plusieurs GPUs e e e

5.5.4

Speedup

An de mieux analyser le gain en performance relatif au nombre de GPUs utiliss, nous allons reprendre les modlisations prcdemment tablies pour e e e e e modliser la courbe de speedup thorique de notre implmentation. e e e La mesure du speedup (gure 5.3) conrme que le choix de la dcoupe vertie cale du probl`me convient bien ` un nombre limit dunits de calcul. En eet, e a e e au-del` dun certain seuil lajout de GPUs ` tendance ` rduire le gain. Sur des a a a e petits probl`mes les gains sont faibles. Cependant d`s que leur taille devient e e consquente, le speedup thorique est presque optimal jusqu` une trentaine de e e a GPUs. Ce qui correspond ` la taille moyenne dun cluster de GPGPU. a

76

Figure 5.3 Mod`le : speedup thorique e e

77

Chapitre 6

Mesures
6.1 Introduction

Nous allons maintenant nous intresser ` la performance relle de nos imple a e e mentations. Il va tre ncessaire de mesurer ces performances selon plusieurs crit`res. e e e Le premier est le bon fonctionnement de limplmentation. En eet, certains e probl`mes de programmation linaire peuvent savrer complexe ` rsoudre ` e e e a e a cause des cycles et de la prcision de calcul limite sur les nombres ottants. e e Il est donc important de garantir que limplmentation de lalgorithme et des e direntes mthodes sont robustes. e e Le second crit`re est le gain apport par la paralllisation de lalgorithme. e e e Pour cela, il va tre ncessaire de trouver une implmentation squentielle et e e e e performante an de lutiliser comme rfrence pour la comparaison. Direntes ee e implmentations vont tre passes en revue et le fonctionnement de celle choisie e e e sera bri`vement tudi. e e e Une fois que ces dirents crit`res seront mesurs, il sera possible danalyser e e e les rsultats obtenus. Pour ce faire, les performances thoriques dtermines dans e e e e le chapitre 5 seront compares ` celles caractrises par les mesures obtenues au e a e e cours de chapitre. Nous tcherons de dterminer pour quel type de probl`mes a e e nos implmentations fonctionnent le mieux. e

6.2

Implmentation de rfrence e ee

Il existe de nombreuses implmentations du simplexe. La majorit de ces e e implmentations sont bases sur lalgorithme du simplexe rvis. e e e e Parmi ces derni`res, on peut compter CPLEX et MINOS qui sont des ime plmentations commerciales. CPLEX est le produit dIBM et montre de tr`s e e bonnes performances. Il existe aussi plusieurs implmentations libres qui approchent des perfore mances des deux prcdemment cites. GLPK (GNU Linear Programming Kit) e e e est une librairie qui fait partie du projet GNU et est base sur une partie du e langage AMPL (un langage de modlisation pour probl`mes mathmatiques). Il e e e e y a aussi LP SOLVE qui est une implmentation aboutie et qui dispose de nombreuses fonctionnalits. Ces deux solvers orent aussi la possibilit de rsoudre e e e 78

des probl`mes mixte entier-rel. e e Limplmentation choisie comme rfrence est CLP (COIN-OR Linear Proe ee gramming). Elle fait partie du projet COIN-OR (COmputational INfrastructure for Operations Research). Ce projet a pour mission dorir ` la communaut a e open source des logiciels lis ` la recherche oprationnel. CLP est limplmene a e e tation open source approchant au mieux des performances des implmentations e commerciales cites prcdemment. e e e CLP est bas sur lalgorithme du simplexe rvis. An de tirer un prot maxie e e mal de la densit faible en coecients non-nuls des probl`mes de programmation e e linaire, il utilise des structures de donnes ne mmorisant que les coecients e e e non-nuls du probl`me. e

6.3
6.3.1

Mesures de fonctionnement
Objectif

Avant de comparer nos implmentations avec CLP, il est ncessaire de contre e o ler quelles permettent de traiter les mmes probl`mes que ce dernier. En eet, e e une implmentation basique de lalgorithme du simplexe ne permet pas de traie ter tous les probl`mes. e Dirents cas peuvent subvenir empchant lobtention de la valeur optimum. e e Les principales dicults rencontres par lalgorithme sont les cycles et les ime e prcisions numriques (qui napparaissent que lors du passage ` la pratique). e e a Certains probl`mes, les cas de bord, contiennent un grand nombre de ce type e de dicults. e

6.3.2

Ensemble de donns e

An de bien tester limplmentation, il est ncessaire de disposer dun ene e semble de donnes consquent et vari. e e e Lensemble de probl`mes linaires disponible sur le dpt Netlib [4] correse e e o pond bien ` ces crit`res. Il est gnralement utilis comme banc de tests par a e e e e la majorit des implmentations du simplexe. Il est compos de 77 probl`mes e e e e de tailles petite ` moyenne. Ces probl`mes reprsentent toutes les variantes de a e e bornes individuelles sur les variables (xe, libre, plus petite que ou encore plus e grande que). Une partie des probl`mes provient de probl`mes rels (production-allocation, e e e scheduling) diciles ` rsoudre. Le reste est compos de probl`mes conus pour a e e e c gnrer des situations de cycles ou dinstabilit numrique. e e e e En plus de cet ensemble de donnes, plusieurs probl`mes de scheduling nous e e ont t fournis par la compagnie APM Technologies [2]. Lensemble des proee bl`mes ` notre disposition ore une bonne base pour tester la majorit des e a e dicults pouvant tre rencontres par des implmentations du simplexe. e e e e

6.3.3

Rsultats e

La derni`re version de limplmentation arrive ` rsoudre la totalit des e e a e e probl`mes de lensemble de donnes Netlib ainsi que les dirents probl`mes e e e e fournis par APM Technologies. La prcision sur les rsultats obtenus sont de e e lordre de 106 . 79

Il est intressant de relever que sur ce premier chantillon de probl`mes e e e notre implmentation ncessite moins ditrations pour rsoudre les probl`mes. e e e e e Nanmoins, elle est plus lente que CLP, notamment ` cause de linitialisation e a du GPU. Ceci est facilement explicable par la petite taille des probl`mes ainsi e que par leur faible densit et indique que les GPUs doivent tre utiliss pour e e e des probl`mes de grande taille. e Il est aussi important de souligner quan dobtenir de tels rsultats de nome breuses modications ont du tre apportes ` limplmentation initiale. En efe e a e fet, cette derni`re ne rsolvait que 50% des probl`mes approximativement. La e e e mthode expand [13] et une attention particuli`re aux eets des imprcisions e e e numriques ont fortement aid ` stabiliser lalgorithme. e ea

6.4
6.4.1

Mesures de performance
Objectif

Maintenant que nous avons dtermin que les deux implmentations pere e e mettent dobtenir les mmes rsultats, nous allons nous intresser ` leur perfore e e a mance. La premi`re performance que nous allons mesurer est le temps dexcution e e pris pour rsoudre des probl`mes de tailles variables. A partir de ces mesures, e e nous tablirons aussi le temps dexcution moyen par itration. e e e Ceci est important car le CLP nutilise pas la mme mthode de choix de la e e variable entrante que nos implmentations. De ce fait, le nombre total ditrae e tions peut tre fortement dirent. La prochaine mesure sera donc une comparaie e son du nombre moyen ditrations que met le CLP pour rsoudre des probl`mes, e e e compar ` celui de notre implmentation utilisant la mthode steepest edge, puis ea e e la mthode standard. e Finalement, nous allons nous intresser aux dirences entre lalgorithme du e e simplexe rvis et du simplexe standard. Le premier est rput pour tre partie e e e e culi`rement performant sur des probl`mes de faible densit (matrices creuses), e e e alors que le second est cens tre performant sur des probl`mes denses. Pour ce ee e faire, nous allons valuer le temps pris par les implmentations pour rsoudre e e e des probl`mes de taille xe mais de densit variable. e e

6.4.2

Environnement de mesures

Les performances sont dpendantes du matriel sur lequel les mesures ont e e t eectues. An de dterminer notre environnement de mesures, nous allons ee e e numrer les caractristiques cls du syst`me dont nous disposons. Le syst`me e e e e e e est compos dun serveur et dune tesla S1070. Les deux sont interconnects par e e deux connections PCI16x. Le serveur contient : 2 Intel Xeon X5570 - 2.93GHz (quad core) 24 Gb de DDR3 Disque dur SSD de 250Gb PCI8x Sur un rack 1U tesla S1070 se trouve 4 GPUs dont les caractristiques sont les e suivantes : 30 Streaming Multiprocessors

80

8 curs par SM ` environ 1.4GHz a 4GB de GDDR3, soit max. 100GB/s de bande passante pour un kernel 1000 GFLOPS en simple prcision, 80GFLOPS en double prcision e e

6.4.3

Ensemble de donnes e

Lensemble de donnes pour cette partie des mesures est tr`s particulier. e e Il doit contenir un nombre consquent de probl`mes de taille et de densit vae e e riables. Aucun ensemble de donnes correspondant ` ces crit`res nest disponible e a e a ` notre connaissance. Cependant, il existe direntes mthodes pour gnrer des probl`mes lie e e e e naire. Linconvnient de ce type de mthode est que les probl`mes en rsule e e e e tant disposent tous des mmes caractristiques. En eet, pour une mme taille e e e et une mme densit, deux probl`mes gnrs de la sorte ncessitent approxie e e e ee e mativement le mme nombre ditrations et am`ne ` une valeur optimale tr`s e e e a e proche. Malgr cet inconvnient, nous allons utiliser une de ces techniques car elle e e nous permet dobtenir des probl`mes dont la taille et la densit peuvent tre e e e spcies. De plus, les probl`mes gnrs disposent tous dune solution faisable. e e e e ee ce qui est pratique. La technique en question consiste ` dterminer les tailles m et n de la matrice. a e Il sut ensuite de gnrer des coecients entre 0 et 1 pour les variables des e e quations avec une probabilit d quivalente ` la densit voulue. Ensuite, les e e e a e coecients de la fonction objectif sont placs ` -1 pour les variables disposant e a de coecients non-nuls dans leur colonne. Les autres ont leur coecient de la fonction objectif plac ` 1. Finalement, le membre droit de lquation est x ea e e arbitrairement ` 1. a

6.4.4

Rsultats e

Taille de probl`me variable e Le temps dexcution pour une itration en fonction de la taille du probl`me e e e a t mesur. La densit maximale des probl`mes a t xe ` 5% dans le but ee e e e ee e a dobtenir des performances intressantes avec CLP. Le temps moyen par itrae e tion a t obtenu en eectuant la division entre le temps total dexcution des ee e direntes implmentations et leur nombre ditrations ncessaires ` la rsolue e e e a e tion du probl`me. e La gure 6.1 dmontre que CLP obtient de bonnes performances pour des e petits probl`mes de densit faible. La tendance est inverse pour les implmene e e e tations sur GPUs. Les temps dinitialisation ainsi que les changes de messages e entre GPUs les rendent peu ecients pour des probl`mes de petite taille. Tandis e que pour ceux de grandes tailles, elles sont bien plus rapides que le CLP. La seconde mesure est celle du temps pris par la rsolution dun probl`me e e en fonction de sa taille. La densit a t xe cette fois ` 30% an davoir e ee e a une premi`re impression de son inuence sur CLP. An de bien souligner cela, e seules les mesures pour lesquelles limplmentation a russi ` rsoudre tous les e e a e probl`mes dans un temps donns sont aches. Ce temps a t x ` 30 minutes e e e e e ea maximum pour CLP.

81

Figure 6.1 Mesures : temps pour une itration (d < 5%) e

Figure 6.2 Mesures : temps pour un probl`me (d < 30%) e On peut constater dans la gure 6.2 que d`s que la densit augmente, CLP e e prend un temps considrable pour rsoudre des probl`mes, mme ceux ayant e e e e une taille relativement petite (en de` de m = 500). Une densit plus grande ca e que 20% et un probl`me de taille 750 ncessitent dj` un temps tr`s important e e ea e pour CLP (plus de 30 minutes). 82

Limplmentation sur un GPU ore de bonnes performances sur les proe bl`mes de petite ` moyenne tailles. A partir dun certain seuil le temps pour e a rsoudre un probl`me cro de faon fortement exponentielle. Lajout de GPUs e e t c amliore les performances de mani`re considrable pour les probl`mes de grande e e e e taille. On peut remarquer que pour m = 5000, le speedup semble tre proche e du speedup optimal. Nombre ditrations e Nous allons dsormais dterminer limpact qua la mthode de choix de la e e e variable entrante sur le temps de rsolution dun probl`me. Pour ce faire, nous e e allons comparer le nombre ditrations mis par CLP et par le simplexe sur GPU e pour rsoudre un probl`me. Limplmentation sur GPU sera excute une fois en e e e e e utilisant la mthode standard (choix du plus grand coecient dans la fonction e objectif) et une fois avec la mthode steepest edge. CLP utilise une mthode e e modie du steepest edge base sur une approximation de la norme (voir section e e 4.5.2).

Figure 6.3 Mesures : nombre ditrations pour un probl`me e e Sur notre ensemble de donnes, la mthode standard semble avoir une croise e sance quadratique. Du moins, elle semble direr fortement des analyses dcrites e e par V. Chvatal [6] qui proposait une croissance linaire dpendante de m voire e e une croissance semblable ` m log(n). a La gure 6.3 semble plutt dcrire des fonctions quadratiques pour la mo e e thode standard et celle de CLP. Ce dernier dispose de moins de mesures ` cause a de son long temps dexcution pour les probl`mes de grande taille. e e Bien que la courbe de la mthode du steepest edge semble presque linaire, e e une approximation de type p mq semble obtenir des rsultats semblables avec e 1 p = 30 et q = 1.7, soit une fonction avec une croissance faiblement exponentielle.

83

Malgr le cot lev en calculs de la mthode steepest-edge, sa rduction du e u e e e e nombre ditrations ncessaires ` rsoudre un probl`me justie son utilisation. e e a e e Rappelons que dans les implmentations squentielles les mthodes de choix de e e e la variable entrante sont tires de cette mthode. Cependant, la quantit de e e e calculs quelle demande est rduite en utilisant des approximations. Tandis que e dans notre cas, les calculs quelle ncessite se paralllise tr`s bien, ce qui la rend e e e tr`s intressante. e e Densit variable e On va sintresser ici au comportement des algorithmes du simplexe standard e et du simplexe rvis en fonction de la densit du probl`me ` traiter. Nous allons e e e e a mesurer le temps dexcution par itration que mettent les implmentations CLP e e e (mthode rvis) et GPU (mthode standard) pour rsoudre des probl`mes de e e e e e e taille 500 2000 dont la densit varie entre 1% et 99%. e

Figure 6.4 Mesures : temps pour une itration (densit variable, taille xe) e e On peut constater dans la gure 6.4 que limplmentation sur GPU ncessite e e un temps quasi constant en fonction de la densit. Tandis que les performances e de CLP sont fortement inuences par la densit du probl`me. Ces derni`res e e e e sont bonnes pour des densits en de` de 3%. Il est intressant de remarquer e ca e que le temps mis par CLP augmente de mani`re rapide pour des densits plus e e petites que 20% apr`s quoi la croissance diminue fortement. e

84

6.5
6.5.1

Analyse des rsultats e


Inuence de la densit e

Dapr`s les mesures obtenues, nous pouvons conrmer que lalgorithme du e simplexe rvis ore des performances intressantes pour des probl`mes de tr`s e e e e e faibles densits. Cependant ces performances chutent rapidement d`s que la dene e sit cro un peu. Cela sexplique premi`rement par lutilisation de structure de e t e donnes ne mmorisant que les coecients non-nuls. La taille de cette structure e e est dpendante de la densit. Lorsque celle-ci devient importante, la structure e e devient trop lourde ` grer, ce qui diminue les performances. a e Le second probl`me est li ` la rsolution des syst`mes dquations. En eet, e ea e e e cette opration est facile lorsquune matrice poss`de peu de coecients none e nuls. Nanmoins pour des matrices remplies de donnes, cette tche devient e e a rapidement tr`s complexe. e En ce qui concerne le simplexe standard, le travail eectu est indpendant e e de la densit car la matrice est enti`rement recalcule ` chaque itration. Les e e e a e performances de limplmentation de ce dernier sont donc constants face ` une e a variation de la densit. e Finalement, il demeure encore une observation intressante au sujet de lvoe e lution de la densit dun probl`me. En eet, selon le type de probl`me et la e e e structure des quations, il est fort probable quau l des itrations la densit e e e dun probl`me croisse de faon signicative. An dillustrer cette thorie nous e c e avons mesur lvolution de la densit de trois probl`mes linaires du dpt e e e e e e o Netlib durant leur rsolution par limplmentation sur GPU. e e

Figure 6.5 Evolution de la densit au l des itrations e e La gure 6.5 conrme notre thorie. Il est cependant important de noter que e la magnitude de la croissance est dpendante du probl`me. Thoriquement, la e e e densit pourrait mme dcro e e e tre. Le cas le plus simple illustrant ceci serait un 85

probl`me dont chaque quation contiendrait la mme variable avec le mme coe e e e ecient. Une simple soustraction de cette variable dans chacune des quations e surait ` diminuer fortement la densit. Les implmentations rputes du sima e e e e plexe eectuent nanmoins une phase de pr-traitement [5] servant ` dtecter ce e e a e genre de cas an de simplier le probl`me initial avant dappliquer le simplexe. e Cette derni`re observation joue un rle important sur le comportement du e o CLP. Le temps dexcution par itration de celui-ci nest de ce fait pas constant. e e Il peut cro de faon importante au l des itrations selon lvolution de la tre c e e densit du probl`me. e e

6.5.2

Comparaison du mod`le et des rsultats e e

Nous allons dsormais comparer les rsultats obtenus ` ceux drivs du moe e a e e d`le dni au chapitre 5. e e Premi`rement, nous allons vrier si le mod`le obtient des rsultats proches e e e e de ceux mesurs. Pour ce faire, nous allons comparer les courbes obtenues lors e de la modlisation du temps pris par une itration au temps rel mesur. e e e e An de dterminer quelle mthode de modlisation sapproche le plus de nos e e e kernels, nous allons tudier les deux cas possibles de modlisation : celui par e e sommation des instructions arithmtiques aux instructions dacc`s ` la mmoire e e a e et celui bas sur la slection du maximum de ces deux types dinstructions. e e

Figure 6.6 Comparaison du mod`le et des mesures (temps par itration) e e La gure 6.6 conrme que le mod`le semble bien correspondre ` la ralit, e a e e particuli`rement la simulation utilisant la somme des instructions. Nanmoins e e il demeure certaines dirences entre le mod`le et les mesures. e e La premi`re dirence est lallure de la courbe de la mesure relle pour e e e des probl`mes de petites tailles. Cette mesure est obtenue par la division du e temps total et du nombre ditrations. De ce fait, le temps dinitialisation Tinit e 86

est aussi divis par le nombre ditrations qui est relativement faible pour des e e petits probl`mes. Ceci nest bien entendu pas reproduit par le mod`le, ce qui e e explique la dirence entre les deux courbes. e La seconde dirence se situe dans la croissance de la courbe. Rappelons que e lors de la modlisation, nous avons x de faon arbitraire le ratio de variables e e c non-basiques ligibles pour entrer dans la base. Il est donc possible de modier e celui-ci an dinuencer la croissance de la courbe. La derni`re dirence, sans compter les dirents nombres ngligs dans e e e e e le mod`le, demeure dans la modlisation du nombre ditrations ncessaires ` e e e e a rsoudre un probl`me. Comme nous lavons vu dans la section 6.4.4, la fonction e e lie ` la croissance du nombre ditrations est plus semblable a k = q mp que e a e ` l log(n) m o` q, p, l sont des constantes ` dnir. u a e Nous allons essayer de faire correspondre le mod`le ` la ralit en faisant e a e e varier ces dirents param`tres. Pour quils soient tous bien reprsents par le e e e e mod`le, nous allons comparer les mesures et la simulation du temps ncessaire e e pour rsoudre un probl`me avec 1 GPU ainsi quavec 4 GPUs. e e

Figure 6.7 Fitting du mod`le aux mesures e


1 Le rsultat obtenu (gure 6.7) en appliquant notre mod`le avec q = 29 , e e p = 1.71 et = 0.7 semble correspondre ` limplmentation, tout aussi bien pour a e 1 GPU que pour 4 GPUs. Le mod`le pour 4 GPUs semble toutefois un petit peu e plus rapide que la ralit. Cela est toutefois explicable tant donn que les bandes e e e e passantes des direntes mmoires ont t modlises selon leur performance de e e ee e e pointe. Il faut aussi prendre en compte que le temps de synchronisation entre les CPUs na pas t ajout. ee e An de conrmer ces observations, les coecients de corrlation entre chaque e mesure et son mod`le respectif ont t calculs. La totalit de ses coecients e ee e e

87

se trouvent tre suprieur ` 0.999. Rappelons quun coecient de corrlation e e a e proche de 0 signie que les variables (mod`le / mesure) sont linairement inde e e pendante et, inversement, quun coecient de corrlation proche de 1 signie e que les variables sont linairement dpendante. e e

6.5.3

Gain apport par lutilisation de GPUs e

Au vu des rsultats obtenus, il est clair que limplmentation du simplexe e e standard sur GPU ore de meilleures performances que des versions squentielles e de lalgorithme du simplexe rvis sur certain type de probl`mes. Cette catgorie e e e e de probl`mes semblent tre dnie en grande partie en fonction du nombre de e e e coecients non-nuls contenus dans un probl`me. Ce nombre de coecients est e dpendant de la densit et la taille du probl`me, soit : d m n (o` d est la e e e u densit). e Pass un certain seuil de coecients non-nuls, notre implmentation devient e e plus ecace. Par exemple, prenons le cas dun probl`me fourni par APM Teche nologies. Ce probl`me est de taille consquente (m = 2500 et n = 144000) mais e e dispose nanmoins dune tr`s faible densit, d = 0.004. Malgr la faible densit e e e e e du probl`me, notre implmentation sur 4 GPUs est approximativement 12 fois e e plus rapide que CLP. On pourrait se demander si dautres GPUs amlioreraient encore ce rsule e tat. Dapr`s le speedup thorique dcrit ` la section 5.5.4, les gains devraient e e e a encore cro tre suite ` lajout dautres GPUs. An de conrmer cela, nous ala lons nous intresser au speedup rel obtenu en comparant les mesures de notre e e implmentation sur un GPU ` celle sur plusieurs GPUs. e a

Figure 6.8 Speedup rel pour direntes tailles de probl`mes e e e En comparant la gure 6.8 ` la gure 5.3, on peut constater que notre mod`le a e 88

est optimiste, surtout pour les probl`mes de petite taille. Pour les probl`mes de e e moyenne et grande tailles, le speedup rel semble correspondre reltaivement bien e a celui modlis. Ceci laisse prsager que notre implmentation apporterait des ` e e e e gains encore plus importants si dautres GPUs taient disponibles jusqu` raison e a denviron 10 ` 20 GPUs pour des probl`mes de grande taille. a e

89

Chapitre 7

Conclusion
7.1 Rsum du travail ralis e e e e

Lobjectif de ce travail tait dtudier et dimplmenter lalgorithme du sime e e plexe sur GPGPU (General-Purpose Computing on Graphics Processing Units). Cet algorithme dispose dj` de nombreuses implmentations squentielles. Ceea e e pendant, la majorit de ces derni`res orent uniquement de bonnes performances e e pour la rsolution de probl`mes de petite ` moyenne tailles dont la densit est e e a e faible. Cest pour cela que nous nous sommes intresss ` parallliser cet algoe e a e rithme ` laide de GPGPU. a Nous avons dbut par ltude des deux lments cls de ce travail. Le premier e e e ee e est lalgorithme du simplexe. La mthode standard ainsi que la mthode rvis e e e e ont t dcrites et illustres ` laide dexemples. Cet algorithme a t dcompos ee e e a ee e e en trois tapes principales, soit : la recherche de la variable entrante, suivie de e celle de la variable sortante et nalement de la mise ` jour du probl`me. a e Nous nous sommes ensuite intresss au second lment, les GPGPU, et e e ee plus particuli`rement ` larchitecture CUDA (Compute Unied Device Archie a tecture), propose par NVIDIA. Cette architecture de type SIMT (Simple Ine sutrction Multiple Threads) a t dcrite de telle mani`re ` mettre en vidence ee e e a e ses deux caractristiques principales : ses dirents niveaux de mmoire et la e e e dcomposition du travail en tches. Ceci nous a permis daborder les principes e a de programmation cruciaux sur GPUs. ` A partir de l`, nous avons compar les deux mthodes du simplexe. Ceci an a e e de dnir laquelle serait la plus adapte pour une implmentation sur GPUs. e e e Nous avons choisi la mthode du simplexe standard car cette derni`re semblait e e mieux proter dune paralllisation sur plusieurs GPUs. Avant de se lancer dans e sa mise en place, les performances de CUDA sur les oprations principales du e simplexe ont t compares ` leur quivalent CPU. Les oprations de recherche ee e a e e de variables semblent orir peu de gains alors que la mise ` jour de la matrice a garantit des gains importants. Ces gains tant encourageants, lalgorithme du simplexe standard a t parale ee llis sur un GPU. La structure de mmoire mise en place, ainsi que lalgorithme e e e utilis ont t dcrits. La premi`re version obtenue ntait pas aussi robuste que e ee e e e les logiciels existants. An de corriger ce probl`me, elle a t amliore par des e ee e e mthodes de choix de variables trouves dans la littrature scientique. A pare e e

90

tir de cette version, nous avons tudi les possibilits de partage des donnes e e e e et du travail, dans loptique dune paralllisation multi-GPU. La dcoupe vere e ticale du probl`me a t choisie parce quelle ncessite peu de communications e ee e supplmentaires et quelle ore de bonnes performances pour un nombre limit e e de GPUs. Lalgorithme et les particularits ncessaires ` sa mise en place ont e e a ensuite t examins. ee e Un mod`le de performance a t tabli ` partir de ces deux versions de e ee e a lalgorithme : celle sur un GPU et celle sur plusieurs GPUs. Pour cela, il a t ee ncessaire de dcortiquer et destimer le fonctionnement dune application GPU. e e Le mod`le obtenu nous a permis destimer le temps ncessaire pour rsoudre une e e e itration ou un probl`me entier et par la suite le comportement de nos paralllie e e sations face ` une croissance de la taille des probl`mes. Nous nous sommes aussi a e intresss ` limpact quaurait lajout dautres units de calcul en tablissant le e e a e e speedup thorique. Les rsultats obtenus ` ces direntes tapes promettent des e e a e e gains intressants en performance suite ` lajout de GPUs. e a Les performances relles des implmentations 1 ont t nalement analyses. e e ee e Dans un premier temps, il nous a fallu choisir une version de rfrence du simee plexe an de comparer nos rsultats. Parmi les implmentations squentielles e e e existantes, nous avons choisi CLP parce quil fait partie dun vaste projet open source de logiciels de recherche oprationnelle, COIN-OR. De plus, ses perfore mances et sa robustesse sont proches des versions commerciales. La robustesse de nos implmentations a t contrle, avec succ`s, sur lene ee oe e semble des probl`mes linaires du dpt Netlib [4] ainsi que sur des probl`mes e e e o e rels li ` laviation (conception dhoraire dquipage et aectation davions e e a e aux routes) fournis par la socit APM Technologies [2]. Cet ensemble de donee nes est gnralement utilis comme benchmark pour ce type de logiciel. Nous e e e e avons alors mesur les performances de CLP ainsi que celles de nos versions. e Les rsultats obtenus pour nos versions ont permis de conrmer le mod`le tae e e bli prcdemment. Et surtout, la comparaison de ceux-ci aux rsultats de CLP e e e a mis en vidence des gains de performance tr`s important pour des probl`mes e e e de moyenne ` grande taille. a

7.2
7.2.1

Discussion
CUDA

Au premier abord, la mise en place de programmes pour ce type darchitecture peut sembler vidente. Il sut en eet de dcouper le calcul total en e e sous-oprations. Ceci est gnralement facile pour des calculs vectoriels ou mae e e triciels. Cependant, il existe une grande dirence entre un kernel fonctionnel e et un kernel optimis. e Larchitecture CUDA est relativement complexe comme nous lavons vu durant son tude. Et de ce fait, il nest pas ais de tirer prot au mieux de ses e e performances de pointes. Les direntes optimisations possibles dpendent de e e la taille des probl`mes ` traiter, de lorganisation des acc`s mmoire et de la e a e e collaboration entre les tches. Par exemple, nous avons vu dans la section 4.5.3 a une stratgie an datteindre plus rapidement les performances de pics. e
1. Les implmentations sont disponibles sur le site du groupe SPC du dpartement dine e formatique de lUniversit de Gen`ve [11]. e e

91

Cette complexit sest une fois de plus manifeste lors de la modlisation de e e e lalgorithme (voir section 5.2). Durant cette modlisation, nous avons d estimer e u les dirents mcanismes mis en place par lordonnanceur dans le but de cacher e e la latence des acc`s mmoire. e e Les kernels ncessitent donc une attention particuli`re an dobtenir une ape e plication optimise. Pour une mme opration, il pourrait mme tre imaginable e e e e e de disposer de plusieurs kernels optimiss pour des tailles ou congurations de e probl`mes spciques. e e

7.2.2

Simplexe

Lalgorithme du simplexe tel que dcrit par V. Chvatal [6] est relativement e simple ` mettre en place. La version obtenue par lapplication de cette descripa tion nest cependant pas tr`s performante ni robuste. Les probl`mes de pere e formances sont lis ` des choix de variables faciles ` mettre en place, mais ne e a a prenant pas en compte tous les crit`res impliqus, tandis que ceux de stabilits e e e sont lis aux probl`mes dimprcisions numriques. En eet, ces erreurs sur les e e e e oprations ottantes dtriorent le probl`me ditration en itration. De ce fait, e ee e e e il est ncessaire de prendre des prcautions an de limiter leur inuence sur les e e mthodes de choix de variables. Dans le pire des cas, le choix dun faux pivot e am`nerait ` une version errone de la matrice. e a e Il est donc important de rechercher et de mettre en place des heuristiques permettant damliorer les performances et la stabilit. Cest ce que nous avons e e fait dans la section 4.5.2 en utilisant la mthode du steepest edge an de se e lectionner la variable entrante et expand an de choisir la variable sortante. Ces deux mthodes ont amen des amliorations drastiques des performances e e e de lalgorithme. Celui-ci est pass dun taux infrieur ` 50% de russite sur le e e a e benchmark ` un sans faute suite ` lajout de expand ainsi que dun mcanisme a a e de tolrance des imprcisions numriques. La mesure du nombre total ditrae e e e tions ncessaires pour rsoudre un probl`me (voir section 6.4.4) dmontre bien e e e e lavantage apport par limplmentation du steepest edge ou dune mthode sie e e milaire. Plusieurs approches sont possibles pour implmenter dirents lments de e e ee lalgorithme. Par exemple, la mmorisation de la base ou encore la technique e de la recherche dune solution initiale peuvent tre mises en place de mani`re e e simple en utilisant plus de mmoire, ou au contraire de mani`re plus complexe e e an de rduire lutilisation de cette derni`re. La premi`re option peut amener e e e a ` une structure de donnes de grande taille (voir section 2.4.4 et 4.5.2), ce qui e aurait un impact sur les performances, tant donn que lopration de mise ` e e e a jour de la matrice est dpendante de cette taille. Tandis que la seconde option e ncessite la mise en place de mthodes plus complexes et plus coteuses an de e e u maintenir une taille proche de celle du probl`me initial. Ces gains se traduisent e par la possibilit de traiter des probl`mes plus grands et plus rapidement, car e e la mise ` jour de la matrice demande beaucoup moins de travail. a

7.2.3

Choix

Nous allons discuter ici des dirents choix eectus au cours de limplmene e e tation.

92

La premi`re dcision a t de slectionner lalgorithme du simplexe standard e e ee e plutt que sa version rvise. Les comportements des direntes implmentao e e e e tions ont conrm ce choix. En eet, lanalyse des mesures ` la section 6.4.4 e a dmontre que le simplexe rvis subit de lourdes pertes en performance d`s que e e e e le probl`me devient de taille trop consquente, ou que sa densit dpasse un e e e e certain seuil. Alors que notre implmentation du simplexe standard nest pas e dpendant de la densit du probl`me et que sa raction face ` une croissance de e e e e a la taille du probl`me semble plus douce. Nos rsultats compars ` ceux obtenus e e e a par J. Bieling et al. [10] lors de leur implmentation du simplexe rvis sur GPU e e e semblent comptitifs pour des probl`mes de taille moyenne. Cependant, il est e e dicile darmer ces observations. En eet, leur implmentation est limite ` e e a un GPU et donc la taille des probl`mes quils peuvent traiter est limite par la e e taille de sa mmoire. e Nous avons ensuite choisi dutiliser la dcoupe du probl`me en bandes vertie e cales an de partager le calcul sur plusieurs GPUs. Cette dcision a t faite en e ee prenant en compte le nombre de GPUs disponibles dans la majorit des clusters e GPGPU. Ces derniers ne disposent pas dun grand nombre de GPUs, rarement plus de quelques dizaines. Les speedups thorique et pratique obtenus aux sece tions 5.5.4 et 6.5.3 dmontrent que pour des probl`mes de tailles moyenne et e e grande, lajout dunits de calcul supplmentaires apporte des gains proches de e e la valeur optimale. Il est nanmoins intressant de soulever que dans le cadre dun cluster come e pos dun nombre important de GPUs, il serait plus intressant dutiliser la e e dcoupe du probl`me en tuiles. De plus, lutilisation de MPI orirait des gains e e supplmentaires. En eet, limplmentation faite avec POSIX neectue pas de e e rduction au niveau des changes inter-CPUs. Nous avons donc une complexit e e e de lordre O(x NGP U ) o` x est la taille du message. Alors que lutilisation de u MPI diminuerait cela ` O(x log2(NGP U )). Ceci nest pas drangeant pour un a e nombre faible de GPUs, mais pourrait le devenir dans le cas oppos. e

7.2.4

Rsultats et mod`le de performance e e

Le mod`le de performance tabli dans le chapitre 5 a t confront aux e e ee e mesures relles dans la section 6.5.2. La courbe issue du mod`le a t ajuste e e ee e de telle sorte ` correspondre aux rsultats obtenus lors de lutilisation de 1 ` a e a 4 GPUs avec succ`s. Le mod`le de performance est donc d`le aux mesures e e e relles. Ce qui nous permet danticiper thoriquement des modications dordre e e matriel lies aux performances des GPUs par exemple. e e La comparaison des deux mthodes du simplexe nous a amen ` analyser de e ea mani`re approfondie linuence de la densit dans la section 6.4.4. La mthode e e e rvise sest montre particuli`rement sensible ` cette derni`re. Tandis que notre e e e e a e implmentation est reste constante face aux variations de la densit. e e e De plus, nous avons dtermin dans la section 6.5.1 quil y a de fortes proe e babilits pour que la densit dun probl`me croisse durant sa rsolution. Ces e e e e derni`res observations lies aux mesures obtenues ` la section 6.4.4, nous pere e a mettent de dterminer que notre implmentation est beaucoup plus eciente e e dans le cas o` le nombre de coecients non-nuls du probl`me dpasse un ceru e e tain seuil. Ce seuil est donc dpendant de la taille du probl`me et de la densit, e e e soit de d m n. Par exemple, pour m = 500 et n = 2500 le seuil de densit e semble tre x ` environ d = 0.03. e ea 93

7.3

Perspectives

La technologie des GPGPU est assez rcente. Nous pouvons donc nous ate tendre ` diverses amliorations dordre logiciel ou matrielle durant les annes ` a e e e a venir. Les librairies voluent constamment. Soit elles orent de nouvelles fonce tionnalits, soit elles amliorent les performances de celles qui existent dj`. Les e e ea outils de dveloppement pourraient bncier damliorations an de faciliter e e e e le debug et le proling de kernels. Du point de vue matriel, ` lheure o` ce e a u mmoire est crit, une nouvelle famille de GPUs a t mise sur le march par e e ee e NVIDIA. Cette famille, fermi, dispose dune structure dirente au niveau des e streaming multiprocessors dans le but dorir de meilleurs performances pour les nombres ottants en double prcision. Les performances de pics sont annoncs e e a 500GFLOPS pour les nombres en double prcision, contre 80GFLOPS pour ` e les GPUs utiliss lors de nos mesures. Cette famille de GPUs dispose de caches e sur la mmoire globale an de diminuer la latence des acc`s ` celle-ci. e e a Notre implmentation ore de tr`s bonnes performances pour une certaine e e catgorie de probl`mes. Nanmoins, il pourrait tre intressant de parallliser e e e e e e lalgorithme du simplexe rvis sur un GPU an dorir aussi de meilleures e e performances pour les probl`mes de petite ` moyenne taille. Ce travail a dj` e a ea t en partie fait par J. Bieling et al. [10], cependant leur implmentation na ee e pas t faite ` laide de CUDA et sa robustesse na, a priori, pas t teste. ee a ee e Prenons par exemple la structure typique des probl`mes que doivent rsoudre e e APM Technologies. Ces probl`mes contiennent gnralement un nombre tr`s e e e e faible dquations pour un nombre consquent de variables, par exemple m = 150 e e et n = 50000. Ils ne sont donc pas tr`s grands et gnralement leur densit est e e e e infrieure ` 1%. Ces probl`mes pourraient donc bncier de lalgorithme du e a e e e simplexe rvis sur GPU. e e Finalement, il existe une mthode autre que le simplexe pour rsoudre les e e probl`mes linaires, et qui a beaucoup volue durant ces derni`res annes. La e e e e e e mthode du point intrieur [18] consiste, comme son nom lindique, ` parcourir e e a le polytope li au probl`me, non pas par ses bords, mais par son corps. Cette e e mthode est rpute pour obtenir de bons rsultats sur des probl`mes de grande e e e e e taille ou contenant de nombreux cycles. Elle ncessite un nombre important de e calculs matriciels. Il pourrait donc tre intressant dtudier une paralllisation e e e e de cette derni`re sur GPU. e

94

Bibliographie
[1] NVIDIA CUDA Compute Unied Device Architecture : Programming Guide, 2008. Version 2.0. [2] APM technologies sa. http ://www.apmtechnologies.com/, 2010. [3] MPS le format. 2010. http ://lpsolve.sourceforge.net/5.5/mps-format.htm,

[4] The netlib repository. http ://www.netlib.org, 2010. [5] G. Mitra A.L. Brearley and H.P. Williams. Analysis of mathematical programming problems prior to applying the simplex algorithm. In Mathematical Programming 8 (1975) 54-83, volume 8, pages 5483. North-Holland Publishing Company, 1975. [6] Vasek Chvatal. Linear Programming. W.H. Freeman, 1983. [7] Kishore Kothapalli et al. A performance prediction model for the CUDA GPGPU platform. Technical report, International Institute of Information Technology, Hyderabad, 2009. [8] J. A. J. Hall. Towards a practical parallelisation of the simplex method, 2007. [9] Frederick S Hillier and Gerald J. Lierberman. Introduction to Operations Research. 9 edition, 2010. [10] Peter Martini Jakob Bieling, Patrick Peschlow. An ecient GPU implementation of the revised simplex method. In IEEE Xplore. [11] X. Meyer. Code source : implmentation du simplexe standard sur GPUs. e http ://spc.unige.ch/open source, 2011. [12] Ping-Qi Pan. A largest-distance pivot rule for the simplex algorithm. European Journal for Operational Research, 187 :393402, 2008. [13] Michael A. Saunders Philip E. Gill, Walter Murray and Margaret H. Wright. A pratical anti-cycling procedure for linearly constrained optimization. Mathematical Programming, 45 :437474, 1989. [14] Wei Li Pingqi Pan and Jun Cao. Partial pricing rule simplex method with decient basis. NUMERICAL MATHEMATICS, 15 :2230, 2006. A Journal of Chinese Universities. [15] Artur Swietanowski. A new steepest edge approximation for the simplex method for linear programming. Computational Optimization and Applications, 10 :271281, 1998. [16] Michael E. Thomadakis and Jyh-Char Liu. An ecient steepest-edge simplex algorithm for SIMD computers, 1996. 95

[17] Vasily Volkov. Better performance at lower occupancy, 2010. [18] Stephen J. Wright. Primal-dual interior-point methods. SIAM, 1998.

96