FLASH INFORMATIQUE FI



Parallélisme extrême sur le Blue Gene/L




LÄTT Jonas


Introduction

Depuis l’introduction du circuit intégré dans les années 1950, le marché de l’informatique suit une tendance caractérisée par l’augmentation exponentielle de la puissance de calcul au fil des années. Souvent citée sous le nom de loi de Moore d’après une constatation du cofondateur d’Intel Gordon E. Moore sur l’évolution de la microtechnique, cette tendance s’applique à des aspects variés de l’informatique tels que la vitesse d’exécution des processeurs ou encore la quantité de mémoire disponible dans les ordinateurs. La loi de Moore fait le bonheur des chercheurs dans le domaine du calcul numérique, car elle leur permet de fréquemment augmenter la rapidité de leurs simulations et la taille des problèmes simulés, permettant ainsi de nouvelles percées scientifiques. Depuis plusieurs années, ce bel optimisme dans le domaine du calcul numérique se trouve cependant freiné. Alors que la loi de Moore reste valable, elle ne s’exprime plus en termes d’augmentation de la performance brute des processeurs mais plutôt en termes d’augmentation du nombre d’unités de calcul dans des processeurs multi-coeurs. Cette nouvelle tendance entraîne deux changements importants pour le calcul scientifique. En premier lieu, le développement de programmes parallèles est devenu un besoin de base et non plus un luxe destiné à pousser les performances aux limites du réalisable. Par exemple, la plupart des ordinateurs de bureau modernes possèdent des processeurs à deux ou quatre coeurs. Même pour l’exécution d’une simulation modeste sur un ordinateur personnel, un programme parallélisable est requis, sous peine de renoncer à la moitié voire aux trois quarts de la performance offerte par le processeur.
Une deuxième conséquence est l’augmentation massive du nombre de coeurs disponibles dans des ordinateurs parallèles destinés au calcul scientifique. Alors que récemment encore, beaucoup de groupes de recherche effectuaient leurs calculs sur des grappes d’ordinateurs avec une centaine de processeurs environ, des machines consistantes de plusieurs milliers de coeurs sont en train de devenir monnaie courante. Ce phénomène est parfois désigné sous le nom de extreme-scale parallelism, qu’on traduirait par parallélisme extrême en français. Comme d’autres mots-clés à la mode, ce terme ne possède pas de signification précise, mais reflète plutôt un changement qualitatif ressenti dans la communauté, avec un impact sur la culture de programmation pour l’implantation de modèles numériques. Dans le cas du parallélisme extrême, ce changement s’est manifesté en premier lieu en tant que difficulté rencontrée dans plusieurs secteurs du calcul numérique : des programmes parallèles qui originalement étaient développés pour des grappes d’une petite dizaine de noeuds, qui ensuite ont pu être adaptés sans trop de difficultés aux machines à une ou même plusieurs centaines de noeuds, soudainement se trouvent impuissants face à la nouvelle génération de machines parallèles et refusent une mise à l’échelle d’un nouvel ordre de grandeur par rapport au nombre de noeuds.
Afin d’illustrer les enjeux rencontrés lors de la parallélisation sur des milliers de noeuds, et dans l’espoir de faciliter à d’autres programmeurs le passage à la nouvelle génération de machines parallèles, cet article raconte l’histoire du logiciel SPECULOOS [1]. Ce logiciel, dont l’acronyme signifie SPECtral Unstructured eLements Object-Oriented System, permet des simulations en dynamique des fluides à l’aide d’une méthode numérique dite d’éléments spectraux. Développé au début des années 1990 dans le laboratoire d’ingénierie numérique (LIN) de l’EPFL, le code de SPECULOOS s’est patiemment adapté à l’évolution du matériel informatique pour finalement refuser ses services sur des plates-formes à plusieurs milliers de coeurs. À plusieurs reprises, le code a dû être disséqué et analysé jusqu’à ce que son profil de performance soit établi et que des modifications appropriées puissent être amenées. Cet effort a été gratifiant, puisque SPECULOOS est maintenant capable d’exploiter la pleine puissance de la machine parallèle Blue Gene/L, qui fait la fierté de l’EPFL avec ses 8192 coeurs, répartis sur 4096 noeuds bi-coeurs.
Nous montrons comment cette adaptation a été possible, et de quelle manière cette percée affecte la qualité de la recherche menée. En outre, le Blue Gene/L est mis en perspective avec d’autres plates-formes de calcul à haute performance plus économiques, et l’impact du choix de la machine sur la dynamique du travail scientifique dans un groupe est mis en évidence.

