Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/06977.jsonl.gz/19

Editorial
Vittoria REZZONICO
Le HPC (Calcul à Haute Performance) est une discipline vaste, qui englobe des domaines comme l’architecture des processeurs, les modèles de programmation, le calcul scientifique, l’architecture des bâtiments et les sciences environnementales. Si les calculateurs peuvent être utilisés pour appuyer la recherche, il sont aussi utilisés pour simuler les futures générations de puces qui vont aller dans les prochains supercalculateurs et l’impact environnemental de leur exploitation.
Le HPC rapproche les techniciens, les responsables d’infrastructure et les chercheurs : une machine pour être exploitée au mieux, doit être bien gérée ; les administrateurs doivent connaître les besoins des utilisateurs qui, à leur tour, doivent connaître l’architecture de la machine pour pouvoir en tirer le meilleur parti. De plus, les calculateurs ont besoin de courant et de climatisation, et c’est là que les infrastructures entrent en jeu.
Dans cet éditorial, nous allons faire le point de l’état de l’art en HPC pour les architectures et les langages.
FLOPS
Le nombre d’opérations à virgule flottante par seconde est une unité de mesure pour évaluer la vitesse des calculateurs. Le repère le plus commun (et celui utilisé pour rédiger la liste Top500, voir ci-dessous) est le benchmark autrefois Linpack : une bibliothèque de fonctions en Fortran pour l’algèbre linéaire. Le problème que les machines doivent résoudre est plus particulièrement un système linéaire Ax=b dense en double précision (64bits) par une décomposition LU de la matrice des coefficients [A b]. Les données sont distribuées dans une grille PxQ de processus.
Pour donner une idée des ordres de grandeur : un PC dernier cri (Intel Core i7 par exemple) est capable de 70 GFLOPS, et un vieux Pentium à 166MHz (1996) arrive à 25MFLOPS.
MégaFLOPS = 106 FLOPS à 1961
GigaFLOPS = 109 FLOPS 1984
TéraFLOPS = 1012 FLOPS 1997
PétaFLOPS = 1015 FLOPS on est ici
ExaFLOPS = 1018 FLOPS 2020 ?
En suivant la loi de Moore
La loi de Moore sur la performance des calculateurs (voir encadré) s’appuyait jusqu’en 2002 sur le fait que la fréquence des CPU doublait tous les 18 mois. Maintenant, puisque la consommation électrique se comporte comme le carré de la fréquence, pour doubler le nombre de FLOPS il vaut mieux doubler le nombre de processeurs (ce qui double la consommation), plutôt que doubler la fréquence (ce qui quadruplerait la consommation). La loi de Moore dans les machines d’aujourd’hui perdure presque uniquement grâce à l’augmentation des unités de calcul dans une puce.
Loi de Moore
Les lois de Moore (il y en a toute une famille) concernent l’évolution de la puissance des ordinateurs et de la complexité des puces. Ce sont plutôt des conjectures, car leur validité peut ne pas être vérifiée à long terme.
Première loi de Moore (1965) : la complexité des semiconducteurs double tous les ans à prix constant.
Deuxième loi de Moore (1975) : le nombre de transistors des microprocesseurs sur une puce de silicium double tous les deux ans.
Version communément appelée Loi de Moore : la vitesse des processeurs double tous les dix-huit mois.
Dans la figure 1 on voit que la loi de Moore s’est vérifiée jusqu’à aujourd’hui pour la première machine du Top500 ainsi que pour la dernière et la somme des puissances, et que si la loi de Moore continue d’être vérifiée, on atteindra le ExaFLOPS vers 2020.
Le Top500
Le projet Top500 vise à rédiger une liste des 500 plus puissants ordinateurs au monde, la métrique (benchmark) étant le Rmax de Linpack. Cette liste est mise à jour 2 fois par année : aux ISC (International Super Computing) de juin en Allemagne (voir article Impressions de ISC 09 dans ce numéro) et aux SuperComputing en novembre aux Etats-Unis (voir article SuperComputing SC08 de P. Jermini et J.-C. Leballeur, FI 1/2009). Cette liste est reconnue par les usagers, les constructeurs, ainsi que par les médias.
Historiquement, dans le Top500 les machines vectorielles sont apparues en premier, ensuite les machines scalaires (SMP), puis c’était l’ère Beowulf (voir mon article Beowulf-me ! paru dans le FI 8/2007), et maintenant, c’est l’ère des systèmes Green, ou bien, écologiques. Auparavant on avait assisté à la propagation des clusters, et cette tendance ne va pas disparaître bientôt vu leur nombre dans le Top500 : une machine typique du Top500 est un cluster avec InfiniBand qui tourne sous Linux. Cette année, par contre, trois machines différentes occupent les premières positions (voir article Impressions de ISC 09). Est-ce que cela marque le début d’un chaos architectural, ou bien s’agit-il d’une exploration de technologies pour nous mener avec succès à l’ExaFLOPS ? Les performances de ces trois machines sont très proches – ceci montre qu’il y a plusieurs chemins vers la puissance.
Dans la figure 1, on voit que la loi de Moore est encore valable, malgré qu’on ait assisté dernièrement à un changement radical : ce n’est plus l’accroissement de la fréquence d’horloge du CPU mais l’augmentation du nombre des unités de calcul qui permet l’augmentation des performances. Mais considérant les problèmes de réseau et d’accès à la mémoire, jusqu’où peut-on aller ?
- fig. 1
- Évolution de la puissance de calcul des calculateurs dans le Top500, le premier +, le dernier x et la somme de toutes les puissances de calcul *. Les grosses étoiles représentent respectivement le Petaflops en 2009 et le ExaFLOPS en 2019
La course au MachoFLOPS
Un an après le PétaFLOPS on pense bien sûr déjà à l’ExaFLOPS qui, selon la loi de Moore, est prévu autour de l’an 2020. On peut remarquer que la consommation électrique suit aussi une loi de Moore. Si on extrapole cette loi pour 2020, on observe que la machine la plus rapide arrive à une consommation de 20 à 50 MW (ce qui correspond à la consommation énergétique d’une grosse ville). Ceci nous fait réfléchir : arrivera-t-on à l’ExaFLOPS ? Réfléchissons sur comment rendre les puces moins gourmandes en énergie. Déjà, une machine comme RoadRunner (numéro un du Top500) est moins gourmande qu’un cluster généraliste comme Jaguar (numéro deux), ceci grâce à des puces simplifiées. En plus, on peut améliorer le rendement en évitant les fuites d’énergie et en utilisant du refroidissement à eau proche des processeurs (comme dans le projet Aquasar).
On peut déjà imaginer l’architecture que la machine ExaFLOPS exhibera : le jeu d’instructions doit être amélioré, ce qui amènera moins de consommation par core. Le x86 n’arrive pas à l’ExaFLOPS de façon naturelle : la fréquence ne peut plus augmenter et en multipliant les cores dans une puce on va bientôt atteindre une limite imposée par la bande passante mémoire.
En outre, le fait qu’il y ait beaucoup de CPU demande une réflexion sur le MTBF (Mean Time Between Failures) : les pannes vont se produire plus fréquemment, voici un calcul simple :
- supposons qu’une puce tombe en panne tous les 40 ans, et supposons les pannes sans mémoire (c’est-à-dire, le comportement d’une puce ne dépend pas de son passé). Si on a n puces, la probabilité qu’aucune ne défaille un jour donné est de (1-1/40/365)n. Prenons un exemple pratique avec une machine comportant 8192 puces ; alors la probabilité de panne en un jour est de 40% environ. Ce calcul est bien sûr sursimplifié : on ne calcule pas ainsi le MTBF, mais cela donne une idée de l’ordre de grandeur.
- fig. 2
- Speedup versus nombre de processeurs pour différentes portions de code séquentiel selon la loi d’Amdahl. On remarque que même un code avec uniquement 5% de code séquentiel ne se parallélise pas bien au-dessus de 1000 processeurs, le speedup idéal étant égal au nombre de processeurs.
Le problème logiciel
La machine ExaFLOPS aura une dizaine de millions de cores. Ceci requiert d’exploiter tous les niveaux de parallélisme de façon optimale.
- Le massivement parallèle nécessite l’emploi de la bibliothèque MPI, et pour l’instant il n’y a pas de bibliothèque de remplacement établie et utilisée à large échelle : on ne va donc pas se débarrasser de MPI dans un futur proche.
- La programmation multi-thread (que ce soit OpenMP, Pthreads ou Intel TBB) va prendre de l’importance : le nombre de cores partageant la mémoire augmentera, et utiliser MPI n’est parfois pas raisonnable. Il faut par contre porter attention au piège d’Amdahl dans OpenMP : ce langage est utilisé le plus souvent sur du multicore, est-ce que les programmes se paralléliseront bien sur du many-core ? Un code qui se parallélise bien sur 16 cores peut avoir des problèmes à 128. Des problèmes pour l’instant sous-estimés dans ce type de parallélisation sont par exemple :
- La gestion de threads.
- Le fait de paralléliser des morceaux de code (fork-join) nous fait subir les pires conséquences de la loi d’Amdahl (voir encadré) : il faut apprendre à exploiter le parallélisme naturel du problème au lieu de paralléliser simplement le code.
- Le manque de contrôle sur la localisation de la mémoire par rapport au core.
Loi d’Amdahl
La loi d’Amdahl exprime le gain de vitesse d’exécution d’un programme en fonction du nombre de processeurs : étant donné le nombre de processeurs p et la portion de code séquentiel non parallélisable a, on obtient un gain de performance (speedup) S de
S = 1/ (a + (1-a)/p)
La conséquence directe de cette loi est le plafonnement de la vitesse d’exécution d’un code en parallèle. Mais tout n’est pas perdu...
Ces problèmes sont en partie résolus par de nouveaux modèles de programmation parallèle (lire le rapport de conférence 38th SPEEDUP Workshop on High-Performance Computing dans ce numéro). Dans le massivement parallèle, il ne faut pas compter les opérations mais plutôt les communications et les déplacements dans la mémoire : le goulet d’étranglement a été déplacé vers le bus mémoire et le réseau. N’oublions pas qu’un transfert mémoire prend plus de temps qu’une multiplication, et qu’une comparaison du type if (a == b) (jamais prise en compte lors du nombre d’opérations) peut beaucoup ralentir un code.
Loi de Gustafson
Cette loi nous sauve du problème de plafonnement de performance vu dans l’encadré concernant la loi d’Amdahl : elle nous dit que tout problème suffisamment grand peut être parallélisé de façon efficace. Soit p le nombre de processeurs, n la taille du problème et b la partie non parallélisable du code, alors le speedup en fonction du nombre de processeurs est donné par
S(p) = p – b(n) (p -1)
Si lorsque n tend vers l’infini b devient négligeable, alors S(p) tend vers p. Une conséquence pratique de cette loi est qu’avec plus de processeurs, on peut résoudre des problèmes plus grands (ce qui serait impossible avec peu de processeurs).
GPGPU et programmation hybride
Dans cette jungle de nouvelles architectures et langages, comment faut-il s’orienter ? On considère que:br>
- La programmation sur les processeurs hétérogènes de type Cell (machine numéro un du Top500) n’est pas évidente, mais même si le Cell n’était pas là pour rester, la gymnastique mentale nécessaire pour le programmer est un atout dans un HPC qui tend à l’hétérogénéité.
- Nvidia est le premier constructeur à avoir introduit un langage pour programmer les GPU de façon assez directe : CUDA. Comme premier arrivé il mérite du succès mais on a souvent vu que le premier n’est pas nécessairement celui qui va rester : son concurrent OpenCL se donne comme objectif d’être un langage unique pour plusieurs architectures parallèles et est supporté par les trois grands acteurs du GPGPU (ATI, Nvidia et Intel). Encore une fois, la gymnastique mentale pour apprendre CUDA n’est pas une perte de temps. N’oublions pas que pour le moment les cartes graphiques sont très puissantes dans un domaine assez restreint : le calcul matriciel en simple précision. La double précision est déjà partiellement là, mais même si la plupart des problèmes résolus grâce au HPC contiennent une bonne partie de calcul matriciel, ce n’est pas tout.
Donc même si maintenant la situation semble confuse, ces architectures sont là pour rester et évoluer. Les concepts sur lesquels elles se basent ne sont pas juste une mode, et apprendre à les exploiter est un bon investissement.
Et à l’EPFL ?
Dans ce numéro Spécial HPC, vous découvrirez la diversité des thèmes de recherche où l’apport de la simulation numérique est fondamental. Toute institution de recherche se doit d’être équipée d’infrastructures de pointe, avec des architectures complémentaires – sans oublier la nécessité de former à une utilisation efficace de ces ordinateurs. Vous trouverez des rapports de conférences suivies par des membres de la communauté, des descriptions des ressources à disposition des chercheurs, ainsi que des articles écrits par les chercheurs eux-mêmes. Vous aurez ainsi un panorama de ce qui se passe à l’EPFL en HPC depuis plusieurs points de vue.
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é USBLe Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.
Taguage des articlesDepuis 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.