MDE4HPC : une approche modèle pour la simulation numérique

Télécharger le fichier original (Mémoire de fin d’études)

Simulation numérique et calcul haute-performance

Lors de la conception d’une théorie ou d’un produit, il est parfois trop couteux, long, dangereux ou tout simplement impossible de réaliser toutes les expérimentations ou proto-types qui permettraient de valider les choix eﬀectués. La simulation numérique en se basant sur des modèles physiques et mathématiques oﬀre une alternative séduisante pour la vali-dation de ces choix de conception. C’est pour cette raison que l’utilisation de la simulation numérique ne cesse de prendre de l’ampleur dans le monde. Certains États la considèrent comme un élément clé de la course à la compétitivité que leurs entreprises doivent mener sur la scène internationale [6, 205].
La prochaine étape majeure pour la communauté du calcul haute performance est le franchissement de l’exascale, soit la mise en production d’un supercalculateur capable d’eﬀectuer 1018 opérations à virgule-flottante par seconde. Par rapport au K Computer, le supercalculateur le plus puissant en 2012 selon le classement des 500 plus gros calculateurs [154], il nous reste à améliorer les performances par un facteur 100 pour franchir ce seuil. Toutes les grandes puissances mettent en place des programmes de recherche visant à développer les composants matériels et logiciels nécessaires au franchissement de cette étape qui, conformément aux prévisions actuelles, devrait se produire aux alentours de 2020 [72].

Univers de la simulation numérique

De notre perception de la réalité à la machine

Le développement d’un logiciel de simulation numérique comportent plusieurs étapes qui sont présentées dans la figure 2.1. La première étape consiste à choisir un modèle physique permettant de représenter notre perception d’un objet ou d’un phénomène réels.
Pour une majorité de ces modèles, une résolution analytique n’est pas possible. Dans ce cas, on a recours à une technique de résolution approchée du système d’équations physiques. Afin de pouvoir exécuter le modèle mathématique de résolution par un ordinateur, il est nécessaire de créer une implémentation logicielle via un langage de programmation adapté à la machine cible. Et c’est finalement à l’issue de cette ultime étape que nous pouvons exécuter nos scénarios de simulation sur les calculateurs compatibles. Malheureusement, et nous y reviendrons en détails dans la section 2.1.3, il est existe une adhérence plus ou moins forte entre le logiciel de simulation et le calculateur cible.

Programme Simulation

En 1996 la France a définitivement arrêté les essais nucléaires. Afin de garantir la fiabilité et la sûreté des têtes nucléaires sur le long terme, le programme Simulation a été mis en place [1]. Ce dernier vise à reproduire par le calcul les diﬀérentes phases de fonctionnement d’une arme nucléaire. Il se décompose en trois volets que sont : la physique des armes, la validation expérimentale et la simulation numérique qui nous intéresse plus particulièrement dans notre cas. De la complexité et de la précision des modèles développés par les scientifiques du CEA/DAM découlent des besoins colossaux en puissance de calcul. Le programme Tera [99] a été mis en place afin de fournir les moyens de calcul nécessaires au volet simulation numérique du programme Simulation. Dans le cadre de ce dernier, le principal supercalcu-lateur du CEA/DAM est remplacé tous les quatre ans avec un objectif d’accroissement des performances par un facteur supérieur à dix. La figure 2.2 présente le précédent modèle, Tera-10 ainsi que son successeur Tera-100 en production depuis juin 2012. Il est intéressant de noter deux faits parmi les chiﬀres présentés dans cette figure : – Performance : en 1965 [158] Gordon Moore fit l’une des prédictions les plus vision-naires de toute l’histoire de l’informatique. Il modifia son propos en 1975 [159] et énonça que le nombre de transistors des microprocesseurs sur une puce de silicium doublerait tous les deux ans. Son propos originel a été altéré à maintes reprises et l’on considère de nos jours que la loi de Moore décrit le doublement de la performance tous les 18 mois.
À présent si l’on regarde le dernier changement de machines du programme Tera, on constate que les performances entre les deux versions ont été améliorées par un facteur 20 en 4 ans alors que sur la même période la loi de Moore prédit un facteur d’augmentation de 4. Avec un tel rythme, des ruptures technologiques matérielles apparaissent.
– Obsolescence : prenons l’exemple de la machine Tera-10, lors de son premier classe-ment au TOP500 [154]. Elle figurait parmi les cinq supercalculateurs les plus puis-sants au monde. Seulement six mois plus tard, elle se trouvait déjà à la 12e place du classement. Au bout de quatre ans et demi, elle était reléguée dans la deuxième partie du classement.
Face à cette obsolescence fulgurante, on comprend qu’un renouvellement fréquent est inéluctable, ne serait-ce que pour des raisons énergétiques, puisque l’évolution de la performance par watt des calculateurs suit une tendance proche de la loi de Moore [158] (qui s’applique seulement à l’évolution de la performance). En eﬀet, on constate qu’un des aspects de ces machines qui revêt de plus en plus d’importance est la consommation électrique. À titre de comparaison, la puissance électrique nécessaire au K Computer évoqué précédemment est de 12,7 Mw soit plus que la production électrique d’un petit pays comme le Togo. Signe de la prise de conscience de l’impor-tance de la consommation électrique, le GREEN500 [86], un nouveau classement des supercalculateurs en fonction de leur performance par watt a été créé.

