Portage du modèle climatique de surface continentale de l'ipsl. sur une grappe de serveurs XD1

Transcription

1 BERNARDO Frederic Master 2 Physique et Applications CCI Université Paris XI Orsay (91) Portage du modèle climatique de surface continentale de l'ipsl sur une grappe de serveurs XD1 Différences de température entre les années 2000 et 2070 selon deux scénarios de l'ipcc, a2 (gauche) et b2 (droite) IPCC 2001 Stage de Master 2 Professionnel Compétences Complémentaires en Informatique sous la direction de M. Mancip et Y. Meurdesoif à l'institut Pierre Simon Laplace (IPSL Jussieu) 1 / 42 Avril Août 2006

2 2 / 42

3 Remerciements Martial Mancip, Yann Meurdesoif, Sébastien Denvil, Patrick Brockmann, Abderrahmane Idelkadi, Jacques Lefrère, Marie Angèle Filiberti, Marie Alice Foujols, Patricia Cadule, Olivier Marti, Armella Longrez, Mina Melloulchi, Laurent Fairhead, Laurent Bourdette, les membres du LMD, du LSCE, du SA et de l'ensemble de l'ipsl Michel Krawczyk, Stéphane Rohrbach, François Gueudet, les membres du CCRE de Jussieu Denis Girou, Patrick Corde, les membres de l'idris 3 / 42

4 Table des matières Remerciements 3 1.Présentation du stage Présentation des organismes d'accueil 1.2.Le modèle climatique de l'ipsl :IPSL CM4 1.3.Présentation du calcul parallèle a)du séquentiel au parallèle b)le supercalculateur parallèle du CCRE : le XD1 2.La parallélisation du modèle climatique de surface continentale ORCHIDEE Le fonctionnement des modèles climatiques de l'ipsl Le calcul parallèle La parallélisation d'orchidee 17 a)le modèle climatique global b)le modèle climatique de surface continentale ORCHIDEE c)les fichiers externes utilisés par ORCHIDEE a)les caractéristiques du calcul parallèle b)les différences entre le calcul distribué et le calcul partagé c)l'utilisation d'une implémentation de directives parallèles : MPI a)les principes de la répartition des calculs a)une répartition des charges évolutive b)une parallélisation néanmoins incomplète 3.Après la parallélisation Différentes versions possibles pour ORCHIDEE_OL 3.2.Les principaux problèmes rencontrés 3.3.Un modèle en constante évolution Fiabilisation et portabilité de la version parallèle 21 a)évolutions disjointes des versions parallèles séquentielles b)l'environnement des modèles de l'ipsl 4.Protocole de test Les critères de test Les caractéristiques utilisées pour l'évaluation des performances 4.3.La mise en oeuvre sur le XD1 4.4.La récupération des résultats a)les entrées sorties b)l'influence du nombre de processus et des options de compilation 4 /

5 5.Résultats et analyse Les options de compilation et le nombre de processus 5.2.Les entrées sorties 6.Conclusions et perspectives Bilan de la parallélisation 6.2.Les bénéfices apportés par le récent supercalculateur XD1 du CCRE 6.3.Les critères déterminants pour l'optimisation des calculs d'orchidee Annexes 33 Glossaire 40 Bibliographie 42 5 / 42

6 1. Présentation du stage Médiatisé par le protocole de Kyoto en 1997, le réchauffement climatique est lié selon la majorité scientifique en partie à l'activité humaine, notamment sa production en gaz à effet de serre. Pour confirmer cette théorie, ont été mises en place des simulations du climat, visant également à prévoir ses évolutions futures. L'IPSL (Institut Pierre Simon Laplace), par le biais de son pôle modélisation, possède un modèle climatique global, permettant de mettre en évidence l'évolution climatique selon de nombreux paramètres, notamment l'activité anthropique et la nature des gaz émis par les activités humaines. Reposant sur l'exploitation des données recueillies, le modèle climatique de l'ipsl nécessite des ressources informatiques importantes et de plus en plus coûteuses. Les supercalculateurs sur lesquels s'exécutent ce type de simulation se tournent d'ailleurs de plus en plus vers les technologies de calculs parallèles : une mise en commun de plusieurs systèmes, pas forcément identiques, chaque système s'octroyant une partie de la charge. Ce type d'architecture, s'appuyant sur des technologies de communication entre les systèmes, se révèle incontournable, mais requiert la parallélisation du code exécuté, une mise en oeuvre plus ou moins complexe qui demande des compétences informatiques spécifiques. La parallélisation de LMDz (modèle de circulation générale atmosphérique du Laboratoire de Météorologie Dynamique) et d'orchidee (ORganizing Carbon and Hydrology In Dynamic EcosystEms), composantes du modèle climatique global de l'ipsl, est réalisée depuis l'été 2005 par Y. Meurdesoif, ingénieur LSCE (Laboratoire des Sciences du Climat et de l'environnement). S'appuyant sur MPI (Message Passing Interface), les modèles parallèles de l'ipsl sont ainsi capables de tirer parti des architectures des supercalculateurs parallèles, notamment la grappe de serveurs XD1 (Cray), récemment installée au CCRE (Centre de Calcul Recherche et Enseignement) à l'upmc (Université Pierre et Marie Curie). En intégrant l'équipe ORCHIDEE au sein de l'ipsl, j'ai été amené à assurer le débogage de la version parallèle de ce modèle, à en finaliser la parallélisation et à y intégrer certaines évolutions des nouvelles versions séquentielles, introduites récemment. J'ai ensuite effectué le portage de la composante terrestre du modèle global sur le XD1. Cela m'a permis de tester les performances du modèle parallèle et de ses variantes possibles, dans les conditions réelles de fonctionnement. Enfin, l'analyse des résultats obtenus m'a permis de dégager les caractéristiques les plus déterminantes sur les performances de la version parallélisée du modèle. Dans la suite de cette introduction seront présentés l'ipsl qui m'a accueilli ainsi que les différents organismes qu'il m'a été amené de côtoyer à travers mon stage. Une brève description des modèles climatiques IPSL CM (modèle climatique couplé) sera ensuite abordée. 6 / 42

7 1.1.Présentation des organismes d'accueil L'Institut Pierre Simon Laplace (IPSL) regroupe près de 40% du dispositif national de recherche du CNRS et des universités dans le domaine des sciences de l'océan et de l'atmosphère, soit quelques 750 personnes (environ 250 chercheurs et enseignants chercheurs, 250 ingénieurs, techniciens et agents administratifs et 250 doctorants, post doctorants et stagiaires) réparties dans cinq laboratoires : le Centre d'étude des Environnements Terrestre et Planétaires (CETP) le Laboratoire de Météorologie Dynamique (LMD) le Laboratoire d'océanographie et du Climat : Expérimentation et approches Numériques (LOCEAN) le Laboratoire des Sciences du Climat et de l'environnement (LSCE) le Service d'aéronomie (SA) Fig. 1 : Structure de l'ipsl Ces laboratoires et la structure fédérative sont placés sous la tutelle de quatre organismes gouvernementaux (CNRS, CEA, IRD, CNES) et de quatre établissements d'enseignement supérieur (Université Pierre et Marie Curie, Université de Versailles Saint Quentin, École Normale Supérieure, École Polytechnique). Ils sont implantés sur plusieurs sites en région parisienne : Université Pierre et Marie Curie à Jussieu, Verrières le Buisson / Vélizy, Plateau de Saclay / Gif sur Yvette, Saint Maur. L'IPSL étudie l'évolution du climat, de l'effet de serre et de la couche d'ozone, et s'intéresse à la pollution de l'air et des océans. Dans une perspective plus large, il cherche aussi à comprendre les processus qui régissent l'évolution des autres environnements planétaires du système solaire. Des actions fédératrices sont mises en place pour répondre à des priorités nationales : recherche sur le climat, impacts des activités humaines aux échelles régionales et locales, planétologie. Une des grandes réussites de l'ipsl en tant que fédération de laboratoires de recherche est le développement d'un modèle global couplant les modèles conçus par les laboratoires pour rendre compte 7 / 42

8 individuellement des processus atmosphériques, océaniques et biosphériques. Par ailleurs, ce stage m'a également amené à consulter régulièrement les administrateurs du CCRE de l'upmc, dont les missions sont d'offrir, auprès de la communauté scientifique du campus Jussieu, un ensemble de ressources matérielles et logicielles dans différents domaines (calcul scientifique, sauvegardes des données sensibles des laboratoires de Jussieu dont ceux de l'ipsl,...). Enfin, j'ai également eu l'opportunité de suivre deux formations à l'idris (Institut du Développement et des Ressources en Informatique Scientifique), me permettant d'acquérir certaines connaissances informatiques spécifiques au calcul scientifique. Centre majeur du CNRS pour le calcul numérique intensif de très haute performance, l'idris participe à la mise en place de ressources informatiques nationales, et assure leur support, au service de la communauté scientifique de la recherche publique. J'ai été intégré dans l'équipe ORCHIDEE de l'ipsl à Jussieu (Paris), sous les directives de mes responsables de stage, M. Mancip, ingénieur IPSL en charge du modèle ORCHIDEE, et Y. Meurdesoif, ingénieur LSCE qui effectua sa parallélisation ainsi que celle de LMDz, toutes deux composantes du modèle climatique global de l'ipsl. J'ai ainsi pu avoir accès à un serveur de calcul léger, calculo, basé sur un bi processeur Opteron, sur lequel s'est déroulée la phase de développement, avant d'effectuer des tests de performances sur le récent supercalculateur du CCRE. 1.2.Le modèle climatique de l'ipsl :IPSL CM4 Le modèle climatique de l'ipsl est un support privilégié pour simuler l'évolution du climat. S'appuyant sur les données climatologiques mondiales, il calcule l'évolution temporelle du climat sur de longues périodes (de 150 ans à ans), à travers les variations de ses caractéristiques : la température du sol, le nombre de couches végétales, l'albédo, la vitesse du vent, l'évaporation, etc... La comparaison des résultats entre une simulation de référence et une simulation tenant compte d'une hypothèse d'étude (comme l'augmentation ou l'absence de gaz d'origine anthropique) permet par exemple, d'évaluer l'influence de l'homme dans le climat d'aujourd'hui et de demain. Il est ainsi possible d'effectuer plusieurs modélisations du climat de demain en variant, par exemple, la quantité de CO2 émise par l'homme dans l'atmosphère. Cette méthode revient à évaluer qualitativement l'évolution du climat selon les différents scénarios économiques possibles. Ces simulations ont d'ailleurs été conduites récemment par plusieurs laboratoires des sciences du climat et aboutissent à des conclusions proches de celles de l'ipsl. Le modèle global s'appuie sur les différentes composantes actives du système terrestre et leurs interactions : LMDz pour l'atmosphère OPA pour l'océan LIM (Louvain la Neuve Ice Model) pour la glace de mer ORCHIDEE pour la surface terrestre OASIS (Ocean Atmosphere Sea Ice Snowpack) en tant que coupleur Ce système souple et par composante, écrit en Fortran95, permet de simuler de façon autonome ou en interaction les unes avec les autres chacune de ces composantes. Il offre en outre la possibilité d'incorporer de plus en plus de processus physiques, chimiques ou biologiques, améliorant ainsi la pertinence du modèle au fil des versions de chaque composante, sous l'impulsion de différents laboratoires du pôle de modélisation. 8 / 42

