Équipe SATANAS Supports et algorithmes pour les applications numériques haute performance. Alexandre DENIS

Transcription

1 Équipe SATANAS Supports et algorithmes pour les applications numériques haute performance Alexandre DENIS

2 L équipe Satanas Deux équipes-projets INRIA RUNTIME Supports exécutifs performants pour architectures parallèles ScAlApplix Schémas et algorithmes hautes performances pour les applications scientifiques complexes

3 À propos des préoccupations quotidiennes de l équipe Satanas «Conception de supports d exécution pour machines parallèles» Outils pour faciliter le développement et accélérer l exécution des programmes sur des machines compliquées Domaine d application = Calcul intensif et simulation Sismologie, Nucléaire, Dynamique moléculaire, Météo, Combustion, Partenaires : CEA, EDF, IFP, Total,

4 Dassault Falcon 7X Entièrement conçu et dessiné par ordinateur

5 Simulation d un séisme dans les environs de Nice

6 Autres domaines applicatifs ayant donné lieu à des simulations de grande taille Simulation des instabilités d un plasma dans un tokamak (dans ITER avec le CEA Cadarache) Utilisation du solveur direct PaStiX Simultation de flux neutroniques dans un cœur de réacteur nucléaire (avec EDF) Méthodes de décomposition de domaines

7 Les ordinateurs «parallèles» Motivation La durée des calculs requis par une simulation serait énorme sur une station de travail La quantité de mémoire est également est insuffisante Machines parallèles «plusieurs processeurs utilisés conjointement» Idée : plus on est nombreux, plus le travail avance vite! Cela peut prendre plusieurs formes : Un PC contenant quelques processeurs Une machine spécialisée contenant beaucoup de processeurs Une grappe de PC Une grille de calcul

8 Machines parallèles contemporaines Quelle est la tendance?

9 Machines spécialisées Désormais appelée machines «massivement parallèles» Plusieurs centaines de milliers de processeurs Coût exorbitant, architecture spécifique peu évolutive

10 Grappes de PC (Clusters) Ensemble de PC reliés par un réseau rapide Les PC sont «normaux», juste un peu survitaminés Rapport performance/prix imbattable!

13 Les grilles de calcul Interconnexion de machines à l échelle d un pays d un continent de la planète Exemple Plate-forme expérimentale Grid sites Plusieurs grappes par site Plus de 5000 processeurs

14 Évolution des architectures parallèles Grappes de machines multiprocesseur Réseaux rapides Processeurs «banalisés» Programmation distribuées «à plat» Parallélisme à gros grain Modèle à mémoire distribuée

15 Pourquoi une telle percée des grappes? Bla-bla habituel Architecture évolutive Facile à programmer Extension de la mémoire des PC, ajout de nouveaux PC, etc. Matériel familier Vraie raison : rapport performance/prix excellent Les grappes bénéficient de l évolution des processeurs «banalisés» Intel, AMD, IBM, Sun On retrouve ces processeurs dans les stations de travail et les consoles de jeux! C est dans ce domaine que les évolutions sont les plus spectaculaires

16 Gordon Moore a toujours raison

17 Les vertus de la finesse de gravure La fréquence augmente En tout cas, c était vrai jusqu à il y a peu La dissipation thermique et la consommation deviennent problématiques Mais surtout, il y a de la place pour de nouveaux circuits Caches Exécution dans le désordre Prédicteurs en tous genres Analyse de dépendances (renommage des registres) Exécution spéculative (branchements, préchargements) Unités de calcul supplémentaires?

18 Les limites de l «ILP» ILP = Instruction Level Parallelism Mais un flot séquentiel reste une suite d instructions souvent désespérément séquentielles! Pas assez de parallélisme détectable «localement» Les pipelines demeurent sous-utilisés Il serait vain d ajouter encore des pipelines parallèles à moins que?

19 Les processeurs multicœurs = plusieurs processeurs gravés sur une même puce Puce bi-cœurs avec 4 voies Caches externes parfois partagés Tendance nette chez les constructeurs Intel core 2 Duo, Itanium 2 Montecito, Intel Terascale à 80 cœurs! AMD dual-core Opteron IBM Power5 SUN Niagara

20

21 Impact de l évolution des processeurs Puces multicœurs Architecture hiérarchique Topologie complexe Accès non uniformes Retour à l ère des machines CC-NUMA? Grappes de machines multicœurs Pas juste un niveau hiérarchique de plus

22 Et les machines multiprocesseurs? Elles sont majoritairement «à mémoire commune» Il suffit donc de relier plusieurs processeurs à (au moins) un banc mémoire proc proc proc proc mémoire Architecture à accès mémoire uniforme

23 Avec des processeurs multicœurs Les échanges entre processus deviennent non uniformes Données, synchronisations mémoire

24 On peut hiérarchiser davantage Mémoire directement attachée aux puces AMD HyperTransport, Intel QuickPath Interconnect mémoire mémoire mémoire mémoire Architecture à accès mémoire non uniforme (NUMA)

25 Vers des architectures hiérarchiques complexes Vers des machines de plusieurs centaines de processeurs Tout le monde n est pas directement connecté à tout le monde mémoire mémoire Ex: machine Tera10 du CEA/DAM réseau

26 Programmation parallèle contemporaine Les machines sont difficile à exploiter Pendant longtemps, l évolution des microprocesseurs a permis d accélérer les calculs sans effort de la part des programmeurs Aujourd hui, le matériel demande des efforts énormes aux programmeurs Qui n y sont pas habitués :-)

27 Comment exploiter efficacement de telles architectures de manière portable?

