Résolution massivement parallèle de problèmes combinatoires ; cas particulier du problème de Langford

Transcription

1 Université de Reims Champagne-Ardennes Julien Loiseau Résolution massivement parallèle de problèmes combinatoires ; cas particulier du problème de Langford Master 1 Informatique TER : Travail d Etude et de Recherche Travail encadré par Michaël Krajecki et Christophe Jaillet avec la participation de François Alin Centre de Recherche en STIC Ce travail a été réalisé avec le concours du Centre de Calcul de Champagne-Ardenne ROMEO 11 juin 2014

2 Sommaire Table des figures Introduction ii iii 1 Problèmes combinatoires et résolution parallèle Problèmes combinatoires Classes de complexité CSP Tout problème combinatoire peut être représenté comme un CSP Méthode de résolution retenue Tâches et résolution parallèle Architecture GPU NVIDIA - Kepler CUDA, Compute Unified Device Architecture Cluster multi-gpu Résolution arborescente sur architecture multi-gpu Régularisation, pour exécution sur GPU Hybridation des deux méthodes Problème de Langford et implémentation Présentation Approche de Miller Implémentation Résolution multi-gpu du problème de Langford Structure du client Méthodologie expérimentale Résultats Conclusion et perspectives Conclusion Perspectives Références 33 8 Annexe 34 i

3 Table des figures 1 Nombre de supercalculateurs avec GPU au top500 c NVIDIA iii 2 Les différents types de problèmes d optimisation combinatoire : problèmes de décision, d optimisation combinatoire Classes de complexité des problèmes (sous l hypothèse que P NP ) Représentation arborescente d un CSP Descente dans l arbre de recherche Partition espace de recherche Génération naïve des tâches Méthodes de vérifications partielles Fermi vs. Kepler : Architecture c NVIDIA Fermi vs. Kepler : Architecture d un StreamingM ultiprocessor c NVIDIA Organisation des threads CUDA c NVIDIA Utilisation des streams CUDA Cluster de calcul multi-gpu ROMEO Détail et structure de la méthode Solution du problème de Langford à trois couleurs Vue numérique du problème de Langford d ordre Construction de l arbre de recherche à trois couleurs Langford, client-serveur Utilisation des streams CUDA Temps en fonction du nombre de blocks et de threads pour N=15 P= Temps en fonction du nombre de blocks et de threads pour N=15 P= Temps en fonction du nombre de blocks et de threads pour N=17 P= Profondeur Streams ii

4 Introduction Dans les dernières années le calcul haute performance a adopté une nouvelle tendance qui promet de se rapprocher de la barre de l exascale 1, par l utilisation du calcul hybride : les calculs sont accélérés par des accélérateurs matériels, spécialisés et surpuissants, qui sont adjoints aux processeurs dans des nœuds de calcul plus évolués. Les accélérateurs sont des unités massivement parallèles, pouvant être dotés de centaines d unités de calcul spécialisés, qui se déclinent en plusieurs familles dont les cartes graphiques et les processeurs spécialisés. Les cartes graphiques ont désormais une place très privilégiée dans le paysage HPC grâce à leurs performances crêtes annoncées, qui sont actuellement de l ordre de plusieurs TFlops pour une seule carte, pour un prix modique. Les cartes graphiques ont fait leur apparition en même temps que la demande pour des interfaces graphiques faciles à utiliser par l utilisateur lambda. L apparition des premiers jeux vidéo a poussé encore plus l évolution de ces co-processeurs car ils réclamaient de plus en plus de réalisme et de fluidité dans les affichages. À un certain moment ces unités sont devenues si puissantes que des chercheurs ont considéré leur potentiel de puissance, pour les mettre au profit de calculs généralistes indépendants de toute vocation graphique. En 2007, NVIDIA a proposé le premier langage généraliste de programmation pour ses cartes graphiques ; ce fut le point du départ pour une adoption de ces nouvelles architectures dans le monde des supercalculateurs, pour arriver aujourd hui à avoir de plus en plus de GPU au sein des supercalculateurs comme le montre la figure 1. Figure 1 Nombre de supercalculateurs avec GPU au top500 c NVIDIA L apport du calcul hybride est significatif et permet en effet d augmenter considérablement la puissance des machines parallèles. Ainsi l objectif de l exascale est effectivement à portée, dans un avenir proche. En recherche opérationnelle, plusieurs types de problèmes existent. Les problèmes combinatoires, aléatoires ou encore concurrentiels. Les problèmes combinatoires sont des problèmes visant à tester de nombreuses combinaisons entre un grand nombre de variables et à trouver une solution optimale ou proche de l optimum en respectant un ensemble de conditions. Ces problèmes combinatoires peuvent se ramener à un problème SAT, problème de satisfaisabilité, que l on peut ensuite mettre sous formalisme CSP, problème de satisfaction de contraintes. On connait actuellement un grand nombre de techniques pour résoudre un problème sous forme CSP, le backtrack, forward-checking, backjumping, etc. 1. Soit de générer une puissance d au moins un exaflops iii

