I – Les défis au développement de codes parallèles

Développer un code HPC consiste à tirer le meilleur parti de la performance crête des machines. Le tableau 2 montre, pour différents calculateurs, le ratio d’efficacité pour l’exécution de Linpack [8], cas, on le sait, éminemment favorable au parallélisme. On peut observer que les performances obtenues varient très largement d’une machine à l’autre. Elles sont le résultat de compromis entre architecture matérielle et investissements logiciels. On peut également remarquer que les architectures hybrides à base de CPU et de GPU ont une efficacité moindre. Par conséquent, migrer vers un nouveau système requiert une approche plus intégrée afin d’obtenir une efficacité élevée.

En pratique, si on veut réussir à produire un code efficace sur plusieurs générations de machines, de nombreux paramètres sont à prendre en compte. La durée de vie d’un système est de l’ordre de cinq années tandis que celle des codes peut s’étaler sur plus de vingt ans. Les applications doivent donc survivre à quatre voire cinq générations de matériels, avec toutes les différences qu’ils comportent, en particulier dans les domaines du système d’exploitation, du compilateur et de l’environnement de programmation. En réalité, cette estimation peut s’avérer plus faible si l’on considère que les applications sont souvent récupérées par des équipes autres que celles qui les ont développées. C’est pourquoi seuls des modèles standards, qu’il s’agisse de programmation, de développement ou de structuration des codes, peuvent assurer cette pérennité. Choisir un standard peut toutefois s’avérer difficile et avoir des conséquences considérables. L’histoire montre que les passages successifs d’une technologie parallèle à une autre, comme celles du Fortran vectoriel au Fortran / OpenMP, puis au Fortran / MPI, par exemple, ne se sont pas faits sans difficultés. La raison de ces difficultés tient en grande partie à la complexité de mise en œuvre de ces technologies dans les algorithmes et les méthodes numériques. Par ailleurs, il faut réaliser que la production d’une ligne de code coûte entre 10 et 100 euros selon la complexité de l’algorithme et la méthode d’évaluation du coût lui-même [9, 10].

A ce titre, Jack Wells, d’ORNL, indiquait lors de la précédente édition du forum ORAP [11], qu’une à deux année-hommes étaient nécessaires pour porter chacun des codes de la machine Jaguar (2.3 Pflops en 2010) à la machine Titan (27 Pflops en 2012). Il estime que 70 % à 80 % du temps de portage a été dévolu à la restructuration du code, indépendamment du modèle (OpenMP, CUDA, OpenCL ou OpenACC). Chaque équipe dédiée à une application a dû ensuite choisir un modèle parmi les différents paradigmes précédents ce qui, selon le cas, a pu conduire à des résultats différents en fonction du code concerné.

On le sait, la programmation homogène arrive en fin de vie. Les systèmes aujourd’hui combinent différents niveaux de parallélisme pour offrir des performances élevées : instructions vectorielles, parallélisme entre cœurs de processeur, simultaneous multithreading (SMT) et accélérateurs. Les codes doivent donc être adaptés à chacun de ces niveaux. Ce problème dépasse le simple niveau de la programmation ; il concerne également l’algorithmie numérique. Il faut en effet pourvoir exprimer les différents niveaux de parallélisme au sein de l’algorithme lui-même : macro pour MPI, méso pour le parallélisme entre threads et micro pour le parallélisme vectoriel. De plus, ne pas exploiter le niveau vectoriel, typiquement avec des instructions vectorielles comme AVX par exemple, peut limiter la performance de 50 % à 85 % selon les systèmes. Ces chiffres ne sont pas près de décroître avec les prochains processeurs dont les instructions vectorielles seront de plus en plus importantes en taille. L’hétérogénéité des architectures sous-entend également l’utilisation de bibliothèques numériques qui, en fonction des processeurs pour lesquels elles ont été optimisées, n’est pas aussi immédiate. C’est le cas par exemple de CUBLAS [12] par rapport à MKL [13]. Des techniques sophistiquées de runtime [14] peuvent aussi s’avérer nécessaires afin de pouvoir optimiser la configuration matérielle car, pour respecter des contraintes énergétiques, les applications doivent pouvoir s’adapter en temps réel à la charge de la machine, et cela en fonction de l’allocation des données et des ressources. La standardisation des API liées au runtime reste donc un enjeu majeur.

Mais ce qui est au cœur de la conception ou de la migration des codes est sans conteste l’organisation des structures de données. Elle doit en effet, dans une approche holistique, répondre à de nombreuses contraintes : localité des accès, asynchronisme, pré- et post-traitements, mise en œuvre « checkpoint-restart », etc. Le tout en ayant à l’esprit que les mouvements de données sont de plus en plus coûteux en termes de temps et d’énergie. Les systèmes d’entrées / sorties, très souvent négligés, voient leur coût augmenter jusqu’à dominer celui des systèmes. En conséquence, il n’est quasiment plus possible de dissocier le cœur de la simulation des pré- et post-traitements [15]. Des techniques d’analyses des données in situ ou en transit peuvent atténuer le flux des grandes volumétries qui sont aujourd’hui traitées a posteriori. Ces techniques nécessitent en revanche que l’application ait connaissance de la structuration des données qu’elle traite. C’est dans ce domaine que le HPC et le Big Data se combinent [16].