9 Fig. 2 : Cartes des différences de températures entre la décennie et la décennie dans le scénario A2 Mais l'un des buts avoués de la modélisation à l'ipsl est d'utiliser son modèle pour des durées de plus en plus importantes, sur des grilles de résolutions de plus en plus fines. Ainsi, alors que la modélisation climatique est par nature consommatrice et génératrice de quantités importantes de données, la tendance est largement à la hausse, sans oublier les paramètres de plus en plus nombreux et les phénomènes de plus en plus complexes à prendre en compte, comme par exemple certaines interactions biochimiques. Il en résulte une amélioration indéniable des résultats, de par leur précision et leur fiabilité, mais également un net accroissement des temps de calcul. Actuellement, sur la plate forme de développement (un bi processeur Opteron), la version séquentielle de la modélisation climatique de la surface continentale, ORCHIDEE, sur 32 jours avec un pas de temps de 30 minutes sur la carte mondiale en résolution 1 de longitude sur 1 de latitude, effectue une restitution en 156 minutes. Toutefois, ORCHIDEE ne représente que 7% environ du temps de calcul dans le modèle global, et une simulation de 32 jours n'aborde pas les échelles climatiques, à l'heure où le monde s'interroge sur le climat des années 2100 et plus. Ces chiffres informent cependant sur l'importance des ressources requises pour ce genre de modélisation climatique. 1.3.Présentation du calcul parallèle Il est à noter que le calcul précédemment décrit n'a fait intervenir qu'un seul des deux processeurs de la machine, ce qui s'avère strictement normal dans le cadre d'un modèle strictement séquentiel. Alors que le marché informatique se dirige vers une multiplication des processeurs au sein d'une même unité de calcul, une évolution nécessaire serait donc l'utilisation en parallèle des processeurs lors de calculs lourds. Néanmoins, la puissance du processeur élémentaire reste un élément clé. 9 / 42

10 a) Du séquentiel au parallèle Mais les supercalculateurs, dédiés à ce genre de travail, offrent également d'autres avantages au calcul parallèle. De plus en plus bâtis sur des systèmes complets autonomes inter connectés entre eux, ils permettent de bénéficier de plusieurs systèmes de fichiers en plus de l'apport de plusieurs processeurs de calculs. Ceci favorise donc également la rapidité des entrées sorties, élément le plus critique dans certaines applications scientifiques comme celles de la modélisation climatique. Ainsi, les plus importants superordinateurs sont maintenant pour la plupart constitués de plusieurs centaines voire milliers de processeurs, et offrent des puissances potentielles de calcul énormes. Pour les exploiter pleinement, les constructeurs ont tout d'abord mis au point des protocoles propriétaires de communication entre processeurs, utilisables par des directives parallèles. Ceux ci aboutissent à partir de 1992 à des "standards de fait" multi plates formes, avec OpenMP et MPI (Message Passing Interface). Ces derniers sont à présent les modèles de programmation parallèle les plus utilisés, parfois simultanément du fait de leur complémentarité. Fig. 3 : Photographie d'un XD1 constitué de 6 chassis (soit 72 processeurs). Le XD1 du CCRE ne dispose que de 5 chassis. b) Le supercalculateur parallèle du CCRE : le XD1 Le CCRE de l'upmc s'est doté en 2005 d'un supercalculateur de type intermédiaire, dédié aux applications parallèles avec MPI. Le XD1, conçu par Cray, est formé de 28 noeuds de calculs auquel s'ajoutent les 2 noeuds du serveur frontal. Chaque noeud est constitué d'un bi Opteron à 2,6 GHz, chaque processeur étant doté de 2 Go de mémoire DDR SDRAM (4 Go pour ceux du 10 / 42

11 frontal) ainsi qu'un disque local de 74 Go en S ATA (250 Go pour le frontal). Un réseau de haute performance assure un débit d'au moins 4 Go/s entre deux processeurs quelconques, avec une latence inférieure à 2 µs. Enfin, le frontal est relié par un débit de 200 Mo/s à un stockage externe de type SAN (Storage Area Network) de 2 To. Calculateur Calculo Eclair XD1 Tera 10 BlueGene L Puissance théorique (GFlops) Nombre de CPU Commentaires 13 2 Plate forme de développement (IPSL) Plate forme d'évaluation (CCRE) N 1 français (CEA) N 1 mondial (DOE/NNSA/LLNL USA) Fig. 4 : Puissance théorique des serveurs de calculs utilisées, comparé à des références du top500 mondial Fig. 5 : Architecture matérielle du XD1 du CCRE eclair Chaque noeud est géré par un système Linux 64 bits autonome, et comprend des implémentations libres et propriétaires. Ainsi sont disponibles les compilateurs GNU et PGI, ainsi que les bibliothèques MPICH2 (implémentation MPI open source) et NetCDF (Network Common Data Form, implémentation libre de gestion de données fournie par Unidata). L'ensemble des noeuds de calcul est piloté par le système de soumission SGE (Sun Grid Engine). En effet, plusieurs travaux d'utilisateurs différents sont effectués au même instant sur le XD1, comme pour la majorité des supercalculateurs actuels. Chacun d'eux est soumis en batch au SGE, qui lui réserve alors le nombre de noeuds demandé. Le frontal est le seul élément du 11 / 42