5 La méthode backtrack avec, si possible, la possibilité de faire des tests sur des configurations partielles, est parfaite pour une implémentation CPU mais se prête très mal à l architecture synchrone du GPU. Le but de cette étude sera donc de trouver une méthode pour permettre de résoudre de manière efficace des problèmes sous formalisme CSP sur une architecture multi-gpu. Dans un premier temps, nous décrivons les problèmes combinatoires et les spécificités des accélérateurs matériels de NVIDIA avec, en particulier, la K20Xm sur laquelle les tests ont été réalisés. Nous décrivons ensuite les techniques pour permettre d utiliser ces accélérateurs matériels pour les problèmes combinatoires, après les avoir mis en formalisme CSP. Ceci passe par la régularisation des calculs qui peuvent ainsi se porter facilement sur GPU. Enfin, nous traitons l exemple d un problème particulier, celui de Langford. Nous montrons les méthodes que nous avons mises en place pour porter ce problème sur GPU et comment accélérer au maximum le calcul avec la méthodologie mise en place. Nous montrons aussi dans cette partie les résultats obtenus sur le problème de Langford. Enfin nous développerons les suites du projet avec une autre méthode de résolution du problème de Langford, la méthode de Godfrey. Durant ce stage, j ai tout d abord réalisé une étude bibliographique sur les problèmes combinatoires et les méthodes de résolution possibles avec l étude de différents articles et thèses. Ensuite l étude s est portée sur le problème de Langford et des méthodes existantes de résolution de ce problème ainsi que des moyens de mettre ces méthodes en œuvre et des travaux existants. Le travail de recherche s est poursuivi par la découverte du développement CUDA avec l étude de documents techniques. Dans un second temps je suis passé à l étape d implémentation de ces techniques en version séquentielle et enfin à des versions parallèles CUDA, OpenMP et MPI. Un temps a aussi été consacré à la recherche d autre techniques utilisant différents types d accélérateurs matériels. Les méthodes que j ai dû aborder ici sortent du cadre de la formation Master 1 et sont donc une avance pour moi sur les cours de Master 2. Le code était développé à la fois de manière personnelle et en groupe. De nombreux échanges ont eu lieu avec les membres du CReSTIC et l équipe de ROMEO. Un rapport hebdomadaire voire quotidien a été fait à mon encadrant, monsieur Christophe Jaillet. Je me suis investi fortement dans ce travail et j ai essayé d être présent à la faculté durant l ensemble du stage, moyennant la seconde semaine de vacances durant laquelle l établissement était fermé, toute la journée de 8h à 18h30 voire plus, certains jours où plus des développements étaient nécessaires. La préparation d une présentation pour le groupe RGE et ce même rapport ont été les éléments terminaux de ce stage. Mon travail sur ce projet ne va pas s arrêter là et je compte participer au maximum aux suites qui vont être données à ce travail. A court terme, la rédaction d un article scientifique en anglais destiné à une conférence internationale est en cours. Ce rapport a été précédé par une formation sur les FPGA (Field Programmable Gate Array) pour découvrir les possibilités de ce type d accélérateur. Une présentation devant le groupe RGE a aussi été réalisée le 5 juin 2014 et une autre suivra pour les Journées de la simulation à Reims le 12 juin Un article basé sur ce travail est en cours de rédaction pour une conférence internationale, the 20 th IEEE Internationale Conference On Parallel and Distributed Systems. iv

6 Julien Loiseau 1 Problèmes combinatoires et résolution parallèle 1.1 Problèmes combinatoires Les problèmes combinatoires constituent une branche de la recherche opérationnelle. Ils consistent à déterminer, parmi un ensemble discret X de solutions envisageables, celles qui vérifient certaines contraintes ou critères d optimisation. Ils apparaissent dans de nombreux domaines : militaire et géostratégique, logistique et optimisation industrielle, économie,... On distingue essentiellement deux catégories de problèmes combinatoires : les problèmes de décision et les problèmes d optimisation. Dans le cas d un problème de décision il s agit de déterminer si, oui ou non, il existe des solutions. La recherche est interrompue dès qu une première solution est trouvée, qu il en existe d autres ou non. En particulier, les éventuelles solutions d un problème de décision sont toutes équivalentes. Lorsqu on considère un problème d optimisation, on cherche à obtenir une solution qui minimise ou maximise la valeur d une fonction objectif. La plupart du temps, on parle de fonction de coût, qu il s agit de minimiser 2. La figure 2 rappelle ces différentes catégories de problèmes combinatoires. Considérons l ensemble X des valeurs envisageables (espace de recherche). problème de décision On suppose disposer d une fonction booléenne sol caractérisant, parmi les valeurs envisageables, celles qui en sont des solutions.?x X / sol(x) = vrai Nb : il ne s agit pas de déterminer l ensemble S = {x X / sol(x) = vrai}, mais de déterminer si S =. problème d optimisation On dispose d une fonction de coût fcout appréciant la qualité d une valeur ou d une solution. déterminer x tq fcout(x ) = min{fcout(x) / x X } ou déterminer x tq fcout(x ) = min{fcout(x) / x X et sol(x) = vrai} (Hyp : S ) Figure 2 Les différents types de problèmes d optimisation combinatoire : problèmes de décision, d optimisation combinatoire. Explosion combinatoire Dans certains domaines, un petit changement sur les données d un problème peut suffire à rendre sa résolution très difficile. C est ce qu on observe lorsqu on souhaite calculer les valeurs de la fonction d Ackermann 3. En pratique, dans le cadre des problèmes combinatoires, la taille de l espace de recherche (de l ensemble X ) est souvent extrêmement grande, au point qu elle est souvent exponentielle en fonction 2. On peut d ailleurs toujours se ramener à une minimisation car maximiser une fonction consiste à minimiser son opposé ou, si on veut ne considérer que des quantités positives, minimiser son inverse. 3. La fonction d Ackermann est définie sur N N par A(0, n) = n + 1, A(m, 0) = A(m 1, 1) si m > 0, et (cas général) A(m, n) = A(m 1, A(m, n 1)) lorsque m, n > 0. 1

