Calcul scientifique haute performance sur GPUs.

Calcul scientifique haute performance sur GPUs. David Michéa(1), Dimitri Komatitsch(2,3), Gordon Erlebacher(4) and Dominik Göddeke(5) Portage de SPECFEM3D (SEM) sous CUDA + MPI Portage CUDA du code différences finies ONDES3D (1) BRGM, Orléans, France (2) University of Pau, CNRS and INRIA Magique3D, Pau, France (3) Institut universitaire de France, Paris, France (4) Florida State University, USA (5) TU Dortmund, Germany

SPECFEM3D Dimitri Komatitsch Jeroen Tromp David Michéa Min Chen Vala Hjörleifsdóttir Sue Kientz Qinya Liu Alessia Maggi Brian Savage Bernhard Schuberth Leif Strand Carl Tape Jesus Labarta But : modéliser la propagation d ondes sismiques dans la terre entière ou dans des régions densément peuplées à la suite de grands tremblements de terre SPECFEM3D est open source (GNU GPL v2) Le code Fortran original sans CUDA a été principalement développé par Dimitri Komatitsch and Jeroen Tromp à l université de Harvard, Caltech et Princeton (USA) et à l université de Pau (France) depuis 1996 Il a été optimisé avec le Barcelona Supercomputing Center, Espagne (Jesus Labarta et al.) et David Michéa de l INRIA (HPC-Europa program, 2007)

Spectral-Element Method Developed in Computational Fluid Dynamics (Patera 1984) Introduced for 3D elastodynamics by Komatitsch et al., Chaljub et al. Large curved spectral finite-elements with high-degree polynomial interpolation: accuracy of a pseudospectral method, flexibility of a finiteelement method Mesh honors the main discontinuities (velocity, density) and topography Very efficient on parallel computers, no linear system to invert (diagonal mass matrix) Curved 27-node elements are mapped to unit cube provides efficient way of capturing curvature of sphere, and accuracy for surface waves High-degree pseudospectral finite elements: Number of integration Gauss Lobatto Legendre (NGLL) points = 5 to 9 usually

Maillage : une sphère cubique Gnomonic mapping (Sadourny 1972) Ronchi et al. (1996), Chaljub (2000) Analytical mapping from six faces of cube to unit sphere

Structure du code A chaque itération de la boucle en temps, trois principaux types d opérations sont effectuées : Mise à jour (sans dépendances) de tableaux globaux composés de points uniques du maillage Calculs purements locaux du produit de matrices de dérivations prédéfinies avec une copie locale des vecteurs déplacements le long de plans de coupes dans les 3 directions (i, j & k) d un élément spectral 3D Mise à jour (sans dépendances) d autres tableaux globaux composés de points uniques du maillage

Numérotation locale vs numérotation globale En 3D et pour NGLL=5, pour un maillage hexahédrique régulier, il y a : 125 points d intégration dans chaque élément 27 appartiennent uniquement à cet élément 98 appartiennent à plusieurs éléments Problème : on doit sommer les contributions locales dans les tableaux globaux

Coloriage du maillage Problème : s assurer que les contributions de deux noeuds locaux n impactent jamais le même point global à partir de différentes warps. Utilisation du coloriage : supprimer les dépendances entre les points du maillage dans un même kernel

Parallélisation avec MPI Ancien schéma de communication (MPI bloquant) Mise à jour effectuées directement dans les tableaux Tous les éléments sont calculés avant l envoi des messages Nouveau schéma de communication (MPI non bloquant) Mise à jour effectuées d abord dans les buffers Les messages sont envoyés après le calcul des éléments externes A B A B C D C D Coût des communications pour la version CPU ~ 5%, Sur la version TESLA GPU, avec un speed-up de 15, le coût des communications ~44% > Nécessité d utiliser des communications MPI asynchrones. > Les communications MPI sont bien recouvertes par le calcul sur GPU.

Schema des 2 versions sans MPI (v2 : out of GPU core)

Schema avec MPI

Coalescence des accès en mémoire globale Dans les kernels 1 & 3, Tous les accès sont parfaitement coalescés Dans le kernel 2, Tous les accès aux tableaux locaux sont parfaitement coalescés (125 pts alignés sur 128 floats) Par contre, Lors de l accès aux tableaux globaux dans le kernel 2, l indirection nécessaire pour gérer la topologie non structurée du maillage (ie local global) entraîne des accès non-coalescés inévitables.

Optimisation du code CPU : défauts de cache V4.0 => Il est crucial de réutiliser les points communs en les gardant dans le cache V4.0 V3.6