Limites du modèle actuel

Dans cette quête eﬀrénée vers toujours plus de puissance de calcul, une question sub-siste : serons-nous capable d’exploiter nos logiciels de simulation eﬃcacement sur ces futures machines?
Au cours de la dernière décennie, les fabricants de microprocesseurs se sont heurtés aux limites physiques des technologies de gravure actuelles [185] avec pour conséquences de sérieux problèmes de dissipation de chaleur et de synchronisation de données. Ces limita-tions les ont contraint à revoir en profondeur la conception de l’architecture des processeurs. C’est pour cette raison que l’on a assisté à l’émergence d’architectures parallèles au sein même des microprocesseurs grand public : les processeurs multicœurs. L’hégémonie de ces nouvelles architectures sonne le glas du modèle de programmation séquentiel en tant que tel puisqu’il ne permet pas de tirer pleinement parti de la puissance de ces nouveaux pro-cesseurs. Ce changement de paradigme est en train de modifier profondément les habitudes de développement des logiciels courants.
A contrario, la communauté du calcul haute performance est coutumière de la program-mation d’architectures parallèles puisque elles sont présentes dans les calculateurs depuis la fin des années 1980. Malheureusement les pratiques actuelles de programmation paral-lèle dans ce milieu se situent à un bas niveau d’abstraction. Bien qu’un bon niveau de performance puisse être atteint avec la plupart de ces approches, un certain nombre d’in-convénients apparaissent en termes de dépendances vis-à-vis de l’architecture, de mélange des préoccupations et de complexité de programmation : Problème No 1 Dépendance vis-à-vis de l’architecture
Dans le cas du CEA/DAM, l’expérience nous montre qu’en moyenne les modèles de simulation numérique associés à nos problématiques ont une espérance de vie de l’ordre de vingt à trente ans et doivent donc être maintenus sur cette période. De façon identique aux autres types de logiciel, toutes les contraintes liées à la mainte-nance logicielle sur de longues périodes doivent être prises en compte. On peut citer, par exemple, le renouvellement des équipes de développeurs ou l’obsolescence des technologies logicielles. Il y a cependant une contrainte propre à notre domaine qui est la nécessité de réaliser des portages lourds avec une fréquence élevée. En eﬀet, dans la présentation du programme Tera (Partie 2.1.2) nous avons évoqué un changement de machines tous les quatre ans avec parfois des diﬀérences prononcées d’architec-ture. La figure 2.3 [143] résume clairement la situation, la durée de vie des ressources matérielles est cinq à sept fois plus courte que la durée de vie des applications propres à notre domaine.
Malheureusement les applications de simulation numérique sont mal armées face à ces fréquents changements. Comme nous allons le voir dans la partie 2.2, les ar-chitectures des supercalculateurs sont très spécifiques. L’utilisation de modèles de programmation très proches du niveau de la machine pour exploiter finement et avec eﬃcacité ces spécificités induit une dépendance forte entre le logiciel et sa plateforme d’exécution. C’est pour cette raison que la complexité de portage d’un logiciel de simulation entre deux supercalculateurs peut être élevé afin de conserver des propriétés de performance satisfaisantes.
On peut observer dans la figure 2.2 un eﬀet collatéral provoqué par ces portages complexes : la machine Tera-10 est restée en production simultanément à Tera-100 pendant un an. La performance par watt et la puissance bien supérieure de Tera-100 suggèrent logiquement une mise hors tension rapide de Tera-10, or ce n’est pas le cas.
Ce délai se justifie par la nécessité d’eﬀectuer le portage entre machines et surtout de s’assurer de la validité du portage puiqu’il serait désastreux qu’un changement de machine provoque une dégradation à l’égard des fonctionnalités.
Les Problème No 2 Mélange des préoccupations/manque de formalisme diﬀérentes étapes du processus de développement d’un logiciel de simulation numérique ont été présentées dans la figure 2.1. L’implémentation logicielle du modèle mathématique de résolution (schéma numérique) contient à la fois des informations relatives aux modèles physiques et mathématiques ; et des informations relatives à la gestion de la plateforme d’exécution. Ces instructions concernant la partie purement informatique (gestion des données et du parallélisme) sont entrelacées avec des instructions concernant la résolution des modèles physiques. Cet enchevêtrement amène son lot de problèmes :
– la capitalisation sur les connaissances qui vise à sauvegarder le savoir-faire acquis par un individu lors de sa carrière dans une entreprise est impactée par le mélange des préoccupations et le manque de formalisme des techniques de développement actuelles qui ne fournissent pas une vision facilement compréhensible de la conception des diﬀérents artéfacts logiciels. Le turn-over des équipes de développement est problématique puisque une partie de la connaissance part avec la personne.
– les phases de portage présentées précédemment sont profondément aﬀectées puisque les instructions concernant diﬀérents aspects sont complètement mélangées. Sachant que lors d’un changement de machine les modèles physiques et mathématiques n’ont pas de raison d’être modifiés, il est diﬃcile d’identifier et de mettre à jour les parties informatiques sans altérer ces derniers.
– pour les mêmes raisons que la maintenance adaptative évoquée à l’instant, la maintenance corrective et la maintenance évolutive se voient compliquées.
– l’imbrication des diﬀérents aspects (mathématiques, parallélisme) provoque un manque de modularité qui freine la réutilisation entre projets.
Complexité de programmation Lors de l’établissement d’un profil Problème No 3 développeurs d’applications de simulation une tendance émerge : la plupart type des d’entre eux ne possèdent pas un bagage informatique très important, notamment en génie logiciel puisqu’ils ont accompli des études longues en mathématiques appliqués ou dans le domaine d’application de la simulation. Ils sont par contre souvent familiers avec les langages dédiés très proche du formalisme mathématique tel que le langage MATLAB [4].
D’un autre coté le développement d’une simulation parallèle requiert beaucoup plus de connaissances informatiques qu’un développement standard de logiciel. Bien que nous aborderons le sujet plus en détails, il est judicieux de mentionner que l’on as-siste aujourd’hui à une diversification des langages et bibliothèques de programmation parallèle en corrélation avec la diversification des architectures parallèles. Cette pro-fusion de nouveautés restreint l’utilisation de ces nouvelles architectures à quelques développeurs ou scientifiques prêts à investir du temps dans l’apprentissage de leurs spécificités matérielles et logicielles.
Au final, on demande aux développeurs de simulation numérique l’assimilation de beaucoup de concepts qui les empêchent de se concentrer sur leur cœur de métier sur lequel ils pourraient apporter le maximum de valeur ajoutée.