7 Julien Loiseau 1.2 Classes de complexité de la taille du problème. 1.2 Classes de complexité Dans le cas des problèmes de décision, on distingue plusieurs classes de problèmes selon la «difficulté» de leur résolution. P : il existe une machine de Turing polynomiale 4 et déterministe 5 résolvant le problème. NP : il existe une machine de Turing polynomiale et non déterministe 6 résolvant le problème, c est à dire qu il existe une exécution de cette machine de Turing qui donne la solution en un temps polynomial 7. NP-difficile : Un problème est dit NP-difficile (ou NP-dur) si tout problème de NP lui est polynomialement réductible (pb 1 est NP-difficile si pb NP, pb pb 1 ). Un problème est donc NP-difficile lorsque sa complexité en temps est pire que celles de tous les problèmes NP. NP-complet : Un problème est dit NP-complet s il est à la fois NP-difficile et de classe NP. La figure 3 représente les différentes classes de complexité selon l hypothèse P NP. indécidable décidable problème de l arret NP difficile NP P NP complet SAT Figure 3 Classes de complexité des problèmes (sous l hypothèse que P NP ). Voici quelques exemples de problèmes de recherche combinatoire : Problèmes P : vérifier qu une instanciation d un problème de satisfaction de contraintes est une solution (pour un nombre déterminé de contraintes car l instance du problème est donnée). Problèmes NP-complets (par ordre croissant de difficulté) : trouver une solution d un problème de recherche combinatoire dont on sait qu il est satisfiable. déterminer si un problème de contraintes est satisfiable. déterminer une solution [optimale] d un problème d optimisation combinatoire ou déterminer toutes les solutions d un problème de recherche combinatoire (pour les afficher, les stocker, les compter,... ) ; ces problèmes sont plus difficiles que la recherche de satisfiabilité car il faut envisager toutes les solutions par exemple pour connaître la meilleure ou les compter. 4. polynomiale : dont le temps d exécution est borné par un polynôme N k, k étant une certaine constante et N désignant la taille du problème (plus précisément la taille de l instance du problème dans un codage déterminé). 5. déterministe : les instructions se succèdent selon un ordre non aléatoire : à chaque état est associée une action et une seule. 6. non déterministe : la succession des instructions est régie de façon non déterministe : dans certains états un choix peut être fait entre plusieurs actions, autorisant plusieurs exécutions différentes de la machine de Turing sur une même instance du problème. 7. Ces notions sont basées sur les temps d exécution. Il existe une notion symétrique pour la complexité spatiale, qui permet d introduire les classes de problème s P -space, NP -space,... 2

8 Julien Loiseau 1.3 CSP Problèmes NP-difficiles mais non NP-complets : Les problèmes non polynomiaux, même non déterministes, sont des cas pathologiques construits sur mesure et souvent extrêmement compliqués ; leur intérêt se limite essentiellement au fait qu ils sont non polynomiaux. Problèmes indécidables : Turing a prouvé en 1936 que le problème de l arrêt 8 est indécidable. D autres problèmes ont été prouvés indécidables (directement ou par équivalence au problème de l arrêt) : parmi ceux-ci, citons tout de même le problème du castor affairé (busy beaver), qui consiste à déterminer le nombre d étapes que peut effectuer une machine de Turing à n états, sans données initiales, avant de s arrêter. 1.3 CSP Formellement, un problème de satisfaction de contraintes est un triplet(x, D, C) tel que : X : un ensemble fini de variables D : un domaine de valeurs discret et borné 9 C : un ensemble fini de contraintes Une contrainte peut être définie à son tour comme une paire < t, R > avec : t : un N uplet de variables R : un ensemble de N uplet valeurs, R est une relation L évaluation d une contrainte par une fonction v : X D. On peut donc vérifier une solution ou un état satisfaisant le problème par : < (x 1,..., x n ), R > si (v(x 1 ),..., v(x n )) R 1.4 Tout problème combinatoire peut être représenté comme un CSP Comme l indique le titre de ce paragraphe, tout problème combinatoire peut être représenté comme un CSP (Constraint Satisfaction Problem). Preuve : En effet, comme la résolution de CSP est un problème NP-complet, tous les problèmes de la classe NP peuvent s y ramener moyennant une transformation polynomiale en temps. C est justement le cas des problèmes combinatoires, qui sont de classe NP (ils sont NP-complets). Ainsi, tout problème combinatoire peut être représenté comme un CSP. Comme les différents problèmes peuvent être abordés soit selon l angle de la recherche combinatoire, soit selon celui de l optimisation combinatoire, on représente sous forme de CSP le problème a priori, pour ne faire intervenir la fonction d évaluation que lors de la résolution (dans le cas où la question posée sur ce problème relève de l optimisation). Bien sûr, il appartient aux utilisateurs de déterminer une représentation intelligente du problème sous forme d un CSP car le choix de cette formulation (choix des variables ; nombre de contraintes, leur arité ;... ) peut avoir de réelles incidences sur l efficacité de la résolution. Représentation arborescente Nous disposons d un domaine de valeurs fini pour chacune des variables, on peut donc mettre en place l arbre représentant l ensemble des combinaisons possibles. Une 8. Étant donnée une machine de Turing déterministe et un mot d entrée, ce problème consiste à déterminer si son exécution se termine (n aboutit pas à un cycle).cela revient à déterminer si un programme (ensemble d instructions avec des instructions de branchement conditionnel), exécuté sur des données initiales déterminées, termine son exécution en un nombre fini d étapes (sans boucle infinie). 9. On peut également envisager des CSP continus. 3

9 Julien Loiseau 1.5 Méthode de résolution retenue branche de l arbre représentera un état du problème, valide ou non. La Figure 4 est un exemple de représentation arborescente. Pour la variable x 1 le premier niveau est l ensemble des valeurs possibles. Ensuite pour chacune des valeurs de x 2, on va décliner au niveau suivant l ensemble des valeurs possibles de x 2, puis x 3, etc. Figure 4 Représentation arborescente d un CSP Dans ce type de représentation et par la suite, pour le parcours de l arbre, on peut choisir de prendre ou non un ordre fixe pour les variables ou leurs valeurs. Selon le problème traité cela pourra avoir, ou non, de l importance. 1.5 Méthode de résolution retenue Plusieurs méthodes de résolution existent pour parcourir et trouver des solutions dans un tel arbre de recherche. Nous traitons ici uniquement de la méthode de recherche arborescente par backtrack. Baktrack La méthode se déroule ainsi : Tenter de descendre dans l arbre (Créer une nouvelle configuration partielle) Configuration valide : Continuer le parcours de la branche Configuration invalide, impasse : Abandon de la branche, traiter la branche suivante Une exemple de backtrack est donné en Figure 5. _ instanciation suivante descente impasse remontée Figure 5 Descente dans l arbre de recherche. 4