Évaluation de l’enjeu et du gain d’une parallélisation

Avant de pouvoir paralléliser un code, il est important de comprendre de quelle manière se répartissent ses besoins en termes de ressources de calcul. Une telle évaluation se fait par un bilan qu’on appelle le profil de complexité, qui permet entre autres d’estimer le gain de performance que peut amener une parallélisation, et de juger de la qualité de la parallélisation lors des exécutions expérimentales du code obtenu.
En dynamique des fluides, on cherche à calculer ou simuler l’évolution de certaines variables représentant l’état du fluide, telle que la vitesse instantanée de l’écoulement en chaque point du fluide. Dans la méthode d’éléments spectraux, le domaine occupé par le fluide est découpé en sous-domaines appelés les éléments. A l’intérieur de chaque élément, les variables du fluide sont considérées comme des fonctions dépendantes de la position spatiale, et ces fonctions sont représentées de manière approchée par des polynômes. On appellera N le degré de ces polynômes, et on dira qu’un domaine spatial tri-dimensionnel est subdivisé en E*E*E=E3 éléments. Dans la stratégie de parallélisation adoptée par SPECULOOS, on distribue les éléments sur la machine parallèle en en attribuant un ou plusieurs à chaque coeur. Le programme décompose ensuite son évolution temporelle en cycles successifs, durant lesquels chaque coeur effectue d’abord des calculs sur les éléments qui lui sont attribués, puis les coeurs se transmettent des valeurs calculées situées sur la surface de leurs éléments. Cette manière de paralléliser un code est élégante et efficace, et ne possède essentiellement que trois facteurs limitatifs pouvant affecter la performance. En premier lieu, la parallélisation nécessite une communication entre processeurs qui est effectuée en plus du calcul proprement dit, et qui peut devenir coûteuse. La parallélisation n’en vaut donc la peine que si le temps de communication est fortement inférieur au temps de calcul requis par chaque élément. En deuxième lieu, la performance peut être affectée par un déséquilibre des charges entre coeurs. Si un coeur se voit attribuer moins d’éléments que les autres, ou si le calcul sur certains éléments s’avère moins onéreux que sur d’autres, le coeur peut gaspiller une partie de son temps à attendre la communication provenant de ses partenaires. Le dernier facteur potentiellement limitant est représenté par des petites composantes non parallélisables du code qui sont exécutées par chaque coeur en plus du travail sur les éléments, et qui ne profitent donc pas de la parallélisation. Il s’agit là d’un aspect de la parallélisation sur lequel nous insistons particulièrement dans cet article, et qui sera repris en détail dans un chapitre ultérieur.
Pour améliorer la précision du calcul numérique, on peut choisir, soit d’améliorer la résolution spatiale du domaine simulé en augmentant le paramètre E et donc le nombre d’éléments, soit d’améliorer la précision du modèle en augmentant le degré polynomial N. Il est en effet connu que l’erreur de l’approximation numérique est proportionnelle à la valeur 1/E (N+1) dans tout problème dont la solution est suffisamment régulière. En vue d’une parallélisation efficace, il est souvent considéré comme plus favorable d’augmenter le paramètre N, avec l’effet d’augmenter fortement la charge de calcul de chaque élément en n’augmentant que légèrement le volume de données à communiquer entre coeurs. Ainsi, le coût relatif de la communication se trouve diminué. D’un autre côté, une augmentation du nombre d’éléments est favorable à l’équilibrage des charges entre coeurs, car elle entraîne une flexibilité accrue dans le choix de l’attribution d’éléments aux coeurs. Cet argument est particulièrement pertinent lors d’une parallélisation à un niveau extrême, puisqu’il n’est pas rare de se retrouver avec un nombre d’éléments inférieur à celui de coeurs, et donc d’atteindre une limite naturelle à la possibilité de paralléliser le code. C’est pourquoi nous considérons surtout des situations dans lesquelles le degré polynomial est choisi préalablement comme un paramètre constant, et le nombre d’éléments est ajusté en fonction de la précision de calcul souhaitée ou de la taille de la machine parallèle utilisée.
Revenons-en donc au code SPECULOOS et à une estimation (simplifiée) de sa complexité. Un cycle temporel consiste en un processus itératif, durant lequel une opération spécifique est appliquée à chacun des E3 éléments durant chaque itération, contribuant ainsi à la complexité du code d’un facteur E3 par pas d’itération. Le coût de l’opération en question varie quant à lui en fonction du degré polynomial par une loi de puissance à exposant 4, ce qui rajoute un facteur N4 à l’estimation de complexité. Finalement, il est connu que le processus itératif converge en un nombre d’itérations augmentant linéairement avec le paramètre E, et de même avec le paramètre N. Le temps de calcul T d’un cycle temporel est donc estimé comme étant
T = λ E4 N5    [Equation 1]
lors d’une exécution séquentielle (c’est-à-dire non parallèle). Le paramètre λ dépendant du matériel informatique utilisé et de différents choix dans l’implantation du code, mais pas de E ni de N.
Dans ce qui suit, nous étudions les enjeux inhérents à la parallélisation d’un problème à taille constante. Nous choisissons donc le nombre d’éléments et le degré polynomial, E et N, comme paramètres constants, et mesurons le temps de calcul nécessité lors d’une exécution sur un nombre variable de processeurs p. Une telle mesure ne reflète pas toujours le gain de la parallélisation perçu en pratique, car il est commun dans le quotidien scientifique d’augmenter la taille du domaine de calcul lors de l’augmentation du nombre de coeurs d’une machine parallèle. D’un autre côté, les processeurs modernes, constitués d’un grand nombre de coeurs, encouragent de plus en plus les chercheurs à opter pour un parallélisme massif autant pour de grands que pour de petits problèmes. Nous choisissons donc cette vision plus exigeante du parallélisme (il est plus difficile de paralléliser un petit qu’un grand problème) afin que les conclusions soient généralement valables. Le temps de calcul est alors estimé comme étant
T = 1/p λ E4 N5 + T(séquentiel) + T(communication).    [Equation 2]
Par cette formule, on suppose que l’équilibrage de charge entre les coeurs est parfait, et on tient compte de la partie de code non parallélisable par le paramètre T(séquentiel) ainsi que du temps de communication entre les coeurs, T(communication).

