Evolution des processeurs : quoi anticiper pour les codes ?
By , and   |  May 12, 2014

Cet article est une synthèse du Forum ORAP qui s’est tenu en novembre 2013 chez Total à Paris – La Défense. Le thème de ce forum portait sur l’impact de l’évolution des technologies de processeurs sur les codes et l’un de ses objectifs a été d’identifier les bonnes pratiques qui peuvent aider au développement de futur codes dans le domaine du calcul hautes performances.

• François Bodin (IRISA)
• Henri Calandra (Total)
• Alain Refloc’h (ONERA)

Les personnes suivantes ont contribué à cet article :
Jean-Michel Alimi (Observatoire de Paris), Guillaume Colin de Verdière (CEA DAM), François Courteille (NVIDIA), Quang Dinh (Dassault Aviation), Romain Dolbeau (CAPS Entreprise), Yvan Fournier (EDF), Laura Grigori (INRIA Rocquencourt), Thomas Guignon (IFPEN), Michel Kern (INRIA), Yann Meurdesoif (CEA), Raymond Namyst (INRIA Bordeaux), Serge Petiton (Université de Lille 1, Sciences et Technologies), Philippe Ricoux (Total), Philippe Thierry (Intel).

C’est un constat : la stagnation de la fréquence des processeurs conduit naturellement à une augmentation du nombre de cœurs de calcul [1, 2]. Et, conséquence de cette évolution, le parallélisme multicœurs doit dorénavant être pris en compte pour faire évoluer les applications existantes, dites legacy. Il doit même être considéré comme un pilier central de la conception de toute nouvelle application HPC. En outre, alors même que la largeur des instructions vectorielles s’accroît, le débit mémoire, qui alimente les unités de calcul, reste et restera très insuffisant. Nous sommes aujourd’hui bien loin des 24 octets par flop des CRAY 1 d’antan ! La localité des accès aux données, déjà un enjeu majeur à l’époque, devient maintenant critique.

Le tableau 1 liste quelques caractéristiques des supercalculateurs contemporains projetées à des niveaux exaflopiques afin d’illustrer la trajectoire que devront suivre les systèmes HPC d’ici à 2020, date supposée du passage à l’échelle. Cette projection représente certes un scénario d’évolution extrême mais elle a toutefois le mérite de donner un ordre de grandeur du parallélisme que devront exploiter les codes pour rester efficaces sur les dix à vingt prochaines années. Dans quelques cas seulement, l’exécution d’une application requiert la totalité de la puissance du calculateur ; on parle alors de “capability computing“. Toutefois, dans la plupart des cas, l’efficacité de la machine représente sa capacité à réaliser un grand nombre de tâches ; on parle alors de “capacity computing“. Dans tous les cas, c’est le parallélisme massif au niveau du nœud que les codes devront exploiter.

CPU

Intel Xeon Phi

GPU

Fréquence (Ghz)

1 – 3.2

1

0.7 – 1.5

Nombre de cœurs par processeur

8 – 32

61

500 – 900

Nombre de nœuds (milliers)

10 – 100+

1 – 50

1 – 20

Performance crête (Pflops)

20.1 – Sequoia

48 (+6.9) – Tianhe2

24,5 (+2.6) – Titan

Performance Linpack (Pflops)

17.2

33.9

17.6

Facteur pour atteindre l’exaflop (1018)

x58

x29.5

x56.8

Dans la perspective du passage à l’échelle, l’évolution des processeurs impacte de manière profonde les pratiques de développement et de maintenance des codes ainsi que les méthodes numériques [3, 4]. La plupart des codes parallèles sont aujourd’hui mis en œuvre avec MPI, et un processus par cœur CPU a été jusque-là le meilleur compromis. Mais cette pratique n’est plus adaptée à l’exploitation de systèmes à mémoires hiérarchiques, de sorte que mixer OpenMP avec MPI [5, 6], devient maintenant une pratique plus courante.

Dans ce contexte, migrer les codes existants, dits legacy,représente un véritable défi tant ils contiennent généralement des milliers de lignes développées durant des décennies et tant ils combinent différentes couches écrites dans plusieurs langages comme F77, F90, C ou C++. En outre, ces codes ont été conçus pour une exécution séquentielle avec un seul objectif en tête : réduire le nombre d’opérations.

Dans une vielle bâtisse, quand on remplace un carreau de carrelage, c’est quelquefois l’ensemble du mur qui vient avec. Cette métaphore illustre de nombreuses situations où la modularité du code souffre d’ajouts successifs de nouvelles fonctionnalités. La validation de ces codes peut par ailleurs être complexe et ralentir d’autant les profondes modifications nécessaires à une mise en œuvre parallèle efficace. La migration de code est un typiquement projet complexe, qui implique des expertises orthogonales, notamment en ingénierie logicielle. Par ailleurs, l’absence de visibilité sur les standards de programmation et sur l’architecture des processeurs n’incite pas à opérer ces mutations. Bill Harrod, de l’US Department of Energy, a très bien résumé ce contexte lors de sa présentation au forum Big Data and Extreme-scale Computing (BDEC) [7] : “Le monde a changé. Les technologies changent à une vitesse dramatique. Le marché IT évolue lui aussi de manière fulgurante avec des ventes de PC en berne et une croissance dominée par les appareils mobiles. Dans le domaine HPC, d’importantes incertitudes planent tandis que le volume et la variété des données explosent, ce qui constitue une menace pour le futur du calcul…”

Il est tout aussi important de noter que ce sont l’écosystème et la distribution qui motivent principalement la modification des applications. Il est en effet toujours plus facile de justifier des changements par des besoins utilisateurs plutôt que par des contraintes liées à l’évolution des technologies. Pourtant, ce manque d’anticipation pourrait bien sonner le glas à de nombreux codes.

Nous considérons ici le code des applications comme étant une des composantes d’une infrastructure globale de calcul qui comprend les entrées / sorties, le système de visualisation, les récepteurs, etc. L’objet de cet article est de lister, de façon collective, les conséquences de l’évolution des technologies de calcul sur le développement des applications scientifiques. Cette synthèse se veut volontairement courte, et n’a pas pour ambition de pointer vers les bonnes stratégies de développement. Elle est organisée en trois parties : la première indique les problématiques à prendre en compte pour le développement de codes parallèles ; la deuxième se focalise sur les aspects algorithmiques et numériques ; la dernière dresse un panorama des meilleures pratiques actuelles.

[Références]

[1] S. H. Fuller and L. I. Millett. Computing performance: Game over or next level? Computer, 44(1):31–38, 2011.

[2] D. D. Journal. The free lunch is over: A fundamental turn toward concurrency in software. 2009.

[3] G. M. Amdahl. Validity of the single processor approach to achieving large scale computing capabilities. In Proceedings of the April 18-20, 1967, Spring Joint Computer Conference, AFIPS ’67 (Spring), pp 483–485, New York, NY, USA, 1967. ACM.

[4] J. L. Gustafson. Reevaluating Amdahl’s law. Commun. ACM, 31(5):532–533, May 1988.

[5] Pierre-Francois.Lavallée. Programmation hybride mpi-openmp.

[6] J. Zollweg. Hybrid programming with openmp and mpi.

[7] B. Harrod. Big data and scientific discovery, presentation at bdec fukuoka, japan. 2014.

Navigation

<123>

© HPC Today 2024 - All rights reserved.

Thank you for reading HPC Today.

Express poll

Do you use multi-screen
visualization technologies?

Industry news

Brands / Products index