12 calculateur réellement accessible par l'utilisateur, où il peut effectuer des compilations, ainsi que des post traitements. 2. La parallélisation du modèle climatique de surface continentale ORCHIDEE 2.1.Le fonctionnement des modèles climatiques de l'ipsl a) Le modèle climatique global Comme décrit plus haut, le modèle climatique global de l'ipsl s'articule sur plusieurs composantes, chacune interagissant plus ou moins directement avec les autres (cf figure 6). Fig. 6 : Structure du modèle climatique global de l'ipsl autour de ses composantes Cependant, d'autres outils sont également utilisés dans le cadre du couplage et des entrées sorties. Ainsi le couplage LMDZOR (composé de LMDz et d'orchidee) ORCALIM (OPA et LIM) est effectué par OASIS par projection de grilles. Les opérations d'entrées sorties sont gérées par IOIPSL, une bibliothèque developpé par l'ipsl qui constitue l'interface du modèle avec NetCDF. b) Le modèle climatique de surface continentale ORCHIDEE LMDZOR est en fait «piloté» par LMDz, celui ci appelant un module intersurf présent dans ORCHIDEE. Cet appel à chaque pas de temps, soit toutes les 30 minutes de temps simulé, en communiquant certaines données atmosphériques (ensoleillement, température de l'air,...). Le modèle de surface continentale est en fait constitué de deux modules, SECHIBA et STOMATE (voir figure 7). 12 / 42

13 fig. 7 : Composition du modèle climatique de surface continentale ORCHIDEE de l'ipsl SECHIBA est appelé par intersurf toutes les 30 minutes de temps simulé et traite de la physique de la surface continentale, des sols et de la végétation. Les phénomènes hydrologiques dont le routage de l'eau sont également gérés par SECHIBA, mais seulement une fois par jour. Quant à STOMATE, il est appelé toutes les 24 heures pour traiter la biogéochimie continentale, comme la croissance de la végétation, dont l'évolution des phénomènes modélisés est moins rapide. Les calculs du modèle ORCHIDEE à travers ces deux modules s'effectuent principalement sur les points de terre, eux même étant obtenus à partir de la grille à deux dimensions représentant le domaine étudié (cf figure 8). Cette conversion est obtenue en parcourant en longitude puis en latitude la grille, remplissant au fur et à mesure un tableau à une dimension par les points contenant au moins une fraction de surface continentale. La construction d'un index des points de terre permet ensuite de reconstituer la grille. L'utilisation des points de terre au lieu d'une grille 2D est motivée par le gain de place mémoire apporté. En effet, ce choix permet de n'utiliser que 33% de la mémoire requise en deux dimensions, dans le cas d'une modélisation climatique globale (soit la proportion de surface terrestre émergée sur la planète), autorisant ce modèle à s'exécuter en global sur une simple station de travail (la taille mémoire requise montant jusqu'à environ 600 Mo). En outre, cette méthode requiert peu de calculs supplémentaires, étant donné l'absence d'interactions entre les points de terre, sauf dans le cas du routage de l'eau (un tableau de voisins étant alors utilisé). II est également possible d'utiliser ORCHIDEE seul pour la modélisation du climat sur la surface terrestre. Cette version, dite forcée, exploite des fichiers de forçage fournis par LMDz, contenant les données climatiques nécessaires à la simulation. ORCHIDEE_OL (pour Off Line) est en fait une «surcouche» autonome d'orchidee, qui dans un premier temps lit les données d'initialisation, puis au fur et à mesure de la simulation, les données de forçage. Celles ci étant obtenues dans une grille 2D (selon la latitude et la longitude), il est aussi nécessaire de les convertir en points de terre avant d'appeler le modèle. 13 / 42

14 Fig. 8a : Modélisation de la température au sol de la surface continentale durant l'année 1982 (en K) Seuls les points de la grille 2D comportant des surfaces continentales sont indexés par ORCHIDEE en points de terre. Outre une méthode efficace pour tester ORCHIDEE, le forçage permet d'utiliser la simulation climatique seulement au niveau de la surface terrestre très simplement et rapidement, les autres données étant extraites des fichiers de forçage toutes les 6 heures (et interpolées entre ces lectures), au lieu d'être calculées dans les autres composantes du modèle. c) Les fichiers externes utilisés par ORCHIDEE Le modèle climatique de surface continentale nécessite, que ce soit dans sa version forcée ou couplée, des fichiers de tailles importantes : Plusieurs fichiers décrivant d'entrée, accédés uniquement en lecture, décrivent les propriétés de la surface continentale, comme l'hydrologie ou la répartition des végétaux. Les fichiers de redémarrage restart, en lecture et en écriture, permettent de reprendre la modélisation à partir de données déjà obtenues. Cette fonction est en effet essentielle dans le cas de la modélisation climatique, où les temps d'initialisation des modèles nécessitent leur exécution sur des milliers d'années avant d'obtenir l'état d'équilibre. Les fichiers history contiennent les données calculées par le modèle. Écrits par SECHIBA et STOMATE, ils constituent les résultats exploitables fournis par la simulation. Uniquement dans le cas de la version forcée, ORCHIDEE utilise des fichiers de forçage contenant les données atmosphériques. Celles ci sont fournies directement par LMDz dans le cas du modèle couplé. 14 / 42

15 Tous ces fichiers de données sont au format NetCDF, un format portable de stockage de données binaires compressées, ce qui ne les empêche pas d'atteindre 1,8 Go pour les seuls fichiers de lecture. Mais un autre fichier, au format texte, intervient dans la configuration du modèle. Le fichier de paramétrage, run.def, permet de configurer sans recompilation les différentes options du modèle (le temps de la simulation, le niveau d'écriture, etc...). 2.2.Le calcul parallèle a) Les caractéristiques du calcul parallèle La vitesse des traitements séquentiels traditionnels semble s'approcher de la limite physique au delà de laquelle il n'est plus possible d'accélérer. En revanche, il est à présent possible d'utiliser à moindre coût : Plusieurs processeurs dans une même puce (architecture actuellement popularisée par les constructeurs sous l'appellation «multi core») Plusieurs processeurs sur une même carte mère (architecture multi processeurs) Plusieurs cartes mères sur le même châssis Les supercalculateurs actuels sont donc conçus autour de ce principe d'architecture parallèle. Leur puissance potentielle de calcul s'est d'ailleurs accrue d'une façon considérable depuis 1990, s'appuyant simplement sur la multiplication des ressources de calculs. Il existe cependant une limite au gain apporté par ce système, schématisée par la loi d'amdahl : R étant le gain de temps entre la version séquentielle et la version 1 parallèle du même programme R= s s étant un paramètre dépendant du programme et de l'efficacité de sa 1 s parallélisation, ou coefficient de parallélisabilité N N le nombre de processeurs Fig. 9 : Loi d'amdahl définissant le gain par processeur Fig. 10 : Évolution du gain R en fonction du nombre de processeurs N selon la loi d'amdahl pour s = 0,88, face au gain idéal (s = 1) 15 / 42

16 Le rendement de la parallélisation diminuant avec le nombre de processeurs mis en jeu, cela implique que les simulations utilisent rarement toutes les ressources disponibles du système, surtout lorsque l'on considère que le coût d'un travail est généralement fonction du temps consommé total (et donc le temps du calcul multiplié par le nombre de processeurs sollicités). Ce rendement peut d'ailleurs être quantifié par le coefficient de parallélisabilité : 1 R s= 1 1 N 1 Fig. 11 : Coefficient de parallèlisabilité obtenu à partir de la loi d'amdahl selon le gain R et le nombre de processus N b) Les différences entre le calcul distribué et le calcul partagé Le calcul parallèle consiste en l'exécution simultanée d'une même tache, celle ci étant adaptée et partitionnée afin de pouvoir être répartie entre plusieurs systèmes de calcul en vue de traiter plus rapidement des problèmes plus grands. Il existe plusieurs types d'ordinateurs parallèles, caractérisés, principalement, par différents modèles d'interconnexions entre les processeurs et entre les processeurs et la mémoire. La classification la plus populaire est celle de Flynn (1966), qui classe les ordinateurs parallèles selon le type d'organisation du flot de données et du flot d'instructions. Elle distingue ainsi les machines SPMD (Single Program Multiple Data), à flot d'instructions unique sur des données multiples, et les machines MPMD (Multiple Program Multiple Data) à flot d'instructions et de données multiples. Les modèles de programmation parallèle MPI et OpenMP fonctionnent selon le type SPMD, bien qu'il leur soit possible d'émuler le MPMD. Les directives parallèles les plus utilisées actuellement, OpenMP et MPI, utilisent néanmoins des structures différentes : Fig. 12 : Deux conceptions du calcul parallèle : à ressources partagées (OpenMP), ou distribuées (MPI) Partagé dans le cas de l'openmp. Parfaitement adapté aux ordinateurs multi processeurs, les 16 / 42

17 processus partagent la même architecture système mais s'exécutent sur des processeurs différents. Distribué dans le cas de MPI. Cette solution est préconisée pour les grappes de PC comme le XD1, plusieurs exécutions se déroulant sur des systèmes différents, uniquement liées par les communications réseaux. Leur différences permettent de les utiliser conjointement afin de tirer pleinement profit des ressources offertes par les grappes de serveurs multi processeurs. c) L'utilisation d'une implémentation de directives parallèles : MPI MPI est disponible pour la plupart des langages classiques, comme le C, le C++, le Fortran90... Chaque processus, à qui MPI attribue un rang lui servant d'identifiant, exécute le même programme. Toutes les variables du programme sont privées et résident dans la mémoire locale allouée à chaque processus. Les données sont ensuite échangées entre deux ou plusieurs processus via des appels à des fonctions MPI. 1. program qui_je_suis 2. implicit none 3. include 'mpif.h' 4. integer :: nb_procs,rang,code 5. call MPI_INIT(code) 6. call MPI_COMM_SIZE(MPI_COMM_WORLD,nb_procs,code) 7. call MPI_COMM_RANK(MPI_COMM_WORLD,rang,code) 8. print *,'Je suis le processus ',rang,' parmi ',nb_procs 9. call MPI_FINALIZE(code) 10.end program qui_je_suis fig. 13a : Exemple d'un programme MPI en Fortran Source : Cours MPI de l'idris $ mpirun np 7 qui_je_suis Je suis le processus 3 parmi 7 Je suis le processus 0 parmi 7 Je suis le processus 4 parmi 7 Je suis le processus 1 parmi 7 Je suis le processus 5 parmi 7 Je suis le processus 2 parmi 7 Je suis le processus 6 parmi 7 fig. 13b : Exemple d'exécution d'un programme MPI Très souvent, notamment dans le cas du XD1, l'architecture parallèle est exploitée telle que chaque processeur est réservé à un processus. Mais il est également possible, que ce soit en test ou en production, et indépendamment de l'architecture, que plusieurs processus soient exécutés par un unique processeur. Par exemple, sur notre plate forme de développement constituée d'un bi processeur, il est possible de lancer un calcul parallèle sur 1, 2, 4 processus ou plus, partagés entre les deux processeurs de la configuration. 2.3.La parallélisation d'orchidee a) Les principes de la répartition des calculs Dans le cas d'orchidee (et de IPSL CM4 plus généralement), la parallélisation se base 17 / 42