Architectures des supercalculateurs

La compréhension des contraintes inhérentes aux applications de simulation numérique nécessite une connaissance des architectures matérielles et de leurs évolutions. Il n’est en eﬀet pas possible de décorréler l’analyse des systèmes logiciels de celle des supports d’exé-cution. Cette partie s’attache donc tout d’abord à proposer une classification des diﬀérentes architectures matérielles tout en présentant les concepts clés du domaine. Après un rapide historique des types d’évolution auxquels nous avons assisté depuis les années 1960 jus-qu’aux années 2000, nous terminerons par un tour d’horizon des évolutions possibles pour le futur.

Classification des architectures

Il existe plusieurs façons de catégoriser les diﬀérentes architectures matérielles. L’ap-proche la plus courante se base sur la taxonomie définie par Flynn en 1972 [88]. Nous commencerons donc par présenter cette dernière. Cependant son manque de précision dans notre cadre nous amènera à introduire des concepts additionnels afin d’étendre sa portée.

Taxonomie de Flynn

La taxonomie de Flynn classifie les architectures en fonction de leur nombre de flots d’instructions et de flots de données. Sachant que cette taxonomie ne prend en compte que la diﬀérence entre flot unique et flots multiples, on obtient quatre combinaisons possibles :
– Single Instruction, Single Data (SISD) : cette architecture, présentée dans la figure 2.4, est la plus simple puisque la notion de parallélisme n’intervient au niveau ni des données, ni des instructions. Il n’y a qu’une seule unité d’exécution pour produire les résultats. Cette catégorie correspond à l’architecture dite de Von Neumann et définie par ce dernier dans son rapport [210] paru en 1945 sur la conception logique de l’ordinateur EDVAC (Electronic Discrete Variable Automatic Computer).
– Single Instruction, Multiple Data (SIMD) : cette catégorie regroupe les architec-tures qui permettent d’appliquer un unique traitement (instruction) à un ensemble de données comme décrit dans la figure 2.5. Ces architectures sont donc particulièrement adaptées au calcul vectoriel. L’architecture actuelle des processeurs graphiques aussi appelés graphics processing unit (GPU) est partiellement basée sur cette approche.
– Multiple Instruction, Single Data (MISD) : ce type d’architecture est très peu courant. En eﬀet on cherche à appliquer des traitements multiples sur une donnée unique, les applications sont de ce fait limitées.
– Multiple Instruction, Multiple Data (MIMD) : on termine par la catégorie rencontrée le plus fréquemment. Eﬀectivement la plupart des systèmes parallèles actuels peuvent être placés dans cette catégorie. Comme le met en avant la figure 2.6, ce type d’architecture comprend plusieurs unités d’exécution qui possèdent chacune leur propre flot de données. Cette définition permet beaucoup de marge de manœuvre et regroupe par conséquent des systèmes très variés. C’est pour cette raison que la prochaine partie s’attachera à caractériser diﬀérents types de sous-systèmes de cette catégorie.