10 Julien Loiseau 1.6 Tâches et résolution parallèle Nous retenons la méthode naïve, selon laquelle l ordre des variables considérées est fixé statiquement, ainsi que l ordre des variables. On obtient l algorithme naïf associé (voir algorithme 1). Algorithm 1 Algorithme standard Début : Initialisation while!done do Vérifier le noeud if successf ul then descendre else end if end while remonter On regarde si le noeud est valide Valide, on descend Invalide, on remonte Plusieurs types de backtrack sont possibles. Vérification a posteriori : Si on ne peut pas de vérifier la consistance des nœuds de l arbre au fur et à mesure du parcours, la seule méthode possible est de faire une vérification a posteriori. On est obligé de parcourir l arbre jusqu à une feuille et ensuite appliquer la fonction de vérification de l état. Cette méthode est la plus lourde car on sera obligé de parcourir l ensemble de l espace de recherche. Vérification à la volée : Parfois le problème permet de faire des vérifications à la volée lorsqu une solution partielle est générée. Cette méthode permet de faire des découpes dans l arbre à des profondeurs basses réduisant ainsi très largement l espace de recherche. 1.6 Tâches et résolution parallèle Une telle représentation arborescente se prête parfaitement à la génération de tâches qui sont en fait des "sous-problèmes" pour partitionner l espace de recherche. En effet une fois arrivé sur un nœud donné on peut prendre en considération un sous-arbre à partir de ce nœud. Ce noeud peut être choisi à n importe quelle profondeur pour la génération des tâches. Le Figure 6 montre, la découpe d un arbre de recherche avec deux tâches. Figure 6 Partition espace de recherche 5

11 Julien Loiseau 1.6 Tâches et résolution parallèle On peut donc partitionner l ensemble de l espace de recherche en divisant l arbre de recherche en tâches. Ces tâches peuvent être générées de plusieurs manières. Tout d abord, à la figure 7 on montre que, si seule la vérification a posteriori est possible, la génération des tâches se fait à une profondeur donnée. Ici on place les variables x 1, x 2 et x 3 avant de générer la tâche qui sera partagée entre différents moyens de calculs par exemple. Figure 7 Génération naïve des tâches Si on dispose d une méthode d évaluation des instanciations partielles, on peut suivre la même procédure qu en Figure 7 mais en éliminant les tâches inconsistantes avant de les partager. Comme montré en Figure 8 (a), on va éliminer énormément de tâches inutiles et donc réduire le nombre de partitions. Enfin la méthode la plus optimisée, si encore une fois les données du problème le permettent, est de réaliser à chaque noeud une évaluation partielle pour élimier au plus haut les branches inconsistantes. La figure 8 (b), est semblable à celle de (a) au niveau des tâches subsistant, mais la génération de ces tâches aura été accélérée par l élagage de branches au plus tôt. Figure 8 Méthodes de vérifications partielles Cette dernière méthode est la plus optimisée (pour un parcours backtrack) du point de vue de la génération des tâches et du partitionnement de l espace de recherche. 6

12 Julien Loiseau 2 Architecture GPU C est en 2007 qu a lieu la réelle révolution du GPGPU, lorsque NVIDIA a mis à disposition des programmeurs la première version de son framework de programmation, appelé CUDA (Compute Unified Device Architecture), qui permet un accès direct à l architecture du périphérique via le langage C, familier, auquel sont apportées des modifications minimales. Cela fut le point de départ pour le GPU Computing avec, par la suite, de nouvelles versions améliorant la programmabilité. Dès lors les GPU deviennent donc attractifs et on peut espérer tirer parti de ces accélérateurs, intéressants pour leur grande puissance de calcul théorique, leur prix modeste, ainsi que pour leur faible consommation malgré un système de refroidissement efficace. Les parties suivantes vont détailler l architecture des cartes NVIDIA sur lesquelles l ensemble du développement et des tests a été réalisé et en particulier les cartes K20Xm dont dispose le centre de calcul ROMEO NVIDIA - Kepler La série Tesla est le haut de gamme de NVIDIA dédié au calcul généraliste. Cette section présente la dernière architecture de cette série, nommée Kepler. Depuis le lancement de son framework CUDA, Kepler est la troisième architecture de GPU NVIDIA ; elle a été explicitement conçue pour le calcul à haute performance Architecture matérielle Contenant jusqu à 7,1 milliards de transistors gravés dans la nouvelle technologie de lithographie à 28 nm, l architecture Kepler offre une performance en double précision allant jusqu à 1.31 TFlops. Pour comparer avec la génération précédente, l architecture Fermi disposait de 3 milliards de transistors dans une puce gravée avec la technologie 40 nm, pour une performance en double précision moindre de moitié. Voici les détails techniques et comparatifs entre une carte Quadro 6000 d architecture Fermi et une carte K20Xm disposant de l architecture Kepler : Caractéristiques Fermi Quadro 6000 KEPLER K20Xm Compute capability Fréquence d horloge 574 MHz 732 MHz Performance en simple précision Gflops 3.95 Tflops Performance en double précision Gflops 1.31 Tflops Taille mémoire 6144 MB 6144 MB Bande passante mémoire (GB/sec) 143GB/s 250GB/s L architecture Kepler du GK110 est composée de 2880 unités de calcul élémentaires (les coeurs CUDA), organisées en 15 Streaming Multiprocessors (SMX) de 192 coeurs chacun 11. En comparaison l architecture Fermi ne comptait que 512 coeurs, organisées en 16 SM (Streaming Multiprocessors, 10. http ://romeo.univ-reims.fr SMX dans le cas des K20Xm 7

13 Julien Loiseau 2.1 NVIDIA - Kepler version Fermi) de 32 coeurs chacun (figure 9(a)). L architecture Kepler est actuellement déclinée en deux architectures : le K10 (512 coeurs) composé de 2 cartes GK104 ; K20 (2496 coeurs) et K20X (2688 coeurs) composé d une carte GK110 (voir figure 9(b)). L architecture d un Streaming Multiprocessor (SM/SMX) a beaucoup changé au cours du temps. Celle du Kepler (figure 10(b)) est composée de 192 coeurs CUDA en simple précision et 64 unités en double précision, 32 unités de SFU (Special Function Units 5), 32 unités d entrées/sorties (dédiées aux accès mémoire). (a) Fermi GF104 (mi 2010) (b) Kepler GK110 (fin 2012) c Figure 9 Fermi vs. Kepler : Architecture NVIDIA Un aspect innovant de l architecture Kepler réside dans la réduction de la fréquence d horloge des shaders. En effet dans l architecture Fermi le shader avait une fréquence double par rapport à celle du GPU. Cela permettait de soutenir un certain débit avec moins de copies de la part de l unité d exécution. Ainsi les ordonnanceurs et les unités de texturing opéraient à la fréquence des processeurs élémentaires (SP, Streaming Processor), alors que les unités d entrées/sorties (pour des lectures/écritures) et les SFU (Special Fonction Unit) opéraient à la fréquence du shader, donc deux fois plus vite que la fréquence du coeur. Mais cette implémentation est gourmande en énergie. C est pour cette raison que dans l architecture Kepler, les shaders fonctionnent à la même fréquence que le reste du coeur. Pour maintenir le même débit, la plupart des unités fonctionnelles ont été doublées afin de compenser la baisse de fréquence. Ainsi, les architectures de la gamme Kepler sont bien deux fois plus puissantes que les Fermi, mais pas quatre fois comme on l annonce parfois Modèle d exécution Le modèle d exécution SIMT (Single Instruction stream, Multiple Threads) proposé par NVIDIA est proche du modèle SIMD (Single Instruction stream, Multiple Data stream), mais il présente des 8