18 sur une répartition géographique, plus particulièrement sur celle des points de terre, facilitée par leur faible interaction. Ainsi, chaque processus ne «voit» que son domaine de points de terre, qui lui est fixe. Un processus root, identifié par le rang 0, effectue l'écriture des fichiers de redémarrage, et les calculs concernant le routage de l'eau. Cette dernière nécessitant de nombreuses communications «points à points», sa parallélisation paraît peu bénéfique, d'autant plus que sa version séquentielle consomme peu de temps de calcul. Le modèle atmosphérique LMDz fonctionnant sur le principe d'une grille 2D, l'appel à ORCHIDEE via intersurf ne concerne que les processus contenant des points de terre, sans modification de leur répartition dans le modèle terrestre. En revanche, dans le cas du modèle forcé, c'est le processus root qui effectue l'initialisation du parallélisme, notamment par l'attribution des points de terre à tous les processus, et les variables liées à leur répartition (cf fig. 8). De plus, la parallélisation comprenant également l'écriture des fichiers d'historique, un outil rebuild a été developpé et fourni par la bibliothèque IOIPSL pour permettre la reconstruction d'un fichier d'historique unique à partir des parties écrites par chaque processus. a) Une répartition des charges évolutive Lors de la première exécution du modèle forcé, root effectue une répartition égale en nombre de points de terre entre chaque processus, afin de distribuer équitablement la charge de travail à chaque processus ( s > 1, dans la loi d'amdahl, cf figure 9). Mais une répartition égale des points de terre ne suffit pas, puisque différents critères comme la présence de végétation ou l'ensoleillement influent énormément sur le nombre des phénomènes impliqués et donc sur le volume de calcul de chaque point. Ceux ci sont ainsi plus "lourds" en zone tropicale que dans les régions désertiques ou polaires. De plus, le processus root effectue également des opérations diverses non parallélisables (routage de l'eau, initialisation du parallélisme, etc...), et s'en trouve donc ralenti par rapport aux autres processus. Or les multiples communications émaillant la version parallèle font toutes appel à des synchronisations entre processus, imposant donc de les "mettre à niveau" régulièrement. Forcément, le processus ne contenant que des points d'une région polaire, favorisée au niveau des calculs, doit alors attendre que les autres processus aient terminé leurs calculs avant de pouvoir communiquer avec eux. La parallélisation n'est dans ce cas là pas optimale. Rééquilibrer les charges revient donc en pratique à diminuer le temps d'attente de chaque processus. C'est d'ailleurs en se basant sur le temps d'attente durant les précédentes modélisations que vont être redistribués les points de terre. À la fin de chaque exécution, le nombre de points de terre pour chaque processus est recalculé en fonction de leur temps d'attente. Le résultat de ce réajustement est stocké dans un fichier texte load_balancing, en vue d'être utilisé à la prochaine exécution (cf figure 14) fig. 14 : Contenu du fichier load_balancing pour une répartition sur 2 processus de 762 points (Europe) Ainsi, un processus ayant eu un temps d'attente supérieur aux autres processus, se verra attribuer un nombre supérieur de points de terre à la prochaine exécution. L'équilibre est donc amélioré au fur et à mesure des exécutions du modèle sur le même domaine avec le même nombre de processus. Concrètement, les tests ont montré que l'équilibre est quasiment atteint après seulement une première simulation d'au moins 30 jours, sauf certains cas particuliers. Par exemple, une première modélisation globale (contenant points de terre) à 4 processus va s'effectuer sur 3900 points de terre pour chaque processus, puis la répartition s'optimise par la suite. 18 / 42

19 Fig. 8b : Répartition de la zone Europe Afrique par ORCHIDEE_OL sur 3 processus, avec description des paramètres de la grille pour le 3ème processus (en bleu) (cf fig. 8c en annexe). 19 / 42

20 b) Une parallélisation néanmoins incomplète Il existe cependant des temps d'attente incompressibles entre les processus malgré une répartition de charges optimale. En effet, cette dernière n'est parfaitement efficace que si les calculs parallèles de chaque processus s'équilibrent simultanément avec les tâches non parallélisées. Ainsi ces dernières devraient toutes être suivies de calculs parallèles avant que le modèle n'effectue une synchronisation. En particulier, les opérations de lecture écriture des fichiers de redémarrage, pris en charge uniquement par le processus root, sont souvent encadrées de communications et donc de synchronisation, empêchant les autres processus de prendre en charge les calculs durant les phases d'attente. 3. Après la parallélisation 3.1.Différentes versions possibles pour ORCHIDEE_OL Élément critique du modèle séquentiel (jusqu'à 40% du temps de restitution), les entrées sorties ont également été concernées par la parallélisation, et seules les opérations sur les fichiers de redémarrage et d'initialisation restent affectées au seul processus 'root'. Ainsi, chaque processus obtient directement du fichier de forçage les données du domaine qui lui est affecté dans le cas du modèle forcé. Cette méthode est optimale pour les machines à systèmes de fichiers multiples comme le XD1, et ne pénalise pas les autres architectures. Cependant, l'utilisation de la bibliothèque IOIPSL par ORCHIDEE, pour les opérations d'entrées sorties, présente quelques défauts, notamment la lecture des fichiers de forçage : l'extraction des données d'un domaine spécifique du fichier de forçage passe obligatoirement par la lecture de ces données sur le domaine global. Peu gênante dans le cas du XD1, cette situation est préoccupante pour la modélisation sur une machine au système de fichier unique comme les stations de travail traditionnelles. Chaque processus va donc parcourir entièrement le même fichier, soit une lecture d'environ 100 Mo (correspondant à la cinquantaine de caractéristiques requises) à chaque passe principale, une interpolation étant effectuée pour les passes internes. C'est pourquoi j'ai développé, en concertation avec mes responsables, une version d'orchidee_ol où la lecture des fichiers de forçage se fait uniquement par 'root', celui ci les dispersant ensuite selon les besoins des autres processus. La charge réseau ainsi induite par la dispersion est négligeable quelle que soit l'architecture du calculateur, mais le système de fichiers se voit épargner une multitude de lectures inutiles. Cette version, à première vue fonctionnelle, mit rapidement en évidence un problème, jusqu'ici indécelé dans la version précédente, entraînant une modification des résultats par rapport aux précédents. Ensuite, devant les mises à jour prochaines de IOIPSL, il a été décidé d'abandonner cette nouvelle version et de concentrer les efforts sur d'autres aspects du code : débogage, mise à niveau par rapport à la version séquentielle. Néanmoins, cette variante de la version parallèle aura mis en lumière un problème important dans l'implémentation de la parallélisation, aboutissant dans certains cas à des résultats faux. 3.2.Les principaux problèmes rencontrés Les difficultés rencontrées dans la parallélisation proviennent en majorité de la répartition des points. En effet, sa mise en oeuvre a nécessité l'ajout de nombreuses variables permettant de passer de la grille 2D globale aux points de terre locaux (cf fig. 8b). Par exemple, le problème rencontré par ma version modifiée d'orchidee_ol provenait d'une initialisation erronée des index locaux, construits à partir d'un mauvais décalage de départ. 20 / 42

21 Cette erreur, qui touchait également la version parallèle d'origine, ne provoquait pas d'interruption de programme car les données en entrée étaient sous forme de tableaux 2D entièrement remplis (et donc couvraient un domaine plus large que le domaine local de chaque processus), contrairement à la version modifiée. Pour celle ci, les processus ne possédaient que les données appartenant à leur domaine propre, ce qui conduisait donc à des erreurs lorsque les index locaux accédaient à des données hors de leur domaine. 3.3.Un modèle en constante évolution a) Évolutions disjointes des versions parallèles séquentielles L'IPSL utilise actuellement le CVS (Concurrent Versions System) pour le contrôle de ses versions des modèles. En effet, des versions de production dites taggées (actuellement 1.4 pour ORCHIDEE) évoluent à partir des versions head de développement, selon les contributions de plusieurs intervenants du pôle de modélisation. Yann Meurdesoif a ainsi débuté la parallélisation du code d'orchidee (et de LMDz) durant l'été 2005 à partir de ce qui constituait alors la version de développement. La version qui m'a été fournie en Avril 2006 ne comportait donc pas les quelques évolutions intéressantes apparues sur la version séquentielle toujours en développement. J'ai donc intégré celles ci à la version parallèle, notamment, le module de grille, qui, en séparant la gestion de la grille 2D du reste du code, améliorait significativement sa maintenance. De plus, l'implémentation du parallélisme avait complexifié la gestion de la grille, rendant ce nouveau module encore plus intéressant. Ce module grid est utilisé par les versions forcée et couplées, et concerne quelques variables liées à la gestion en 2 dimensions et en points de terre : la fraction continentale de chaque point, la position de chaque point de terre selon la grille 2D (définie par le format des données atmosphériques) et selon sa position géographique (latitude longitude), les 4 voisins de chaque point de terre et la résolution de chaque point dans la grille 2D. Dans la version parallèle, ces variables sont dupliquées, car locales (seulement pour le domaine couvert par le processus), et globales, suffixée '_g', i.e. pour tout le domaine couvert par la modélisation (conformément à la convention de nommage du modèle, permettant d'identifier clairement les éléments provenant de la parallélisation). b) L'environnement des modèles de l'ipsl L'installation de ORCHIDEE et des autres modèles de l'ipsl passe par un module conçu par le pôle de modélisation, MODIPSL. Constituée de scripts shell (ksh pour la plupart), cette composante a dû être légèrement modifiée, premièrement pour la parallélisation du code et l'utilisation de nouvelles bibliothèques, et ensuite en vue du portage du code sur le XD1. Les interventions sur MODIPSL sont cependant facilitées par l'utilisation d'un fichier de paramétrage listant les options à utiliser lors des compilations. # Q mpif90 # Q mpif90 F_C = mpif90 c Mpreprocess Mbounds Mnosecond_underscore # D MD F_D = tp k8 64 Mvect O3 fast I$(ORDIR)/src_parallel/ D_MATHELP_ fig. 15 : Extrait du fichier AA_make.gdef servant à la configuration d'orchidee_ol Cette partie indique les options de compilations à insérer dans les Makefile 3.4.Fiabilisation et portabilité de la version parallèle La diversité de la communauté des utilisateurs d'orchidee nécessite des implémentations 21 / 42

22 sur de nombreux systèmes différents. En particulier, le serveur de développement sur lequel étaient testées les premières versions de ORCHIDEE_OL, disposait des outils suivants : un système Linux g95, compilateur Fortran open source supportant la norme Fortran95 (version 32 bits) MPICH2, bibliothèque MPI, supportant entièrement la norme MPI 1, et partiellement la norme MPI 2 (également 32 bits) NetCDF, bibliothèque développée par Unidata permettant de conserver et de manipuler des données scientifiques sous forme de fichiers binaires compressés (version 32 bits) bash et tcsh, interpréteurs de commande UNIX libres La visualisation des résultats au format NetCDF passe par Ferret, un programme externe gratuit et multi plateformes La seconde implémentation MPI libre disponible, du nom de LAM (Local Area Multicomputer), impose de mineures modifications de code pour être utilisée. Le problème survient seulement lors de l'utilisation de précisions spécifiques pour les entiers et les flottants, les deux bibliothèques utilisant des noms de type différents, tous deux étant autorisés selon la norme MPI 1. Un second aspect logiciel à prendre en compte est celui des débogueurs. Seul outil libre gérant la programmation parallèle MPI, gdb a été essentiellement utilisé pour la correction des problèmes d'orchidee, bien que n'étant pas exempt de défauts. Par exemple, l'arrêt sur erreur de l'application à déboguer, que ce soit causé par une erreur de segmentation ou par une erreur dans une communication MPI, provoque parfois l'arrêt de gdb, rendant délicate la localisation de l'erreur en cause. J'ai également eu l'occasion de déboguer sous une autre application, payante et non présente ni sur calculo ni sur le XD1, distribué par Etnus sous le nom de totalview. Sous une interface graphique permettant quasiment toutes les opérations disponibles, cette application ne présentait pas les mêmes défauts que son alternative libre. Dans le cas du XD1, nous utilisons une plate forme semblable mais entièrement 64 bits. De plus le compilateur de PGI (de Portland Group) est préféré à celui de g95, s'avérant être d'une complémentarité efficace combiné à son concurrent libre. Il mit ainsi en évidence des problèmes non signalés par g95, principalement des erreurs à l'exécution (ou runtime) : La détection de l'usage de tableaux non conformants dans les structures WHERE n'est pas encore implémentée dans g95. Son incorporation dans la bibliothèque runtime est cependant planifiée par Andy Vaught, développeur de g95. Par défaut autorisée par g95, l'utilisation de variables non initialisées et certains dépassements de tableaux n'étaient pas permis par l'implémentation de PGI. Pour qu'il continue à pouvoir être facilement modifiable par les différents intervenants, ORCHIDEE se doit de conserver la simplicité du modèle séquentiel au niveau des processus physiques. Ainsi les climatologues, désirant modifier le code, pour améliorer ou ajouter un phénomène lié au climat, sont dispensés des connaissances liées au parallélisme et à MPI. De même, il apparaît important que le code puisse être porté sur des machines ne disposant pas de bibliothèques MPI. Pour ces raisons, les directives parallèles ont été pour leur grande majorité séparées du reste du code, encapsulées dans un module PARALLEL gérant les communications MPI. Cette différentiation a permis de résoudre facilement le cas de systèmes dépourvus de bibliothèques MPI : une clé de précompilation CPP_PARA doit être indiquée pour implémenter le module MPI à la compilation. Le code ainsi obtenu est indépendant de MPI et convient aussi bien aux supercalculateurs qu'aux stations de travail, via une modification du fichier de paramètres de 22 / 42

23 MODISPL. De plus, la parallélisation du code avait apporté beaucoup d'éléments redondants, comme par exemple des calculs d'index globaux par rapport aux index locaux. J'ai donc éliminé du mieux possible ces redondances par l'utilisation de variables globales contenues dans le module PARALLEL. Cela rendait également possible une simplification des interfaces des fonctions de SECHIBA et de STOMATE, mais cette partie fut laissée au soin des équipes en charge de ces modules. Enfin, la version parallèle du modèle ORCHIDEE a été validée par une vérification informatique sur les fichiers historiques. Ces derniers étaient comparés à ceux obtenus après l'exécution du modèle séquentiel lors d'une exécution identique. 4. Protocole de test 4.1.Les critères de test a) Les entrées sorties Les opérations d'entrées sorties étant également parallélisées, l'exécution peut se dérouler sur le XD1 selon plusieurs principes différents : 1. Le répertoire de travail est sur le SAN et identique pour tous les processus. On espère ainsi profiter de l'architecture performante du SAN, bien que cette méthode génère un grand nombre d'accès disques concurrents. 2. Un répertoire situé sur le disque local de chaque noeud est utilisé par les 2 processus se déroulant sur celui ci. Cet espace de stockage est moins performant que le SAN, mais ce principe permet de répartir les opérations d'entrées sorties entre les noeuds. Son inconvénient est bien sûr la copie nécessaire sur chaque noeud des fichiers d'entrées et la récupération après restitution des fichiers de sortie (1,8 Go par paire de processus). 3. Le travail est effectué sur le SAN dans des répertoires spécifiques aux processus. Les performances du SAN sont également mises à contribution, mais sur des fichiers différents. Cette méthode s'avéra plutôt contraignante, paralysant le SAN pour les copies de fichiers entre répertoires (1,8 Go pour chaque processus). Inutilisable lors des premières exécutions (le SAN étant commun à tous les utilisateurs du CCRE), et peu bénéfique pour les performances du modèle (temps de restitution identique), cette méthode ne sera pas retenue, bien que fonctionnelle. J'ai donc comparé les performances des deux premières méthodes, l'exécution se déroulant donc soit sur le même répertoire du SAN, soit sur des répertoires spécifiques sur le disque local du noeud. Un nombre variable de processus a été testé dans ces deux configurations, afin de retenir l'influence de la répartition des entrées sorties sur le modèle ORCHIDEE. b) L'influence du nombre de processus et des options de compilation Afin d'évaluer les bénéfices de la parallélisation d'orchidee et de déterminer son nombre de processeurs optimum, les tests ont été effectués sur un nombre variable de processus. En comparant avec 1, 2, 4, 8 ou 16 processus et selon des options de compilation différentes spécifiques au compilateur Fortran90 de PGI, pgf90 : version g : sans optimisation, et permettant le débogage options : g version k8 : avec optimisation selon la machine ciblée, en l'occurrence un k8 64 bits options : fast 23 / 42