Le processus de développement des applications est lui aussi malmené, notamment le “cycle en V” qui a désormais atteint ses limites [17]. En effet, le développement HPC se caractérise moins par ses spécificités en ingénierie logicielle que par ses besoins avancés en optimisation des codes. Des technologies comme Hudson [18] et des méthodologies de développement agiles [19, 20] comme SCRUM peuvent à cet égard être synonymes de bonnes pratiques pour la communauté HPC. C’est particulièrement vrai dans le cas des applications Exascale où une approche de type co-design est nécessaire [21].

L’évolution des codes implique aussi de pouvoir réunir au sein de projets HPC des compétences variées. La complexité et l’étendue des tâches, qu’il s’agisse de l’exploitation du parallélisme massif, de l’algorithmique ou de la distribution des I/O, ne peuvent être adressées qu’en regroupant différentes communautés scientifiques dans un même lieu, physique ou virtuel. Ce défi n’est pas mince, d’autant que chaque organisation doit être adaptée à chaque écosystème. En pratique, un projet Open Source impliquant une communauté scientifique étalée dans le monde entier ne sera pas organisé de la même façon qu’un projet confiné au sein d’une organisation unifiée, quelle que soit sa taille.

II – Considérations algorithmiques

Il est probable que l’évolution des architectures pousse à revenir aux équations de la physique plutôt qu’à faire évoluer les codes aux forceps. Le compromis établi ces dernières décennies consistant à réduire le volume de calculs au détriment de leur régularité est aujourd’hui en contradiction avec une parallélisation efficace des codes. Le coût des flops a en effet largement baissé alors que celui du mouvement des octets a fortement grimpé. Par conséquent, ce compromis doit maintenant être revu en tenant compte de considérations économiques. La parallélisation, les méthodes numériques et la physique sont imbriquées, et ce sont les premières qui guident ce qui peut être simulé.

Il faut aussi se rendre à l’évidence et reconnaître que l’accroissement des performances ne vient pas uniquement des calculateurs. Dans certains cas, l’évolution des algorithmes a permis d’obtenir des gains équivalents à ce que l’évolution des machines a pu offrir au cours des 25 dernières années [22]. En revanche, l’évolution des machines peut influencer le choix des algorithmes qui doivent parvenir à un équilibre entre qualité numérique et scalabilité selon la méthode choisie, implicite ou explicite, le pas de temps, les graphes acycliques, etc. En ce qui concerne la discrétisation, comme par exemple l’utilisation ou non de maillages évolutifs pour améliorer la régularité des calculs, son choix a un impact sur toute l’architecture logicielle. Ainsi, des méthodes que l’on pourrait qualifier de “subtiles”, comme Lagrange à cardinalité fixe par rapport à ALE à cardinalité variable ou même Euler par rapport à AMR, peuvent ne pas facilement passer à l’échelle. Faut-il pour autant les abandonner ?

Quoi qu’il en soit, la route vers l’Exascale est sans aucun doute une période bénie pour les scientifiques car elle multiplie la recherche de nouveaux algorithmes dits “communication avoiding“, une piste qui doit être poursuivie et même amplifiée [23, 24, 25].

[8] Top 500.

[9] Estimating the total development cost of a linux distribution.

[10] S. McConnell. Software Estimation: Demystifying the Black Art. Microsoft Press, Redmond, WA, USA, 2006.

[11] J. Wells. What does titan tell us about preparing for exascale supercomputers? 2013.

[12] NVIDIA. CUBLAS Library User Guide. nVidia, v5.0 edition, Oct. 2012.

[13] Intel Math Kernel Library.

[14] Starpu handbook, 2013.

[15] The eofs e10 workgroup.

[16] Eesi2 – xyratec working document – wg 5.1, 2013.

[17] F. P. Brooks, Jr. The Mythical Man-month (Anniversary Ed.). Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995.

[18] Hudson – continuous integration.

[19] K. Schwaber and M. Beedle. Agile Software Development with Scrum. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1st edition, 2001.

[20] D. A. Dewi, E. Sundararajan, and A. S. Prabuwono. The adaptive agile in high performance computing: Case study on parallel image feature extraction. Sci.Int. (Lahore), pp 1045–1052, 2013.

[21] Etp4hpc strategic research agenda, 2013.

[22] D. Keyes, P. Colella, T. H. Dunning, and W. D. Gropp. A science-based case for large-scale simulation, volume 2, Sept. 2004. DRAFT, Office of Science, U.S. Department of Energy.

[23] L. Grigori, J. Demmel, and H. Xiang. Calu: A communication optimal lu factorization algorithm. SIAM J. Matrix Analysis Applications, 32(4):1317–1350, 2011.

[24] Extreme maths working group (emwg), 2013.

[25] Applied mathematics research for exascale computing, 2014.