Classification étendue

Nous venons de voir que la taxonomie de Flynn n’est pas assez précise pour diﬀéren-cier les grandes classes de calculateurs. La figure 2.7 propose une vue d’ensemble d’une classification étendue, en particulier de la catégorie MIMD qui nous concerne plus parti-culièrement. Ainsi la catégorie MIMD peut se décomposer en deux grandes familles : les architectures où la mémoire est partagée et celle où la mémoire est distribuée.
Premièrement, dans le cas de l’architecture à mémoire partagée, décrite dans la figure 2.8, les diﬀérentes unités d’exécution accèdent à une mémoire commune et partagent donc le même adressage mémoire. De prime abord cette approche apparait intuitive mais elle est confrontée aux accès concurrents aux données (en lecture ou écriture) qui vont nécessiter l’introduction de nouveaux concepts tel que le sémaphore défini par Dijkstra [70]. Au sein des architectures à mémoire partagée, on trouve plusieurs sous-catégories mais nous n’en présenterons que deux : les SMP et les NUMA. Tout d’abord les machines SMP (Symmetric MultiProcessing) possèdent des temps d’accès à la mémoire identiques pour toutes les unités d’exécution. Malheureusement ce schéma simple du point de vue de l’utilisation
provoque un goulot d’étranglement sur l’accès à la mémoire lorsque l’on augmente le nombre d’unité d’exécution. Ensuite on trouve les machines où les accès mémoires ne sont pas uniformes, dites NUMA (NonUniform Memory Access), car elles possèdent une hiérarchie dans l’organisation de la mémoire. Par conséquent les temps d’accès à la mémoire dépendent de la proximité entre l’unité d’exécution et la mémoire à laquelle cette dernière souhaite accéder. Afin de pallier ce problème, l’architecture cache coherent NUMA (ccNUMA) propose d’améliorer l’architecture NUMA en ajoutant un cache à chaque unité exécution. Bien que les défauts de cache soient à prendre en compte, l’architecture ccNUMA se rapproche de l’architecture SMP d’un point de vue utilisation.