24 version k8sse : identique à la précédente, mais comprenant des instructions SSE (utilisable sur les processeurs Opteron), permettant parfois une amélioration des performances selon le code exécuté. options : fastsse version k8mpfo : identique à la version k8, mais incluant les optimisations apportées par un fichier de profil pgfi.out créé par une première exécution avec l'option Mpfi. options : fast Mpfo version k8ssenont : identique à la version k8sse, mais avec un schéma de gestion des données différentes, pouvant améliorer les performances des instructions SSE options : Mnontemporal fastsse Ces différentes versions constituent les principales optimisations de compilations disponibles sous PGI. Cette comparaison a été effectuée en utilisant un unique répertoire sur le SAN. 4.2.Les caractéristiques utilisées pour l'évaluation des performances Pour comparer les performances des différentes configurations du modèle, nous utiliserons deux critères : Le temps global utilisé par le processus le plus long (en l'occurrence, il s'agit toujours de root qui finalise les fichiers de sortie). Exprimé en cycles, il s'agit du temps CPU consommé par le calcul obtenu à partir de la fonction Fortran95 CPU_TIME. À noter que la fonction SYSTEM_CLOCK également disponible indique le temps réel de restitution, mais qu'il est quasiment identique à la valeur précédente (différences de l'ordre de 0.1%), les noeuds utilisés étant entièrement réservés à ce calcul. Le temps global hors MPI, identique au précédent sauf qu'il ne comprend pas le temps d'attente des processus lors des communications MPI. C'est une caractéristique importante de l'équilibre de charge, utilisée pour comparer le gain de parallélisation selon le nombre de processus. Chaque communication MPI est encadrée par deux appels système pour déterminer sa durée et la soustraire au temps global. L'échange en lui même étant d'une durée négligeable, c'est en fait le temps de synchronisation et donc d'attente qui est obtenu. Les temps obtenus n'intègrent pas le temps de reconstruction des fichiers historiques via l'outil rebuild, nécessaire dans le cas d'une exécution parallèle. Bien que les noeuds soient entièrement dévolus aux calculs d'orchidee lors des exécutions, les ressources du SAN, partagées par différents utilisateurs et différents calculateurs, influent sur les performances du modèle. Pour cette raison, les tests sont lancés plusieurs fois (au moins 4 fois sauf pour les tests à 16 processus) à des moments différents, et leur meilleure performance est retenue. En général, les tests ne présentaient pas de différences de plus de 5%, hormis dans les cas bien précis de pannes matérielles. Par ailleurs, la répartition des points de terre utilisée sera une répartition optimum, obtenue après plusieurs exécutions. Les critères de test comme les options de compilation et la localisation n'influent pas sur cette répartition, contrairement bien sûr au nombre de processus utilisés. 4.3.La mise en oeuvre sur le XD1 Le XD1, comme la majorité des supercalculateurs, est destiné à être utilisé simultanément pour plusieurs tâches, le plus souvent soumis par des équipes différentes. Afin d'exploiter efficacement l'architecture mis en place, il utilise donc le SGE : chaque travail est mis en attente jusqu'à libération des ressources demandées, pour ensuite être exécuté. Pour éviter la monopolisation du système par un seul type de calcul, les travaux sont répartis en trois catégories 24 / 42

25 selon une limite de temps de travail, celle ci étant fixée par l'utilisateur lors de sa soumission : jusqu'à 2 heures (2 noeuds réservés) de 2 à 24 heures (6 noeuds réservés) de 24 à 72 heures (20 noeuds réservés). Le nombre de noeuds d'une classe peut s'étendre selon nécessité vers ceux des classes supérieures. Par exemple, dans le cas d'une soumission demandant 16 processus, la première classe va être utilisée selon le nombre de processeurs disponibles (4 processeurs au maximum), puis la deuxième classe (12 processeurs au maximum), puis en dernier ressort les processeurs de la troisième classe. Les processeurs chargées d'une tâche lui sont alors exclusivement réservées, hormis la faible charge de maintien du système. Pour effectuer des mesures de performances sur ORCHIDEE_OL, nous resterons dans la classe de travail la plus petite, dont la durée est inférieure à 2 heures, suffisante pour nous permettre d'effectuer des modélisations sur l'europe pour des durées de 96 jours, avec une résolution de 1 sur 1 en longitude et latitude. Par ailleurs, favorisée par une priorité plus élevée que celles des autres utilisateurs, cette classe me permet de voir mes soumissions plus rapidement traitées, de quelques minutes à quelques jours selon le nombre de processus demandés. SGE met à disposition un programme permettant les soumissions de travail, qsub, admettant en argument un fichier de soumission et quelques options pour paramétrer le travail en question. Certaines sont obligatoires, comme le nombre de processus demandés ou le temps de travail maximal, d'autres sont optionnelles, comme la priorité qui lui est accordée par rapport à ses autres travaux, ou l'utilisation d'un répertoire de travail spécifique. Un fichier de configuration personnel existe dans le répertoire d'accueil de l'utilisateur,.sge_request, indiquant les options utilisées par défaut. Le fichier de soumission, en argument de qsub est en fait un fichier de script shell, pouvant également contenir les paramètres spécifiques au travail soumis via des commentaires, et, outre les éventuelles taches de pré et post traitements, contient au moins la commande spécifique à la mise en parallèle de l'exécution (cf figure 16). $ mpirun hostfile $TMPDIR/machines $XD1LAUNCHER job Fig. 16 : commande de lancement de travail parallèle sur le XD1 La commande qsub provoque en fait l'exécution du script qu'il désigne sur un des processeurs du serveur de calculs. Avant cette exécution, le SGE initialise la variable $TMPDIR sur cette machine, désignant un emplacement du type /tmp/xx...xx/ spécifique à cette soumission. Dans ce répertoire est créé le fichier texte machines, contenant les noms des processeurs sur lesquels sera effectué le travail représenté par job. Il est d'ailleurs impossible pour l'utilisateur d'accéder à une des machines de calculs autrement que par l'appel à qsub. Le fichier machines est lu lors de l'appel mpirun, amorçant le parallélisme. Le travail job, le plus souvent l'exécutable du modèle, est à ce moment là effectué par tous les processus. L'utilisation d'un script shell à la place d'un exécutable permet en outre d'effectuer rapidement et simplement des opérations de pré/post traitements qui doivent s'appliquer sur tous les processus. Dans le cas d'orchidee, le script run_orchidee gère selon les options demandées la copie de fichiers vers les disques locaux ou vers le SAN. Et ce même script peut lancer à son tour le travail parallèle pour chaque processus, leur synchronisation s'effectuant via la directive d'initialisation MPI, mpi_init, présente dans le code du modèle. Or l'exécution d'orchidee entraîne l'accès exclusif à certains fichiers de sortie, imposant une seule simulation à la fois, et donc une seule soumission à la fois. C'est pourquoi il me sera nécessaire de prendre en charge l'enchaînement des soumissions de façon séquentielle par un script. Le script run_wait effectue une soumission dès qu'une exécution est terminée. Pour cela, il appelle 25 / 42

26 toutes les 10 secondes, la commande SGE qstat, qui informe sur les travaux en cours et en attente, et il soumet une exécution d'orchidee dès qu'il n'en existe ni en cours ni en attente (cf figure 17). Fig. 17 : Scripts utilisés pour effectuer les tests sur le XD1 Si la procédure de test s'en trouve plus complexe, elle nous permettra cependant d'effectuer sans interactions avec le supercalculateur plus de 50 exécutions en 3 semaines, malheureusement entre coupées de pannes logicielles et matérielles du XD1. Un problème est également apparu au niveau de la gestion des classes de soumission : l'utilisation de la première classe, aux travaux inférieurs à deux heures, aurait dû me permettre d'exécuter rapidement les séquences de soumission, avec la succession rapide des exécutions, favorisée par une priorité supérieure aux autres utilisateurs. Mais la possibilité d'utiliser une durée limite d'exécution nulle (considérée par SGE comme infinie), occupant la première classe, a imposé une attente des exécutions beaucoup plus longue, d'autant plus que ces travaux duraient parfois plus d'une journée. 4.4.La récupération des résultats Les résultats sont enregistrés sur le SAN, dans des répertoires spécifiques à chaque test, via le script exécuté par chaque processus. Je récupère les résultats des tests par l'intermédiaire d'un script Perl result_extract.pl, parcourant tous les répertoires de résultats, et enregistrant dans les fichiers RESULT.nb_de_processus des indicateurs de performances plus facilement exploitables. 5. Résultats et analyse 5.1.Les options de compilation et le nombre de processus La version k8 (cf 4.1) apparaît dans figure 19 la plus performante et ce, quelque soit le nombre de processus utilisés, alors que l'utilisation des instructions SSE, d'un gain parfois spectaculaire dans certaines applications n'apporte pas d'amélioration. Cela semble provenir, selon un article paru sur le site x86 secret, de l'architecture même de l'opteron, qui constitue les machines du XD1 : ces processeurs ne parviendraient pas à tirer parti des opérations vectorielles lors de l'utilisation d'instructions SSE. ORCHIDEE_OL et les autres modèles de l'ipsl étant optimisés pour les processeurs vectoriels, le gain réel pouvant être apporté par les instructions SSE est absorbé par la perte de la vectorisation, aboutissant à des performances légèrement moins bonne que sans l'utilisation du SSE, quelle que soit la méthode de gestion de données utilisée (le prefetching) : k8sse et k8ssenont. 26 / 42

27 Par ailleurs, la version compilée à partir du fichier de profil, k8mpfo, est également moins performante que la version k8 dont elle est pourtant issue. En effet, la version k8mpfo a été compilée à partir d'un seul fichier de profiling issu d'une exécution de la version k8 sur seulement deux jours de simulation au lieu de 93 jours et sur seulement quatre processus (une exécution qui diffère donc énormément de celles qui sont effectuées dans le cadre du test, faussant alors l'optimisation apportée par le compilateur qui exploite ce profiling). Sans surprise, la version de débogage confirme l'intérêt de l'optimisation du code par le compilateur, et sera bien sûr à proscrire en environnement de production. Les autres comparaisons sont donc réalisées à partir de la version k8, bien que ses performances soient très proches de celles des autres versions. Nombre de processeurs Temps de restitution (en cycles CPU) 601,79 331,45 176,77 102,63 77,52 Gain par rapport à la version séquentielle 1 1,81 3,4 5,86 7,76 Fig. 18 : Tableau des performances en vitesse d'exécution obtenues selon le nombre de processeurs utilisés Fig. 19 : Évolution des performances en cycles CPU d'orchidee_ol selon les options de compilation et le nombre de processus utilisés 27 / 42

28 Nous voulons à présent déterminer le bénéfice apporté par la parallélisation selon le nombre de processus utilisés. Nous pouvons évaluer l'efficacité du parallélisme à travers deux caractéristiques quantifiables : le gain par processus R/N obtenu par la version parallèle sur la version séquentielle et, plus finement, le coefficient de parallélisabilité s selon la loi d'amdahl (cf 2.2). Compris entre 0 et 1, celui ci quantifie plus exactement le rendement apporté par la multiplicité des processus, et donc la quantité de ressources utilisées. Dans la figure 20, le gain par processeur R/N de la parallélisation nous indique une baisse du rendement en multipliant les processus de travail, comme l'annonçait la loi d'amdahl (cf figure 10). Cependant, la pente de cette décroissance, plutôt faible, semble annoncer un modèle efficace pour le parallélisme, notamment sur ce genre d'architecture. Ceci est plus nettement mis en évidence par la courbe du coefficient de parallélisabilité, aux valeurs maximales supérieures à 0,6. Le maximum, atteint pour 6 processeurs, est d'ailleurs à relativiser dans le cas de notre modèle : la décroissance de ce coefficient est très faible et plutôt satisfaisante à 8 processus. Le rendement est en revanche très inférieur au delà de cette valeur. La baisse du coefficient de parallélisabilité vient justement des éléments non parallélisés des calculs : l'initialisation du parallélisme et certaines lectures et écritures, toutes seulement effectuées par le processus root. Ce dernier est en effet chargé de certaines tâches au temps d'exécution constant, alors que les charges de chaque processus s'allègent à mesure que leur nombre s'accroît, les amenant à augmenter leur temps d'attente lors des synchronisations. Fig. 20 : Évolution du gain par processeur R/N en vitesse d'exécution et du coefficient de parallélisabilité s selon le nombre de processeurs sur le modèle ORCHIDEE_OL 28 / 42

29 5.2.Les entrées sorties Les résultats obtenus plaident très légèrement en faveur d'une parallélisation totale, aussi bien des calculs que des opérations d'entrées sorties. Mais les performances semblent plus régulières dans le cas d'une exécution locale, ne subissant pas l'influence d'un SAN parfois ralenti par d'autres utilisateurs. Le temps de copie n'a en revanche pas pu être déterminé avec certitude et la figure 21 ne prend pas cette caractéristiques en compte. Cependant, il aurait été intéressant de tester d'autres méthodes de copie des fichiers, la commande cp n'étant pas optimale pour les préparations dans le cas de l'exécution sur les disques locaux : L'outil rcp permettant de s'affranchir du passage par la couche NFS du serveur frontal, très consommatrice en temps CPU. Ce procédé, notamment utilisé avec LMDz sur le récent supercalculateur de l'idris, un SX8 de NEC, permettait de gagner 80% du temps de copie par rapport à l'utilisation de la commande cp. Cette méthode aurait cependant nécessité que le SAN soit directement accessible par les noeuds de calculs. La couche NFS lors de la copie peut également être évitée par le biais d'une application parallèle, le réseau RapidArray du XD1 étant optimisé pour MPI. Pour des raisons de temps, ces méthodes n'ont pas été testées dans le cadre de ce stage. Mais on peut noter également sur la figure 21 que les temps d'attente MPI sont bien plus importants dans le cas de la version s'exécutant sur les disques locaux. Ce résultat met en évidence une répartition des charges moins efficace dans le cas d'espace de stockage aux débits moins performants. En effet, le processus root est l'élément lent dans cette version, un phénomène plus accentué que dans le cas de la version s'exécutant sur le SAN. Il effectue notamment des tâches non parallélisées qui ne sont pas compensées par la répartition des charges (cf. 2.3.c). Ceci peut constituer une voie à explorer pour une optimisation possible du modèle parallèle. 29 / 42

30 Fig. 21 : Comparaison des performances d'orchidee_ol selon son exécution sur les disques des noeuds ou sur le SAN 30 / 42

31 6. Conclusions et perspectives 6.1.Bilan de la parallélisation Nous pouvons tout d'abord faire un premier bilan des bénéfices apportés par la parallélisation du modèle climatique de surface continentale. Avec des temps de restitution nettement réduits par rapport au modèle séquentiel, cette version parallèle parvient à tirer à profit efficacement de la multiplication des ressources. Ainsi, près d'un an après le début de la parallélisation de LMDz et d'orchidee par Y. Meurdesoif, ce dernier modèle présente des améliorations pouvant être considérées comme nécessaires étant donné l'évolution actuelle des supercalculateurs. Mais la parallélisation d'un modèle aussi complexe multiplie les sources d'erreurs possibles, nécessitant une rigueur particulière pour obtenir un code valide. Cet aspect est à prendre en compte, d'autant plus qu'une partie de la maintenance du code se voit à présent réservée aux ingénieurs de l'ipsl possédant les compétences nécessaires dans le domaine du calcul parallèle. Grâce à l'encapsulation des directives de parallélisation, les chercheurs pourront néanmoins bénéficier de cette avancée technique sans les contraintes qui y sont liées. 6.2.Les bénéfices apportés par le récent supercalculateur XD1 du CCRE L'autre partie de mon stage portait sur le portage du modèle de surface continentale sur un supercalculateur de type grappe de serveurs, sur lequel il est également appelé à être exploité. Son architecture spécifique permet, à travers l'exploitation de divers scripts, d'étendre les possibilités d'optimisation, comme par exemple l'emploi de disques locaux à la place de la baie de stockage centralisé. L'aspect négatif de cette «liberté» est la complexité qui s'y lie, et la nécessité de connaître précisément les caractéristiques techniques du système et les outils associés afin de pouvoir en tirer idéalement profit. Par ailleurs, d'autres éléments sont mis en avant dans ce stage en vue d'une exploitation optimale du modèle sur le serveur de test. Tout d'abord, il s'avère inutile d'utiliser un fichier de profiling visant à optimiser la compilation du modèle destiné à s'exécuter selon des paramètres divers. Mais il serait pourtant intéressant de tester un modèle sur une durée identique à celle dont est issu le fichier de profiling pour savoir si un gain est possible par ce biais là. Un autre point concerne l'une des technologies des processeurs actuels, le SSE, semblant ne pas pouvoir être pleinement exploitée par ce modèle. Une hypothèse possible serait l'impossibilité pour l'architecture du K8 Opteron de pouvoir traiter des opérations vectorielles par des instructions SSE. Une confirmation de cette interprétation pourrait émaner de la comparaison des performances du XD1 face à une architecture équivalente dotée de processeurs différents capables de tirer profit de ces deux optimisations simultanément. 6.3.Les critères déterminants pour l'optimisation des calculs d'orchidee Les performances obtenues par le modèle parallèle constituent déjà une satisfaction, d'autant plus que le XD1 est une des architectures où sera porté le modèle climatique global de l'ipsl dans le cadre de simulations à but scientifique. Néanmoins, les tests de performance mettent en avant des limites au gain apporté par la parallélisation telle qu'elle est implantée dans ORCHIDEE_OL. En particulier, le coefficient de parallélisabilité s (issu de la loi d'amdahl, cf 2.2.a) montre un «rendement» des ressources parallèles optimum pour 6 processeurs et satisfaisant jusqu'à 8. Au delà, la parallélisation perd énormément en efficacité. Ceci nous amène à penser que l'utilisation de plus de 16 processeurs sur 31 / 42

32 ce modèle dans le cas du XD1, n'apporterait pas de gain dans la vitesse d'exécution, à moins d'améliorer les éléments non parallélisés, comme les lectures et écritures de certains fichiers. Dans la même optique, il serait intéressant d'expérimenter d'autres méthodes d'exploitation des systèmes de stockage, notamment dans le cas du XD1 : la combinaison du SAN et des disques locaux pourrait être la solution idéale pour optimiser les opérations massives d'entrées sorties des modèles climatiques. 32 / 42

33 Annexes fig. 8b : Exemple de la répartition d'un domaine d'étude (ici l'europe et l'afrique) sur 3 processeurs (cf fig. 8). Script de récupération des résultats des tests effectués sur le XD1 eclair : result_extract.pl 1. #!/usr/bin/perl w 2. use diagnostics; 3. use Carp; sub min { my $min = shift; $min = $_ < $min? $_ : $min $min } sub init_file { 8. #Init var 9. $dir = $_[0]; 10. $ok = 0; 11. %array = ('nb'=>0,'version'=>''); # Action 14. open FILE, "< $dir/out.0" or die "pb $dir/out.0"; 15. while ($ligne = <FILE>) { 16. if ($ligne =~ /.*ORCHtmp.*/) { 17. $ok = 1; 18. } 19. if ($ligne =~ /ORCHIDEE_BIN.+orchidee_ol_(.+)/ && $ok) { 20. $array{'version'} = $1; 21. } 22. if ($ligne =~ /NSLOTS=([0 9]+)/ && $ok) { 33 / 42

34 23. $array{'nb'} = $1; 24. } 25. } # Verif 28. close FILE; 29. return(%array); 30.} sub init_dir { 33. opendir DIR, '.' or die ". n'existe pas!"; = readdir DIR; 35. foreach $dir (@files) { 36. # Run of the 08/08/2006 have to be 37. if ( d $dir && $dir =~ /ORCH_.*/ &&!($dir =~ /.+\ _[0 9]{4}/) 38. && ( f "$dir/shell.out" f "$dir/out_orchidee_100")) { 39. print "DIR = $dir"; 40. if ( f "$dir/out.0") { 41. print " OK"; 42. push(@array, $dir); 43. } 44. print "\n"; 45. } 46. } 47. close DIR; 48. return(@array); 49.} sub print_result { 52. $nb = $_[0]; 53. %result = %{$_[1]}; 54. open FILE, "> RESULT.$nb" or die "Pb RESULT.$nb"; 55. foreach $version (keys %result) { 56. %time = %{$result{$version}}; # Index array for sort 59. $i=0; 60. %temp_sort = (); 61. foreach $val (@{$time{'global'}}) { 62. $temp_sort{$i++} = $val; 63. } = sort({$temp_sort{$a} <=> $temp_sort{$b}} keys %temp_sort); print FILE $version; 67. print $version; 68. foreach $i (@sorting) { 69. if ($time{'spec'}[$i] ne '*') { 70. print FILE "\t".($time{'global'}[$i] time{'hs_mpi'}[$i])."\t".$time{'global'}[$i]; 71. } 72. print ' ('.$time{'global'}[$i].','.$time{'hs_mpi'}[$i].')'.$time{'spec'}[$i]; 73. } 74. print FILE "\n"; 75. print "\n"; 76. } 77. close FILE; 78.} sub get_result { 81. # Init input 82. $dir = $_[0]; 83. %conf = %{$_[1]}; 34 / 42