14 Julien Loiseau 2.1 NVIDIA - Kepler particularités importantes. L unité d exécution du code s appelle un kernel (noyau en français). Le kernel est exécuté simultanément sur un ou plusieurs SM ou SMX par l intermédiaire de threads regroupés dans des blocs. Chaque thread dispose de son propre environnement d exécution (espace d adresses, registres d état, mémoire locale). Ils sont cependant regroupés dans des warps, lots de 32 threads qui exécutent tous leurs instructions de façon synchrone. (a) Fermi SM (GF104) (b) Kepler SMX (GK110) Figure 10 Fermi vs. Kepler : Architecture d un StreamingM ultiprocessor c NVIDIA Chaque SMX contient 4 ordonnanceurs pour les warps et 8 unités pour l envoi des instructions (instruction dispatch units) permettant à 4 warps de s exécuter simultanément sur 2 instructions différentes au même cycle. L ordonnanceur est composé d unités matérielles spécialisées offrant par exemple : Un mécanisme de scoreboarding pour les registres dans le cas des opérations avec une latence importante (accès aux textures et chargement mémoire) ; Un mécanisme de décision pour choisir le meilleur warp parmi une liste des warps éligibles ; un mécanisme d ordonnancement au niveau des blocs. Caractère innovant de l architecture Kepler : En plus de ces structures matérielles, une importante partie de la puce de l architecture Fermi était dédiée à un mécanisme de scoreboarding pour éviter les aléas d acheminement des données pour les calculs mathématiques. Selon plusieurs études, les architectes ont conclu que cette information est déterministe (les latences du pipeline mathématique ne sont pas variables) et qu il serait possible pour le compilateur de déterminer à l avance l instant où une instruction est prête à être exécutée, et de stocker cette information dans l instruction elle-même. 9

15 Julien Loiseau 2.2 CUDA, Compute Unified Device Architecture Cela a permis de remplacer des unités matérielles complexes par des unités plus simples, capables d extraire les informations prédéterminées de la latence et de les utiliser pour déterminer les warps éligibles pour être exécutés Hiérarchie mémoire Pendant l exécution du kernel, les threads ont accès à différents espaces mémoire : shared memory : 48Ko de mémoire partagée disponible sur chaque SMX, qui permet de collaborer à l ensemble des threads qui s y exécutent. Cette mémoire partagée, organisée en 32 banques (banks, indépendantes pour accélérer les accès concurrents) et alimentée avec 16Ko cache L1. Cette mémoire partagée bénéficie d une latence réduite ; étant implémentée sur la puce, la vitesse d accès est équivalente à celle des registres [tant qu il n y a pas de conflit de banque entre les threads]. local memory : un maximum de 521Ko de mémoire privée disponible pour chaque thread, utilisée pour stocker des tableaux ou structures trop volumineuses pour être mises dans l espace des registres (register spill) ; cette zone mémoire se retrouve dans la mémoire globale du périphérique et est dont pénalisée par des temps de latence très important pour le chargement des données, bien que les dernières architectures favorisent les délais d accès par l utilisation de deux niveaux de caches mémoires (L1 et L2). global memory : un maximum de 6Go pour l ensemble de la carte GPU, répartis en 8 partitions partagées par tous les threads pendant toute la durée d exécution de l application ; l accès passe par des caches L1 et L2, ainsi que par un cache de données en lecture seule. constant memory : 64Ko de mémoire, en lecture seule, situés dans la mémoire globale du périphérique. L accès est accéléré grâce à 8Ko de cache spécifique par SMX mais, comme pour la mémoire locale, les temps d accès sont très pénalisants. texture memory : il s agit d un espace mémoire en lecture seule, situé dans la mémoire globale, optimisé pour des accès en deux dimensions (car accessible via les unités de texture). Comme la mémoire constante, cette mémoire est située dans la mémoire globale de la carte et les temps d accès sont donc défavorables, bien que les accès soient accélérés par l utilisation de caches mémoire spécifiques (huit caches L2 de 32Ko, un par partition DRAM ; 10 caches L1 de 24KB chacun, associés aux TPC, Texture Processor Cluster). 2.2 CUDA, Compute Unified Device Architecture Après avoir présenté ce que contenait exactement un GPU en terme de matériel, nous présentons maintenant les parties dans lesquelles le développeur intervient avec l utilisation de l architecture de traitement parallèle CUDA, développée par NVIDIA Langage de programmation En tant que langage de programmation, CUDA est une extension du langage C ou C++ [avec certaines restrictions]. Il permet de spécifier le code exécuté sur GPU (précisé dans des fonctions dites kernels) ainsi que les parties relevant du CPU : pré-traitements, transferts mémoire (CPU-GPU et GPU-CPU) et lancement des kernels Organisation des threads Tous les GPUs NVIDIA ont plusieurs processeurs et chacun d entre eux possède plusieurs coeurs, chacun de ces coeurs peut faire tourner des threads de manière indépendante. Ces threads sont re- 10

