FLASH INFORMATIQUE FI

Numéro spécial Calcul à haute performance à l’EPFL


Exploiter la puissance de calcul du Blue Gene/L : un exercice d’équilibriste




Felix SCHüRMANN


Traduit de l’anglais par Christian Clémençon

Programmer le BG/L (supercalculateur IBM Blue Gene/L) n’est de prime abord pas très différent que de programmer d’autres systèmes parallèles, sauf qu’en cas d’erreur, au lieu de quelques messages, ce sont souvent des milliers qui défilent sur la console, rendant la mise au point des programmes ardue. D’autres problèmes plus subtils sont également à considérer lors du développement d’applications massivement parallèles : en particulier, bénéficier de toute la puissance de calcul du BG/L de l’EPFL requiert une répartition fine et équilibrée des calculs sur les 8’192 processeurs que compte la machine, ce qui constitue généralement un défi majeur. Mais c’est bien entendu aussi le très grand nombre de processeurs qui fait tout l’intérêt de ce supercalculateur. Une application bien adaptée, qui pourrait par exemple résoudre un problème en 10 minutes sur toute la machine, nécessiterait 57 jours sur un seul processeur. Cela fait toute la différence sur le type et l’ampleur des problèmes scientifiques qu’il est désormais envisageable lorsqu’on dispose d’une telle puissance de calcul. Dans le cadre du projet Blue Brain [1], qui a démarré en même temps que l’acquisition par l’EPFL du BG/L en juillet 2005, nous avons développé différentes applications qui tournent sur la machine entière, nous permettant ainsi de construire, simuler et analyser de manière efficace un modèle de 1 mm3 de tissu du cerveau d’un rat.

Caractéristiques du Blue Gene/L

Avant de porter une application sur BG/L, il est essentiel de bien comprendre les spécificités de l’architecture de la machine. Les concepteurs du BG/L ont en effet veillé à ce que la machine soit équilibrée. Nous verrons plus loin ce que recoupe exactement ce terme dans le contexte de machine parallèle. Pour parvenir à réaliser une machine fiable et peu gourmande en énergie, IBM a choisi des processeurs de puissance modeste (de type PowerPC 440 cadencés à 700 MHz) disposant de relativement peu de mémoire vive (256 MB par processeur). Cette approche a permis un packaging simple et homogène d’un très grand nombre de composants dans un volume réduit, tolérant un refroidissement à air peu coûteux. La puissance de calcul du BG/L réside donc essentiellement dans la multitude de processeurs, et non dans leur puissance individuelle. Pour pouvoir bénéficier du parallélisme massif qu’inspire ce très grand nombre de processeurs, il est essentiel de les interconnecter efficacement. BG/L dispose à cet effet de plusieurs réseaux spécialisés : l’un pour les communications de processeur à processeur (dites point à point), un second pour les communications entre plusieurs processeurs (dites collectives), un troisième pour les synchronisations (dites par barrière), et finalement un réseau pour les entrées-sorties. La machine est dite équilibrée, car la vitesse des processeurs, la bande passante de la mémoire et des différents réseaux sont dans des proportions qui conviennent à des applications pouvant s’exécuter sur un très grand nombre de processeurs et devant s’échanger fréquemment beaucoup d’informations. C’est notamment le cas d’applications de simulation dans de nombreux domaines scientifiques.

Parallélisme intrinsèque

Concevoir un logiciel extensible (scalable en anglais) à des milliers de processeurs, c’est avant tout concevoir un logiciel intrinsèquement parallèle. Typiquement, une conception centralisée introduisant un goulot d’étranglement - telle que celle de type maître/esclave, ou celle où un processeur unique est dédié aux entrées-sorties - est à bannir. Le modèle de programmation parallèle supporté par IBM pour le BG/L est basé sur le standard MPI-2 (Message Passing Interface 2). MPI-2 inclut notamment les primitives MPIO pour faciliter les entrées-sorties parallèles collectives, grâce auxquelles par exemple 8’192 processeurs peuvent lire ou écrire dans un même fichier exactement comme un seul processeur le ferait, sans devoir se soucier des problèmes complexes sous-jacents de synchronisation, de gestion des tampons, de routage de messages, etc.

Équilibre de la charge

Une autre difficulté majeure de toute application non trivialement parallèle (dont les processeurs communiquent) est l’équilibre de la charge (load-balance en anglais) entre les différents processeurs. Il est en effet évident que la puissance de calcul est gaspillée, si par exemple 8’191 processeurs se tournent les pouces en attendant le résultat d’un processeur surchargé. De tels déséquilibres de charge se manifestent souvent dans des opérations collectives, car les processeurs les moins chargés parviennent en premier au point de synchronisation et doivent attendre, inactifs, que les processeurs les plus lents y arrivent aussi. Malheureusement, l’équilibre de charge est largement dépendant du type d’application, et peut varier en fonction du nombre de processeurs, de la taille du problème, et même en cours d’exécution (équilibre de charge dynamique).
Dans le cadre du projet Blue Brain, nous avons été confrontés à un défi particulier d’équilibre de charge dans notre simulateur NEURON [2]. Une simulation consiste à reproduire la propagation d’impulsions électriques dans un réseau de 10’000 neurones formant une colonne néocorticale. Le calcul s’effectue par étapes successives dans le temps. À chaque étape, le simulateur calcule le signal électrique qui se forme dans chaque neurone en fonction de sa morphologie (telle qu’elle a été déterminée expérimentalement en laboratoire). Après un certain nombre d’étapes, certains neurones produisent une impulsion électrique qui est propagée aux neurones récepteurs, selon la topologie du réseau neuronal, et ainsi de suite. Il est à noter que, pour propager les impulsions, il s’est avéré plus avantageux d’utiliser une communication collective impliquant tous les processeurs (MPI_allgather), fortement optimisée pour le BG/L, plutôt que des paires de communications point à point n’impliquant que les neurones interconnectés. Le problème d’équilibre de charge vient du fait que (1) il y a plus de neurones que de processeurs, et (2) la complexité des neurones peut varier d’un facteur de cinq en fonction de leur morphologie. En répartissant simplement des neurones entiers sur les processeurs, la simulation est ralentie par les processeurs qui ont hérité des neurones les plus complexes. Ce problème de scalabilité est illustré sur la figure par les carrés noirs, qui montrent clairement que la performance s’infléchit à partir de 2’048 processeurs déjà.