35 # Init Output & local var = (0,0,''); 87. $global = 0; # global time 88. $hs_mpi_root = 0; # global time without mpi time for root 89. $hs_mpi = 0; # global time without mpi for the fastest proc 90. $spec = ''; # hs_mpi_root has to be greater than others hs_mpi 93. # else this means a server pbm leads one of the process to a light load 94. # Pbms will be noticed with a * in $spec if ($conf{'nb'} == 1) { 97. $out_root = 'shell.out'; 98. } 99. else { 100. $out_root = 'out_orchidee_100'; 101. } 102. open FILE, "< $dir/$out_root" or die "Pb $dir/$out_root"; 103. # Lecture du fichier de sortie du proc root 104. while ($ligne = <FILE>) { 105. if ($ligne =~ /THAT ALL FOLK!!/) { 106. $ok = 1; 107. } 108. if ($ligne =~ /TEMPS GLOBAL.+CPU TIME.+([0 9.]{17})/) { 109. $global = $1; 110. } 111. if ($ligne =~ /TEMPS HORS MPI.+CPU TIME.+([0 9.]{17})/) { 112. $hs_mpi = $1; 113. $hs_mpi_root = $1; 114. } 115. } 116. close FILE; for ($i=1; $i<$conf{'nb'}; ++$i) { 119. if ($ok) { 120. $ok = 0; 121. $nb = '0'.$i; 122. if ($i >9) { 123. $nb = "$i"; 124. } 125. $FILE = 'out_orchidee_1'.$nb; if ( f "$dir/$file") { 128. open FILE, "< $dir/$file" or die "Pb $dir/$file"; 129. while ($ligne = <FILE>) { 130. if ($ligne =~ /THAT ALL FOLK!!/) { 131. $ok = 1; 132. } 133. if ($ligne =~ /TEMPS HORS MPI.+CPU TIME.+([0 9.]{17})/) { 134. $hs_mpi = min($1,$hs_mpi); 135. if ($1 > $hs_mpi_root) { 136. $spec = '*'; 137. } 138. } 139. } 140. close FILE; 141. } 142. else { 143. $ok=1; 144. } 35 / 42