16 Julien Loiseau 2.2 CUDA, Compute Unified Device Architecture groupés au sein de blocs de une à trois dimensions. Ces blocs sont eux-mêmes regroupés au sein d une grille qui peut, elle aussi, avoir jusque trois dimensions. Le nombre de threads qui vont tourner est donc égal au nombre de threads par blocs, multiplié par le nombre de blocs par grille, voir Figure 11. Les threads se répartissent ensuite sur les SMX libres et se divisent alors en sous-groupes de k-threads appelés warps. Dans notre architecture (Kepler GK110), les threads se répartissent par groupes de 32 dans les warps. Figure 11 Organisation des threads CUDA c NVIDIA L organisation des threads est toutefois limitée par plusieurs facteurs (Kepler GK110) : la taille maximale d un bloc est de 1024 threads ; la taille maximale de la grille est de blocs ; seuls 16 blocs peuvent passer en même temps sur un même SMX ; des contraintes sur la place en mémoire et les registres entrent aussi en ligne de compte ; elles seront abordées dans la partie suivante. Les dimensions de la grille et des blocs ne sont pas imposés et peuvent être adaptées au problème traité pour répartir au mieux les tâches des threads par groupes. C est le GPU et non le développeur qui est en charge de la répartition des blocs et des threads sur le GPU. Les threads peuvent se placer sur n importe quel SMX libre puis dans n importe quel warp. Donc pendant l exécution le placement des ressources sur la carte n est pas déterminé à l avance. De même l exécution des blocs se fait de manière complètement indépendante. Entre les threads, des méthodes de communication sont toutefois possibles avec les méthodes de shuf f le ou encore les opérations atomic. Ces méthodes permettent de passer facilement d une architecture à l autre. En effet, 11

17 Julien Loiseau 2.2 CUDA, Compute Unified Device Architecture si le développeur respecte les conditions de la carte en terme de taille de bloc et de grille, la répartition se fera automatiquement sur la carte cible sans changement dans le code. Les threads CUDA sont ensuite répartis par groupes de 32 dans les warps. Ce sont ces warps qui s exécutent en Single-Instruction Multiple Thread (SIMT) ce qui veut dire que chaque thread exécute la même opération au même moment. Si le code comporte des embranchements comme des if, les threads vont être séquentialisés. C est à dire que pendant qu une partie des threads entrera dans le if, l autre partie attendra la fin de l exécution du if. Si le code comporte un else, ce sera ensuite à l autre partie des threads d attendre avant de reprendre le calcul de manière parallèle. Donc les conditionnelles sont possibles avec CUDA mais une utilisation trop importante avec trop de divergence verra les capacités de calcul s effondrer de par la séquentialisation du code. Pour demander l exécution sur le GPU d un ensemble de blocs et de threads, on utilise un kernel identifié par le préfixe global. Il défini le code que va exécuter chacun des threads. Pour permettre à chacun des threads de s identifier et de ne travailler que sur sa partie des opérations, des identificateurs sont disponibles : threadidx, comprenant trois dimensions et donnant la position du thread dans le bloc ; blockidx, pour la position du bloc dans la grille ; griddim, dimensions de la grille ; blockdim, dimensions du bloc. Une fois le kernel lancé les dimensions sont fixes. Les kernels s exécutent de manière asynchrone avec le CPU qui les ont lancés. Dans les anciennes version de CUDA, seul le CPU avait la possibilité de lancer des kernels mais sur l architecture Kepler le kernel lui même peut relancer dynamiquement plusieurs kernels[7]. On spécifie la taille de grille et de bloc au moment de lancer le kernel avec la syntaxe CUDA kernel grid,block (parametres) ce qui permet de changer les dimensions entre l exécution de deux kernels. Les fonctions device sont des fonctions uniquement utilisable par les fonctions global. Pendant l exécution, le programmeur à la possibilité de coordonner l ensemble des threads en utilisant une fonction de barrière similaire à celle de MPI, _synthreads(). L ensemble des threads du même bloc vont devoir attendre que chaque thread soit en synchronisation avant de poursuivre son exécution. De ce fait les threads qui auront un temps d exécution plus rapide devront attendre les plus lents. Le temps de calcul total sera donc la vitesse de calcul du plus lent des threads. La méthode _cudathreadsynchronize() va, quant à elle, attendre la synchronisation de l ensemble des threads de l ensemble des blocs qui s exécutent avant de poursuivre l exécution Gestion mémoire Dans l architecture de développement CUDA, le CPU et le GPU ont, de base, une mémoire complètement séparée. Tous les threads du GPU utilisent la mémoire GPU avec les parties que nous avons décrites précédemment. Le CPU doit donc dans un premier temps, charger l ensemble des données sur le GPU avant de lancer un kernel pour les utiliser. Les différents types de mémoire présentés peuvent être utilisés mais il faut bien garder à l esprit qu un bloc va s exécuter sur un SMX qui à une limitation en terme de registre par threads. Ainsi le SMX comporte au maximum registres qui doivent se partager entre les threads avec un maximum de 255 registres par threads. Pour ne pas utiliser qu une partie des ressources de la carte, NVIDIA a mis en place un système d occupancy qui est le rapport du nombre de warps actifs et du nombre de warps total. Cette valeur est censée permettre de trouver le 12