Résultats - Accélération Mesh size GTX 280 8800 GTX Version 1 Version 1 Version 2 Time / element Speedup Time / element Speedup Time / element Speedup Transfer time 65 MB 0.94 µs 21.5 1.5 µs 13.5 4.2 µs 4.6 68% 405 MB 0.79 µs 24.8 1.3 µs 15 3.7 µs 5.3 68% 633 MB 0.77 µs 25.3 1.3 µs 15 3.7 µs 5.3 67% Le speedup final pour le code CUDA + MPI est de 25x Les performances se dégradent pour les trop petits modèles, le nb d éléments dans chaque couleur doit être > 1024

Validation

Portage sous CUDA du code différences finies ONDES3D ONDES3D est un programme qui simule la propagation d ondes sismiques dans un milieu élastique hétérogène. Il utilise la méthode des différences finies du 4eme ordre. Il a été écrit par Hideo Aoschi & Arianne Ducellier du BRGM. Il implémente les couches absorbantes C-PML de D.Komatitsch and R.Martin (Geophysics, 2007)

Structure du code <initializations/> <time loop> <update source momentum/> CPU <memcpy H->D (few data)/> <compute velocity vector from stress tensor/> <compute stress tensor from velocity vector/> <memcpy D->H (few data)/> <record seismograms/> CPU </time loop> GPU GPU Toutes les structures de données sont hébergées sur le GPU, à l exception des sismogrammes.

Stencil différences finies du 4eme ordre Méthode des différences finies : un méthode simple mais une implémentation délicate sur GPU > Le stencil de calcul conduit à une forte redondance de lecture > Nécessité d utiliser massivement la mémoire partagée

Topologie du bloc de points (1 thread par point) > Pour un bloc de points à calculer, besoin de connaître les valeurs d un «halo» de points autour > Il faut réduire le ratio halo_points / block_points pour réduire la redondance de lecture > Approche intuitive : des blocs 3D qui minimisent ce ratio > Problème : pas assez de mémoire partagée pour avoir des blocs 3D assez gros pour avoir un bon ratio.

Algorithme à fenêtre coulissante Utilisation de l approche de P. Micikevicius de NVIDIA (2009) : un algorithme à fenêtre coulissante > Utiliser un pavage 2D au lieu des blocs 3D et boucler sur l axe Z. > En 2D, il y a assez de mémoire partagée pour avoir des pavés suffisamment gros pour obtenir un bon ratio entre les points calculés et les points du halo. > Les données suivant l axe Z sont décalées en registres à chaque itération suivant un mécanisme de pipeline => à part pour les halos, les données d un point ne sont chargés qu une fois depuis la mémoire globale à chaque itération (en temps).

bloc 2D On utilise un thread par point dans le plan xy et on le pave avec des blocs de 16x8 threads. Pour un bloc : 4*16+4*8+16*8 données chargées par 16*8 threads => 1.75 accès en mémoire globale / thread pour chaque itération

Schema de fonctionnement des kernels

coalescence des accès mémoire (globale) Pour notre carte NVIDIA 8800 GTX, D après le CUDA Programming Guide, l accès en mémoire globale par tous les threads d une half-warp est coalescé en une transaction mémoire s il satisfait ces 3 conditions : Les threads doivent accéder des mots de 32 bits, résultant en une transaction mémoire de 64 octets. Ces 16 mots doivent se trouver dans le même segment de taille égale à la taille de la transaction mémoire Les threads doivent accéder ces mots séquentiellement. => Le profiler CUDA nous donne gst_uncoalesced = 0. Les lectures ne sont pas coalescées pour les halos, ni pour les C-PMLs qui sont accédées via une indirection pour ne pas gâcher de mémoire.

Speedup Speedup : de 40x à 50x Le speedup dépend de : > l épaisseur des C-PMLs: si l épaisseur des C-PML n est pas multiple de 16 (blockdim.x), les threads d une half-warp divergent dans les C-PMLs. > Dimensions du modèle Si la largeur du modèle n est pas multiple de 16 (blockdim.x), certains threads sont inactifs et les threads d une half-warp divergent pour les C-PMLs situées à droite.

Scaling Le scaling suivant Z est quasi linéaire. Malgré les accès coalescés, le scaling suivant X (en terme de nb de blocs) n est pas régulier. Ceci est probablement dû à des exigences hardware non documentées.

Validation

Conclusions & perspectives > Portage réussi de codes FD & SEM sur grappe de GPUs > Les résultats sont satisfaisant en terme d accélération > Les principales limitations ont été les ressources internes de la carte (registres + shmem), particulièrement si nous voulons ajouter d autres paramètres comme de l atténuation (l occupancy pour ONDES3D est de 0.166, principale limite : le nombre limité de registres) > Nous avons réalisé un premier prototype de couplage calcul-visualisation interactif qui nous permet de visualiser la simulation tournant sur notre grappe de GPU en temps réel sur notre banc de réalité virtuelle et d interagir avec celle-ci. > Nous n avons pas encore testé nos codes sur la nouvelle architecture FERMI de NVIDIA à voir > Si le BRGM devait s investir durablement dans le GPGPU, le prochain projet se fera en utilisant le standard OpenCL.