JPEG - 2.6 ko
fig. 1
Temps de simulation en secondes d’une colonne néocorticale de 10,000 neurones en fonction du nombre de processeurs. Les carrés pleins représentent le cas où les processeurs ne traitent que des neurones entiers, alors que les cercles pleins le cas où les neurones sont fractionnés et répartis sur plusieurs processeurs pour équilibrer la charge. Les cercles vides montrent le temps moyen utile de calcul. La ligne traitillée montre la performance théorique idéale par rapport au temps de calcul séquentiel sur un processeur.

Pour remédier à ce problème, nous avons développé un algorithme parallèle de simulation du neurone [3]. À chaque étape de simulation, le calcul du signal électrique dans un neurone s’effectue par une discrétisation spatiale de ce dernier en compartiments, qui décrit la topologie interne du neurone. Une matrice tridiagonale représente cette topologie en arbre. Il faut ensuite résoudre plusieurs systèmes d’équations différentielles pour chaque compartiment et finalement réduire la matrice par une élimination de Gauss. Notre algorithme parallèle peut fractionner la matrice sur plusieurs processeurs et ainsi répartir la résolution des équations différentielles d’un neurone, tout en conservant un schéma de résolution globale implicite nécessaire à la stabilité de la solution. Grâce à cette parallélisation au niveau du neurone, et en connaissant la complexité des neurones impliqués dans une simulation, il est possible de calculer à l’avance une répartition générale de toutes les parties de neurones afin d’obtenir une scalabilité linéaire quasi parfaite, comme illustrée par les cercles noirs sur la figure. Dans ce cas de figure, c’est donc une répartition de charge statique qui s’opère au début de chaque simulation.

Conclusion

Dans le cadre du projet Blue Brain, c’est bel et bien la puissance de calcul du BG/L de d’EPFL qui est déterminante. En moins d’une semaine, nous pouvons régénérer les modèles mathématiques de neurones en utilisant un algorithme génétique massivement parallèle spécialisé [4], calculer un réseau de dix à cent mille neurones constituant un tissu virtuel de cerveau, grâce à une infrastructure massivement parallèle de détection de contacts [5] et finalement, comme nous l’avons décrit ci-dessus, effectuer des dizaines de simulations de colonne néocorticale. De plus, pour analyser la pertinence des résultats obtenus, nous disposons d’une puissante machine SGI Prism Extreme avec 300GB de mémoire partagée et équipée de logiciels de visualisation scientifiques spécialisés.

Quelques conseils et pièges à éviter pour développer sur BG/L

Il est généralement contre-productif de commencer à écrire et paralléliser une application sur BG/L. Un PC à deux coeurs, équipé d’une librairie MPI-2 open-source, fera très bien l’affaire. Porter ensuite le code MPI existant est assez simple, du moins pour un premier jet non optimisé. IBM fournit les compilateurs croisés C, C++ et Fortran ainsi que les librairies système nécessaires pour produire un exécutable, incluant une librairie MPI-2. Il faut toutefois noter que le BG/L ne supporte pas l’édition de liens dynamique. Seules les librairies statiques sont donc admises. De plus, le micro noyau des noeuds n’autorise pas les codes multitâches. Une autre difficulté provient de la taille relativement modeste de la mémoire (512 MB par noeud, ou 256 MB par processeur) qui nécessite parfois un redécoupage délicat du problème. D’autre part, sur les processeurs de type PowerPC, le tas et la pile croissent l’un vers l’autre, ce qui peut provoquer des crashs vicieux en cas de chevauchement involontaire. Pour améliorer les performances, préférez les primitives de communication collectives, très rapides sur BG/L, aux combinaisons maison complexes de Send/Receive. En ce qui concerne les entrées/sorties, évitez de produire une multitude de petits fichiers. Utilisez plutôt les primitives MPI-IO collectives qui sont optimisées pour l’architecture du BG/L et de son système de stockage.
Pour debugger, des printf judicieusement placés peuvent s’avérer indispensables. Un debugger GBD très rudimentaire est aussi disponible. Finalement, IBM fournit un kit d’outils assez complet d’aide à l’optimisation des performances.

[1] Markram, H. (2006). The blue brain project. Nat Rev Neurosci 7(2) : 153-60.

[2] Hines, M. L. & Carnevale, N. T. (1997). The NEURON simulation environment. Neural Computation, 9, 1179-1209.

[3] Hines, M., H. Markram, F. Schürmann (2008). Fully Implicit Parallel Simulation of Single Neurons, Journal of Computational Neuroscience (in press, e-print available ahead of print).

[4] Druckmann, S., Y. Banitt, et al. (2007). A novel multiple objective optimization framework for constraining conductance-based neuron models by experimental data. Frontiers in Neuroscience 1(1) : 7-18.

[5] Kozloski, J., K. Sfyrakis, et al. (2008). Identifying, tabulating, and analyzing contacts between branched neuron morphologies. IBM Journal of Research and Development 52(1/2).



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.