18 Julien Loiseau 2.2 CUDA, Compute Unified Device Architecture meilleur compromis entre taille de bloc et nombre de registres nécessaires pour une kernel. Des études ont montré [13] que l on peut toutefois avoir de bien meilleurs résultats avec une occupancy faible et que ce n est donc pas forcément l unique paramètre à prendre en compte. Voici un rappel des types de mémoire et leur utilisation : Memoire Localisation Cache Accès Visibilité Registre On-chip Non R/W 1 thread Locale Off-chip Non R/W 1 thread Shared On-chip? R/W tous les threads Global Off-chip Non R/W tous les threads Constante Off-chip Oui R tous les threads Texture Off-chip Oui R/W tous les threads Registre : Géré directement par CUDA ; Local : Toutes variables déclarées sans identifiants dans le kernel ; Shared : Variables avec l identifiant shared ; Global : Variables déclarées global en dehors du kernel. Les mémoire constantes et textures sont gérées en dehors du kernel avec un chargement mémoire spécifique. Comme sur un CPU, les allocations mémoire se font avec des fonctions de malloc, cudamalloc() et le chargement se fait ensuite par memcpy entre l host et le device, cudamemcpy(). Ces copies mémoires peuvent se faire dans les deux sens cudamemcpyhosttodevice ou cudamemcpydevicetohost. Pour des mémoires spécifiques comme la mémoire constante ou texture, le chargement est un peu différent et fait à appel à des fonctions spécifiques (cudamemcpytosymbol() et cudabindtexture()) Streams CUDA propose, depuis la version 2.0, l utilisation de plusieurs streams. Dans la version de base, les étapes de chargement en mémoire (H2D), de calcul (kernel) et de récupération du résultat (D2H) se font de manière synchrone. En effet le kernel ne peut pas calculer tant que l ensemble des données n est pas disponible sur le device et le résultat n est pas disponible avant la fin du calcul, voir Figure 12 Sequential version. En découpant ce flux de données et de calcul on peut commencer à charger une partie des données tout en calculant une autre partie. Un flux est un type cudastream. On utilise les fonctions de memcpy en mode asynchrone pour ne pas rendre ce chargement bloquant pour le GPU, cudamemcpyasyn(...,stream). On choisit donc dans quel stream on réalise le chargement. Pour la récupération du résultat l opération est la même. Le lancement du kernel est, de base, asynchrone mais s exécute sur le stream default. Au lancement du kernel, on choisit donc le stream kernel grille, bloc, memoire, stream (parametres). Sur la Figure 12, dans la version asynchrone on voit que le chargement des données est toujours séquentiel mais que le kernel peut s exécuter en parallèle d une opération mémoire, ici le temps de calcul est divisé de moitié. 13

19 Julien Loiseau 2.3 Cluster multi-gpu Figure 12 Utilisation des streams CUDA Les streams nécessitent un placement en mémoire spécifique entre l host et le device. Il faut utiliser de la «pinned memory». Ce sont des espaces ayant le même adressage sur l host et le device, ce qui accélère les transferts entre les deux acteurs. 2.3 Cluster multi-gpu L ensemble des tests de cette étude a été réalisé sur le cluster de calcul ROMEO. Ce cluster est composé d un ensemble de 130 nœuds (serveur hybrides CPU-GPU). Chaque nœud comprend deux "machines" : 1 CPU Intel Ivy Bridge de 8 coeurs 1 GPU NVIDIA TESLA K20Xm Cluster Noeud Noeud Noeud CPUs Noeud Noeud Noeud Machine GPUs Machine Figure 13 Cluster de calcul multi-gpu ROMEO 14

20 Julien Loiseau 3 Résolution arborescente sur architecture multi-gpu Les problèmes combinatoires peuvent donc être formalisés en CSP, comme abordé dans la partie 1, et représentés sous forme arborescente. Or ces problèmes se résument à traiter un nombre important de contraintes et l une des méthodes de résolution parallèle est de parcourir l arbre de recherche une fois divisé en tâches. 3.1 Régularisation, pour exécution sur GPU Malheureusement, comme nous l avons vu en partie 2.2, les threads du GPU ne supportent que difficilement l irrégularité qui génère des divergences. La version backtrack du parcours n est donc pas optimale pour une utilisation GPU et nous devons mettre en place une version régulière de la résolution. En effet, même si cela est plus long, on peut se permettre de descendre aux feuilles de l arbre systématiquement, même si cela induit un plus grand nombre de calculs. On réalise donc une vérification a posteriori des branches. Ces calculs sont gérés en parallèle grâce à l architecture GPU. Il n y a donc plus de backtrack, on descend dans l arbre jusqu à atteindre une feuille et on vérifie, une fois cette feuille atteinte, si la branche est valide. Auncun test n est opéré sur les nœuds durant la descente. L algorithme devient systématique, par l évaluation systématique de chacun des cas (algorithme 2) : Algorithm 2 Algorithme régularisé Début : Initialisation for domaine variable i do affectation variable i for domaine variable i 1 do affectation variable i 1 for... do... for domaine variable 0 do affectation variable 0 if nœud valide then ajouter aux solutions end if end for end for end for end for Fin 3.2 Hybridation des deux méthodes Les accélérateurs matériels sont forcément couplés à des CPU pour leur donner des tâches de calculs à gérer. La méthode standard de descente avec backtrack est très adaptée aux CPU et la méthode régulière aux GPU. On peut donc facilement répartir la charge de calcul entre les deux acteurs. Le 15

21 Julien Loiseau 3.2 Hybridation des deux méthodes CPU va générer des tâches à un certain niveau avec l algorithme de backtrack, une fois une certaine profondeur de calcul atteinte, la tâche de finir la descente de l arbre pourra être confiée au GPU avec l algorithme régularisé comme en Figure 14 (a). Cette méthode permet une mise en parallèle, le CPU prépare des tâches d une profondeur donnée pendant que le GPU traite une autre tâche. Cette méthode, scalable, peut être portée sur une architecture client-serveur. Le serveur a pour but de générer un certain nombre des sous-problèmes à une profondeur donnée avec la méthode de backtrack et de les distribuer aux clients. Ceux-ci peuvent ensuite continuer le parcours de l arbre avant de donner des tâches au GPU. Le schéma de parcours de l arbre client-serveur est présenté en Figure 14 (b). Backtrack Régulier (a) Partage du parcours Serveur Bakctrack Clients GPUs Régulier (b) Structure générale Figure 14 Détail et structure de la méthode 16