Exemple d’application

Afin d’illustrer les concepts exposés dans le chapitre précédent, nous introduisons un problème bien connu en dynamique des fluides décrivant un écoulement dans une cavité cubique, entraîné par un mouvement constant sur la face supérieure de la boîte, ainsi qu’il est illustré par la figure 1.

JPEG - 10 ko
figure 1
Représentation bidimensionnelle de l’écoulement dans une cavité entraînée

Ce problème, qui a été étudié durant de longues années et par différentes approches dans le laboratoire d’ingénierie numérique, met en évidence un comportement riche et intriguant, en dépit de sa simplicité apparente. Déjà lorsque la vitesse d’entraînement du fluide est faible, on observe, en plus de deux grands tourbillons centraux dans la cavité, une séquence infinie de tourbillons dans les coins de la cavité, avec une structure passablement complexe. À des vitesses plus élevées, le fluide entre dans ce que l’on appelle un régime turbulent, dans lequel la structure de l’écoulement est chaotique dans l’espace et dans le temps. Il devient alors impossible, même d’un point de vue théorique, de trouver une solution exacte aux équations des fluides, et on se borne à décrire le résultat par l’intermédiaire de propriétés statistiques. Au vu des difficultés de cette entreprise, cette tâche est à ce jour encore un sujet de recherche active. Les résultats obtenus ont des répercussions non seulement sur la théorie des fluides turbulents, mais aussi dans des domaines d’ingénierie, car ils mènent à une meilleure compréhension générale des écoulements de fluides dans des espaces confinés.
Les différents régimes d’un écoulement sont décrits par un paramètre du nom de nombre de Reynolds, désigné par l’acronyme Re, qui dépend de la vitesse d’entraînement du fluide, ainsi que de sa viscosité et de la taille de la cavité. Dans un régime turbulent, caractérisé par un nombre de Reynolds élevé, la simulation des fluides est rendue difficile par l’apparition de tourbillons de différentes tailles, allant de la taille de la cavité entière jusqu’à de très petites échelles. Indépendamment de leur taille, ces tourbillons ont un impact décisif sur le comportement du fluide et doivent donc tous être entièrement simulés. Pour ne pas faciliter les choses, la taille ε des plus petits tourbillons diminue à une vitesse polynomiale lorsque le nombre de Reynolds augmente, selon la loi suivante : ε  Re -(3/4). La seule manière de suivre cette évolution dans une simulation, lorsque le degré polynomial N est choisi comme un paramètre constant, consiste à adapter le paramètre E de manière équivalente : E Re (3/4). Le nombre total d’éléments croît donc à une vitesse effrayante, proportionnelle à E3  Re(9/4). En plus du nombre d’éléments, la durée de la simulation croît fortement à cause de l’occurrence d’événements rares ne pouvant être observés que dans des simulations suffisamment longues. Face à ces difficultés, il est courant dans les domaines d’ingénierie de recourir à des modèles de la turbulence dans lesquels on ne simule que les grands tourbillons, et remplace la physique des petits tourbillons par des lois simplifiées. Une telle approche n’est par contre pas admissible en sciences fondamentales, lorsqu’il s’agit d’obtenir des informations aussi précises que possible sur la physique des fluides.
Dans l’ère de l’avant Blue Gene, le nombre de Reynolds pouvant être atteint dans les simulations s’élevait aux environs de Re = 10’000, ce qui correspond par exemple au régime d’écoulement de l’air autour d’un piéton marchant à une vitesse modeste. D’autre part, le nombre de Reynolds correspondant à beaucoup de situations d’intérêt industriel, tel que l’écoulement de l’air autour d’une voiture en mouvement, s’élève à des valeurs d’un million ou plus. Alors que ces valeurs restent inatteignables sans le recours à des modèles de la turbulence, une machine telle que le Blue Gene/L permet néanmoins de s’y approcher de manière significative en atteignant des valeurs aussi élevées que Re = 100’000. Il s’agit là d’un régime exhibant des phénomènes physiques fondamentalement différents à ceux des nombres de Reynolds inférieurs, permettant une compréhension de nouveaux aspects de la turbulence.

