7.2.1 L’identification d’un besoin
La problématique du calcul hybride est un point de convergence entre l’ONERA et AxesSim. Chacun, riche de plusieurs expériences (Quercy, MaxwellTD, hybridation Alice-CRIPTE), entrevoit le potentiel d’une telle stratégie permettant de résoudre des problèmes concrets comme le sujet propre à cette thèse (hybridation 3D-1D). Cependant, un autre constat est fait : si cette approche est prometteuse, sa mise en œuvre est complexe de par des problématiques informatiques. Le cadre de cette thèse nous a permis de réfléchir sur cette problématique.
Mais avant de rentrer dans le vif du sujet, clarifions la notion d’hybridation. Les hybri-dations se classent suivant deux critères :
1. le type d’échanges entre les unités de calcul : unidirectionnel ou bidirectionnel. 2. la relation temporelle ou récurente des échanges qui peut être forte, (échange à chaque
itération) ou faible (pour une exécution séquentielle avec un seul échange). La topo-logie électromagnétique nous montre que l’hybridation faible n’a pas de sens sans des hypothèses permettant de négliger une rétroaction.
Le tableau 7.1illustre avec des exemples cette classification.
unidirectionelle bidirectionelle
forte surface Huygens champ-total/champ-diffracté (TF/SF) - rayonnement en domaines disjoints par hybridation TF/SF
interaction entre domaines disjoints par double surface Huygens TF/SF- interac-tion champ/fil (modèle de R. Holland) faible hybridation champ/câble
temps/fré-quence (FDTD-3D/ BLT)
Table 7.1 – Classification des différents types d’hybridation
L’hybridation faible unidirectionelle semble la plus simple à mettre en œuvre. Cette stratégie de calcul met en œuvre plusieurs outils distincts dans un scénario collaboratif séquentiel ; où un premier outil fait un premier calcul puis stocke un résultat intermédiaire qui sera utilisé comme donnée d’entrée pour un second outil. La principale difficulté est de définir un format d’échange commun ne laissant pas de place à l’interprétation.
En revanche l’hybridation forte, qu’elle soit uni ou bidirectionelle, demande d’une part de convenir d’un format d’échange, mais impose également de revoir en profondeur la struc-ture interne des outils. Entre autre cela nécessite d’introduire un mécanisme informatique permettant la synchronisation et l’échange des données durant le déroulement du calcul.
7.2.2 Les solutions technologiques pour le calcul parallèle
Il existe plusieurs solutions technologiques (thread, processus, socket, OpenMP, MPI, ØMQ, OpenCL...) permettant le calcul parallèle. Chacune de ces solutions est propre ou optimale pour un type de calcul parallèle donné ou plus précisément pour un type d’archi-tecture matérielle décrit ci-après :
– Calcul multi-cœur :
Consiste à exécuter des instructions parallèlement ou de manière imbriquée1 sur une même puce électronique : nous parlons parfois d’hyper threading ou de thread maté-rielle.
Dans cette catégorie les processus partagent la mémoire au niveau du cache2, cela permet de réaliser des échanges de données très rapides entre les processus.
– Calcul multi-processeur :
Consiste à implanter sur une même architecture matérielle plusieurs unités de calcul qui peuvent échanger de manière rapide des données, par le partage de zone mémoire (vive) nécessitant la mise en œuvre d’un bus de données très complexe qui limite leur déploiement à très grande échelle.
Dans cette catégorie, les processus partagent la mémoire et sont donc en concurrence directe sur ces zones. L’échange de données entre processus est donc rapide mais délicat.
– Calcul distribué :
Dans cette approche, plusieurs ordinateurs (au sens large) sont organisés en cluster, grille etc, à travers un réseau de communication de type Ethernet (TCP/IP) par exemple.
Dans cette configuration, les ordinateurs ne partagent pas d’espace mémoire mais échangent des messages à travers un réseau. Dans cette configuration, les partages de données sont coûteuses en temps mais les ressources mémoire sont plus simplement extensibles (scalabilité).
– Les autres :
Processeur vectoriel, calcul sur processeur graphique (GPGPU), etc.
Il est tout à fait possible d’utiliser des technologies prévues pour une architecture sur une autre. En revanche, elle ne pourra pas tirer partie des avantages conférés par l’architecture matérielle. Dans certaines configurations, elle peut même dégrader les performances. Par exemple, Intel a implémenté le standard OpenMP pour des ordinateurs en réseau (Cluster OpenMP*). Dans cette implémentation, la mémoire partagée ne l’est que virtuellement car elle doit être synchronisée entre les différents ordinateurs. Dans ce cas de figure, une utili-sation abusive de la mémoire partagée va ralentir les accès car ils devront être synchronisés à travers un réseau. Alors que sur une architecture multi-cœur serait indolore.
Il est important de distinguer les différents types de calculs parallèles car chacun a ces propres spécificités, contraintes et limitations. Dans cette section, nous allons plus parti-culièrement étudier le calcul distribué nécessitant l’utilisation de technologies permettant l’échange de messages à travers une interface réseau (socket, MPI, ØMQ). Nous nous arrê-terons plus particulièrement sur MPI (Message Passing Interfce) et ØMQ (The Intelligent Transport Layer), plus adaptés au calcul scientifique à haute performance.
1. Parallélisme d’instruction ou chevauchement partiel d’instructions permettant de commencer l’exécu-tion d’une instrucl’exécu-tion sur un microprocesseur avant que la précédente instrucl’exécu-tion ne soit finie (pipelines). [90]
a. MPI - Message Passing Interface
MPI [91] conçu en 1993, est une norme définissant une bibliothèque de fonctions, dispo-nible dans un grand nombre de langages. Cette norme s’est imposée comme standard pour le calcul parallèle sur système à mémoire distribuée (calcul distribué). Elle peut également être utilisée pour le calcul multi-processeur et multi-cœur sans pour autant en tirer avantage. Sur ce type d’architecture, OpenMP est plus adapté.
Un atout majeur de MPI est que de nombreux fabricants de super-calculateurs four-nissent leur propre implémentation de MPI, particulièrement optimisée pour leur architec-ture matérielle. C’est une des raisons qui permettent à MPI d’avoir aujourd’hui cette place privilégiée pour le calcul scientifique parallèle.
b. ØMQ - The Intelligent Transport Layer
ØMQ (ZeroMQ ou zmq) [92] est une librairie de la famille des AMQP (Advanced Message Queuing Protocol) qui a plus pour vocation de fournir un standard d’échange de messages pour les applications. Il fournit une interface unifiée pour plusieurs protocoles de transports inter-thread et inter-processus pour du calcul parallèle en mémoire partagée ou via un réseau avec TCP (Transmission Control Protocol) ou encore PGM (Pragmatic General Multicast) pour une optimisation dans le cas de transferts multi-récepteurs.
ØMQ se distingue de MPI par le fait qu’il n’est pas basé sur la notion de mono-programme. Avec MPI, de manière schématique, nous exécuterons en même temps N fois le même programme. Dans une architecture basée sur ØMQ, toutes les entités peuvent être distinctes. MPI2 assouplit cette notion de mono-programme mais l’idée reste très présente.
c. OpenPALM
Dans cette section, nous avons présenté les solutions techniques de calcul parallèle per-mettant de faire du calcul hybride. Cependant, il existe déjà un certain nombre de solutions permettant de faire du calcul hybride. L’une d’entre elles, qui a retenu notre attention, est OpenPALM [93]. Cette technologie, issue du calcul météorologique, a été conçue pour faire du calcul hybride (modèle thermique de l’atmosphère, des continents et des océans).
OpenPALM est basé sur MPI, avec une interface graphique comme celle de LabView3[95] (branchement graphique de modules par des liens représentant les échanges entre modules). Nous n’avons pas retenu cette solution car la définition d’un module pour OpenPALM lui est propre. En d’autres termes, il ne semble pas possible d’utiliser le même module pour une utilisation dans OpenPALM et pour l’utiliser seul ; ce qui est une contrainte qui s’est imposée à nous.
7.2.3 Présentation de la méthode
Quand nous pensons à une stratégie d’hybridation, nous voulons un outil capable de mixer plusieurs codes de calculs, permettant de tirer partie des avantages de chaque méthode et cela de manière presque automatique. Il semble que c’est plus un problème informatique. 3. LabVIEW est un logiciel de développement d’applications de la société américaine National Instru-ments, basé sur un langage de programmation graphique appelé langage G. [94]
La réalité est bien différente : d’une part, chaque méthode numérique a ses propres spécificités qui peuvent la rendre incompatible avec une autre et cela même en restant dans une même physique. De plus, chaque stratégie d’hybridation s’appuie sur un principe physique. Ainsi les types d’échanges entre les modules peuvent être très variés.
Les outils du domaine temporel n’échappent pas à cette règle. Nous devons parfois faire cohabiter des stratégies temporelles comme le leap-frog, le RK2, etc. avec des pas de temps différents. Il semble délicat de laisser vivre chaque outil de manière indépendante, sans la moindre connaissance des contraintes des autres outils mis en jeu. Cependant, comme nous voulons une architecture peu ou pas intrusive, nous sommes loin du compte si chaque ou-til doit avoir une pleine connaissance de la stratégie des autres. La définition d’un chef d’orchestre, qui seul connaît la mélodie et donne le rythme à chaque instrument, semble pertinent. Ainsi les instruments ne connaissent et ne jouent que leur partition sans se pré-occuper des autres.
L’utilisation d’un « chef d’orchestre » permet de nous affranchir de l’intrusivité associée au principe physique et mathématique de chaque outil mis en jeu. Mais il y a une autre intrusivité, l’intrusivité informatique que l’on peut voir sous deux angles. D’une part, quel est l’effort, le travail à fournir pour hybrider un outil ? L’autre point de vue est la capacité qu’a un outil à fonctionner seul et dans une stratégie d’hybridation.
La figure7.1résume la solution proposée. Dans cette solution, les modules de calcul sont des « boites noires ». Par la suite nous parlerons de workers. Nous ajoutons à ces modules une interface. Cette interface doit être superficielle pour qu’elle soit la moins intrusive possible dans le module. Cette interface permet de diriger le worker par le biais d’un contrôleur (driver). Enfin, le rôle du chef d’orchestre est réalisé par le manager qui a une fonction d’administration.
Terminologie :
– worker : définit un module de calcul ou toute autre application que nous voulons hy-brider. Un worker est executé au sein d’un processus qui lui est propre. C’est cette propriété qui donne le caractère parallèle de l’exécution. De plus chaque worker (pro-cessus) peuvent être executé sur des machines différentes pour distribuer la charge de calcul. Enfin chaque worker peut être des processus parallèles basés sur MPI ou OpenMP par exemple.
– interface : représente les capacités offertes par le worker au sein du manager.
– driver : définit comment est utilisé un worker par le biais de son interface pour réaliser la fonction attendue pour la stratégie d’hybridation. Le driver peut être vu comme la fonction principale (main) exécutée par chaque worker.
– l’application : (ou le manager) est le composant central qui organise les échanges à l’aveugle. Les drivers fournis par l’utilisateur donnent le comportement.
La stratégie proposée s’appuie sur la notion d’un manager qui va administrer et gérer l’exécution de chaque worker suivant la séquence de commandes définie par le driver. Cette vision hérite de l’approche généralement employée pour faire une application multi-méthode avec MPI. Le principe consiste à définir une fonction principale pour chaque méthode mise en jeu. Puis dans la fonction principale de l’application, nous faisons un aiguillage sur chaque méthode en fonction du numéro de processus. Cette approche présente l’inconvénient de devoir lier dans une seule application toutes les méthodes, ce qui peut s’avérer limitant dans
Figure 7.1 – Synoptique générale du manager illustré par une hybridation Alice/Milo.
certains cas de figure. L’autre limitation est, qu’en général, l’implémentation de chaque méthode est faite par l’approche dite « dirigée par le contrôle », ce qui en général produit un mauvais découpage fonctionnel de l’implémentation. Autrement dit, nous retrouvons des instructions liées à la gestion du calcul hybride, aux échanges de données dans des fonctions liées au calcul et cela dans des fonctions très profondes.
L’approche proposée impose un découpage fonctionnel plus atomique et fait remonter toutes les fonctions de communication et d’administration au plus haut niveau, ce qui permet de les mutualiser et de les rendre transparentes pour l’utilisateur. Notons, que si l’utilisateur ne voit plus les fonctions liées à l’hybridation, c’est qu’elles ne sont plus intrusives.