| ... | @@ -5,22 +5,16 @@ https://fr.wikipedia.org/wiki/Repr%C3%A9sentation_des_symboles_musicaux_en_infor |
... | @@ -5,22 +5,16 @@ https://fr.wikipedia.org/wiki/Repr%C3%A9sentation_des_symboles_musicaux_en_infor |
|
|
|
|
|
|
|
<img src="/uploads/04900d606aecf88c1de6051adeb47a50/logo-reprises.png" align="left" width="40" hspace="10">
|
|
<img src="/uploads/04900d606aecf88c1de6051adeb47a50/logo-reprises.png" align="left" width="40" hspace="10">
|
|
|
|
|
|
|
|
# Calcul reproductible pour la physique
|
|
# Calcul reproductible pour la physique
|
|
|
|
|
|
|
|
<img src="/uploads/04900d606aecf88c1de6051adeb47a50/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.
|
|
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/04900d606aecf88c1de6051adeb47a50/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.
|
|
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 ?).
|
|
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.
|
|
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/04900d606aecf88c1de6051adeb47a50/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.
|
|
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.
|
|
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.
|
| ... | |
... | |
| ... | | ... | |