JPEG - 9.4 ko
figure 2
Performance d’exécution du logiciel SPECULOOS sur le Blue Gene/L

La figure 2 met en évidence la performance du logiciel SPECULOOS lors d’une simulation de la cavité entraînée sur le Blue Gene/L. Cette étude de performance est régie par une vision forte du parallélisme, gardant le nombre d’éléments constant d’une exécution du programme à l’autre. Le nombre d’éléments est choisi de manière à n’attribuer qu’un seul élément à chaque coeur lors de l’utilisation des 8192 coeurs de la machine. Il s’agit là d’un test extrêmement exigeant pour un programme parallèle, permettant de mettre en évidence un éventuel défaut dans la stratégie de parallélisation. Le nombre de coeurs varie d’une valeur de 1024 à une valeur de 8192. La courbe affiche une mesure de la performance du programme, donnée par l’inverse du temps d’exécution, et renormalisée par le temps d’exécution sur 1024 coeurs. L’équation 2 permet d’interpréter cette courbe de la manière suivante. Si les composantes rédhibitoires à la parallélisation, T(séquentiel) et T(communication), sont nulles, la valeur de performance est égale au nombre de coeurs p divisé par 1024, tel qu’il est indiqué par la courbe pointillée sur le graphique. Pour des raisons développées dans le chapitre suivant, les anciennes versions de SPECULOOS possédaient des composantes non parallélisables difficiles à identifier, menant à un très grand écart entre les courbes de parallélisation mesurées et la valeur idéale représentée par la courbe pointillée. Une fois ces composantes éliminées, on voit sur la figure 2 que l’écart en question s’est réduit à une valeur d’environ 20%. Des mesures ont montré que cet écart incombe entièrement aux temps de communication, réfléchissant une perte incontournable et inhérente au processus de parallélisation. À ce stade, le logiciel SPECULOOS exploite donc de façon souhaitable les ressources offertes par la machine Blue Gene/L./p>