36 145. } 146. } if ($ok) { = ($global, $hs_mpi, $spec); 150. } 151. return(@result); 152.} @dirs = init_dir(); 156.foreach $dir (@dirs) { 157. print 'Entering '.$dir."\n"; 158. %conf = init_file($dir); 159. if ($conf{'nb'}!= 0) { = get_result($dir,\%conf); 161. push(@{$results{$conf{'nb'}}{$conf{'version'}}{'global'}}, $temp[0]); 162. push(@{$results{$conf{'nb'}}{$conf{'version'}}{'hs_mpi'}}, $temp[1]); 163. push(@{$results{$conf{'nb'}}{$conf{'version'}}{'spec'}}, $temp[2]); 164. } 165.} 166.foreach $nb (keys %results) { 167. %result = %{$results{$nb}}; 168. print_result($nb,\%result); 169.} Script de soumission en chaîne run_wait 1. #!/bin/bash for i in ; do 4. for version in k8; do 5. for np in ; do 6. echo "WAITING qsub np=$np version=$version" 7. while [ $(qstat grep 'orch_' c) ne 0 ]; do 8. sleep done # Output 12. date=`eval date +%y%m%d_%h%m` 13. OUTPUT="$HOME/TEST/ORCH_${np}_$version.$date" 14. mkdir $OUTPUT qsub o "$OUTPUT/shell.out" N "orch_${np}_$version" pe am.mpi $np submit.bis o $version d $OUTPUT $@ 18. done 19. done 170. Script de lancement de l'exécution en parallèle sur le XD1 eclair : submit.bis #!/bin/bash ## Init >begin OUTPUT='.' ORCHIDEE_INPUT="$HOME/TEST/HOMERUN" ORCHIDEE_BIN="$HOME/ORCHIDEE_PARA/modipsl/bin/orchidee_ol" WKDIR="$HOME/TEST/HOMERUN" CP_INPUT=0 # copy of the input file 36 / 42

37 9. LBO='Load_balance_orchidee.dat' 10.COPYRUN= ## Options 13.while getopts c:o:d: V 14. do 15. case $V in 16. c) case $OPTARG in 17. 'home') WKDIR="$HOME/TEST/HOMERUN" # run in the SAN dir, and same input for each procs (default) 18. ;; 19. 'copy') WKDIR="$HOME/TEST/COPYRUN/PS${MPIRUN_RANK}" # run in the SAN dir, but in different input 20. COPYRUN=1 21. CP_INPUT=1 22. ;; 23. 'tmpdir') WKDIR="/tmp/ORCHtmp" # copy to local HD and run 24. CP_INPUT=1 25. ;; 26. esac 27. ;; 28. o) ORCHIDEE_BIN="${ORCHIDEE_BIN}_$OPTARG" 29. ;; 30. d) OUTPUT=$OPTARG 31. ;; 32. esac 33.done ## Init >end 36.OUTPUT_OUT="$OUTPUT/out.$MPIRUN_RANK" 37.if [! d $WKDIR ]; then 38. mkdir $WKDIR 39.#else 40.# if [ $CP_INPUT eq 1 ]; then 41.# rm $WKDIR/* Rf 42.# fi 43.fi echo "WKDIR=$WKDIR" >> $OUTPUT_OUT 46.echo "ORCHIDEE_BIN=$ORCHIDEE_BIN" >> $OUTPUT_OUT 47.echo "NSLOTS=$NSLOTS" >> $OUTPUT_OUT rm ${WKDIR}/*_rest_out.nc ${WKDIR}/*_forcing.nc ${WKDIR}/*_history_*.nc ${WKDIR}/Load_balance_orchidee.dat f #*********************************** 53.## Pre working ********************* 54.begin=`eval date +%s` if [ e "${LBO}_${MPIRUN_NPROCS}" ]; then 57. cp "${LBO}_${MPIRUN_NPROCS}" "${WKDIR}/${LBO}" 58.fi 59.if [ $CP_INPUT eq 1 ]; then # If the input files have to be copied 60. for carte in carteveg5km.nc elevation.nc irrigated.nc islscp2_for_1982.nc lai2d.nc ncc_for_1982.nc reftemp.nc routing.nc soils_param.nc; do 61. if [! e "${WKDIR}/$carte" ]; then 62. echo "copie $carte for RANK=$MPIRUN_RANK" 63. cp "${ORCHIDEE_INPUT}/$carte" "${WKDIR}/" 64. fi 65. done 66. cp "${ORCHIDEE_INPUT}/run.def" "${WKDIR}/" 37 / 42

