|
|
|
# Reprises : calcul reproductible pour la physique
|
|
|
|
|
|
|
|
<img src="/uploads/1fa38e1196ae62b6ff50aa11783aab77/logo-reprises.png" align="left" width="40" hspace="10">
|
|
|
|
Les nouvelles architectures matérielles posent un défi majeur aux applications de nos communautés, dont la durée de vie est très longue (10 à 20 ans typiquement) alors que chaque génération de matériel (tous les 2 ans) apporte de nouvelles optimisations qu’il faut utiliser pour bénéficier des améliorations de performance. Jusqu’à maintenant, cela a été un frein majeur à l’adoption de ces nouveaux matériels, en dehors de quelques domaines précis ou le bénéfice semble évident (GPUs pour le Deep Learning). Encore plus particulièrement dans notre institut, l'utilisation des grilles de calcul, assemblage de matériel hétéroclie (par opposition aux super-calculateurs), constitue un défi supplémentaire pour la portabilité du code, ses performances, mais aussi pour la reproductibilité des résultats.
|
|
|
|
|
|
|
|
<img src="/uploads/1fa38e1196ae62b6ff50aa11783aab77/logo-reprises.png" align="left" width="40" hspace="10">
|
|
|
|
|
|
|
|
Ce projet se propose d’explorer tous les moyens techniques qui prétendent concilier **performance**, **portabilité** (sur les différents matériels d'une grille) **et pérennité** (possibilité de s'adapter au matériel à venir). Il s'agit généralement d'utiliser une représentation assez abstraite du calcul à réaliser, par exemple en s'appuyant sur un langage dédié à une problématique donnée (Domain Specific Language), et d'en déduire automatiquement des implémentations efficaces pour les architectures ciblées. Cela peut aussi s'obtenir par le biais de standards tels qu'OpenCL, par de la generation de code, ou de la méta-programmation à base de templates.
|
|
|
|
|
|
|
|
Dans nos disciplines, il pourrait être approprié d'avoir un langage source Python-like, Python étant perçu comme simple par les physiciens, et une implémentation générée C++-like, ce dernier étant déjà notre langage privilégie pour la performance. A ce titre, Pythran est un outil qui mériterait sans doute qu'on s'y intéresse un peu. Il y a aussi des langages qui se prétendent mieux armés pour la définition de DSL, tels que Groovy et Ruby (Julia ?).
|
|
|
|
|
|
|
|
Par ailleurs, avant de pouvoir écrire des codes "métamorphique", il faut acquérir un certain savoir-faire sur les architectures matérielles de dernière génération et la meilleure façon de les exploiter : GPU, Knight Landing, FPGA, etc. Tous les collègues qui veulent construire et partager ce savoir-faire sont les bienvenus.
|
|
|
|
|
|
|
|
<img src="/uploads/1fa38e1196ae62b6ff50aa11783aab77/logo-reprises.png" align="left" width="40" hspace="10">
|
|
|
|
|
|
|
|
Nous souhaitons également éviter des calculs trop précis, ou des itérations inutiles. Depuis trop longtemps, on pratique la double précision par défaut, sans évaluer son utilité, et cette question devient encore plus prégnante avec les accélérateurs de calcul moderne, qui peuvent être radicalement plus efficaces en simple précision.
|
|
|
|
|
|
|
|
Pour pouvoir se convaincre d'abandonner la double précision, encore faut-il reprendre le contrôle de la précision de nos calculs flottants, être capable de reproduire les résultats en contexte d'exécution parallèle, comprendre l'impact de la parallélisation sur la génération des nombres aléatoires, ainsi que repenser nos schémas numériques et nos choix algorithmiques pour le parallélisme.
|
|
|
|
|
|
|
|
Les nouveaux outils d'arithmétique stochastique développés en France nous offre une opportunité de **profiler nos calculs flottants**, d'identifier les zones de précision inutilement élevée, et au contraire de renforcer la précision de façon ciblée sur les calculs les plus instables, par exemple à l'aide d'algorithmes d'artihmétique compensée.
|
|
|
|
|
|
|
|
## ||: Objectifs
|
|
|
|
|
|
|
|
* Comparer les approches disponibles : directives, bibliothèques, transpilateurs et générateur de code, langages dédiés, ...
|
|
|
|
* Aider à choisir parmi la pléthore de technologies logicielles disponibles, celles qui préservent la portabilité et la durabilité du code et de ses performances.
|
|
|
|
* Rechercher une solution permettant l'écriture d'un code général simple, stable et durable, qui puisse être transformé autmatiquement selon le besoin en code spécialisé performant pour tel ou tel matériel particulier.
|
|
|
|
* Evaluer l'impact du modèle de données dans cette approche.
|
|
|
|
|
|
|
|
* Mieux évaluer la précision et la reproductibilité de nos calculs.
|
|
|
|
* Evaluer l'impact des technologies parallèles sur la précision et la (non)reproductibilité.
|
|
|
|
* Adapter la génération des nombres aléatoires à l'exécution en contexte parallèle.
|
|
|
|
* Explorer la possibilité de calculer certaines sous-partie, ou certaines étapes, en precision réduite (y compris par des options de compilation telles que -Ofast).
|
|
|
|
* Explorer la possibilité de calculer certaines sous-partie, ou certaines étapes, en precision augmentée.
|
|
|
|
* Trouver comment contourner les difficultés pour la validation des résultats de physique (sorties stockées/affichées dans un ordre aléatoire, non-associativité du calcul flottant...).
|
|
|
|
* En coordination avec des numériciens, optimiser le calcul avec des matrices de taille "moyenne", telles que celles qui interviennent dans la reconstruction de traces.
|
|
|
|
|
|
|
|
---
|
|
|
|
## ||: Partenaires et sympathisants internes
|
|
|
|
|
|
|
|
#### Chercheurs
|
|
|
|
|
|
|
|
* Ziad El Bitar, IPHC, 0.1 ETP
|
|
|
|
* David Rousseau, LAL, 0.1 ETP
|
|
|
|
* Yohann Scribano, LUPM, 0.1 ETP
|
|
|
|
* Hervé Wozniak, LUPM, 0.1 ETP
|
|
|
|
* Johan Bregeon, LUPM
|
|
|
|
* Johann Cohen-Tanugi, LUPM
|
|
|
|
* Gilles Maurin, LAPP
|
|
|
|
* Vincent Poireau, LAPP
|
|
|
|
|
|
|
|
#### Ingénieurs
|
|
|
|
|
|
|
|
* David Chamont, LAL, 0.3 ETP
|
|
|
|
* Hadrien Grasland, LAL, 0.2 ETP
|
|
|
|
* Gilles Grasseau, LLR, 0.2 ETP
|
|
|
|
* Luisa Arrabito, LUPM, 0.1 ETP
|
|
|
|
* Jean Jacquemier, LAPP, 0.1 ETP
|
|
|
|
* Bogdan Vulpescu, LPC, 0.1 ETP
|
|
|
|
* Vincent Lafage, IPNO, 0.05 ETP
|
|
|
|
* Jean-Noel Albert, LAL
|
|
|
|
* Pierre Aubert, LAPP
|
|
|
|
* Arnaud Beck, LLR
|
|
|
|
* Nicolas Clémentin, LUPM
|
|
|
|
* Maude Le Jeune, APC
|
|
|
|
* Emmanuel Medernach, IPHC
|
|
|
|
* Jérôme Pansanel, IPHC
|
|
|
|
* François Touze, LAL
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
## ||: Contacts externes
|
|
|
|
|
|
|
|
* SERMA, Emeric Brun.
|
|
|
|
* IAS, Claude Mercier.
|
|
|
|
* [Ecole Centrale de Nantes](https://supercomputing.ec-nantes.fr), Richard Randriatoamanana, Hugues Digonnet.
|
|
|
|
* Telecom Sud-Paris, équipe Samovar, Gael Thomas : DSL
|
|
|
|
* EDF, François Fevotte : Verrou
|
|
|
|
* LIRMM, [DALI](https://www.lirmm.fr/recherche/equipes/dali) (Philippe Langlois, David Parello) : calcul reproductible
|
|
|
|
* LRI, Joel Falcou ? Programmation générative
|
|
|
|
* LRI, Marc Baboulin ? Algèbre pour matrices 5x5
|
|
|
|
* LIP6, Fabienne Jezequel ? Cadna
|
|
|
|
* INRIA ?
|
|
|
|
* GDR IM ?
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
## Participants
|
|
|
|
|
|
|
|
#### Participants et sympathisants internes
|
|
|
|
|
|
|
|
* APC : Cécile Cavet, Martin Souchal
|
|
|
|
* LAL : Oleg Lodygensky, Gerard Marchal-Duval, David Chamont.
|
|
|
|
* LPNHE : Aurélien Baily-Reyre, Olivier Dadoun, Victor Mendoza.
|
|
|
|
* LLR : Andrea Sartirana, Grasseau Gilles.
|
|
|
|
* IPHC : Jérôme Pansanel, Emmanuel Medernach.
|
|
|
|
|
|
|
|
#### Partenaires externes
|
|
|
|
|
|
|
|
* Groupe de travail Aristote sur la virtualisation légère.
|
|
|
|
* Centrale Nantes : Pierre-Emmanuel Guerin, Richard Randriatoamanana.
|
|
|
|
* IAS : Marc Dexet.
|
|
|
|
|
|
|
|
---
|
|
|
|
## Liens
|
|
|
|
|
|
|
|
* [**_Master-projet DecaLog_**](https://gitlab.in2p3.fr/CodeursIntensifs/DecaLog/wikis/home)
|
|
|
|
* [**_Wiki privé de Reprises_**](https://gitlab.in2p3.fr/CodeursIntensifs/Reprises/wikis/home) |
|
|
|
\ No newline at end of file |