Parallélisme extrême la règle du zéro-séquentiel

Trois étapes sont usuellement parcourues pour améliorer la performance parallèle d’un programme. La première consiste à établir le profil de complexité et une estimation théorique du gain de la parallélisation, et la deuxième à déterminer expérimentalement les éventuels fautifs d’une mauvaise performance, en choisissant parmi le déséquilibre des charges, le temps de communication et les composantes séquentielles du programme. Durant la troisième étape, on étudie finalement si les problèmes détectés peuvent être corrigés dans le laps de temps à disposition pour le projet.
Il s’est avéré dans le cas de SPECULOOS que la partie la plus difficile de ce procédé consiste à en respecter la rigueur et à éviter les conclusions hâtives. En effet, la plupart de l’analyse du code s’est effectué sous l’avis à priori que la composante séquentielle du code devait être nulle. La décomposition spatiale du problème et l’attribution aux coeurs étant simples, autant en théorie que dans l’implantation du code, il semblait inconcevable qu’une partie du programme soit exécutée de manière séquentielle. Générant une confusion nourrie en plus par une analyse de complexité incomplète, cet avis hâtif a longuement empêché de tirer la conclusion évidente : le code possédait bel et bien une composante séquentielle, invisible sur dix coeurs, presque invisible sur cent coeurs, mais réduisant à néant les efforts de parallélisation dès que l’on utilisait plusieurs milliers de coeurs.
La partie du code en cause se manifestait lors de la détermination des éléments attribués à chaque coeur. Cette partie est courte, mais non parallélisable, puisqu’elle consiste à effectuer un nombre d’opérations logiques proportionnel au nombre total de coeurs. En outre, cette partie était ré exécuté à chaque cycle temporel, alors qu’il aurait suffi de ne l’exécuter qu’une seule fois et d’en sauvegarder le résultat. Afin de discuter de l’impact de cette composante séquentielle sur la performance du programme, admettons que l’attribution des éléments aux coeurs prenne un millième du temps d’exécution d’un cycle temporel du programme. L’auteur original de la parallélisation de SPECULOOS a donc renoncé au calcul unique et préalable de cette opération en appliquant correctement un des principes fondamentaux du génie logiciel, selon lequel uniquement les parties coûteuses en temps d’exécution sont rendues efficaces, alors que les autres parties sont gardées aussi simples que possible. Cette décision s’avère par contre fâcheuse dans le contexte du parallélisme extrême. Alors que la charge de calcul de chaque coeur est divisée par le nombre de coeurs pour les composantes parallélisables, elle reste constante pour les composantes séquentielles. Sur mille coeurs, la charge relative de notre opération non parallélisée est donc démultipliée d’un facteur mille, et cette contribution originalement négligeable finit par prendre la moitié du temps d’exécution du programme.
La leçon tirée de cette expérience se formule sous forme de la règle du zéro-séquentiel, demandant que le temps séquentiel investi dans un programme parallélisé doive être entièrement nul. Il ne suffit pas de le réduire à une taille considérée comme négligeable sur les ordinateurs contemporains, car leur importance relative croît dans le temps avec le nombre de coeurs des machines parallèles. Quoique simple à comprendre, cette règle n’est pas simple à utiliser, car elle va à l’encontre de l’intuition du programmeur qui se base sur la séparation entre parties importantes et négligeables d’un code. Une manière élégante de la mettre en oeuvre tout en évitant des omissions consiste à adopter une vision locale du parallélisme dans laquelle chaque coeur n’a conscience que des partenaires avec lesquels il entre en contact. Pour garantir le succès de cette stratégie, on omettra simplement de fournir aux coeurs toute information globale, telle que le nombre de coeurs présents dans la machine parallèle. Si l’algorithme marche sans cette information, il y a de fortes chances qu’il survive sans trop de difficultés au transfert sur les futures générations de machines parallèles.