22 Julien Loiseau 4 Problème de Langford et implémentation Nous allons ici présenter le problème de Langford, référencé comme problème SAT. Nous développons ensuite notre implémentation du problème et l organisation globale du code. 4.1 Présentation On considère un nombre pair de cubes deux à deux de même couleur. On s intéresse aux arrangements de ces cubes de telle sorte que les écarts entre les deux cubes de chaque couleur sont non nuls et différents comme le montre la figure ci-dessous. Figure 15 Solution du problème de Langford à trois couleurs L objectif n est pas de trouver une solution mais le nombre total des solutions possibles pour un nombre n donné de paires de cubes. Nous noterons L(2, n) le nombre de solutions existantes pour un nombre de paires n, à une symétrie près. Par exemple, L(2, 3) = 1, et L(2, 8) = 150 Plus formellement Une suite de Langford est une variante d une suite de Skolem. Une suite de Langford d ordre n est une suite de 2n entiers, constituée des entiers de 1 à n répétés chacun deux fois, les deux occurrences d un entier k étant distantes de k + 1 (séparées par k autres entiers) Figure 16 Vue numérique du problème de Langford d ordre 4 La suite de Langford d ordre n, (L 1, L 2,..., L 2n ), présente les propriétés suivantes : pour chaque indice k [1,..n], il y a exactement deux indices i et j, tels que L i = L j ; si L i = L j = k avec i < j alors j i = k + 1. On connaît certaines propriétés des termes L(2, n) 12, mais on ne dispose pas de formule générale permettant de les calculer. La résolution du problème de Langford est un réel challenge de calcul et ce problème est référencé comme tel dans la CSPLib et la SATLib. Il existe différentes représentations du problème qui permettent de mettre en place différentes méthodes de résolution. Nous abordons ici la méthode dite de Miller, qui consiste en une résoution arborescente. 4.2 Approche de Miller Cette partie détaille l approche standard séquentielle. Elle consiste à parcourir en profondeur un arbre de recherche en se fondant sur les valeurs des cubes affectés à chaque position. On dispose de 2 n 12. par exemple, L(2, n) = 0 n 0[4] ou n 3[4] 17

23 Julien Loiseau 4.3 Implémentation positions pour le problème n. Les feuilles de l arbre constituent les solutions au problème de Langford. La construction de l arbre de recherche se fait en plaçant successivement chaque paire de cubes d une même couleur. Pour optimiser l élagage de l arbre, on place les paires dans l ordre décroissant de leurs valeurs. Les placements impossibles sont éliminés au fur et à mesure de la descente dans l arbre de recherche. (1,5) (2,6) (1,4) (2,5) (3,6) (1,4) (2,5) (3,6) (1,3)(2,4)(3,5)(4,6)(1,3)(2,4)(3,5)(4,6)(1,3)(2,4)(3,5)(4,6) (1,3)(2,4)(3,5)(4,6)(1,3)(2,4)(3,5)(4,6)(1,3)(2,4)(3,5)(4,6) Figure 17 Construction de l arbre de recherche à trois couleurs Cet algorithme donne de bons résultats mais, même en parallèle, les versions CPU classiques sont limitées en pratique au problème L(2,19). Pour atteindre les dernières instances, L(2,23) et L(2,24), il a été nécessaire de mettre en œuvre l encodage arithmétique de Godfrey. Dans cette étude nous entendons tirer parti de l équipement massivement parallèle du supercalculateur ROMEO de l URCA pour mettre en œuvre la version régularisée de la méthode de Miller, et prouver qu elle donne de bons résultats jusqu aux limites réalisées sur CPU. Pour aller au-delà, nous evisageons par la suite de porter sur GPU la méthode algébrique de résolution : cela fera l objet d une étude ultérieure. 4.3 Implémentation Dans cette partie nous décrivons l ensemble des choix d implémentation ainsi que les algorithmes retenus pour l implémentation sur GPU du problème Algorithme standard En nous fondant sur la méthode de Miller, nous avons contribué par la proposition d une structure de données adaptée : cet encodage très adapté permet d améliorer la performance de la résolution. Lors de la résolution, on cherche à placer une paire "sur" une combinaison partielle antérieure. On a par exemple à placer la paire des cubes 2 sur la combinaison partielle 4x3xx43x. Ce qui importe pour le placement d une nouvelle paire est de connaître les places libres : peu importent les valeurs des cubes placées sur les positions occupées. Représentation binaire et masques A chaque nœud de l arbre on fait correspondre un masque binaire dans lequel un 0 correspond à une case libre et un 1 à une case occupée. Le numéro et la position des paires importent peu. L essentiel est de savoir si l on peut oui ou non placer les paires suivantes. 18

24 Julien Loiseau 4.3 Implémentation Voici par exemple la représentation de deux placements : 4x3xx43x (affectation partielle de deux paires) x2xx2xxx (placement d une nouvelle paire) On dispose d une solution pour le problème n lorsqu on a pu placer la n ieme paire avec succès. On note qu une solution valide correspond à un masque dans lequel tous les bits sont à 1. Test d un placement Afin de vérifier qu il est possible de placer une paire de cubes à une position donnée, on opère un et bit à bit entre le masque existant et le masque représentant la paire à placer : et = Si le résultat de l opération est 0, la paire peut être ajoutée au masque. Dans le cas contraire, l ajout n est pas possible. Dès lors, il n est pas nécessaire de poursuivre plus avant dans le parcours de la branche ou du sous-arbre (d aucune de ses branches). Placement d une paire Si le test précédent est concluant, on insère la paire dans ce masque en calculant le ou binaire des deux masques : ou = Le parcours de l arbre se poursuit en utilisant le masque nouvellement construit. Algorithme standard Cette stratégie de modélisation et de construction de l arbre permet de mettre en place une méthode de résolution par backtrack en algorithme 3. Algorithm 3 Algorithme standard Début : Initialisation while!done do try if successf ul then lowerpair else end if end while higherpair Tenter de placer la paire courante Paire placée, on passe à la paire inférieure Pas de place on remonte d une paire La méthode présentée par cet algorithme, essaie de placer une paire (méthode try) avec un et binaire sur le masque courant. Si la position est disponible on insère la paire dans le masque avec un ou binaire. La recherche se poursuit sur la paire suivante. Quand un placement n est pas possible sur l ensemble du masque, on remonte à la paire précédente. 19