28 Algorithmes, méthodes et environnements pour le calcul intensif ScAlApplix High Performance Computing Applications Algorithms, Specific Libraries 1 2 Runtime System Operating System Hardware 1 : transmettre au support d exécution toutes les informations issues de la connaissance fine des algorithmes 2 : garantir la portabilité des performances en augmentant l expressivité des interfaces RUNTIME

29 Modélisation de l architecture

30 Modélisation de l architecture

31 Notion de bulle pour exprimer des affinités Réification de la structure des applications Partage de données Opérations collectives... 47

32 Notion de bulle pour exprimer des affinités Réification de la structure des applications Partage de données Opérations collectives... Certaines bulles peuvent être moins élastiques que d autres 48

33 Exemple d exécution réelle Génération de trace légère pendant l exécution Bibliothèque FxT (Fast User/Kernel Traces) co-développée avec UNH Conversion de la trace en animation flash

34 Le standard OpenMP Extension de langages permettant de paralléliser des programmes séquentiels Objectif = parallélisation incrémentale + portabilité Directives de compilation (C, C++, Fortran) + routines spécifiques V1.0 en , V2.5 en mai 2005 Plusieurs propositions d extensions NUMA sont candidates pour la version 3.0 Modèle de programmation Type «Fork-Join», parallélisation des blocs et des boucles

35 Parallélisation des boucles int main() { int i; double m[n]; #pragma omp parallel for for(i=0; i<n; i++) m[i] = f(i); do_something(m); } Le nombre de threads générés par le compilateur est contrôlable En pratique, les utilisateurs le fixent systématiquement

36 À propos du modèle fork/join Thread maître Exécute le code séquentiel Fork : création de threads esclaves Thread maître Fork Threads esclaves Exécutent la portion parallèle Join : destruction des esclaves et retour du contrôle au maître Threads esclaves Join Le nombre d esclaves peut varier d une région parallèle à l autre Technique bien adaptée à la parallélisation incrémentale d un code Fork Join

37 Idée : modifier un compilateur OpenMP pour utiliser BubbleSched Supporter davantage de threads que de processeurs Meilleur contrôle du grain, effets de, équilibrage de charge

38 Mise en œuvre dans GOMP Portage de GNU OpenMP sur les threads Marcel/BubbleSched Compatibilité binaire avec les applications OpenMP existantes Code OpenMP Binaire GNU OpenMP Interface GOMP libgomp Threads GOMP pthreads BubbleSched

39 Évaluation à l aide d une application irrégulière Reconstruction de surface implicite Objectif : trouver une fonction mathématique approximant la surface d un objet défini par un nuage de points

40 Principe de l algorithme séquentiel Approximer la surface par des fonctions quadriques «locales»

41 Principe de l algorithme séquentiel Subdiviser l espace lorsque la précision est insuffisante (ici en 2D)

42 Parallélisation en OpenMP void Node::compute(){ computeapprox(); if(_error > _max_error){ splitcell(); #pragma omp parallel for for(int i=0; i<8; i++) _children[i]->compute(); } }

43 Accélération sur 16 cœurs NPTL nested Marcel nested Affinity

44 Vers des architectures hétérogènes Utilisation d accélérateurs de type GPU Processeurs SIMD très puissants Nombreuses success stories Intégration on-chip IBM Cell/BE 1 PPU + 8 SPUs Intel Larrabee 48 cœurs avec unités SIMD

45 Vers des architectures vraiment hétérogènes Modèle de programmation Jeu d instruction spécialisé Modèle d exécution SIMD Mémoire Taille limitée Pas de cohérence par le matériel Transferts de données explicites Doit-on se réjouir? Mixed Large and Small Core

46 Exploitation des architectures hétérogènes L environnement StarPU CPU+GPU+SPU=*PU Scheduling vs offloading Ordonnancement dynamique de tâches Sur l ensemble des unités de calcul Minimisation des transferts de données A = A+B Mémoire virtuellement partagée hiérarchique Modèles de coûts CPU CPU GPU M. GPU M. B CPU CPU M. BM. CPU CPU CPU CPU SPU SPU SPU SPU SPU SPU A M. AM.

47 Exploitation des architectures hétérogènes Plateforme d ordonnancement ouverte Excellente efficacité Écart raisonnable avec des codes optimisés manuellement Pas de limitation sur la taille des données Diffusion Plateforme de base du projet européen PEPPHER Speed (GFlops) Greed y task model pref etc h data model

48 Conclusion et perspectives Du pain sur la planche

49 Conclusion Les constructeurs de microprocesseurs nous donnent du fil à retordre! Gestion du parallélisme (bientôt massif!) reportée au niveau logiciel Puissance soutenue de plus en plus éloignée de la puissance théorique! Les supports exécutifs doivent suivre Gérer efficacement un grand nombre de flots d exécution simultanés Permettre le contrôle de l ordonnancement Inciter le programmeur à exhiber le plus de parallélisme possible Mais le chemin est encore long! Majorité de programmes écrits en Fortran+MPI Imposer un nouveau modèle de programmation, c est long! 62

50 Et demain? Améliorer l articulation entre compilateurs, supports d exécution et matériel Extraction d informations Collecte d informations Quantification des affinités, schémas de synchronisation Compteurs de performance, accès mémoire/ Maîtriser les évolutions matérielles Architectures multicœurs hétérogènes Architectures dépourvues de cohérence de Accélérateurs spécialisés

51 Supports d exécution pour les nouvelles générations de machines Évolution inquiétante des architectures Machines «embarrassingly parallel», architectures hétérogènes Importance du savoir-faire «de fond» Principaux défis CPU CPU GPU M. GPU M. CPU CPU M. M. Ordonnancement hiérarchique Directives, affinités, compteurs matériels Communications sur topologies complexes Granularité adaptative CPU CPU Modèles hybrides Compilation et Auto-tuning CPU CPU M. M. X

52 Merci! Davantage d information ici :