L’avenir du calcul scientifique : plate-forme généraliste ou matériel dédié ?

Les noeuds du Blue Gene/L sont constitués de processeurs généralistes, ou autrement dit, de machines à tout faire. Du point de vue de leur architecture, ces processeurs sont similaires à ceux que l’on trouve par exemple dans un ordinateur de bureautique. Aux processeurs généralistes s’opposent les unités de calcul dédiées à une tâche particulière. On peut mentionner comme exemple les cartes graphiques destinées au calcul du rendu d’objets géométriques à l’écran. Il peut sembler comme un gâchis d’utiliser du matériel généraliste dans un but aussi spécifique que le calcul scientifique. Cependant, une telle utilisation est devenue très commune grâce à l’évolution impressionnante de la performance des processeurs et au coût modeste du matériel, rendu possible par leur vente en grand nombre dans le domaine de la bureautique et de l’utilisation domestique. Depuis que la performance brute des processeurs a cessé son augmentation rapide, les processeurs dédiés sont cependant réapparus sur le marché comme concurrents sérieux. L’article de Francis Lapique, Les GPU ne sont pas uniquement faits pour les consoles de jeux montre par exemple que les cartes graphiques peuvent être utilisées pour certains types de calcul scientifique et permettent de gagner un facteur 10 ou même 100 en termes de coût financier et de consommation d’énergie, comparé aux processeurs généralistes. Une autre plate-forme de calcul dédiée dont les performances s’approchent de celles des cartes graphiques est proposée par IBM sous la forme du processeur Cell, le processeur utilisé à l’intérieur de la console de jeux PlayStation 3.
L’incroyable performance des cartes graphiques, du Cell et d’autres solutions de calcul dédiées a mené à une véritable ruée vers l’or dans le domaine du calcul scientifique, dont l’ampleur initiale s’est néanmoins estompée face aux difficultés rencontrées à la programmation d’un tel matériel. Étant donné l’actualité de ce sujet, nous allons donc exposer ici les arguments qui ont été soulevés, lors du développement de SPECULOOS, en faveur et en défaveur des plates-formes dédiées, et qui ont finalement mené à la décision de préserver ce logiciel sous une forme généraliste.
Les deux principales difficultés qui se posent lors de la programmation sur du matériel dédié sont le besoin d’adresser des questions techniques de bas niveau ainsi que le manque de portabilité d’une plate-forme à l’autre. Alors que les machines généralistes proposent des couches d’abstraction permettant de programmer avec une certaine facilité et garantissant une vision unifiée de la machine d’un producteur de matériel à un autre, le matériel dédié demande une compréhension des particularités techniques du matériel, ce qui rend impossible le transfert vers le matériel d’un autre producteur. Un bon exemple est fourni par les mécanismes de transfert des données entre la mémoire principale d’une machine et le processeur. Alors qu’une machine généraliste gère automatiquement ce transfert en se basant sur des techniques de mémoire cache, la plupart des machines dédiées demandent au programmeur d’intervenir manuellement dans ce processus. Cette gestion explicite de la mémoire peut mener à des gains de performance très importants, mais elle détourne le programmeur de son but initial, le calcul scientifique, dans un domaine hautement technique.
À première vue, autant les cartes graphiques que les processeurs Cell offrent une structure assez semblable à celle du Blue Gene/L, consistant d’une multitude d’unités de calcul petites, mais efficaces. Il semble donc naturel de retenter l’astuce de la parallélisation en décomposition spatiale, par l’attribution d’un certain nombre d’éléments à chaque unité de calcul. L’impossibilité d’une telle entreprise se manifeste très vite à travers le fait que SPECULOOS peut n’être ni compilé ni exécuté, ni sur une unité de calcul du Cell, ni sur une carte graphique. Les cartes graphiques ne peuvent être programmées qu’à travers un langage de programmation dédié à la machine, comme le langage CUDA pour les cartes graphiques de NVIDIA. On serait donc obligé d’entièrement reprogrammer le programme, ce qui est peu encourageant pour une application comme SPECULOOS qui a pris quinze ans à être écrite. Sur le Cell, la difficulté est encore plus monumentale. Afin d’exploiter le potentiel de cette machine, une partie importante du travail doit être transférée à des unités de calcul du processeur qui portent le nom de SPE (Synergistic Processing Element). Ces SPE se caractérisent par leur très grande vitesse de calcul, mais aussi par la très petite taille de leur mémoire. Bien qu’il soit imaginable de transférer la mémoire de travail associée à un élément spectral sur l’un de ces SPE, il n’est pas possible de transférer le code de SPECULOOS dans son intégralité sur un SPE, car le code lui-même dépasse largement la taille de la mémoire disponible ! Il est par conséquent impossible, ou en tout cas très difficile, de faire exécuter par un SPE l’intégralité des opérations requises pour un élément spectral.
L’utilisation de matériel dédié impose donc une approche hybride dans laquelle quelques parties du code uniquement, jugées cruciales, sont confiées à un SPE du Cell, ou encore à une carte graphique. SPECULOOS par exemple invoque beaucoup de fonctions d’algèbre linéaire de base, qui sont implantées dans des librairies comme BLAS et LAPACK. On pourrait donc espérer un gain de performance en se référant à des versions de ces librairies qui s’exécutent sur des plates-formes dédiées. De nombreuses difficultés doivent par contre être surmontées avant que cette fin soit atteinte, telles que la limitation de mémoire sur un SPE du Cell, la limitation de bande passante connectant une carte graphique à la mémoire centrale, le non-respect des règles de standard pour l’exécution de calculs en virgule flottante pour le Cell et la carte graphique, le manque de précision des calculs en virgule flottante pour les cartes graphiques, et bien d’autres. Le travail de programmation à effectuer doit être considéré comme particulièrement coûteux, car il ne peut être effectué que par une personne ou une équipe de personnes hautement qualifiée dans le domaine d’application du logiciel considéré, dans les domaines de l’analyse numérique, du génie logiciel et de la programmation proche de la machine.
Cette discussion montre que le choix entre une plate-forme généraliste et un matériel dédié revient finalement à une question de répartition des coûts. Alors que dans le premier cas de fortes sommes d’argent sont investies dans l’achat de matériel, c’est le travail de personnel qualifié qui s’avère particulièrement coûteux dans le second cas. En outre, au-delà des considérations de prix, le choix de la plate-forme de programmation aura un impact sur le type et sur la qualité de recherche menés, puisqu’une plate-forme généraliste libère le programmeur de beaucoup de tâches techniques et accorde plus de temps au sujet scientifique en question. Le travail avec ces différentes plates-formes de calcul à haute performance nous a donc fait clairement pencher en faveur du Blue Gene/L pour le code SPECULOOS. De manière générale, le Blue Gene/L et des machines semblables s’avèrent être des outils de travail indispensables pour maintenir le rythme imposé par la recherche de pointe dans un institut tel que l’EPFL.

Remerciements

La version massivement parallèle du code SPECULOOS est le résultat d’un travail pluridisciplinaire de la part de nombreux intervenants. Nous mentionnerons en particulier le soutien théorique et les connaissances détaillées du code SPECULOOS offerts par Michel Deville et Roland Bouffanais, ainsi que le travail d’analyse de code, d’étude et de mesure de performance fourni par Ralf Gruber, Sohrab Kehtari, Vincent Keller et Christoph Bosshard. En outre, l’exploitation efficace du BlueGene/L n’a été possible que grâce à un soutien intensif de la part de l’équipe HPC du Domaine IT, et en particulier grâce aux conseils avisés de Christian Clémençon.

[1] Le logiciel libre OpenSPECULOOS : www.sourceforge.net/projects/openspeculoos/



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.