Table des matières

1 Introduction
I Contexte
2 Simulation numérique et calcul haute-performance
2.1 Univers de la simulation numérique
2.1.1 De notre perception de la réalité à la machine
2.1.2 Programme Simulation
2.1.3 Limites du modèle actuel
2.2 Architectures des supercalculateurs
2.2.1 Classification des architectures
2.2.2 Évolution des architectures
2.2.3 Bilan
3 Développement d’applications de calcul scientifique
3.1 Langages et outils
3.1.1 Fortran : l’origine
3.1.2 Passage de messages
3.1.3 Mémoire partagée
3.1.4 High Performance Fortran (HPF)
3.1.5 Partitioned Global Address Space (PGAS)
3.1.6 Initiative HPCS du DARPA
3.1.7 Support d’exécution
3.1.8 Assemblage de composants parallèles
3.1.9 Parallélisme quasi-synchrone
3.1.10 Accélérateurs matériels
3.1.11 Langages dédiés
3.1.12 Frameworks de développement
3.1.13 Basé sur les modèles
3.1.14 Discussion
3.2 Génie logiciel et calcul scientifique
3.2.1 Conception guidée d’applications parallèles
3.2.2 Cycle de développement
3.3 Conclusion
II Contribution
4 MDE4HPC : une approche modèle pour la simulation numérique
4.1 Fondements théoriques
4.1.1 Principes généraux de l’IDM
4.1.2 L’approche Model Driven Architecture de l’OMG
4.2 Définition de l’approche MDE4HPC
4.2.1 Analyse de la situation
4.2.2 Proposition d’architecture
4.2.3 Processus de développement
4.3 Conclusion
5 Langage HPCML
5.1 Syntaxe abstraite
5.1.1 Présentation générale
5.1.2 Paquetage kernel
5.1.3 Paquetage structure
5.1.4 Paquetage behavior
5.1.5 Paquetage output
5.1.6 Paquetage validation
5.1.7 Paquetage parametric
5.2 Syntaxe concrète
5.2.1 Démarche de conception suivie
5.2.2 Syntaxe concrète d’un diagramme comportemental
5.2.3 Syntaxe concrète de la partie structurelle
5.3 Conclusion
III Outillage et évaluation
6 ArchiMDE : un outil pour l’approche MDE4HPC
6.1 Un atelier de génie logiciel basé sur la plateforme Eclipse
6.2 Paprika Studio
6.2.1 Editeur généré
6.2.2 Editeur générique
6.2.3 Comparaison des approches
6.3 Fonctionnement de l’outil
6.4 Gestion de l’algorithmique de bas niveau
6.4.1 Génération directe
6.4.2 Génération incrémentale
6.4.3 Algorithmique modèle
6.4.4 Synchronisation
6.4.5 Bilan sur le choix du mode de gestion
6.5 Conclusion
7 Étude de cas : code d’électromagnétisme 3D
7.1 Présentation du problème simulé
7.2 Modélisation de l’application avec HPCML
7.2.1 Processus de modélisation
7.2.2 Aperçu général
7.2.3 Calcul de la matrice des contributions
7.3 Conclusion
8 Atteinte des critères d’évaluation
8.1 Portabilité
8.1.1 Cas d’un nouveau code de simulation
8.1.2 Cas d’un changement de machine
8.1.3 Remarques générales sur la portabilité
8.2 Abstraction et accessibilité
8.3 Séparation des préoccupations
8.4 Validation
8.5 Communauté et outillage
8.6 Évaluation globale
IV Perspectives et conclusion
9 Vers une approche globale basée sur la modélisation
9.1 Perspectives pour le langage HPCMLp
9.2 Perspectives pour le langage HPCMLn
9.2.1 Ajout de stratégies parallèles
9.2.2 Algorithmique de bas niveau
9.3 Perspectives pour le langage HPCMLe
9.3.1 Injection d’optimisations
9.3.2 Vers des codes multi-versionnés
9.3.3 Prise en charge du débogage
9.3.4 Models@run.time
9.4 Discussion
10 Conclusion
A Méthodologie d’évaluation des solutions logicielles dédiées à la simulation numérique
Table des Figures
Acronymes
Bibliographie personnelle
Bibliographie