38 67.fi #*********************************** 71.## Job ***************************** 72.cd "$WKDIR" 73.pwd 74.begin_wk=`eval date +%s` 75.time $ORCHIDEE_BIN 76.end_wk=`eval date +%s` 77.cd "$HOME/TEST/" #*********************************** 80.## Post working ******************** 81.if [ $MPIRUN_RANK eq 0 ]; then 82. cp ${WKDIR}/${LBO} ${LBO}_${MPIRUN_NPROCS} 83.fi 84.mv ${WKDIR}/*history* $OUTPUT/ 85.mv ${WKDIR}/out_orchidee* $OUTPUT/ ## Finalize 88.end=`eval date +%s` 89.let "tps=$end $begin" 90.let "tps_wk=$end_wk $begin_wk" 91.echo "Global time (s) : $tps" >> $OUTPUT_OUT 92.echo "Orchidee time (s) : $tps_wk" >> $OUTPUT_OUT Extrait du module PARALLEL contenant la fonction de réajustement des points de terre 1. SUBROUTINE Write_Load_balance(times) 2. IMPLICIT NONE 3. REAL,INTENT(IN) :: times 4. CHARACTER(len=255) :: filename='load_balance_orchidee.dat' INTEGER :: unit_number=10 7. INTEGER :: i,ierr 8. REAL :: All_Times(0:mpi_size 1) 9. REAL :: average 10. REAL :: efficiency 11. INTEGER :: dp,s 12. INTEGER :: New_nbpoints(0:mpi_size 1) WRITE(*,*),'time',times 15. CALL MPI_GATHER(times,1,MPI_REAL_ORCH,All_times,1,MPI_REAL_ORCH,root_prc,MPI_COMM_ORCH,ierr) 16. IF (is_root_prc) WRITE(*,*),'ALL_times',All_times IF (is_root_prc) THEN OPEN(UNIT=unit_number,FILE=trim(filename),STATUS='replace',FORM='formatted',IOSTAT=ierr) average=sum(all_times(:))/mpi_size 23. DO i=0,mpi_size efficiency=all_times(i)/nbp_para_nb(i) 25. New_nbpoints(i)=Nbp_para_nb(i) (All_times(i) average)/efficiency 26. ENDDO S=sum(new_nbpoints(:)) 29. dp=nbp_glo S IF ( dp > 0 ) THEN 32. DO WHILE ( dp > 0 ) 38 / 42

39 33. New_nbpoints(MOD(dp,mpi_size))=New_nbpoints(MOD(dp,mpi_size)) dp=dp ENDDO 36. ELSE 37. dp= dp 38. DO WHILE ( dp > 0 ) 39. New_nbpoints(MOD(dp,mpi_size))=New_nbpoints(MOD(dp,mpi_size)) dp=dp ENDDO 42. ENDIF DO i=0,mpi_size WRITE(unit_number,*) i,new_nbpoints(i) 46. ENDDO 47. CLOSE(unit_number) 48. ENDIF END SUBROUTINE Write_Load_Balance Extrait de l'article sur l'architecture des processeurs AMD K8 x86 64 du site x86 secret : 5) Calculs flottants, SSE et SSE2 Pourquoi plus de registres SSE/SSE2 et pas plus de registres flottants x87? La raison est assez simple : suivant la voie ouverte par Intel, AMD veut tout simplement abandonner le x87. L'x87 est vieillissant, et surtout de manipulation assez peu pratique car les registres sont gérés sous la forme d'une pile et non de registres. Adieu donc le code x87, au profit du code SSE/SSE2 et de ses 16 registres. Corollaire de cet abandon : les intructions MMX de première génération, qui opéraient sur ces mêmes registres x87, sont également abandonnés. Là encore, les instructions MMX passeront par les registres SSE/SSE2. Cela dit, les K7/K8 ne sont pas réputés pour briller particulièrement en SSE/SSE2, surtout face au Pentium 4 qui a été dessiné pour fournir des performances optimales sur ces deux jeux d'instructions. Cette différence de performance provient de l'architecture même des unités de calcul flottant des deux processeurs. Les unités de calculs comprennent des circuits logiques dédiés à un type d'opération. Ces circuits obéissent à des schémas logiques classiques, citons par exemple l'arbre de Wallace qui est une méthode d'organisation des portes logiques pour mener une opération telle qu'une addition ou une multiplication. Le Pentium 4 ayant été dessiné pour prendre en charge les opérations flottantes sur des registres 128 bits, les arbres de Wallace de ses circuits logiques ont une largeur de 128 bits, ce qui signifient qu'ils sont capables de traiter en une passe une multiplication ou une addition 128 bits. Attention, cela ne veut pas dire que de telles opérations s'effectuent en un seul cycle, car ces opérations restent soumises au découpage du pipeline. Le traitement en une passe signifie qu'un seul passage dans l'arbre de Wallace sera nécessaire afin d'effectuer une opération sur des registres 128 bits. Dans le K8, les unités de calculs flottants ont été dessinées pour fournir des performances maximales sur des registres x87, soit 80 bits. Les arbres de Wallace ont donc une largeur de 80 bits, ce qui nécessite deux passes pour effectuer une opération sur des registres 128 bits. Cela explique que les performances SSE et SSE2 du K8 soient, dans la plupart des cas, inférieures à celles obtenues sur un Pentium 4. Cela signifie t il pour autant que le K8 va perdre sa suprématie en calculs flottants lorsqu'il est utilisé dans un environnement 64 bits? Les calculs flottants vont ils donc être moins rapide en mode 64 bits? En fait, cela dépendra, mais dans la plupart des cas, la réponse est non. Pour en comprendre la raison, il faut examiner la façon dont les compilateurs vont créer du code SSE à partir de calculs flottants classiques. Une opération flottante sera transformée en instruction SSE de type scalaire, c'est à dire n'opérant que sur une seule partie de 32 ou 64 bits du registre 128 bits. Ces instructions scalaires sont certes moins efficaces que les instructions vectorielles, qui permettent d'effectuer la même opération sur toutes les parties du registre 128 bits (c'est d'ailleurs la raison d'être de la technique SIMD, Single Instruction Multiple Data). Mais les instructions scalaires n'opérant pas sur les 128 bits du registre, elles peuvent s'effectuer en une seule passe sur un arbre de Wallace de 80 bits, ce qui redonne toute leur performance aux unités de calcul du K8. En résumé, le K8 souffre en SSE dès lors que des instructions vectorielles sont utilisées, mais il se comporte de façon très performantes sur les instructions scalaires. A la différence du Pentium 4, qui digère de la même façon les deux types d'instructions. A la faveur du K8, les compilateurs actuels ne sont capables de générer que des instructions scalaires. L'utilisation d'instruction vectorielles passe par une phase préalable de vectorisation du code, qui à l'heure actuelle n'est faite efficacement que par un programmeur humain. 39 / 42

40 Glossaire CEA Commissariat à l'energie Atomique CCRE Centre de Calcul Recherche et Enseignement (UPMC) CVS Concurrent Versions System Calculo Plate forme de développement du stage, équipée d'un bi Opteron, située à l'ipsl Eclair Plate forme de test du stage, équipée d'une grappe de serveurs XD1, située au CCRE de Jussieu g95 Compilateur Fortran95 open source IDRIS Institut du Développement et des Ressources en Informatique Scientifique IOIPSL Interface NetCDF des modèles climatiques de l'ipsl IPCC Intergovernmental Panel on Climate Change, organisation internationale chargée de compiler les travaux de recherche concernant les changements climatiques IPSL Institut Pierre Simon Laplace LIM Louvain Ice Model LMD Laboratoire de Météorologie Dynamique LMDz Modèle climatique atmosphérique de l'ipsl développé par le LMD LSCE Laboratoire des Sciences du Climat et de l'environnement MODIPSL Jeu de commandes permettant de rapatrier, configurer et compiler tous les modèles de l'ipsl MPI Message Passing Interface, parallélisation multitâches pour systèmes à mémoire distribuée. NFS Network FileSystem, protocole logiciel de montage de systèmes de fichiers via le réseau 40 / 42

41 NetCDF Network Common Data Form, implémentation libre de gestion de données fournie par Unidata ORCHIDEE ORganizing Carbon and Hydrology In Dynamic EcosystEms, modèle climatique de la surface continentale de l'ipsl OpenMP Open Multi Processing, parallélisation multitâches pour machines à mémoire partagée. Opteron Processeur 64 bits compatible 32 bits du fabricant AMD basé sur l'architecture K8 3 PGI Compilateurs propriétaires du Portland Group disponibles pour le C, C++ et Fortran SAN Storage Area Network, réseau spécialisé permettant de mutualiser des ressources de stockage SECHIBA Module d'orchidee gérant la physique de la surface continentale, du sol et de la végétation SGE Sun Grid Engine, système de gestion de travaux en batch sur les systèmes distribués SSE Streaming SIMD Extensions, jeu d'intructions compatibles pour processeurs x86 STOMATE Module d'orchidee gérant la biogéochimie continentale UPMC Université Pierre et Marie Curie Paris VI XD1 (Cray) Supercalculateur constitué d'une grappe de serveurs, équipant notamment le CCRE de Jussieu 41 / 42

42 Bibliographie The new IPSL climate system model : IPSL CM4, Marti O. et al, Juin 2006 Note du pôle de modélisation de l'ipsl n 26 The structure of ORCHIDEE, Polcher J. et al, Décembre L'avenir du calcul parallèle, Foujols M. A., Janvier CCRE 24jan2006.pdf Architecture des processeurs AMD K8 x86 64, x86 secret, Février secret.com/articles/cpu/k8 3/amd64 8.htm Documentations sur le XD1 du CCRE, M. Krawczyk PGF90 Manual, The Portland Group g95 Manual, Vaught A. Support de cours MPI de l'idris, Girou D. Support de cours Fortran95 de l'idris, Corde P. Support de cours OpenMP de l'idris, Chergui J. Wikipedia Google Parallelization of Codes on the SGI Origins, Chang S. Top 500 des plus puissants supercalculateurs connus Groupe d experts intergouvernemental sur l évolution du climat (GIEC) 42 / 42