Francfort en 2019 (Ludwig 2019). La suppression des optimisations vectorielles « agressives » permet de retrouver un comportement normal avec une performance moindre.

Avec la généralisation des exécutions dynamiques à l'intérieur des CPU (également connues sous le nom de « out-of-order », des changements de l'ordre d'exécution des instructions), créées pour mieux alimenter la pile d'exécution des CPU, nous observons depuis plus de problèmes avec l'arithmétique à virgule flottante en HPC. De plus, comme le montrent Mytkowicz et al. (2009), même l'évaluation de la performance d'une fonctionnalité d'optimisation comme O3 peut être non reproductible.

## 5.4. Hétérogénéité du matériel

Dans un environnement de calcul haute performance, tel que les grilles de calcul utilisées par le CERN, les ressources matérielles peuvent être très hétérogènes. Cette hétérogénéité peut avoir des implications significatives pour la reproductibilité, car elle introduit des variations en termes de performance, de précision et de comportement d'exécution entre différents systèmes (Boyer 2022). En effet, l'hétérogénéité potentielle des plateformes matérielles et des réseaux soulève des préoccupations quant à la reproductibilité. La planification dynamique nécessaire pour s'adapter aux ressources et charges changeantes rend difficile l'exécution constante des opérations dans le même ordre lors de différentes exécutions sur une plateforme à mémoire distribuée. La figure 5 illustre un scénario de charge de travail standard pour les expériences LHCb du CERN. Dans cette représentation, divers nœuds de travail sont engagés dans la récupération et le traitement des tâches. Notamment, ces nœuds sont équipés d'un large éventail de composants matériels, illustrant le concept de calcul en grille dans un environnement de calcul à hautes performances.
et le traitement des tâches. Notamment, ces nœuds sont équipés d'un large éventail de composants matériels, illustrant le concept de calcul en grille dans un environnement de calcul à haute performance.

<figure><img src="image_6.png" /><figcaption>**Figure 5.** *Charge de travail typique pour les expériences du LHCb*</figcaption></figure>

Nous pouvons également rencontrer une variabilité de performance en raison de l'hétérogénéité du matériel. Différentes architectures matérielles présentent des capacités de traitement variables, telles que la vitesse d'horloge des CPUs, le nombre de cœurs, la bande passante de la mémoire, les configurations du BIOS et la taille du cache. En conséquence, le même code exécuté sur différentes machines peut présenter des caractéristiques de performance différentes. Cette variabilité peut entraîner des écarts dans le temps nécessaire pour achever les calculs, rendant difficile la comparaison et la reproduction cohérente des résultats à travers diverses configurations matérielles.

De plus, les CPUs peuvent également être très différents au niveau de leur conception, mettant en œuvre différentes technologies et ensembles d'instructions, y compris SIMD (par exemple, AVX dont nous venons de
<figure><img src="image_6.png" /><figcaption>**Figure 5.** *Charge de travail typique pour les expériences du LHCb*</figcaption></figure>

Nous pouvons également rencontrer une variabilité de performance en raison de l'hétérogénéité du matériel. Différentes architectures matérielles présentent des capacités de traitement variables, telles que la vitesse d'horloge des CPUs, le nombre de cœurs, la bande passante de la mémoire, les configurations du BIOS et la taille du cache. En conséquence, le même code exécuté sur différentes machines peut présenter des caractéristiques de performance différentes. Cette variabilité peut entraîner des écarts dans le temps nécessaire pour achever les calculs, rendant difficile la comparaison et la reproduction cohérente des résultats à travers diverses configurations matérielles.

De plus, les CPUs peuvent également être très différents au niveau de leur conception, mettant en œuvre différentes technologies et ensembles d'instructions, y compris SIMD (par exemple, AVX dont nous venons de parler), qui peuvent accélérer certains calculs. Cependant, le code utilisant des ensembles d'instructions spécifiques peut produire des résultats
parler), qui peuvent accélérer certains calculs. Cependant, le code utilisant
des ensembles d'instructions spécifiques peut produire des résultats
différents sur des CPU qui ne prennent pas en charge ces instructions.
Cette divergence peut entraîner des différences de performance et, dans
certains cas, une divergence numérique dans les résultats. Cela peut
également affecter la précision en virgule flottante (par exemple, double
précision, précision étendue). L'utilisation de différentes précisions peut
entraîner des variations dans la précision et l'exactitude numérique des
résultats finaux. Dans certains cas, ces différences peuvent être
négligeables, mais dans d'autres, lorsqu'elles sont répétées intensivement,
elles peuvent affecter de manière significative le résultat final.

Toujours concernant le matériel, les mémoires peuvent varier, et avec
elles, leurs performances. Des hiérarchies de mémoire diverses, telles que
différentes tailles de cache et latences d'accès à la mémoire, peuvent
affecter l'efficacité des applications intensives en mémoire (certaines
applications étant limitées en performance par leurs accès à la mémoire).
Cela aussi peut entraîner des performances variables.

Sur les grilles de calcul, nous cherchons également non seulement la
parallélisation, mais aussi l'équilibrage de charge, et cet aspect est difficile.
Un code optimisé pour une architecture parallèle spécifique peut ne pas
utiliser efficacement d'autres architectures, conduisant à des schémas
différents de parallélisation et, par conséquent, à différentes performances
et résultats numériques.

Enfin, la pile logicielle peut être différente, comme les compilateurs, les
bibliothèques, le système d'exploitation, etc. Toutes ces variations peuvent
conduire à un code généré ou exécuté différent, modifiant potentiellement
la performance et le comportement numérique de l'application.

Pour toutes ces raisons, nous pouvons faire face à des bogues
spécifiques à la plateforme. De tels problèmes peuvent conduire à des
différents sur des CPU qui ne prennent pas en charge ces instructions. Cette divergence peut entraîner des différences de performance et, dans certains cas, une divergence numérique dans les résultats. Cela peut également affecter la précision en virgule flottante (par exemple, double précision, précision étendue). L'utilisation de différentes précisions peut entraîner des variations dans la précision et l'exactitude numérique des résultats finaux. Dans certains cas, ces différences peuvent être négligeables, mais dans d'autres, lorsqu'elles sont répétées intensivement, elles peuvent affecter de manière significative le résultat final.

Toujours concernant le matériel, les mémoires peuvent varier, et avec elles, leurs performances. Des hiérarchies de mémoire diverses, telles que différentes tailles de cache et latences d'accès à la mémoire, peuvent affecter l'efficacité des applications intensives en mémoire (certaines applications étant limitée en performance par leurs accès à la mémoire). Cela aussi peut entraîner des performances variables.

Sur les grilles de calcul, nous cherchons également non seulement la parallélisation, mais aussi l'équilibrage de charge, et cet aspect est difficile. Un code optimisé pour une architecture parallèle spécifique peut ne pas utiliser efficacement d'autres architectures, conduisant à des schémas différents de parallélisation et, par conséquent, à différentes performances et résultats numériques.

Enfin, la pile logicielle peut être différente, comme les compilateurs, les bibliothèques, le système d'exploitation, etc. Toutes ces variations peuvent conduire à un code généré ou exécuté différent, modifiant potentiellement la performance et le comportement numérique de l'application.

Pour toutes ces raisons, nous pouvons faire face à des bogues spécifiques à la plateforme. De tels problèmes peuvent conduire à des
résultats non reproductibles sur certains systèmes, rendant difficile
l'identification et la correction de la cause principale.

5.5. Informatique quantique

Une nouvelle branche du calcul haute performance émerge avec le calcul quantique. Cela est prometteur pour l'optimisation de la résolution de problèmes (Hogg et Portnov 2000). Des outils sont développés pour faciliter l'utilisation du calcul quantique, qui peut rester obscur pour les personnes habituées à l'informatique déterministe classique. (Shaydulin et al. 2021) proposent un toolkit Python nommé QAOAKit, conçu pour la recherche d'algorithmes d'optimisation quantique approximatif (QAOA). Il sert de dépôt unifié de paramètres QAOA pré-optimisés et de générateurs de circuits quantiques. En intégrant des paramètres connus pour le problème MaxCut et en fournissant des outils de conversion pour divers cadres de simulation quantique, QAOAKit facilite la reproductibilité, la comparaison et l'extension des résultats de recherche en optimisation quantique, abordant des questions ouvertes sur la performance et le comportement de l'algorithme.

IBM est à l'avant-garde de l'accès aux machines quantiques avec leur
plateforme IBM Quantum Experience. Cette plateforme permet aux
chercheurs et aux passionnés de réaliser des expériences sur les processeurs
quantiques d'IBM, qui peuvent avoir jusqu'à 127 qubits depuis 2023. Cet
accès remarquable est facilité par Qiskit, un framework de développement
de logiciels de calcul quantique open-source, qui permet aux utilisateurs
d'écrire des algorithmes quantiques en Python. Il y a également QASM
(Quantum Assembly Language), qui offre un moyen d'exprimer des
circuits quantiques à un niveau inférieur, permettant un contrôle plus fin
des opérations quantiques.
résultats non reproductibles sur certains systèmes, rendant difficile
l'identification et la correction de la cause principale.

5.5. Informatique quantique

Une nouvelle branche du calcul haute performance émerge avec le calcul quantique. Cela est prometteur pour l'optimisation de la résolution de problèmes (Hogg et Portnov 2000). Des outils sont développés pour faciliter l'utilisation du calcul quantique, qui peut rester obscur pour les personnes habituées à l'informatique déterministe classique. (Shaydulin et al. 2021) proposent un toolkit Python nommé QAOAKit, conçu pour la recherche d'Algorithme d'Optimisation Quantique Approximatif (QAOA). Il sert de dépôt unifié de paramètres QAOA pré-optimisés et de générateurs de circuits quantiques. En intégrant des paramètres connus pour le problème MaxCut et en fournissant des outils de conversion pour divers cadres de simulation quantique, QAOAKit facilite la reproductibilité, la comparaison et l'extension des résultats de recherche en optimisation quantique, abordant des questions ouvertes sur la performance et le comportement de l'algorithme.

IBM est à l'avant-garde de l'accès aux machines quantiques avec leur
plateforme IBM Quantum Experience. Cette plateforme permet aux
chercheurs et aux passionnés de réaliser des expériences sur les
processeurs quantiques d'IBM, qui peuvent avoir jusqu'à 127 qubits depuis
2023. Cet accès remarquable est facilité par Qiskit, un framework de
développement de logiciels de calcul quantique open-source, qui permet
aux utilisateurs d'écrire des algorithmes quantiques en Python. Il y a
également QASM (Quantum Assembly Language), qui offre un moyen
d'exprimer des circuits quantiques à un niveau inférieur, permettant un
contrôle plus fin des opérations quantiques.
De plus, les méthodes de création de qubits sont variées et font l'objet de recherches actives. En général, les qubits peuvent être réalisés en utilisant plusieurs systèmes physiques. Les méthodes les plus utilisées incluent les ions piégés, où des ions individuels sont confinés et manipulés avec des champs électromagnétiques ; les circuits supraconducteurs qui exploitent les propriétés mécaniques quantiques de circuits électroniques macroscopiques refroidis à près de zéro absolu ; et les qubits à semi-conducteurs, qui sont fabriqués en utilisant des principes similaires à ceux des puces informatiques conventionnelles. Chacune de ces méthodes a ses propres avantages et défis, notamment en termes de passage à l'échelle, de temps de cohérence et de taux d'erreurs. Les chercheurs essaient continuellement d'améliorer ces systèmes, dans le but de créer des qubits plus fiables et durables qui pourraient ouvrir la voie à un calcul quantique plus utile.

Cependant, avec le calcul quantique pour l'optimisation haute performance, de nouveaux défis de reproductibilité apparaissent. Nous pouvons voir que la reproductibilité dans le calcul quantique est l'une des principales préoccupations, nous avons besoin de milliers d'excellents qubits pour obtenir un seul qubit « parfait ». Dans (Mauerer et Scherzinger 2022), ils restent à un niveau élevé, proposant des solutions pour gérer les paquets et les dépendances, ce qui est un problème qui n'est pas seulement propre au calcul quantique, au contraire. Si nous nous penchons plus profondément sur l'aspect technique du calcul quantique, nous pouvons en effet comprendre qu'il a des problèmes intrinsèques (Dasgupta et Humble 2021a; Dasgupta et Humble 2021b; Dasgupta et Humble 2022; Hill et al. 2023) en raison du comportement non déterministe, et du fait qu'il est physiquement difficile d'avoir des qubits fiables en raison de la décohérence, du bruit, du manque de correction d'erreur, etc. IBM offre un accès gratuit pour utiliser ses machines quantiques, et ainsi, beaucoup de recherches sont menées sur leurs machines. Dans (Hill et al. 2023), les
De plus, les méthodes de création de qubits sont variées et font l'objet de recherches actives. En général, les qubits peuvent être réalisés en utilisant plusieurs systèmes physiques. Les méthodes les plus utilisées incluent les ions piégés, où des ions individuels sont confinés et manipulés avec des champs électromagnétiques; les circuits supraconducteurs qui exploitent les propriétés mécaniques quantiques de circuits électroniques macroscopiques refroidis à près de zéro absolu; et les qubits à semi-conducteurs, qui sont fabriqués en utilisant des principes similaires à ceux des puces informatiques conventionnelles. Chacune de ces méthodes a ses propres avantages et défis, notamment en termes de passage à l'échelle, de temps de cohérence et de taux d'erreurs. Les chercheurs essayent continuellement d'améliorer ces systèmes, dans le but de créer des qubits plus fiables et durables qui pourraient ouvrir la voie à un calcul quantique plus utile.

Cependant, avec le calcul quantique pour l'optimisation haute performance, de nouveaux défis de reproductibilité apparaissent. Nous pouvons voir que la reproductibilité dans le calcul quantique est l'une des principales préoccupations, nous avons besoin de milliers d'excellents qubits pour obtenir un seul qubit « parfait ». Dans (Mauerer et Scherzinger 2022), ils restent à un niveau élevé, proposant des solutions pour gérer les paquets et les dépendances, ce qui est un problème qui n'est pas seulement propre au calcul quantique, au contraire. Si nous nous penchons plus profondément sur l'aspect technique du calcul quantique, nous pouvons en effet comprendre qu'il a des problèmes intrinsèques (Dasgupta et Humble 2021a; Dasgupta et Humble 2021b; Dasgupta et Humble 2022; Hill et al. 2023) en raison du comportement non déterministe, et du fait qu'il est physiquement difficile d'avoir des qubits fiables en raison de la décohérence, du bruit, du manque de correction d'erreur, etc. IBM offre
auteurs ont mis en œuvre un algorithme de Grover à trois qubits. L'oracle est codé (avec des portes quantiques) pour trouver la propriété « être égal à cinq ». Ils ont exécuté l'algorithme sur un simulateur quantique, montrant qu'ils devraient obtenir la bonne solution avec une probabilité de 94% ; le calcul quantique étant stochastique par essence, les résultats sont donnés par probabilités. Mais lors de l'exécution sur différentes machines quantiques réelles, les résultats n'étaient pas si bons et ils ont trouvé beaucoup de variabilité. Au mieux, ils ont obtenu la bonne solution avec 60% (ce qui est bien moins que ce qui était prévu selon la simulation, mais est encore utilisable). Le problème de reproductibilité est survenu lors de l'exécution de cette expérience plusieurs fois sur la même machine quantique, ou sur différentes machines quantiques. Avec exactement le même code et les mêmes paramètres, ils ont obtenu à chaque fois des résultats statistiquement différents, la plupart n'étant pas ceux attendus. Cela remet en question l'utilisabilité des ordinateurs quantiques actuels, mais il faut noter des améliorations rapides lorsque nous avons testé le même algorithme sur 3 et 5 qubits un an plus tard (Antunes et Hill 2024). Les simulateurs ou les machines quantiques hybrides sont intéressants pour développer des compétences et dans un but d'apprentissage, mais nous ne pourrons produire des résultats scientifiques approfondis sans une reproductibilité fiable.

Le calcul quantique est une technologie jeune et passionnante. Il est probable que nous verrons bientôt des technologies innovantes et obtiendrons des machines quantiques généralistes avec des qubits hautement utilisables dans les prochaines décennies.

## 5.6. Apprentissage artificiel

Une utilisation récente des ressources de calcul à haute performance traite de l'apprentissage artificiel avec des données massives (Big Data).
un accès gratuit pour utiliser ses machines quantiques, et ainsi, beaucoup
de recherches sont menées sur leurs machines. Dans (Hill et al. 2023), les
auteurs ont mis en œuvre un algorithme de Grover à trois qubits. L'oracle
est codé (avec des portes quantiques) pour trouver la propriété « être égal
à cinq ». Ils ont exécuté l'algorithme sur un simulateur quantique,
montrant qu'ils devraient obtenir la bonne solution avec une probabilité
de 94%; le calcul quantique étant stochastique par essence, les résultats
sont donnés par probabilités. Mais lors de l'exécution sur différentes
machines quantiques réelles, les résultats n'étaient pas si bons et ils ont
trouvé beaucoup de variabilité. Au mieux, ils ont obtenu la bonne solution
avec 60% (ce qui est bien moins que ce qui était prévu selon la simulation,
mais est encore utilisable). Le problème de reproductibilité est survenu
lors de l'exécution de cette expérience plusieurs fois sur la même machine
quantique, ou sur différentes machines quantiques. Avec exactement le
même code et les mêmes paramètres, ils ont obtenu à chaque fois des
résultats statistiquement différents, la plupart n'étant pas ceux attendus.
Cela remet en question l'utilisabilité des ordinateurs quantiques actuels,
mais il faut noter des améliorations rapides lorsque nous avons testé le
même algorithme sur 3 et 5 qubits un an plus tard (Antunes et Hill 2024).
Les simulateurs ou les machines quantiques hybrides sont intéressants
pour développer des compétences et dans un but d'apprentissage, mais
nous ne pourrons produire des résultats scientifiques approfondis sans
une reproductibilité fiable.

Le calcul quantique est une technologie jeune et passionnante. Il est
probable que nous verrons bientôt des technologies innovantes et
obtiendrons des machines quantiques générales avec des qubits très
utilisables dans les prochaines décennies.
L'apprentissage artificiel implique l'utilisation de l'aléatoire pour entraîner les modèles. Cependant, les bonnes pratiques pour la reproductibilité dans le monde de l'apprentissage artificiel ne sont pas si bien répandues. Il peut être difficile d'obtenir des séquences de nombres pseudo-aléatoires reproductibles pour les scientifiques utilisant des frameworks de haut niveau (Onose 2023). De plus, les frameworks d'apprentissage profond eux-mêmes subissent des mises à jour et des changements de version, ce qui peut introduire des écarts lors de la comparaison des résultats obtenus avec différentes versions de logiciels.

L'apprentissage artificiel est souvent associé au big data, qui peut également présenter des défis pour la reproductibilité, principalement en raison de la variabilité des ensembles de données ou de l'échantillonnage des données. À mesure que la taille des ensembles de données augmente, les techniques de filtrage et d'échantillonnage deviennent de plus en plus importantes. Différentes approches d'échantillonnage peuvent entraîner des variations dans les sous-ensembles de données utilisés pour l'analyse, et cela peut potentiellement impacter la reproductibilité des résultats. Lorsque nous considérons la classification, les résultats numériques exacts sont beaucoup moins importants. Cependant, le traitement parallèle et les systèmes distribués, couramment utilisés dans l'analyse de masses de données, peuvent contribuer à un comportement non déterministe, rendant la reproductibilité difficile. Les algorithmes parallèles peuvent présenter des comportements différents en fonction de facteurs tels que l'ordre d'exécution ou l'allocation des ressources informatiques. Par conséquent, obtenir les mêmes résultats à travers différentes exécutions parallèles, simplement à des fins de débogage, peut devenir très difficile. De plus, lorsqu'on traite d'une quantité massive de données, il devient plus difficile de partager de telles données, et cela affecte la capacité d'autres chercheurs à reproduire les résultats. Avec (Collberg et Proebsting 2016), nous avons vu que les recherches financées par des institutions publiques
## 5.6. Apprentissage artificiel

Une utilisation récente des ressources de calcul à hautes performances traite de l'apprentissage artificiel avec des données massives (Big Data). L'apprentissage artificiel implique l'utilisation de l'aléatoire pour entraîner les modèles. Cependant, les bonnes pratiques pour la reproductibilité dans le monde de l'apprentissage artificiel ne sont pas si bien répandues. Il peut être difficile d'obtenir des séquences de nombres pseudo-aléatoires reproductibles pour les scientifiques utilisant des frameworks de haut niveau (Onose 2023). De plus, les frameworks d'apprentissage profond eux-mêmes subissent des mises à jour et des changements de version, ce qui peut introduire des écarts lors de la comparaison des résultats obtenus avec différentes versions de logiciels.

L'apprentissage artificiel est souvent associé au big data, qui peut également présenter des défis pour la reproductibilité, principalement en raison de la variabilité des ensembles de données ou de l'échantillonnage des données. À mesure que la taille des ensembles de données augmente, les techniques de filtrage et d'échantillonnage deviennent de plus en plus importantes. Différentes approches d'échantillonnage peuvent entraîner des variations dans les sous-ensembles de données utilisés pour l'analyse, et cela peut potentiellement impacter la reproductibilité des résultats. Lorsque nous considérons la classification, les résultats numériques exacts sont beaucoup moins importants. Cependant, le traitement parallèle et les systèmes distribués, couramment utilisés dans l'analyse de masses de données, peuvent contribuer à un comportement non déterministe, rendant la reproductibilité difficile. Les algorithmes parallèles peuvent présenter des comportements différents en fonction de facteurs tels que l'ordre d'exécution ou l'allocation des ressources informatiques. Par conséquent, obtenir les mêmes résultats à travers différentes exécutions
sont plus facilement reproductibles car le partage de code est une pratique plus courante. Les entreprises privées ont un poids lourd dans le monde de l'apprentissage automatique et sont moins enclines à partager leur code et leurs données puisqu'elles sont en concurrence pour obtenir un avantage industriel.

Enfin, beaucoup de ressources informatiques sont maintenant proposées par les unités de traitement graphique de type GPU (Graphical Processing Unit) qui sont devenues généralistes (GP-GPU : General Purpose-GPU). Ce matériel est largement utilisé dans le domaine de l'IA, en particulier pour l'entraînement de modèles, car les GPU modernes intègrent un grand nombre de « Tensor cores ». Lors de l'utilisation des GPU pour le calcul à haute performance, la reproductibilité peut faire face à plusieurs défis. La précision en virgule flottante est moins importante car l'entraînement peut souvent être réalisé en demi-précision (FP16) ou parfois moins, les opérations de classification n'ayant pas les mêmes besoins en termes de précision. Cependant, des erreurs d'arrondi non déterministes peuvent survenir lors des calculs numériques. Cela peut entraîner de légères variations dans les résultats même lorsque le même code et les mêmes données sont utilisés. De plus, différentes architectures de GPU peuvent produire des résultats incohérents, rendant la reproductibilité difficile sur diverses configurations matérielles. Les bibliothèques et pilotes de GPU contribuent également aux défis de reproductibilité, leur maintenabilité est réduite dans le temps (parfois seulement 5 ans). De nombreuses bibliothèques d'optimisation dans l'apprentissage artificiel et le Big Data sont spécifiques au fournisseur de matériel, s'appuyant sur des interfaces propriétaires et des fonctionnalités fournies par les fabricants de GPU. Les incompatibilités ou les différences entre les versions de bibliothèques ou les pilotes de GPU peuvent introduire des variations dans les résultats et entraver la reproductibilité. L'exécution parallèle sur les GPU peut également introduire des
parallèles, simplement à des fins de débogage, peut devenir très difficile. De plus, lorsqu'on traite d'une quantité massive de données, il devient plus difficile de partager de telles données, et cela affecte la capacité d'autres chercheurs à reproduire les résultats. Avec (Collberg et Proebsting 2016), nous avons vu que les recherches financées par des institutions publiques sont plus facilement reproductible car le partage de code est une pratique plus courante. Les entreprises privées ont un poids lourd dans le monde de l'apprentissage automatique et sont moins enclines à partager leur code et leurs données puisqu'elles sont en concurrence pour obtenir un avantage industriel.

Enfin, beaucoup de ressources informatiques sont maintenant proposées par les unités de traitement graphique de type GPU (Graphical Processing Unit) qui sont devenues généraliste (GP-GPU : General Purpose-GPU). Ce matériel est largement utilisé dans le domaine de l'IA, en particulier pour l'entraînement de modèle, car les GPU modernes intègrent un grand nombre de « Tensor cores ». Lors de l'utilisation des GPU pour le calcul à hautes performances, la reproductibilité peut faire face à plusieurs défis. La précision en virgule flottante est moins importante car l'entraînement peut souvent être réalisé en demi-précision (FP16) ou parfois moins, les opérations de classification n'ayant pas les mêmes besoins en terme de précision. Cependant, des erreurs d'arrondi non déterministes peuvent survenir lors des calculs numériques. Cela peut entraîner de légères variations dans les résultats même lorsque le même code et les mêmes données sont utilisés. De plus, différentes architectures de GPU peuvent produire des résultats incohérents, rendant la reproductibilité difficile sur diverses configurations matérielles. Les bibliothèques et pilotes de GPU contribuent également aux défis de reproductibilité, leur maintenabilité est réduite dans le temps (parfois
comportements « non déterministes » qui affectent davantage la reproductibilité. Les interférences entre les noyaux de GPU, les variations dans la planification des threads et les conditions de favorisation de la vitesse lors de l'exécution parallèle peuvent entraîner des sorties différentes à travers différentes exécutions, même avec les mêmes données d'entrée et le même code (Taufer et al. 2010 ; Jézéquel et al. 2015).

## 5.7. Erreurs silencieuses (ou « soft errors »)

Rarement mentionnées, les erreurs silencieuses jouent un rôle important dans la fiabilité du calcul à haute performance. Les perturbations de nature électrique ou magnétique au sein d'un système informatique peuvent entraîner le basculement involontaire d'un bit de la mémoire vive dynamique (DRAM : Dynamic Random Access Memory) vers son état opposé. Initialement, ce phénomène était principalement attribué aux particules alpha émises par les impuretés dans l'emballage des puces. Les particules alpha ou la radiation alpha se composent de deux protons et deux neutrons, elles sont généralement émises pendant le processus de désintégration alpha, mais peuvent aussi être produites d'autres manières (Rutherford et Royds 1908). Cependant, Normand (1996) a démontré que la principale cause d'erreurs isolées et temporaires dans les puces DRAM est liée au rayonnement ambiant. Les neutrons, provenant principalement des interactions secondaires des rayons cosmiques, ont été identifiés comme une source clé de ce rayonnement, capable d'altérer le contenu d'un ou plusieurs bits de mémoire ou de perturber les circuits responsables de leurs fonctions de lecture ou d'écriture. Une vaste étude, portant toujours sur la DRAM, a tenté de déterminer la fréquence des erreurs de mémoire (Schroeder et al. 2009). Dans cette étude, le comportement des erreurs de DRAM dans des scénarios réels s'écarte considérablement des hypothèses courantes. Notamment, les taux d'erreur observés de la DRAM sont
seulement 5 ans). De nombreuses bibliothèques d'optimisation dans l'apprentissage artificiel et le Big Data sont spécifiques au fournisseur de matériel, s'appuyant sur des interfaces propriétaires et des fonctionnalités fournies par les fabricants de GPU. Les incompatibilités ou les différences entre les versions de bibliothèques ou les pilotes de GPU peuvent introduire des variations dans les résultats et entraver la reproductibilité. L'exécution parallèle sur les GPU peut également introduire des comportements « non déterministes » qui affectent davantage la reproductibilité. Les interférences entre les noyaux de GPU, les variations dans la planification des threads et les conditions de favorisation de la vitesse lors de l'exécution parallèle peuvent entraîner des sorties différentes à travers différentes exécutions, même avec les mêmes données d'entrée et le même code (Taufer et al. 2010; Jézéquel et al. 2015).

## 5.7. Erreurs silencieuses (ou « soft errors »)

Rarement mentionnées, les erreurs silencieuses jouent un rôle important dans la fiabilité du calcul à hautes performances. Les perturbations de nature électrique ou magnétique au sein d'un système informatique peuvent entraîner le basculement involontaire d'un bit de la mémoire vive dynamique (DRAM : Dynamic Random Access Memory) vers son état opposé. Initialement, ce phénomène était principalement attribué aux particules alpha émises par les impuretés dans l'emballage des puces. Les particules alpha ou la radiation alpha se composent de deux protons et deux neutrons, elles sont généralement émises pendant le processus de désintégration alpha, mais peuvent aussi être produites d'autres manières (Rutherford et Royds 1908). Cependant, Normand (1996) a démontré que la principale cause d'erreurs isolées et temporaires dans les puces DRAM est liée au rayonnement ambiant. Les neutrons,
nettement plus élevés que ce que l'on pensait auparavant, allant de 25 000 à 70 000 erreurs par milliard d'heures d'appareil par Mbit, et plus de 8% des modules de mémoire en ligne double (DIMM) connaissent des erreurs annuellement. Contrairement aux croyances antérieures, il est démontré que les erreurs matérielles, plutôt que les erreurs silencieuses (aussi appelées « soft errors »), dominent le paysage des erreurs de mémoire. Étonnamment, la température, qui est un facteur influent dans des environnements contrôlés, a un impact minimal sur le comportement des erreurs dans des contextes pratiques lorsqu'on tient compte d'autres variables.

Les CPU ne sont pas à l'abri de ce problème. Dans le domaine du calcul avancé, l'augmentation de la surface, la réduction des tailles de fabrication (gravures au nanomètre et en dessous dans les laboratoires) et la densité accrue des composants ont conduit à une augmentation des renversements de bits, qui peuvent causer des erreurs silencieuses. Bien que de telles anomalies soient supposées se produire plus fréquemment dans la DRAM, d'autres composants comme les portes logiques et les unités arithmétiques des CPUs peuvent également être vulnérables (Elliott et al. 2013). Cette étude vise à évaluer l'impact d'un renversement de bit unique sur des opérations en virgule flottante spécifiques. L'auteur se penche sur les erreurs résultant du renversement de bits particuliers dans la représentation en virgule flottante IEEE, évitant de se fier à des informations propriétaires comme les taux de renversement de bits et les conceptions de circuits spécifiques aux fournisseurs. Dans (Dixit et al. 2021), ils considèrent également les CPU dans le cadre de la gestion d'erreurs matérielles. Ils argumentent : « *Par exemple, lorsque vous effectuez 2*×3, le CPU peut donner un résultat de 5 au lieu de 6 silencieusement sous certaines conditions micro-architecturales, sans indication de la mauvaise opération dans les journaux d'événements ou d'erreurs du système. En conséquence, un service utilisant le CPU peut ne pas être*
provenant principalement des interactions secondaires des rayons cosmiques, ont été identifiés comme une source clé de ce rayonnement, capable d'altérer le contenu d'un ou plusieurs bits de mémoire ou de perturber les circuits responsables de leurs fonctions de lecture ou d'écriture. Une vaste étude, portant toujours sur la DRAM, a tenté de déterminer la fréquence des erreurs de mémoire (Schroeder et al. 2009). Dans cette étude, le comportement des erreurs de DRAM dans des scénarios réels s'écarte considérablement des hypothèses courantes. Notamment, les taux d'erreur observés de la DRAM sont nettement plus élevés que ce que l'on pensait auparavant, allant de 25 000 à 70 000 erreurs par milliard d'heures d'appareil par Mbit, et plus de 8% des modules de mémoire en ligne double (DIMM) connaissent des erreurs annuellement. Contrairement aux croyances antérieures, il est démontré que les erreurs matérielles, plutôt que les erreurs silencieuses (aussi appelées « soft errors »), dominent le paysage des erreurs de mémoire. Étonnamment, la température, qui est un facteur influent dans des environnements contrôlés, a un impact minimal sur le comportement des erreurs dans des contextes pratiques lorsqu'on tient compte d'autres variables.

Les CPU ne sont pas à l'abri de ce problème. Dans le domaine du calcul avancé, l'augmentation de la surface, la réduction des tailles de fabrication (gravures au nanomètre et en dessous dans les laboratoires) et la densité accrue des composants ont conduit à une augmentation des renversements de bits, qui peuvent causer des erreurs silencieuses. Bien que de telles anomalies soient supposées se produire plus fréquemment dans la DRAM, d'autres composants comme les portes logiques et les unités arithmétiques des CPUs peuvent également être vulnérables (Elliott et al. 2013). Cette étude vise à évaluer l'impact d'un renversement de bit unique sur des opérations en virgule flottante spécifiques. L'auteur se
conscient de l'inexactitude des calculs et continuer à consommer les valeurs incorrectes
dans l'application. »

De ces études, nous savons que la DRAM et les CPUs peuvent conduire
à ce que nous appelons des erreurs silencieuses. Alors que la technologie
évolue, en travaillant avec des puces toujours plus petites, nous
augmentons la probabilité d'avoir des renversements de bit. Maintenant, à
l'échelle Exascale, nous avons des superordinateurs comme Frontier, qui
possède 8 699 904 cœurs. À cette échelle, le temps moyen avant défaillance
tombe à quelques heures de calcul seulement. Dans la section suivante,
nous verrons les solutions proposées pour pallier ces problèmes.
penche sur les erreurs résultant du renversement de bits particuliers dans
la représentation en virgule flottante IEEE, évitant de se fier à des
informations propriétaires comme les taux de renversement de bits et les
conceptions de circuits spécifiques aux fournisseurs. Dans (Dixit et al.
2021), ils considèrent également les CPU dans le cadre de la gestion
d'erreurs matérielles. Ils argumentent : « Par exemple, lorsque vous effectuez 2*3,
le CPU peut donner un résultat de 5 au lieu de 6 silencieusement sous certaines
conditions micro-architecturales, sans indication de la mauvaise opération dans les
journaux d'événements ou d'erreurs du système. En conséquence, un service utilisant le
CPU peut ne pas être conscient de l'inexactitude des calculs et continuer à consommer
les valeurs incorrectes dans l'application. »

De ces études, nous savons que la DRAM et les CPUs peuvent
conduire à ce que nous appelons des erreurs silencieuses. Alors que la
technologie évolue, en travaillant avec des puces toujours plus petites,
nous augmentons la probabilité d'avoir des renversements de bit.
Maintenant, à l'échelle Exascale, nous avons des superordinateurs comme
Frontier qui possède 8 699 904 cœurs. À cette échelle, le temps moyen
avant défaillance tombe à quelques heures de calcul seulement. Dans la
section suivante, nous verrons les solutions proposées pour pallier ces
problèmes.
# Chapitre 6

## Quelles solutions pour améliorer la reproductibilité ?

### 6.1. Gestion des versions et archivage

Pour garantir la reproductibilité des parties computationnelles d'un article, il est nécessaire d'effectuer un suivi de version, d'archiver, de documenter et de partager le code. Tout d'abord, le suivi de version est effectivement très important lorsqu'il s'agit de codes et de scripts. Imaginez un scénario avec une expérience informatique, aboutissant à des figures intéressantes. Ensuite, vous continuez à mettre à jour votre code. Plus tard, vous voulez retravailler sur ces figures, peut-être parce que vous avez soumis un article de recherche et que les relecteurs vous l'ont demandé, ou peut-être juste dans votre processus de recherche afin de mieux comprendre les figures produites. Comme vous avez modifié le code, vous êtes désormais incapable de générer les mêmes figures, vous n'obtenez plus les mêmes résultats intéressants et vous n'avez pas l'ancienne version du code. Cette situation n'est pas rare et aide à comprendre le besoin d'outils pour contrôler les versions du code. Deuxièmement, il est crucial d'archiver votre code de manière permanente. Le code d'erreur HTML « 404 not found » apparaît bien plus souvent qu'il ne le devrait, nous devons faire attention à l'endroit où nous stockons nos différentes versions de code. Troisièmement, vous devez documenter votre code afin que d'autres personnes puissent l'utiliser et le comprendre. Et enfin, vous devez partager votre code pour que les gens puissent y accéder (Kitzes *et al.* 2018).

Concernant les outils de suivi de version, deux des plus importants sont Git et Apache Subversion. Git est devenu l'outil dominant dans ce domaine et est largement utilisé pour le suivi de version. Git offre de nombreuses
# Chapitre 6

## Quelles solutions pour améliorer la reproductibilité ?

### 6.1. Gestion des versions et archivage

Pour garantir la reproductibilité des parties computationnelles d'un article, il est nécessaire d'effectuer un suivi de version, d'archiver, de documenter et de partager le code. Tout d'abord, le suivi de version est effectivement très important lorsqu'il s'agit de codes et de scripts. Imaginez un scénario avec une expérience informatique, aboutissant à des figures intéressantes. Ensuite, vous continuez à mettre à jour votre code. Plus tard, vous voulez retravailler sur ces figures, peut-être parce que vous avez soumis un article de recherche et que les relecteurs vous l'ont demandé, ou peut-être juste dans votre processus de recherche afin de mieux comprendre les figures produites. Comme vous avez modifié le code, vous êtes désormais incapable de générer les mêmes figures, vous n'obtenez plus les mêmes résultats intéressants et vous n'avez pas l'ancienne version du code. Cette situation n'est pas rare et aide à comprendre le besoin d'outils pour contrôler les versions du code. Deuxièmement, il est crucial d'archiver votre code de manière permanente. Le code d'erreur HTML « 404 not found » apparaît bien plus souvent qu'il ne le devrait, nous devons faire attention à l'endroit où nous stockons nos différentes versions de code. Troisièmement, vous devez documenter votre code afin que d'autres personnes puissent l'utiliser et le
fonctionnalités. Dans le cadre d'une recherche reproductible, nous préconisons son intégration dans le processus de développement, bien que les débutants puissent avoir besoin d'une phase d'apprentissage initiale. En essence, adopter Git représente une des bases de bonnes pratiques en génie logiciel.

Plusieurs plateformes sont disponibles pour l'archivage du code. GitHub et GitLab sont parmi les plus courantes. Ils fonctionnent comme des dépôts, où l'on peut stocker son code. Lors du développement d'un code pour un projet de recherche, l'utilisation de l'un de ces outils, en conjonction avec Git, est presque obligatoire. Cependant, ces outils n'ont pas été initialement conçus pour la recherche reproductible. Il convient de noter que ces plateformes, étant des entités commerciales (dans le cas de Github), ne garantissent pas l'accessibilité perpétuelle du code. Des alternatives comme Zenodo et Software Heritage offrent des solutions plus robustes pour l'archivage du code (Hinsen 2020b). Développés respectivement par le CERN et Inria, Zenodo et Software Heritage fournissent des moyens d'archiver du code, des données ou toute ressource numérique associée à un article, chacun identifié par un ID unique (soit DOI ou SWHID, identifiant extrinsèque ou intrinsèque). Zenodo est davantage orienté vers l'archivage du code et des données d'un article, tandis que Software Heritage est un projet plus vaste, comprenant le stockage de toutes les versions existantes de code open source dans le monde, telles que les bibliothèques et non seulement les artefacts d'articles de recherche.

## 6.2. Programmation lettrée et documentation

Pour résoudre le problème de la documentation (rendre le code aussi clair que possible) et, peut-être aussi un peu, pour résoudre le problème des workflows, la programmation lettrée a été introduite. Il est essentiel, lors du partage de code, de le rendre accessible (dans le sens de la facilité
comprendre. Et enfin, vous devez partager votre code pour que les gens puissent y accéder (Kitzes *et al.* 2018).

Concernant les outils de suivi de version, deux des plus importants sont Git et Apache Subversion. Git est devenu l'outil dominant dans ce domaine et est largement utilisé pour le suivi de version. Git offre de nombreuses fonctionnalités, dans le cadre d'une recherche reproductible, nous préconisons son intégration dans le processus de développement, bien que les débutants puissent avoir besoin d'une phase d'apprentissage initiale. En essence, adopter Git représente une des bases de bonnes pratiques en génie logiciel.

Plusieurs plateformes sont disponibles pour l'archivage du code. Github et Gitlab sont parmi les plus courantes. Ils fonctionnent comme des dépôts, où l'on peut stocker son code. Lors du développement d'un code pour un projet de recherche, l'utilisation de l'un de ces outils, en conjonction avec Git, est presque obligatoire. Cependant, ces outils n'ont pas été initialement conçus pour la recherche reproductible. Il convient de noter que ces plateformes, étant des entités commerciales (dans le cas de Github), ne garantissent pas l'accessibilité perpétuelle du code. Des alternatives comme Zenodo et Software Heritage offrent des solutions plus robustes pour l'archivage du code (Hinsen 2020b). Développés respectivement par le CERN et Inria, Zenodo et Software Heritage fournissent des moyens d'archiver du code, des données ou toute ressource numérique associée à un article, chacun identifié par un ID unique (soit DOI ou SWHID). Zenodo est davantage orienté vers l'archivage du code et des données d'un article, tandis que Software Heritage est un projet plus vaste, comprenant le stockage de toutes les versions existantes de code open source dans le monde, telles que les bibliothèques et non seulement les artefacts d'articles de recherche.
d'utilisation). À cette fin, le concept de programmation lettrée (Literate Programming) a émergé en 1984 avec Knuth (1984). Le principe est d'entrelacer le code avec du texte en langage naturel afin de rendre l'ensemble du contenu plus compréhensible. L'application actuelle de ce principe prend la forme de notebooks : des documents interactifs qui permettent de combiner du texte avec des blocs de code. Ils se présentent sous différentes formes pour différents langages de programmation. Pour faciliter la rédaction de ce type de fichier, des langages de composition de texte sont utilisés : principalement LaTeX et Markdown, ce dernier étant beaucoup plus léger et compréhensible sans interpréteur, comme discuté par Pouzat (2021). Knuth avait développé l'outil initial pour la programmation lettrée, appelé WEB, qui comprenait deux programmes principaux, Tangle et Weave (Knuth 1984). Ce système était adapté pour le langage de programmation Pascal et générait des documents formatés en utilisant TeX. Plus tard, Knuth et Levy (1994) ont créé une version pour le langage C, nommée cweb. Une évolution contemporaine de ces outils est noweb (Johnson et Johnson 1997), conçue pour être adaptable à différents langages. Ses programmes principaux, notangle et noweave, sont tous deux codés en C. Les documents produits via noweave peuvent être formatés en utilisant TeX, LaTeX ou troff, ou même être affichés dans un navigateur web sous forme HTML. Des utilitaires logiciels comme WEB, cweb et noweb permettent aux auteurs de créer à la fois du contenu écrit et du code, mais ils ne disposent pas de mécanismes pour exécuter directement le code dans les documents. Au lieu de cela, le code destiné à l'exécution est extrait, résultant en des fichiers de code source qui sont ensuite transmis à un compilateur ou interpréteur. Un des outils les plus largement adoptés pour réaliser une recherche reproductible était Sweave, qui voit une utilisation croissante au sein de la communauté de programmation R. L'utilisation de Sweave pour la recherche reproductible a donné naissance à des outils analogues comme SASweave et Statweave. Certains de ces
## 6.2. Programmation lettrée et documentation

Pour résoudre le problème de la documentation (rendre le code aussi clair que possible) et, peut-être aussi un peu, pour résoudre le problème des workflows, la programmation lettrée a été introduite. Il est essentiel, lors du partage de code, de le rendre accessible (dans le sens de la facilité d'utilisation). À cette fin, le concept de Programmation lettrée (Literate Programming) a émergé en 1984 avec Knuth (1984). Le principe est d'entrelacer le code avec du texte en langage naturel afin de rendre l'ensemble du contenu plus compréhensible. L'application actuelle de ce principe prend la forme de Notebooks : des documents interactifs qui permettent de combiner du texte avec des blocs de code. Ils se présentent sous différentes formes pour différents langages de programmation. Pour faciliter la rédaction de ce type de fichier, des langages de composition de texte sont utilisés : principalement LaTeX et Markdown, ce dernier étant beaucoup plus léger et compréhensible sans interpréteur, comme discuté par Pouzat (2021). Knuth avait développé l'outil initial pour la programmation lettrée, appelé WEB, qui comprenait deux programmes principaux, Tangle et Weave (Knuth 1984). Ce système était adapté pour le langage de programmation Pascal et générait des documents formatés en utilisant TeX. Plus tard, Knuth et Levy (1994) ont créé une version pour le langage C, nommée cweb. Une évolution contemporaine de ces outils est noweb (Johnson et Johnson 1997), conçue pour être adaptable à différents langages. Ses programmes principaux, notangle et noweave, sont tous deux codés en C. Les documents produits via noweave peuvent être formatés en utilisant TeX, LaTeX ou troff, ou même être affichés dans un navigateur web sous forme HTML. Des utilitaires logiciels comme WEB, cweb et noweb permettent aux auteurs de créer à la fois du contenu écrit et du code, mais ils ne disposent pas de mécanismes pour
outils sont destinés à des langages statistiques autres que R et sont
compatibles avec d'autres systèmes d'écriture de documents que LaTeX,
englobant des formats comme les formats OpenDocument et Microsoft
Word (Lenth et Højsgaard 2007 ; Baier et Neuwirth 2007 ; Lenth 2012).
Sweave et ses variantes ne permettent pas de modifier l'ordre des blocs de
code lors du processus de « tangling ». De ce fait, leur capacité à supporter
la programmation lettrée est seulement partielle. Aujourd'hui, parmi les
outils de programmation littéraire les plus connus, nous pouvons
mentionner :

- Jupyter (Kluyver *et al.* 2016), un notebook principalement utilisé avec le langage Python.

- Rstudio (Allaire 2012), développé principalement pour le langage R.

- Org-mode (Schulte et al. 2012), un outil beaucoup plus polyvalent, utilisable avec tous les langages.

Ces trois outils sont présentés en détail dans le MOOC de recherche reproductible de l'Inria (Pouzat et al. 2018) animé par Arnaud Legrand, Konrad Hinsen et Christophe Pouzat. L'utilisation de notebook et, plus largement, la programmation lettrée, est vivement encouragée par la communauté scientifique. Stanisic et al. (2015) proposent une solution de workflow pour la recherche reproductible basée sur l'utilisation de Git et Org-mode. Desquilbet et al. (2019) discutent de l'utilisation des notebooks dans leur livre sur la recherche reproductible. Stodden et al. (2013) compilent une liste d'outils pour la recherche reproductible, les notebooks en faisant partie intégrante. Ragan-Kelley et al. (2018) proposent même un outil nommé Binder, permettant l'exécution directe des dépôts de notebooks Jupyter sur le web sans installation, en reliant à un dépôt Git. Delescluse et al. (2012) mentionnent également Org-mode et Sweave pour la recherche reproductible, dans le contexte du langage R.
exécuter directement le code dans les documents. Au lieu de cela, le code destiné à l'exécution est extrait, résultant en des fichiers de code source qui sont ensuite transmis à un compilateur ou interpréteur. Un des outils le plus largement adopté pour réaliser une recherche reproductible était Sweave, qui voit une utilisation croissante au sein de la communauté de programmation R. L'utilisation de Sweave pour la recherche reproductible a donné naissance à des outils analogues comme SASweave et Statweave. Certains de ces outils sont destinés à des langages statistiques autres que R et sont compatibles avec d'autres systèmes d'écriture de documents que LaTeX, englobant des formats comme les formats OpenDocument et Microsoft Word (Lenth et Højsgaard 2007; Baier et Neuwirth 2007; Lenth 2012). Sweave et ses variantes ne permettent pas de modifier l'ordre des blocs de code lors du processus de « tangling ». De ce fait, leur capacité à supporter la programmation lettrée est seulement partielle. Aujourd'hui, parmi les outils de programmation littéraire les plus connus, nous pouvons mentionner :

- Jupyter (Kluyver *et al.* 2016), un notebook principalement utilisé avec le langage Python.

- Rstudio (Allaire 2012), développé principalement pour le langage R.

- Org-mode (Schulte *et al.* 2012), un outil beaucoup plus polyvalent, utilisable avec tous les langages.

Ces trois outils sont présentés en détail dans le MOOC de recherche reproductible de l'Inria (Pouzat *et al.* 2018) animé par Arnaud Legrand, Konrad Hinsen et Christophe Pouzat. L'utilisation de notebook et, plus largement, la programmation lettrée, est vivement encouragée par la communauté scientifique. Stanisic *et al.* (2015) proposent une solution de workflow pour la recherche reproductible basée sur l'utilisation de Git et Og-mode. Desquilbet *et al.* (2019) discutent de l'utilisation des notebooks
Avec l'augmentation de l'utilisation du langage de programmation Python, Jupyter est probablement le notebook le plus utilisé et le plus facile à prendre en main. Cependant, pour sa polyvalence, Org-mode est probablement l'outil le plus plébiscité, en particulier par les amateurs de Emacs, car Org-mode se base sur cet éditeur de texte (Stallman 1981).

Lorsque l'on traite de grands projets logiciels complexes, on ne peut pas les coder entièrement en utilisant la programmation lettrée. Dans ce cas, le projet sera codé en utilisant un schéma de développement plus classique (génie logiciel), et on utilisera la programmation lettrée en finalité pour l'exécution ou l'analyse des résultats et des données. Par conséquent, pour traiter de tels projets, vous aurez besoin d'autres outils de documentation que la simple programmation lettrée. Il n'y a pas qu'une seule manière de faire une bonne documentation (Sommerville 2001), et vous aurez besoin de bonnes pratiques issues du génie logiciel. Une manière répandue de documenter du code orienté objet est de produire des diagrammes pour modéliser le code en utilisant le langage de modélisation unifié (UML) (Booch *et al.* 1996).

En plus de la programmation lettrée et d'une documentation plus complète avec des outils de modélisation, l'adhésion aux principes FAIR peut contribuer à renforcer la reproductibilité dans la recherche scientifique. Ces principes plaident en faveur de la facilitation de la recherche d'éléments numériques tels que les données, les algorithmes et les outils, en les rendant facilement trouvables, accessibles, interopérables et réutilisables. La mise en œuvre de ces principes garantit que les résultats de la recherche sont identifiables grâce à des identifiants uniques et des métadonnées riches, accessibles via des protocoles bien définis, interopérables grâce à l'utilisation de formats et de vocabulaires standard, et réutilisables avec des licences d'utilisation claires. L'utilisation des principes FAIR facilite la reproduction des résultats de recherche et favorise également la collaboration et l'innovation en permettant aux
dans leur livre sur la recherche reproductible. Stodden et al. (2013) compilent une liste d'outils pour la recherche reproductible, les notebooks en faisant partie intégrante. Ragan-Kelley et al. (2018) proposent même un outil nommé Binder, permettant l'exécution directe des dépôts de notebooks Jupyter sur le web sans installation, en reliant à un dépôt Git. Delescluse et al. (2012) mentionnent également Org-mode et Sweave pour la recherche reproductible, dans le contexte du langage R.

Avec l'augmentation de l'utilisation du langage de programmation Python, Jupyter est probablement le notebook le plus utilisé et le plus facile à prendre en main. Cependant, pour sa polyvalence, Org-mode est probablement l'outil le plus plébiscité, en particulier pour les amateurs de Emacs, car Org-mode se base sur cet éditeur de texte (Stallman 1981).

Lorsque l'on traite de grands projets logiciels complexes, on ne peut pas les coder entièrement en utilisant la programmation lettrée. Dans ce cas, le projet sera codé en utilisant un schéma de développement plus classique (génie logiciel), et on utilisera la programmation lettrée en finalité pour l'exécution ou l'analyse des résultats et des données. Par conséquent, pour traiter de tels projets, vous aurez besoin d'autres outils de documentation que la simple programmation lettrée. Il n'y a pas qu'une seule manière de faire une bonne documentation (Sommerville 2001), et vous aurez besoin de bonnes pratiques issues du génie logiciel. Une manière répandue de documenter du code orienté objet est de produire des diagrammes pour modéliser le code en utilisant le langage de modélisation unifié (UML) (Booch et al. 1996).

En plus de la programmation lettrée et d'une documentation plus complète avec des outils de modélisation, l'adhésion aux principes FAIR peut contribuer à renforcer la reproductibilité dans la recherche scientifique. Ces principes plaident en faveur de la facilitation de la
chercheurs de partager facilement et de s'appuyer mutuellement sur leur travail (Wilkinson *et al.* 2016).

## 6.3. Workflow

Le workflow d'un article de recherche est une partie importante de la recherche reproductible. Il est essentiel de comprendre l'ordre dans lequel les opérations doivent être exécutées. L'un des premiers outils à émerger est le fichier makefile. L'outil make associé a permis l'automatisation de la construction d'un exécutable, mais pas seulement. Le premier article à le considérer à cette fin est paru en 2000 (Schwab et al. 2000), avec Jon Claerbout, que nous avions déjà vu comme l'un des premiers contributeurs de la recherche reproductible en 1992. Schwab et al. décrivent comment utiliser « make » et des outils associés, ainsi que des conventions de nommage pour les fichiers, afin de garantir que les lecteurs ainsi que les auteurs puissent être capables de reproduire les calculs. Avec (Cohen-Boulakia et al. 2017), nous pouvons voir que la biologie est l'un des domaines qui possède le plus d'outils de gestion des workflows pour améliorer la reproductibilité, peut-être parce que la biologie est un domaine qui produit et analyse beaucoup de données. Dans (Oinn et al. 2004), nous pouvons lire « les expériences in silico en bioinformatique impliquent l'utilisation conjointe d'outils informatiques et de stockage d'informations. Un nombre croissant de ces ressources est mis à disposition avec un accès sous forme de services Web. Les scientifiques en bioinformatique devront orchestrer ces services Web dans des workflows dans le cadre de leurs analyses ». De nombreux outils de workflow ont été créés depuis le fichier makefile en 2000 (plus de 300) (Amstutz et al. 2024). Ils visent à être faciles d'utilisation, souvent en fournissant une interface graphique (GUI). Taverna (Oinn et al. 2004) était un système de gestion de workflow scientifique open source qui fournit un environnement pour la conception
recherche d'éléments numériques tels que les données, les algorithmes et les outils, en les rendant facilement trouvables, accessibles, interopérables et réutilisables. La mise en œuvre de ces principes garantit que les résultats de la recherche sont identifiables grâce à des identifiants uniques et des métadonnées riches, accessibles via des protocoles bien définis, interopérables grâce à l'utilisation de formats et de vocabulaires standard, et réutilisables avec des licences d'utilisation claires. L'utilisation des principes FAIR facilite la reproduction des résultats de recherche et favorise également la collaboration et l'innovation en permettant aux chercheurs de partager facilement et de s'appuyer mutuellement sur leur travail (Wilkinson et al. 2016).

## 6.3. Workflow

Le workflow d'un article de recherche est une partie importante de la recherche reproductible. Il est essentiel de comprendre l'ordre dans lequel les opérations doivent être exécutées. L'un des premiers outils à émerger est le fichier makefile. L'outil make associé a permis l'automatisation de la construction d'un exécutable, mais pas seulement. Le premier article à le considérer à cette fin est paru en 2000 (Schwab et al. 2000), avec Jon Claerbout, que nous avions déjà vu comme l'un des premiers contributeurs de la recherche reproductible en 1992. Schwab et al. décrivent comment utiliser « make » et des outils associés, ainsi que des conventions de nommage pour les fichiers, afin de garantir que les lecteurs ainsi que les auteurs puissent être capable de reproduire les calculs. Avec (Cohen-Boulakia et al. 2017), nous pouvons voir que la biologie est l'un des domaines qui possède le plus d'outils de gestion des workflows pour améliorer la reproductibilité, peut-être parce que la biologie est un domaine qui produit et analyse beaucoup de données. Dans (Oinn et al.
de workflows et un moteur d'exécution de ces workflows. Taverna
optimise la structure du workflow, relie les services Web et les activités, et
prend en charge l'exécution sur des grilles de calcul ou du cloud computing.
Cependant, le projet est désormais abandonné. Galaxy (Giardine et al.
2005) est un système de workflow populaire dans la communauté
bioinformatique qui utilise depuis peu un format de spécification de
workflow JSON ou YAML. Galaxy fut compatible avec Common
Workflow Language (CWL), mais ce n'est plus le cas (Amstutz et al. 2016).
Il fournit une interface graphique pour explorer et partager les exécutions
de workflows. Galaxy gère les dépendances des activités pour la
parallélisation, génère et surveille les tâches, et utilise une planification
dynamique pour la distribution des tâches. OpenAlea (Pradal et al. 2015)
est un système de workflow scientifique open source lié à un outil de
modélisation basé sur le langage Python. Il permet aux utilisateurs
d'exporter des workflows dans un format CWL. Cependant, il présente des
limites en termes de complexité, de manque d'un dépôt centralisé et de
difficulté à visualiser la provenance des données. Nextflow (Di Tommaso
et al. 2014) est un système de workflow en ligne de commande pour la
gestion de workflows scientifiques parallèles complexes. Il utilise une
spécification basée sur du texte et prend en charge des workflows de
processeurs et opérateurs. Il présente des limites en termes de gestion des
dépendances des outils et de manque d'informations de provenance de
données. Pegasus, développé par Deelman et al. en 2004 (Deelman et al.
2004), est un outil utilisé dans plusieurs domaines scientifiques. Il offre
plusieurs caractéristiques importantes comme la capacité de s'adapter à
différents environnements (portabilité), l'utilisation d'algorithmes avancés
pour organiser les tâches de manière optimale, le passage à l'échelle, la
gestion efficace des informations sur l'origine des données, et la tolérance
aux pannes. Pegasus est composé de cinq éléments principaux : un moteur
qui associe les tâches aux ressources disponibles, un système pour exécuter
2004), nous pouvons lire « les expériences in silico en bioinformatique impliquent l'utilisation conjointe d'outils informatiques et de stockage d'informations. Un nombre croissant de ces ressources est mis à disposition avec un accès sous forme de services Web. Les scientifiques en bioinformatique devront orchestrer ces services Web dans des workflows dans le cadre de leurs analyses ». De nombreux outils de workflow ont été créés depuis le fichier makefile en 2000 (plus de 300) (Amstutz et al. 2024). Ils visent à être faciles d'utilisation, souvent en fournissant une interface graphique (GUI). Taverna (Oinn et al. 2004) était un système de gestion de workflow scientifique open source qui fournit un environnement pour la conception de workflows et un moteur d'exécution de ces workflows. Taverna optimise la structure du workflow, relie les services Web et les activités, et prend en charge l'exécution sur des grilles de calcul ou du cloud computing. Cependant, le projet est désormais abandonné. Galaxy (Giardine et al. 2005) est un système de workflow populaire dans la communauté bioinformatique qui utilise depuis peu un format de spécification de workflow JSON ou YAML. Galaxy fut compatible avec Common Workflow Language (CWL), mais ce n'est plus le cas (Amstutz et al. 2016). Il fournit une interface graphique pour explorer et partager les exécutions de workflows. Galaxy gère les dépendances des activités pour la parallélisation, génère et surveille les tâches, et utilise une planification dynamique pour la distribution des tâches. OpenAlea (Pradal et al. 2015) est un système de workflow scientifique open source lié à un outil de modélisation basé sur le langage Python. Il permet aux utilisateurs d'exporter des workflows dans un format CWL. Cependant, il présente des limites en termes de complexité, de manque d'un dépôt centralisé et de difficulté à visualiser la provenance des données. Nextflow (Di Tommaso et al. 2014) est un système de
les tâches sur l'ordinateur local, un ordonnanceur de tâches, un moteur d'exécution à distance, et un dispositif pour surveiller le processus. Ensemble, ces éléments permettent de créer et d'exécuter un workflow efficace sur différentes plateformes informatiques. Swift (Zhao et al. 2007), tout comme Pegasus, est utilisé dans de nombreuses disciplines et se spécialise dans les workflows qui nécessitent une grande quantité de données. Il gère ces workflows en plusieurs étapes : définition du programme, planification, exécution, gestion de la provenance et approvisionnement. Swift supporte la division des workflows, la résilience aux erreurs, et l'allocation dynamique de ressources sur divers sites d'exécution. Kepler (Altintas et al. 2004) est un système de gestion de workflow qui permet différentes méthodes d'exécution. Il intègre une interface graphique. Kepler est capable de planifier de manière statique ou dynamique, offre une tolérance aux pannes et peut exécuter des workflows sur des services Web, des systèmes basés sur des grilles de calcul ou utilisant le framework Hadoop (Borthakur 2007). Chiron (Ogasawara et al. 2013) adopte une approche basée sur une base de données pour gérer l'exécution parallèle de workflows scientifiques intensifs en données. Il utilise un modèle algébrique et des opérateurs pour gérer les données et les activités du workflow. Chiron assure le suivi du workflow, gère différents types de parallélisme (par les données, indépendant, en pipeline) et propose une planification dynamique. Il stocke les informations d'exécution et de provenance dans une base de données structurée. Triana (Taylor et al. 2007) est un outil doté d'une interface graphique, développé initialement pour l'analyse de données dans le projet GEO 600. Triana est conçu pour les applications distribuées. Enfin, Snakemake est un moteur de workflow avancé offrant un langage de définition de workflow basé sur Python, facile à lire. Il permet une exécution flexible, allant d'un seul cœur à la distribution de calculs parallèles sur des clusters avec de nombreux cœurs, sans
workflow en ligne de commande pour la gestion de workflows
 scientifiques parallèles complexes. Il utilise une spécification basée sur du
texte et prend en charge des workflows de processeurs et opérateurs. Il
présente des limites en termes de gestion des dépendances des outils et de
manque d'informations de provenance de données. Pegasus, développé
par Deelman et al. en 2004 (Deelman et al. 2004), est un outil utilisé dans
plusieurs domaines scientifiques. Il offre plusieurs caractéristiques
importantes comme la capacité de s'adapter à différents environnements
(portabilité), l'utilisation d'algorithmes avancés pour organiser les tâches
de manière optimale, le passage à l'échelle, la gestion efficace des
informations sur l'origine des données, et la tolérance aux pannes. Pegasus
est composé de cinq éléments principaux : un moteur qui associe les tâches
aux ressources disponibles, un système pour exécuter les tâches sur
l'ordinateur local, un ordonnanceur de tâches, un moteur d'exécution à
distance, et un dispositif pour surveiller le processus. Ensemble, ces
éléments permettent de créer et d'exécuter un workflow efficace sur
différentes plateformes informatiques. Swift (Zhao et al. 2007), tout
comme Pegasus, est utilisé dans de nombreuses disciplines et se spécialise
dans les workflows qui nécessitent une grande quantité de données. Il gère
ces workflows en plusieurs étapes : définition du programme,
planification, exécution, gestion de la provenance et approvisionnement.
Swift supporte la division des workflows, la résilience aux erreurs, et
l'allocation dynamique de ressources sur divers sites d'exécution. Kepler
(Altintas et al. 2004) est un système de gestion de workflow qui permet
différentes méthodes d'exécution. Il intègre une interface graphique.
Kepler est capable de planifier de manière statique ou dynamique, offre
une tolérance aux pannes et peut exécuter des workflows sur des services
Web, des systèmes basés sur des grilles de calcul ou utilisant le framework
nécessiter de modifier le workflow. Cet outil est particulièrement réputé dans le domaine de la bioinformatique (Köster et Rahmann 2012).

Taverna, Chiron, Triana et Galaxy ont des fonctionnalités telles que l'interface graphique pour la conception des workflows, la prise en charge du parallélisme, la planification dynamique et l'exécution de workflows dans des environnements de grille de calcul et de cloud computing. Taverna prend en charge le partage d'informations sur les workflows, tandis que Galaxy se spécialise dans l'exécution de workflow en bioinformatique. Sequanix propose une interface graphique dynamique pour Snakemake (Desvillechabrol et al. 2018). Un état de l'art sur la gestion des systèmes de workflow est disponible (Liu et al. 2015), et un article sur les workflows plus axé sur les sciences de la vie a également été publié en 2017 (Cohen-Boulakia et al. 2017), tandis que dans (Ivie et Thain 2018), Ivie et Thain proposent un état de l'art plus général sur la gestion des workflows en recherche reproductible.

## 6.4. Environnement logiciel

### 6.4.1. Gérer les dépendances

Lorsque vous écrivez un programme, vous vous reposez toujours sur votre environnement logiciel. À la fin, lorsque vous publierez vos résultats, d'autres chercheurs pourraient rencontrer des obstacles pour relancer votre programme. Il se peut qu'ils ne puissent pas reproduire vos résultats car ils n'ont pas le même environnement logiciel que vous. Avoir une bonne documentation ne suffit pas, tout comme décrire le workflow ou archiver l'historique des versions du code.

Plusieurs solutions existent pour gérer les dépendances logicielles. Par exemple, l'utilisation de « apt-get » sur les distributions Linux, ou l'utilisation de « pip » lors de travaux avec Python. Apt-get est un système de gestion de paquets qui permet l'installation, la mise à jour et la
Hadoop (Borthakur 2007). Chiron (Ogasawara et al. 2013) adopte une approche basée sur une base de données pour gérer l'exécution parallèle de workflows scientifiques intensifs en données. Il utilise un modèle algébrique et des opérateurs pour gérer les données et les activités du workflow. Chiron assure le suivi du workflow, gère différents types de parallélisme (par les données, indépendant, en pipeline) et propose une planification dynamique. Il stocke les informations d'exécution et de provenance dans une base de données structurée. Triana (Taylor et al. 2007) est un outil doté d'une interface graphique, développé initialement pour l'analyse de données dans le projet GEO 600. Triana est conçu pour les applications distribuées. Enfin, Snakemake est un moteur de workflow avancé offrant un langage de définition de workflow basé sur Python, facile à lire. Il permet une exécution flexible, allant d'un seul cœur à la distribution de calculs parallèles sur des clusters avec de nombreux cœurs, sans nécessiter de modifier le workflow. Cet outil est particulièrement réputé dans le domaine de la bioinformatique (Köster et Rahmann 2012).

Taverna, Chiron, Triana et Galaxy ont des fonctionnalités telles que l'interface graphique pour la conception des workflows, la prise en charge du parallélisme, la planification dynamique et l'exécution de workflows dans des environnements de grille de calcul et de cloud computing. Taverna prend en charge le partage d'informations sur les workflows, tandis que Galaxy se spécialise dans l'exécution de workflow en bioinformatique. Sequanix propose une interface graphique dynamique pour Snakemake (Desvillechabrol et al. 2018). Un état de l'art sur la gestion des systèmes de workflow est disponible (Liu et al. 2015), et un article sur les workflows plus axée sur les sciences de la vie a également été publiée en 2017 (Cohen-Boulakia et al. 2017), tandis que dans (Ivie et Thain 2018),
suppression facile de paquets logiciels. Il résout automatiquement les
dépendances, garantissant que toutes les bibliothèques et composants
logiciels nécessaires sont installés. Pip, quant à lui, est un installateur de
paquets pour Python qui simplifie la gestion des bibliothèques Python et
de leurs dépendances. Il permet aux utilisateurs d'installer, de mettre à jour
et de supprimer facilement des paquets Python à partir de l'Index des
paquets Python (PyPI). Mais ils nécessitent tous les deux l'installation
manuelle des paquets (même s'ils peuvent gérer par eux-mêmes les
dépendances entre ces paquets). Même si de tels outils sont bons lorsqu'ils
sont utilisés seuls, ils ne sont pas adaptés à la recherche reproductible. Le
langage Python est désormais adopté pour de nombreuses
expérimentations scientifiques. Il existe des outils spécifiques pour Python
tels que Conda, qui est un gestionnaire de paquets et d'environnements
couramment utilisé dans la communauté scientifique Python. Conda
permet l'installation à la fois de paquets Python et de paquets non-Python,
ce qui le rend utile pour gérer des environnements logiciels complexes avec
des dépendances qui vont au-delà des bibliothèques Python. Enfin, une
fonctionnalité plus avancée vous permet de créer un environnement
virtuel. Venv est un outil qui aide à créer des environnements Python
isolés. Il permet aux utilisateurs de créer des environnements distincts pour
différents projets, évitant ainsi les conflits entre les dépendances.
Lorsqu'un nouvel environnement virtuel est créé, il est livré avec sa propre
copie de l'interpréteur Python et une copie locale de l'outil pip. Cela
garantit que toutes les bibliothèques installées dans l'environnement virtuel
sont isolées de l'environnement Python global, ce qui facilite la gestion et
la reproduction des dépendances spécifiques au projet. Venv est
particulièrement utile lorsque l'on travaille sur plusieurs projets ou que l'on
teste différentes versions de bibliothèques.

Bien que des outils tels que apt-get, pip, Conda et Venv soient largement
utilisés et offrent des moyens pratiques de gérer les environnements
Ivie et Thain proposent un état de l'art plus général sur la gestion des workflows en recherche reproductible.

## 6.4. Environnement logiciel

### 6.4.1. Gérer les dépendances

Lorsque vous écrivez un programme, vous vous reposez toujours sur votre environnement logiciel. À la fin, lorsque vous publierez vos résultats, d'autres chercheurs pourraient rencontrer des obstacles pour relancer votre programme. Il se peut qu'ils ne puissent pas reproduire vos résultats car ils n'ont pas le même environnement logiciel que vous. Avoir une bonne documentation ne suffit pas, tout comme décrire le workflow ou archiver l'historique des versions du code.

Plusieurs solutions existent pour gérer les dépendances logicielles. Par exemple, l'utilisation de « apt-get » sur les distributions Linux, ou l'utilisation de « pip » lors de travaux avec Python. Apt-get est un système de gestion de paquets qui permet l'installation, la mise à jour et la suppression facile de paquets logiciels. Il résout automatiquement les dépendances, garantissant que toutes les bibliothèques et composants logiciels nécessaires sont installés. Pip, quant à lui, est un installateur de paquets pour Python qui simplifie la gestion des bibliothèques Python et de leurs dépendances. Il permet aux utilisateurs d'installer, de mettre à jour et de supprimer facilement des paquets Python à partir de l'Index des paquets Python (PyPI). Mais ils nécessitent tous les deux l'installation manuelle des paquets (même s'ils peuvent gérer par eux-mêmes les dépendances entre ces paquets). Même si de tels outils sont bons lorsqu'ils sont utilisés seuls, ils ne sont pas adaptés à la recherche reproductible. Le langage Python est désormais adopté pour de nombreuses expérimentations scientifiques. Il existe des outils spécifiques pour Python
logiciels et les dépendances, ils présentent des limites par rapport à des
outils plus spécifiques conçus pour la reproductibilité. Tout d'abord,
comme ils ne sont pas conçus pour la reproductibilité, la stabilité des
environnements logiciels peut être difficile à atteindre avec ces outils, car
les versions exactes et les configurations des paquets ne sont pas forcément
explicitement capturées. Cela peut entraîner une perte de reproductibilité.
Par exemple, si vous utilisez une bibliothèque telle que Pandas ou Numpy
en Python, les développeurs pourraient modifier certaines parties du code
sans changer le numéro de version, de sorte que des outils comme pip (et
ceux qui en dépendent) ne pourraient pas clairement identifier les deux
versions du code. Une autre faiblesse de ces outils est qu'ils nécessitent
souvent des privilèges d'administration pour installer des paquets à l'échelle
d'un système d'exploitation, ce qui n'est pas adapté à un environnement de
calcul à haute performance, où vous n'aurez pas les privilèges
administrateurs. Venv offre un certain niveau d'isolation, mais il se limite
aux bibliothèques Python uniquement.

Pour ces raisons, certains outils ont émergé pour fournir une solution
satisfaisante pour améliorer la reproductibilité de la partie
computationnelle d'un article de recherche. CDE (Guo et Engler 2011) est
un outil conçu pour résoudre les problèmes de dépendance. Il regroupe le
code, les données et l'environnement. Aucun accès root n'est nécessaire.
Voici comment fonctionne l'outil : il utilise ptrace et fait un paquetage
automatisé du code, des données et de l'environnement pour s'exécuter sur
une machine Linux. Un problème connu est qu'il pourrait ne pas inclure
toutes les dépendances, qui devraient être ajoutées manuellement. De plus,
il ne fonctionne qu'avec des noyaux Linux compatibles. Il fonctionne de la
manière suivante : Alice lance la commande « cde script.py data.dat ». Cette
action exécute le script Python, capture des informations via ptrace et crée
un répertoire « cde-package ». Alice compresse le répertoire et l'envoie à
Bob. Bob exécute ensuite la commande « cde-exec script.py data.dat ». Au
tels que Conda, qui est un gestionnaire de paquets et d'environnements couramment utilisé dans la communauté scientifique Python. Conda permet l'installation à la fois de paquets Python et de paquets non-Python, ce qui le rend utile pour gérer des environnements logiciels complexes avec des dépendances qui vont au-delà des bibliothèques Python. Enfin, une fonctionnalité plus avancée vous permet de créer un environnement virtuel. Venv est un outil qui aide à créer des environnements Python isolés. Il permet aux utilisateurs de créer des environnements distincts pour différents projets, évitant ainsi les conflits entre les dépendances. Lorsqu'un nouvel environnement virtuel est créé, il est livré avec sa propre copie de l'interpréteur Python et une copie locale de l'outil pip. Cela garantit que toutes les bibliothèques installées dans l'environnement virtuel sont isolées de l'environnement Python global, ce qui facilite la gestion et la reproduction des dépendances spécifiques au projet. Venv est particulièrement utile lorsque l'on travaille sur plusieurs projets ou que l'on teste différentes versions de bibliothèques.

Bien que des outils tels que apt-get, pip, Conda et Venv soient largement utilisés et offrent des moyens pratiques de gérer les environnements logiciels et les dépendances, ils présentent des limites par rapport à des outils plus spécifiques conçus pour la reproductibilité. Tout d'abord, comme ils ne sont pas conçus pour la reproductibilité, la stabilité des environnements logiciels peut être difficile à atteindre avec ces outils, car les versions exactes et les configurations des paquets ne sont pas forcément explicitement capturées. Cela peut entraîner une perte de reproductibilité. Par exemple, si vous utilisez une bibliothèque telle que Pandas ou Numpy en Python, les développeurs pourraient modifier certaines parties du code sans changer le numéro de version, de sorte que des outils comme pip (et ceux qui en dépendent) ne pourraient pas
lieu de rechercher des bibliothèques dans le chemin de Bob, cde-exec utilise
ptrace ou strace pour modifier l'utilisation des bibliothèques et utilise celles
stockées dans le dossier envoyé par Alice. Il peut y avoir une perte de
performance potentielle allant de 2% à 28%. Cette solution peut ne pas
être adaptée à un environnement HPC en raison de la perte potentielle de
performance. L'outil Sumatra (Davison 2012) améliore la recherche
reproductible en fournissant un système de capture automatisée des
métadonnées. La bibliothèque principale de Sumatra met en œuvre des
fonctionnalités telles que la capture de l'environnement matériel et logiciel,
la capture des données d'entrée et de sortie, et la capture du contexte
scientifique. Cette fonctionnalité de base peut être utilisée par différentes
interfaces qui couvrent les différentes méthodes de travail (ligne de
commande, interface graphique, etc.). Les outils Sumatra n'ont pas
nécessairement besoin de capturer toutes les informations pour être
efficaces, plus il y a d'informations enregistrées, plus il est facile de
reproduire les résultats à l'avenir. Sumatra est conçu pour être facile à
utiliser et ne pas ralentir le workflow habituel des scientifiques. Les outils
de Sumatra se composent d'une bibliothèque de base implémentée en
Python, d'un outil en ligne de commande et d'une interface basée sur un
navigateur web. L'outil en ligne de commande permet de capturer le
contexte de calcul, les entrées et les sorties, ainsi que de visualiser les calculs
précédents. L'interface basée sur un navigateur web offre des
fonctionnalités supplémentaires pour visualiser, rechercher et annoter les
enregistrements de calcul. De même que CDE, ReproZip (Chirigati et al.
2016) est un outil qui vise à rendre les expériences computationnelles
reproductibles sur différentes plates-formes et ceci longtemps après leur
création. Il capture automatiquement la provenance d'une expérience en
traçant les appels système, en utilisant ptrace, et utilise ces informations
pour créer un package reproductible léger qui inclut uniquement les fichiers
nécessaires à sa reproduction. ReproZip ajoute une fonctionnalité pour
clairement identifier les deux versions du code. Une autre faiblesse de ces
outils est qu'ils nécessitent souvent des privilèges d'administration pour
installer des paquets à l'échelle d'un système d'exploitation, ce qui n'est pas
adapté à un environnement de calcul à hautes performances, où vous
n'aurez pas les privilèges administrateurs. Venv offre un certain niveau
d'isolation, mais il se limite aux bibliothèques Python uniquement.

Pour ces raisons, certains outils ont émergé pour fournir une solution
satisfaisante pour améliorer la reproductibilité de la partie
computationnelle d'un article de recherche. CDE (Guo et Engler 2011) est
un outil conçu pour résoudre les problèmes de dépendance. Il regroupe le
code, les données et l'environnement. Aucun accès root n'est nécessaire.
Voici comment fonctionne l'outil : il utilise ptrace et fait un paquetage
automatisé du code, des données et de l'environnement pour s'exécuter
sur une machine Linux. Un problème connu est qu'il pourrait ne pas
inclure toutes les dépendances, qui devraient être ajoutées manuellement.
De plus, il ne fonctionne qu'avec des noyaux Linux compatibles. Il
fonctionne de la manière suivante: Alice lance la commande « cde script.py
data.dat ». Cette action exécute le script Python, capture des informations
via ptrace et crée un répertoire « cde-package ». Alice compresse le
répertoire et l'envoie à Bob. Bob exécute ensuite la commande « cde-exec
script.py data.dat ». Au lieu de rechercher des bibliothèques dans le chemin
de Bob, cde-exec utilise ptrace ou strace pour modifier l'utilisation des
bibliothèques et utilise celles stockées dans le dossier envoyé par Alice. Il
peut y avoir une perte de performance potentielle allant de 2% à 28%.
Cette solution peut ne pas être adaptée à un environnement HPC en raison
de la perte potentielle de performance. L'outil Sumatra (Davison 2012)
améliore la recherche reproductible en fournissant un système de capture
automatisée des métadonnées. La bibliothèque principale de Sumatra met
être compatible non seulement avec les systèmes Linux, mais aussi avec Windows ou MacOS. Ses limites concernent les environnements distribués, tels que les clusters MPI ou Hadoop. Cependant, ni Sumatra ni ReproZip ne fournissent une analyse des performances, comme le fait CDE. Comme ReproZip utilise ptrace de même que CDE, une hypothèse plausible serait que les performances devraient être similaires. En fin de compte, ces outils sont conçus pour la recherche reproductible, mais ne sont probablement pas adaptés au calcul à haute performance.

Étant donné que la manipulation de tels outils nécessite une phase d'apprentissage, l'objectif final serait de trouver un outil qui puisse être utilisé par le plus de monde possible et qui soit adapté au calcul à haute performance. Pour gérer les dépendances de bibliothèques, l'outil que nous recommandons est Guix (Courtès et Wurmus 2015). Guix est un outil de gestion de logiciels qui adopte une méthode fonctionnelle pour gérer les dépendances des logiciels. Selon cette méthode, les étapes de construction et d'installation des logiciels sont considérées comme des fonctions pures. Autrement dit, les résultats de ces étapes dépendent uniquement des données fournies en entrée. Cette technique permet de stocker efficacement les résultats sur le disque dur, assurant que les mêmes données d'entrée produiront toujours les mêmes résultats. Pour appliquer cette méthode, Guix exerce un contrôle rigoureux sur l'environnement de construction. Inspiré par Nix (Dolstra et al. 2004), Guix utilise un service système (daemon) avec des privilèges administrateurs pour créer des logiciels dans des conteneurs Linux isolés, notamment dans un environnement chroot. Ces conteneurs disposent de leurs propres identifiants utilisateurs et espaces de noms isolés pour différents aspects tels que la gestion des processus, la communication entre processus, le réseau, etc. L'environnement chroot se limite aux répertoires spécifiquement déclarés, empêchant ainsi l'accès à des outils ou bibliothèques non autorisés durant la construction. Les espaces de noms
en œuvre des fonctionnalités telles que la capture de l'environnement matériel et logiciel, la capture des données d'entrée et de sortie, et la capture du contexte scientifique. Cette fonctionnalité de base peut être utilisée par différentes interfaces qui couvrent les différentes méthodes de travail (ligne de commande, interface graphique, etc.). Les outils Sumatra n'ont pas nécessairement besoin de capturer toutes les informations pour être efficaces, plus il y a d'informations enregistrées, plus il est facile de reproduire les résultats à l'avenir. Sumatra est conçu pour être facile à utiliser et ne pas ralentir le workflow habituel des scientifiques. Les outils de Sumatra se composent d'une bibliothèque de base implémentée en Python, d'un outil en ligne de commande et d'une interface basée sur un navigateur web. L'outil en ligne de commande permet de capturer le contexte de calcul, les entrées et les sorties, ainsi que de visualiser les calculs précédents. L'interface basée sur un navigateur web offre des fonctionnalités supplémentaires pour visualiser, rechercher et annoter les enregistrements de calcul. De même que CDE, ReproZip (Chirigati et al. 2016) est un outil qui vise à rendre les expériences computationnelles reproductibles sur différentes plates-formes et ceci longtemps après leur création. Il capture automatiquement la provenance d'une expérience en traçant les appels système, en utilisant ptrace, et utilise ces informations pour créer un package reproductible léger qui inclut uniquement les fichiers nécessaires à sa reproduction. ReproZip ajoute une fonctionnalité pour être compatible non seulement avec les systèmes Linux, mais aussi avec Windows ou MacOS. Ses limites concernent les environnements distribués, tels que les clusters MPI ou Hadoop. Cependant, ni Sumatra ni ReproZip ne fournissent une analyse des performances, comme le fait CDE. Comme ReproZip utilise ptrace de même que CDE, une hypothèse plausible serait que les performances devraient être similaires. En fin de
isolés empêchent également toute communication avec l'extérieur durant
la construction. Les résultats de chaque construction sont enregistrés dans
un espace de stockage commun, habituellement situé dans /gnu/store.
Chaque élément dans ce stockage porte un nom comprenant un hash basé
sur toutes les données d'entrée utilisées lors de la construction. Ce hash
inclut non seulement les compilateurs et les bibliothèques, mais aussi les
scripts de construction et les variables d'environnement. Ce processus tient
compte de l'ensemble des dépendances de chaque logiciel, incluant
récursivement les outils et bibliothèques utilisés. Cette méthode garantit la
reproductibilité des constructions, permettant ainsi au système de retracer
l'intégralité du réseau de dépendances pour chaque logiciel construit.

Nous avons constaté que Guix est probablement le meilleur outil pour
gérer les dépendances. De plus, cet outil ne fournit pas seulement un fichier
« binaire » illisible à exécuter pour reproduire n'importe quel traitement
(mais dans ce cas, nous ne savons pas vraiment ce que nous exécutons),
mais il offre une vision claire et complète de l'environnement logiciel que
nous utilisons. Chaque version est identifiée par un hash unique, avec la
source disponible sur un dépôt en ligne Guix. Un tutoriel clair et facile à
utiliser a été proposé en 2023; il permet de produire des articles de
recherche reproductibles<fnref n="1" />. Nous recommandons la lecture de ce tutoriel.
Les inconvénients de Guix sont qu'il n'est pas encore très répandu sur les
clusters de calcul, et que le « daemon » s'exécutant en fond nécessite des
privilèges administrateurs, de sorte que la première configuration et
l'installation de Guix doivent être effectuées par un administrateur système
du cluster. Lorsque vous travaillez localement avec Guix, il vous permet, si
les futurs utilisateurs n'ont pas Guix, de générer une image Docker ou une
image Apptainer (nouveau nom du container Singularity adapté au calcul à
haute performance). Nous présenterons ces deux outils par la suite.

<footnote n="1">¹ https://hpc.guix.info/blog/2023/06/a-guide-to-reproducible-research-papers/-
dernier accès le 25/04/2024.</footnote>
compte, ces outils sont conçus pour la recherche reproductible, mais ne sont probablement pas adaptés au calcul à hautes performances.

Étant donné que la manipulation de tels outils nécessite une phase d'apprentissage, l'objectif final serait de trouver un outil qui puisse être utilisé par le plus de monde possible et qui soit adapté au calcul à hautes performances. Pour gérer les dépendances de bibliothèques, l'outil que nous recommandons est Guix (Courtès et Wurmus 2015). Guix est un outil de gestion de logiciels qui adopte une méthode fonctionnelle pour gérer les dépendances des logiciels. Selon cette méthode, les étapes de construction et d'installation des logiciels sont considérées comme des fonctions pures. Autrement dit, les résultats de ces étapes dépendent uniquement des données fournies en entrée. Cette technique permet de stocker efficacement les résultats sur le disque dur, assurant que les mêmes données d'entrée produiront toujours les mêmes résultats. Pour appliquer cette méthode, Guix exerce un contrôle rigoureux sur l'environnement de construction. Inspiré par Nix (Dolstra et al. 2004), Guix utilise un service système (daemon) avec des privilèges administrateurs pour créer des logiciels dans des conteneurs Linux isolés, notamment dans un environnement chroot. Ces conteneurs disposent de leurs propres identifiants utilisateurs et espaces de noms isolés pour différents aspects tels que la gestion des processus, la communication entre processus, le réseau, etc. L'environnement chroot se limite aux répertoires spécifiquement déclarés, empêchant ainsi l'accès à des outils ou bibliothèques non autorisés durant la construction. Les espaces de noms isolés empêchent également toute communication avec l'extérieur durant la construction. Les résultats de chaque construction sont enregistrés dans un espace de stockage commun, habituellement situé dans /gnu/store. Chaque élément dans ce stockage porte un nom comprenant un hash basé
### 6.4.2. Machines virtuelles

Pour rendre la partie informatique de vos recherches plus reproductible, un autre type d'outil existant est celui des machines virtuelles (VM). Une des premières mentions détaillées de ce concept remonte à une cinquantaine d'années (Goldberg 1974). Avec les machines virtuelles modernes, nous utilisons un hyperviseur comme plateforme de virtualisation permettant à plusieurs systèmes d'exploitation de fonctionner simultanément sur une seule machine physique. Il existe actuellement deux types d'hyperviseurs, comme décrit dans la figure 5, natifs et hébergés (hosted). L'hyperviseur natif, également connu sous le nom de « bare metal », est un logiciel qui s'exécute directement sur le matériel ; l'hyperviseur natif interagit directement avec le matériel de l'hôte, fournissant une plateforme sur laquelle plusieurs systèmes d'exploitation peuvent être exécutés par l'hyperviseur. Ce type d'hyperviseur est léger et optimisé pour le noyau de l'hôte. A contrario, l'hyperviseur hébergé est un logiciel qui s'exécute à l'intérieur d'un autre système d'exploitation.

Une machine virtuelle offre un système d'exploitation indépendant, spécialement conçu pour vos expérimentations. Cette isolation permet de capturer et de reproduire fidèlement tous les processus et paramètres impliqués dans vos recherches. Cette caractéristique est particulièrement utile pour permettre à d'autres chercheurs de reproduire vos expériences dans un environnement identique. Toutefois, l'usage de machines virtuelles peut entraîner une réduction des performances, ce qui peut être un frein pour les applications nécessitant une grande puissance de calcul. Malgré cela, pour la plupart des applications, les avantages de reproductibilité et d'isolation offerts par les machines virtuelles compensent largement ce désavantage. Dans (Stodden et al. 2013), les auteurs mentionnent VirtualBox et VMWare comme outils permettant la création et l'utilisation
sur toutes les données d'entrée utilisées lors de la construction. Ce hash inclut non seulement les compilateurs et les bibliothèques, mais aussi les scripts de construction et les variables d'environnement. Ce processus tient compte de l'ensemble des dépendances de chaque logiciel, incluant récursivement les outils et bibliothèques utilisés. Cette méthode garantit la reproductibilité des constructions, permettant ainsi au système de retracer l'intégralité du réseau de dépendances pour chaque logiciel construit.

Nous avons constaté que Guix est probablement le meilleur outil pour gérer les dépendances. De plus, cet outil ne fournit pas seulement un fichier « binaire » illisible à exécuter pour reproduire n'importe quel traitement (mais dans ce cas, nous ne savons pas vraiment ce que nous exécutons), mais il offre une vision claire et complète de l'environnement logiciel que nous utilisons. Chaque version est identifiée par un hash unique, avec la source disponible sur un dépôt en ligne Guix. Un tutoriel clair et facile à utiliser a été proposé en 2023, il permet de produire des articles de recherche reproductibles<fnref n="1" />. Nous recommandons la lecture de ce tutoriel. Les inconvénients de Guix sont qu'il n'est pas encore très répandu sur les clusters de calcul, et que le « daemon » s'exécutant en fond nécessite des privilèges administrateurs, de sorte que la première configuration et l'installation de Guix doivent être effectuées par un administrateur système du cluster. Lorsque vous travaillez localement avec Guix, il vous permet, si les futurs utilisateurs n'ont pas Guix, de générer une image Docker ou une image Apptainer (nouveau nom du container Singularity adapté au calcul à hautes performances). Nous présenterons ces deux outils par la suite.

<footnote n="1">¹ https://hpc.guix.info/blog/2023/06/a-guide-to-reproducible-research-papers/-
dernier accès le 25/04/2024.</footnote>
de machines virtuelles pour la recherche reproductible. De même dans
(Ruiz et al. 2014). Ces deux outils utilisent le deuxième type d'hyperviseur
(hosted) qui est beaucoup plus facile à utiliser (la facilité d'utilisation étant
un critère important pour la recherche reproductible). Mais cela peut aussi
entraîner plus de perte de performance (ce qui n'est pas adapté au HPC).
Certaines publications étudient les performances de la virtualisation de type
1, tandis que d'autres se penchent sur le type 2, souvent dans le contexte
de l'informatique en nuage (ou « cloud computing »). Dans ce contexte, les
machines virtuelles sont omniprésentes pour fournir un système
d'exploitation utilisable à de nombreuses personnes en se basant sur le
même matériel sous-jacent. Le but principal n'est donc pas ici la recherche
reproductible, mais simplement proposer de l'accès à des machines via le
« cloud ».

Concernant les hyperviseurs de type 1, Gilbert et al. (2005) évaluent les
performances de la virtualisation dans le contexte des applications de
physique de hautes énergies au CERN dans un environnement de grille de
calcul. Leurs résultats ont montré que la virtualisation peut avoir jusqu'à 15
% de perte de performance par rapport au temps d'exécution. Ils
travaillaient avec un hyperviseur de type 1, ESX VMware. Dans (Matthews
et al. 2007), les auteurs n'ont pas trouvé que des outils de virtualisation tels
que Xen ou VMware génèrent une perte de performance, tandis que dans
(Padala et al. 2007), les auteurs trouvent que Xen génère beaucoup de perte
de performance, probablement en raison d'un nombre plus élevé de perte
de données dans le cache de niveau 2 (L2 cache miss). Dans (Acharya et al.
2018), leurs résultats montrent que sur les processeurs x86, l'hyperviseur
(en utilisant KVM) fonctionne moins bien que d'autres technologies.
Cependant, ce n'est pas le cas sur les processeurs ARM.
### 6.4.2. Machines virtuelles

Pour rendre la partie informatique de vos recherches plus reproductible, un autre type d'outil existant est celui des machines virtuelles (VM). Une des premières mentions détaillées de ce concept remonte à une cinquantaine d'années (Goldberg 1974). Avec les machines virtuelles modernes, nous utilisons un hyperviseur comme plateforme de virtualisation permettant à plusieurs systèmes d'exploitation de fonctionner simultanément sur une seule machine physique. Il existe actuellement deux types d'hyperviseurs, comme décrit dans la Figure 5, natifs et hébergé (hosted). L'hyperviseur natif, également connu sous le nom de « bare metal », est un logiciel qui s'exécute directement sur le matériel; l'hyperviseur natif interagit directement avec le matériel de l'hôte, fournissant une plateforme sur laquelle plusieurs systèmes d'exploitation peuvent être exécutés par l'hyperviseur. Ce type d'hyperviseur est léger et optimisé pour le noyau de l'hôte. A contrario, l'hyperviseur hébergé est un logiciel qui s'exécute à l'intérieur d'un autre système d'exploitation.

Une machine virtuelle offre un système d'exploitation indépendant, spécialement conçu pour vos expérimentations. Cette isolation permet de capturer et de reproduire fidèlement tous les processus et paramètres impliqués dans vos recherches. Cette caractéristique est particulièrement utile pour permettre à d'autres chercheurs de reproduire vos expériences dans un environnement identique. Toutefois, l'usage de machines virtuelles peut entraîner une réduction des performances, ce qui peut être un frein pour les applications nécessitant une grande puissance de calcul. Malgré cela, pour la plupart des applications, les avantages de reproductibilité et d'isolation offerts par les machines virtuelles compensent largement ce désavantage. Dans (Stodden et al. 2013), les auteurs mentionnent VirtualBox et VMWare comme outils permettant la
<figure><img src="image_7.png" /><figcaption>**Figure 5.** *Hyperviseur type 1 et hyperviseur type 2*</figcaption></figure>

Tous les articles cités précédemment évaluent les performances des hyperviseurs natif (type 1). Et nous pouvons constater que ce n'est probablement pas une solution adaptée pour le calcul à haute performance en raison de la perte de performance induite par leur utilisation, mais ce n'est également pas adapté à la recherche reproductible en raison de sa complexité de mise en place. Nous n'avons trouvé aucun article sur la recherche reproductible évoquant l'utilisation des technologies et outils des hyperviseurs de type 1. Cependant, pour les hyperviseurs hébergés (type 2), tels que VirtualBox et VMware (dans sa version hébergée), il existe des publications du monde de la recherche reproductible qui évoquent leur utilisation pour rendre les articles plus facilement reproductibles.

Dans (Đorđević et al. 2021), un article récent de 2021, les auteurs étudient les performances de VirtualBox par rapport à une exécution native, et concluent que « en ce qui concerne VirtualBox, la chute de performance est notable ». Dans (Beserra et al. 2015), les auteurs se situent
création et l'utilisation de machines virtuelles pour la recherche reproductible. De même dans (Ruiz et al. 2014). Ces deux outils utilisent le deuxième type d'hyperviseur (hosted) qui est beaucoup plus facile à utiliser (la facilité d'utilisation étant un critère important pour la recherche reproductible). Mais celui peut aussi entraîner plus de perte de performance (ce qui n'est pas adapté au HPC). Certaines publications étudient les performances de la virtualisation de type 1, tandis que d'autres se penchent sur le type 2, souvent dans le contexte de l'informatique en nuage (ou « cloud computing »). Dans ce contexte, les machines virtuelles sont omniprésentes pour fournir un système d'exploitation utilisable à de nombreuses personnes en se basant sur le même matériel sous-jacent. Le but principal n'est donc pas ici la recherche reproductible, mais simplement proposer de l'accès à des machines via le « cloud ».

Concernant les hyperviseurs de type 1, Gilbert et al. (2005) évaluent les performances de la virtualisation dans le contexte des applications de physique de hautes énergies au CERN dans un environnement de grille de calcul. Leurs résultats ont montré que la virtualisation peut avoir jusqu'à 15 % de perte de performance par rapport au temps d'exécution. Ils travaillaient avec un hyperviseur de type 1, ESX VMware. Dans (Matthews et al. 2007), les auteurs n'ont pas trouvé que des outils de virtualisation tels que Xen ou VMware génèrent une perte de performance, tandis que dans (Padala et al. 2007), les auteurs trouvent que Xen génère beaucoup de perte de performance, probablement en raison d'un nombre plus élevé de perte de données dans le cache de niveau 2 (L2 cache miss). Dans (Acharya et al. 2018), leurs résultats montrent que sur les processeurs x86, l'hyperviseur (en utilisant KVM) fonctionne moins bien que d'autres technologies. Cependant, ce n'est pas le cas sur les processeurs ARM.
dans le contexte du calcul haute performance, contrairement aux travaux
précédents. Ils ont cherché à analyser les performances de KVM
(hyperviseur de type 1) et de VirtualBox (hyperviseur de type 2). Pour le
traitement, ils ont effectué trois tests différents (HPL, DGEMM et FTT).
Sur le premier, KVM a atteint des performances proches des performances
natives et a obtenu 14% de performance de plus que VirtualBox. Sur le
deuxième, KVM a eu des performances 5% inférieures à une exécution
native, mais a performé 10% mieux que VirtualBox. Sur le troisième test
(FFT), KVM et la performance native ont performé 30% mieux que
VirtualBox. En ce qui concerne l'accès à la mémoire, VirtualBox a
performé environ 25% moins bien que KVM et l'exécution native. Dans
l'ensemble, on peut clairement voir que les hyperviseurs de type 2 ne
conviennent pas au calcul à haute performance. Un document fusionnant
l'utilisation de la virtualisation et du cloud computing dans le cadre de la
recherche reproductible a été proposé par Bill Howe (2012). Il a proposé
d'utiliser les services d'Amazon pour collaborer via le cloud. Cependant,
l'utilisation d'une entreprise privée en tant que tiers n'est pas toujours
adaptée à la science ouverte internationale.

Un autre inconvénient de l'utilisation de machines virtuelles pour la
recherche reproductible est leur opacité et leur demande en ressources. La
distribution de gros fichiers de machines virtuelles sur les réseaux peut être
fastidieuse, et le contenu d'une machine virtuelle reste obscur jusqu'à son
exécution. Bien qu'elles permettent une certaine reproductibilité, les
machines virtuelles ne sont pas optimales en termes de passage à l'échelle,
d'adaptabilité et de performance, engendrant par ce dernier aspect un coût
énergétique supplémentaire dans le contexte où cette consommation est
très sensible (calcul intensif).
<figure><img src="image_7.png" /><figcaption>**Figure 5.** *Hyperviseur type 1 et hyperviseur type 2*</figcaption></figure>

Tous les articles cités précédemment évaluent les performances des hyperviseurs natif (type 1). Et nous pouvons constater que ce n'est probablement pas une solution adaptée pour le calcul à hautes performances en raison de la perte de performance induite par leur utilisation, mais ce n'est également pas adapté à la recherche reproductible en raison de sa complexité de mise en place. Nous n'avons trouvé aucun article sur la recherche reproductible évoquant l'utilisation des technologies et outils des hyperviseurs de type 1. Cependant, pour les hyperviseurs hébergés (type 2), tels que VirtualBox et VMware (dans sa version hébergée), il existe des publications du monde de la recherche reproductible qui évoquent leur utilisation pour rendre les articles plus facilement reproductibles.

Dans (Dorđević et al. 2021), un article récent de 2021, les auteurs étudient les performances de VirtualBox par rapport à une exécution native, et concluent que « en ce qui concerne VirtualBox, la chute de performance est notable ». Dans (Beserra et al. 2015), les auteurs se situent dans le contexte du calcul haute performance, contrairement aux travaux précédents. Ils ont cherché à analyser les performances de KVM
### 6.4.3. Conteneurs

Les conteneurs sont un autre type de virtualisation plus léger que les machines virtuelles et qui fonctionne au niveau du système d'exploitation. Les conteneurs et les technologies de virtualisation matérielles sont similaires en ce qu'ils permettent à plusieurs applications isolées de s'exécuter sur une seule machine hôte. Cependant, il existe des différences significatives dans la manière dont ils y parviennent. La virtualisation matérielle implique l'exécution d'un système d'exploitation complet dans un environnement isolé. Cela nécessite une quantité importante de ressources, notamment de la mémoire et de l'espace de stockage. Le démarrage d'un système d'exploitation invité peut prendre plusieurs minutes. En revanche, les conteneurs partagent le noyau sous-jacent du système d'exploitation hôte et isolent les processus s'exécutant à l'intérieur de ceux-ci des autres processus s'exécutant sur l'hôte. Cela signifie que les conteneurs utilisent directement les fonctionnalités de l'hôte, ce qui se traduit par une utilisation plus efficace des ressources. Plusieurs conteneurs peuvent être exécutés sur un seul hôte, et le démarrage d'un nouveau conteneur est rapide, similaire au démarrage d'une application native. Les conteneurs sont donc en quelque sorte des paquets autonomes et légers qui incluent une application et toutes ses dépendances, partageant le noyau du système d'exploitation hôte. Comparés aux machines virtuelles, ils sont beaucoup plus petits et plus efficaces en termes de ressources, ce qui permet un démarrage rapide avec une utilisation réduite des ressources. Ils ont été initialement conçus pour un déploiement consistant dans divers environnements, du développement à la mise en production. Les conteneurs offrent une solution plus efficace et légère pour l'exécution d'applications isolées que la virtualisation traditionnelle évoquée précédemment.
(hyperviseur de type 1) et de VirtualBox (hyperviseur de type 2). Pour le traitement, ils ont effectué trois tests différents (HPL, DGEMM et FTT). Sur le premier, KVM a atteint des performances proches des performances natives et a obtenu 14% de performance de plus que VirtualBox. Sur le deuxième, KVM a eu des performances 5% inférieures à une exécution native, mais a performé 10% mieux que VirtualBox. Sur le troisième test (FFT), KVM et la performance native ont performé 30% mieux que VirtualBox. En ce qui concerne l'accès à la mémoire, VirtualBox a performé environ 25% moins bien que KVM et l'exécution native. Dans l'ensemble, on peut clairement voir que les hyperviseurs de type 2 ne conviennent pas au calcul à hautes performances. Un document fusionnant l'utilisation de la virtualisation et du cloud computing dans le cadre de la recherche reproductible a été proposé par Bill Howe (Howe 2012). Il a proposé d'utiliser les services d'Amazon pour collaborer via le cloud. Cependant, l'utilisation d'une entreprise privée en tant que tiers n'est pas toujours adaptée à la science ouverte internationale.

Un autre inconvénient de l'utilisation de machines virtuelles pour la recherche reproductible est leur opacité et leur demande en ressources. La distribution de gros fichiers de machines virtuelles sur les réseaux peut être fastidieuse, et le contenu d'une machine virtuelle reste obscur jusqu'à son exécution. Bien qu'elles permettent une certaine reproductibilité, les machines virtuelles ne sont pas optimales en termes de passage à l'échelle, d'adaptabilité et de performance, engendrant par ce dernier aspect un coût énergétique supplémentaire dans le contexte où cette consommation est très sensible (calcul intensif).
Actuellement, les conteneurs sont une des solutions les plus plébiscitées pour assurer la reproductibilité dans les articles de recherche utilisant des outils informatiques. Les conteneurs encapsulent une application et ses dépendances dans une unité autonome, légère et portable. Ces conteneurs fournissent un environnement isolé pour exécuter des applications sur différents systèmes d’exploitation et environnements informatiques, garantissant un comportement cohérent et la reproductibilité des résultats, de manière similaire à ce qui a été obtenu avec les machines virtuelles, mais de manière plus efficace (Boettiger 2015).

La première technologie de conteneurisation étudiée est Docker (Merkel 2014). Plusieurs articles ont plaidé en faveur de Docker dans le cadre de la recherche reproductible (Boettiger 2015; Nüst et al. 2020). Étant donné que Docker était la première technologie étudiée, elle a été comparée à la virtualisation basée sur un hyperviseur concernant le partage de l'environnement logiciel. Dans (Felter et al. 2015), les auteurs ont travaillé avec Kernel Virtual Machine (KVM) (Kivity et al. 2007), qui est un hyperviseur de type 1 souvent étudié. Ils ont exécuté le benchmark Linpack sur Linux natif, Docker et KVM. Une exécution de Linpack passe la majeure partie de son temps à effectuer des opérations mathématiques en virgule flottante. Les performances étaient presque identiques sur Linux et Docker, mais les performances de KVM étaient nettement moins bonnes. Ils ont effectué plusieurs tests différents, pas seulement des opérations arithmétiques en virgule flottante, et ont conclu que Docker égalait ou dépassait les performances de KVM dans tous les cas. Chae et al. (2019) ont comparé Docker à KVM, et leurs résultats montrent que Docker est plus rapide que KVM, en constatant que Docker performe mieux que KVM en termes d'utilisation du CPU, du disque dur et de la RAM. Rad et al. (2017) ont également constaté que Docker performe mieux que les machines virtuelles. Une fois de plus, dans (Chung et al. 2016), les auteurs ont constaté que Docker génère moins de surcharge que les machines
### 6.4.3. Conteneurs

Les conteneurs sont un autre type de virtualisation plus léger que les machines virtuelles et qui fonctionne au niveau du système d'exploitation. Les conteneurs et les technologies de virtualisation matérielles sont similaires en ce qu'ils permettent à plusieurs applications isolées de s'exécuter sur une seule machine hôte. Cependant, il existe des différences significatives dans la manière dont ils y parviennent. La virtualisation matérielle implique l'exécution d'un système d'exploitation complet dans un environnement isolé. Cela nécessite une quantité importante de ressources, notamment de la mémoire et de l'espace de stockage. Le démarrage d'un système d'exploitation invité peut prendre plusieurs minutes. En revanche, les conteneurs partagent le noyau sous-jacent du système d'exploitation hôte et isolent les processus s'exécutant à l'intérieur de ceux-ci des autres processus s'exécutant sur l'hôte. Cela signifie que les conteneurs utilisent directement les fonctionnalités de l'hôte, ce qui se traduit par une utilisation plus efficace des ressources. Plusieurs conteneurs peuvent être exécutés sur un seul hôte, et le démarrage d'un nouveau conteneur est rapide, similaire au démarrage d'une application native. Les conteneurs sont donc en quelque sorte des paquets autonomes et légers qui incluent une application et toutes ses dépendances, partageant le noyau du système d'exploitation hôte. Comparés aux machines virtuelles, ils sont beaucoup plus petits et plus efficaces en termes de ressources, ce qui permet un démarrage rapide avec une utilisation réduite des ressources. Ils ont été initialement conçus pour un déploiement consistant dans divers environnements, du développement à la mise en production. Les conteneurs offrent une solution plus efficace et légère pour l'exécution d'applications isolées que la virtualisation traditionnelle évoquée précédemment.
virtuelles. Potdar et al. (2020) ont comparé Docker et les machines virtuelles en termes de performances CPU, de débit mémoire, d'E/S disque, de test de charge et de mesure de vitesse d'opération, et ont observé que Docker performe mieux que les machines virtuelles dans tous les tests.
Ruiz et al. (2015) confirme également que les technologies de virtualisation utilisant des conteneurs performent mieux.

À partir de cet ensemble d'études, nous constatons que les conteneurs comme Docker sont de meilleurs outils à utiliser que les machines virtuelles dans le contexte de la recherche reproductible. Cependant, nous n'avons pas encore répondu à la question de savoir si Docker induit une surcharge de performance par rapport à l'exécution native, et s'il convient au contexte du calcul à haute performance, c'est donc ce que nous abordons ci-après.

Bien que Docker puisse sembler être une bonne option, il ne convient pas au calcul à haute performance. La première raison est que Docker nécessite des privilèges administrateur. Au sein des clusters de calcul, aucun utilisateur ne devrait avoir de privilèges administrateur. Pour cette raison, Docker n'est pas utilisable dans un contexte de calcul à haute performance. Le deuxième point est que nous avons trouvé des mentions de préoccupations en matière de sécurité dans diverses études sur Docker (Jacobsen et Canon 2015 ; Priedhorsky et Randles 2017 ; Zhou et al. 2022).

D'autres conteneurs ont été développés pour pouvoir être utilisés dans le contexte du calcul à haute performance : Charliecloud (Priedhorsky et Randles 2017), Shifter (Gerhardt et al. 2017), Singularity (Kurtzer et al. 2017) (renommé Apptainer), Sarus (Benedicic et al. 2019) et Podman (Gantikow et al. 2020). Charliecloud exécute des conteneurs sans nécessiter de droit administrateur ou de « daemon ». Il convertit les images Docker en fichiers tar et les décompresse sur les nœuds HPC. Il est considéré sécurisé et supporte également MPI, une norme pour la communication entre les processus dans les systèmes parallèles. De plus, Charliecloud offre une solution pour les problèmes de compatibilité des bibliothèques
Actuellement, les conteneurs sont une des solutions les plus plébiscitées pour assurer la reproductibilité dans les articles de recherche utilisant une partie informatique. Les conteneurs encapsulent une application et ses dépendances dans une unité autonome, légère et portable. Ces conteneurs fournissent un environnement isolé pour exécuter des applications sur différents systèmes d'exploitation et environnements informatiques, garantissant un comportement cohérent et la reproductibilité des résultats, de manière similaire à ce qui a été obtenu avec les machines virtuelles, mais de manière plus efficace (Boettiger 2015).

La première technologie de conteneurisation étudiée est Docker (Merkel 2014). Plusieurs articles ont plaidé en faveur de Docker dans le cadre de la recherche reproductible (Boettiger 2015; Nüst et al. 2020). Étant donné que Docker était la première technologie étudiée, elle a été comparée à la virtualisation basée sur un hyperviseur concernant le partage de l'environnement logiciel. Dans (Felter et al. 2015), les auteurs ont travaillé avec Kernel Virtual Machine (KVM) (Kivity et al. 2007), qui est un hyperviseur de type 1 souvent étudié. Ils ont exécuté le benchmark Linpack sur Linux natif, Docker et KVM. Une exécution de Linpack passe la majeure partie de son temps à effectuer des opérations mathématiques en virgule flottante. Les performances étaient presque identiques sur Linux et Docker, mais les performances de KVM étaient nettement moins bonnes. Ils ont effectué plusieurs tests différents, pas seulement des opérations arithmétiques en virgule flottante, et ont conclu que Docker égalait ou dépassait les performances de KVM dans tous les cas. Chae et al. (2019) ont comparé Docker à KVM, et leurs résultats montrent que Docker est plus rapide que KVM, en constatant que Docker performe mieux que KVM en termes d'utilisation du CPU, du disque dur et de la
logicielles. Il le fait en intégrant des fichiers provenant du système hôte directement dans les images de conteneurs. Cette méthode assure une meilleure compatibilité des applications en conteneur avec l'environnement dans lequel elles sont exécutées. Shifter est un moteur de conteneurs pour le calcul haute performance (HPC) créé par NERSC. Il utilise Docker pour construire des images, les transformant en format « ext4 » puis les compressant en « squashfs» pour le stockage sur des systèmes de fichiers parallèles. Il prend en charge MPI et gère la compatibilité des pilotes GPU en remplaçant le pilote GPU au démarrage du conteneur. Apptainer est un outil populaire dans l'enseignement supérieur et l'industrie pour le HPC. Il fonctionne sans privilèges administrateur et ne requiert pas de processus « daemon », supportant les GPU, MPI, et particulièrement la technologie InfiniBand, essentielle pour l'interconnexion dans les systèmes HPC. Apptainer permet l'exécution portable d'applications via un fichier image unique au format SIF et propose des modèles hybrides pour les applications MPI. Sarus, un autre moteur de conteneurs HPC, s'appuie sur « runc » pour créer des conteneurs conformément à la spécification Open Container Initiative (OCI). Il se compose d'un répertoire de système de fichiers racine et d'un fichier de configuration JSON. Podman exécute des conteneurs sans élévation des privilèges, en utilisant l'espace de noms utilisateur. Il prend en charge le même runtime que Sarus et Docker (runc), ainsi que le runtime plus rapide crun. Il introduit le concept de pod pour regrouper des conteneurs pour des applications complexes. Toutes ces technologies reposent sur une fonctionnalité de base de Linux appelée Linux Containers (LXC) (Senthil Kumaran 2017).

La recherche a montré qu'aucun des conteneurs (virtualisation au niveau du système d'exploitation), n'induit une surcharge significative (n'affecte pas négativement les performances) ou a au moins des performances proches de celles d'une exécution native. Younge et al. (2017)
RAM. Rad *et al.* (2017) ont également constaté que Docker performe mieux que les machines virtuelles. Une fois de plus, dans (Chung *et al.* 2016), les auteurs ont constaté que Docker génère moins de surcharge que les machines virtuelles. Potdar *et al.* (2020) ont comparé Docker et les machines virtuelles en termes de performances CPU, de débit mémoire, d'E/S disque, de test de charge et de mesure de vitesse d'opération, et ont observé que Docker performe mieux que les machines virtuelles dans tous les tests. Ruiz *et al.* (2015) confirme également que les technologies de virtualisation utilisant des conteneurs performent mieux.

À partir de cet ensemble d'études, nous constatons que les conteneurs comme Docker sont de meilleurs outils à utiliser que les machines virtuelles dans le contexte de la recherche reproductible. Cependant, nous n'avons pas encore répondu à la question de savoir si Docker induit une surcharge de performance par rapport à l'exécution native, et s'il convient au contexte du calcul à hautes performances, c'est donc ce que nous abordons ci-après.

Bien que Docker puisse sembler être une bonne option, il ne convient pas au calcul à hautes performances. La première raison est que Docker nécessite des privilèges administrateur. Au sein des clusters de calcul, aucun utilisateur ne devrait avoir de privilèges administrateur. Pour cette raison, Docker n'est pas utilisable dans un contexte de calcul à hautes performances. Le deuxième point est que nous avons trouvé des mentions de préoccupations en matière de sécurité dans diverses études sur Docker (Jacobsen et Canon 2015; Priedhorsky et Randles 2017; Zhou *et al.* 2022).

D'autres conteneurs ont été développés pour pouvoir être utilisé dans le contexte du calcul à hautes performances : Charliecloud (Priedhorsky et Randles 2017), Shifter (Gerhardt et al. 2017), Singularity (Kurtzer et al. 2017) (renommé Apptainer), Sarus (Benedicic et al. 2019) et Podman
montre que Singularity fonctionne à des performances natives dans le cadre
du calcul à haute performance. Xavier et al. (2013) montre que la
virtualisation LXC offre des performances natives. Une étude plus
complète de 2019 (Torrez et al. 2019) a étudié les performances de Shifter,
Charliecloud et Singularity. Ils n'ont trouvé aucune différence significative
de performances entre les trois environnements et l'exécution native, à
l'exception possible d'une légère variation de l'utilisation de la mémoire.
Young et al. (2018) ont étudié les performances de Singularity et Docker,
et les résultats montrent que Singularity n'entraîne aucune perte de
performance, mais Docker entraîne une légère dégradation. Hale et al.
(2017) ainsi que Le et Paz (2017) confirment également que Singularity
n'entraîne aucune perte de performance. Abraham et al. (2020) étudie
davantage le débit d'entrée/sortie sur Docker, Charliecloud, Singularity et
Podman sur un système de fichiers Lustre (un système de fichiers distribué
utilisé dans des environnements de calcul à haute performance au-delà de
40 nœuds). Les résultats « montrent une surcharge de temps de démarrage
pour Docker et Podman, ainsi qu'une surcharge réseau au démarrage pour
Singularity et Charliecloud. Nos évaluations d'E/S montrent qu'avec une
parallélisation croissante, Charliecloud génère une surcharge importante
sur le Metadata Server (MDS) et le Object storage server (OSS) de Lustre.
De plus, nous constatons que le débit observé des conteneurs sur Lustre
est comparable à celui des conteneurs exécutés à partir du stockage local ».
Casalicchio et Perciballi (2017) ont constaté une légère surcharge pour
Docker, d'environ 5 % à 10 % pour la charge CPU et de 10 % à 30 % de
surcharge d'E/S disque. Axés sur des scénarios de calcul à haute
performance, Hu et al. (2019) n'ont trouvé aucune surcharge pour
Singularity sur les applications parallèles MPI et GPU.

Sur la base de ces connaissances, nous constatons que Apptainer
(Singularity) et d'autres technologies de conteneurs, à l'exception de
Docker, conviennent au calcul haute performance et à la recherche
(Gantikow et al. 2020). Charliecloud exécute des conteneurs sans nécessiter de droit administrateur ou de « daemon ». Il convertit les images Docker en fichiers tar et les décompresse sur les nœuds HPC. Il est considéré sécurisé et supporte également MPI, une norme pour la communication entre les processus dans les systèmes parallèles. De plus, Charliecloud offre une solution pour les problèmes de compatibilité des bibliothèques logicielles. Il le fait en intégrant des fichiers provenant du système hôte directement dans les images de conteneurs. Cette méthode assure une meilleure compatibilité des applications en conteneur avec l'environnement dans lequel elles sont exécutées. Shifter est un moteur de conteneurs pour le calcul haute performance (HPC) créé par NERSC. Il utilise Docker pour construire des images, les transformant en format « ext4 » puis les compressant en « squashfs» pour le stockage sur des systèmes de fichiers parallèles. Il prend en charge MPI et gère la compatibilité des pilotes GPU en remplaçant le pilote GPU au démarrage du conteneur. Apptainer est un outil populaire dans l'enseignement supérieur et l'industrie pour le HPC. Il fonctionne sans privilèges administrateur et ne requiert pas de processus « daemon », supportant les GPU, MPI, et particulièrement la technologie InfiniBand, essentielle pour l'interconnexion dans les systèmes HPC. Apptainer permet l'exécution portable d'applications via un fichier image unique au format SIF et propose des modèles hybrides pour les applications MPI. Sarus, un autre moteur de conteneurs HPC, s'appuie sur « runc » pour créer des conteneurs conformément à la spécification Open Container Initiative (OCI). Il se compose d'un répertoire de système de fichiers racine et d'un fichier de configuration JSON. Podman exécute des conteneurs sans élévation des privilèges, en utilisant l'espace de noms utilisateur. Il prend en charge le même runtime que Sarus et Docker (runc), ainsi que le
reproductible. Nous pensons qu'Apptainer est la meilleure solution à
utiliser et à apprendre actuellement, car il est l'outil le plus répandu sur les
clusters de calcul. Cependant, comme Apptainer a récemment changé
(évolution à partir de Singularity), une étude à jour pourrait être utile pour
confirmer qu'Apptainer reste parfaitement adapté aux performances
natives ou proches de celles-ci.

Un inconvénient des conteneurs est qu'ils sont initialement conçus pour
le déploiement, et non pour l'archivage. Bien qu'il soit possible de créer un
Dockerfile qui spécifie les étapes exactes pour construire une image de
conteneur, il n'y a toujours aucune garantie que l'image résultante sera
entièrement reproductible. Cela signifie que même si deux personnes
utilisent le même Dockerfile, elles peuvent obtenir des images de conteneur
légèrement différentes. Une des raisons de ce manque de reproductibilité
est que les images de conteneurs sont des binaires, ce qui signifie qu'elles
sont compilées et non facilement lisibles ou modifiables. Cela rend difficile
la compréhension de toutes les dépendances et configurations à l'intérieur
d'une image de conteneur. Si quelqu'un souhaite reproduire les calculs
effectués à l'intérieur d'un conteneur, il devrait recréer l'environnement de
conteneur exact. Cependant, en raison de la non-reproductibilité des
images de conteneurs, ce processus peut ne pas donner des résultats
identiques. Par conséquent, bien que les conteneurs soient efficaces pour
le déploiement d'applications, ils peuvent ne pas être la solution idéale pour
obtenir une reproductibilité totale dans le contexte de la recherche
scientifique. Cependant, dans la pratique, les conteneurs sont les outils les
plus utilisés et restent adaptés à la recherche reproductible. Comme
mentionné précédemment, Guix pourrait actuellement être la meilleure
solution que nous connaissons pour la reproductibilité computationnelle.
Des états de l'art complets des conteneurs pour le calcul à haute
performance ont été récemment publiés en 2022 et 2023, respectivement
(Zhou et al. 2022) et (Keller Tesser et Borin 2023).
runtime plus rapide crun. Il introduit le concept de pod pour regrouper des conteneurs pour des applications complexes. Toutes ces technologies reposent sur une fonctionnalité de base de Linux appelée Linux Containers (LXC) (Senthil Kumaran 2017).

La recherche a montré qu'aucun des conteneurs (virtualisation au niveau du système d'exploitation), n'induit une surcharge significative (n'affecte pas négativement les performances) ou a au moins des performances proches de celles d'une exécution native. Younge et al. (2017) montre que Singularity fonctionne à des performances natives dans le cadre du calcul à hautes performances. Xavier et al. (2013) montre que la virtualisation LXC offre des performances natives. Une étude plus complète de 2019 (Torrez et al. 2019) a étudié les performances de Shifter, Charliecloud et Singularity. Ils n'ont trouvé aucune différence significative de performances entre les trois environnements et l'exécution native, à l'exception possible d'une légère variation de l'utilisation de la mémoire. Young et al. (2018) ont étudié les performances de Singularity et Docker, et les résultats montrent que Singularity n'entraîne aucune perte de performance, mais Docker entraîne une légère dégradation. Hale et al. (2017) ainsi que Le et Paz (2017) confirment également que Singularity n'entraîne aucune perte de performance. Abraham et al. (2020) étudie davantage le débit d'entrée/sortie sur Docker, Charliecloud, Singularity et Podman sur un système de fichiers Lustre (un système de fichiers distribué utilisé dans des environnements de calcul à hautes performances au-delà de 40 nœuds). Les résultats « montrent une surcharge de temps de démarrage pour Docker et Podman, ainsi qu'une surcharge réseau au démarrage pour Singularity et Charliecloud. Nos évaluations d'E/S montrent qu'avec une parallélisation croissante, Charliecloud génère une surcharge importante sur le Metadata Server (MDS) et le Object storage
## 6.5. Calcul parallèle

### 6.5.1. La reproductibilité des calculs flottants

L'arithmétique en virgule flottante n'est pas associative. Par conséquent, lorsqu'on traite des opérations désordonnées, on peut perdre la reproductibilité. Une méthode pour résoudre ce problème consiste à mettre en œuvre directement des solutions algorithmiques pour gérer les calculs en virgule flottante. Demmel et Nguyen ont largement contribué à ce sujet. En 2013, Demmel et Nguyen (Demmel et Nguyen 2013a) ont abordé le défi de parvenir à une reproductibilité avec les sommes en virgule flottante, en particulier face à la planification dynamique des processeurs qui peuvent modifier l'ordre d'exécution des opérations et à la non-associativité des opérations en virgule flottante dans les environnements de calcul parallèle. Ils proposent une technique de somme en virgule flottante qui est reproductible indépendamment de l'ordre de la somme, en utilisant l'algorithme Rump (Rump et al. 2010), plus efficace que l'utilisation d'une arithmétique avec haute précision. Cette solution fait un compromis entre efficacité et précision. Les performances de cette solution sont améliorées avec l'algorithme OneReduction, toujours de Demmel et Nguyen (Demmel et Nguyen 2014), en utilisant des nombres en virgule flottante indexés et en nécessitant une seule opération de réduction pour réduire le coût de communication sur les plateformes parallèles à mémoire distribuée. Cependant, ces solutions n'améliorent pas la précision. Le résultat calculé, même s'il est reproductible, reste exposé à des problèmes de précision, en particulier lorsque l'on traite un problème où une petite modification des données d'entrée peut entraîner de grandes variations dans le résultat (Chohra et al. 2016). Selon Stodden (Stodden et al. 2013), l'utilisation du type long-double ou de la somme de Kahan peut augmenter la reproductibilité sans augmenter beaucoup le temps de calcul. En ce qui concerne les algorithmes de somme compensée rapides et précis, les
server (OSS) de Lustre. De plus, nous constatons que le débit observé des conteneurs sur Lustre est comparable à celui des conteneurs exécutés à partir du stockage local ». Casalicchio et Perciballi (2017) ont constaté une légère surcharge pour Docker, d'environ 5 % à 10 % pour la charge CPU et de 10 % à 30 % de surcharge d'E/S disque. Axés sur des scénarios de calcul à hautes performances, Hu et al. (2019) n'ont trouvé aucune surcharge pour Singularity sur les applications parallèles MPI et GPU.

Sur la base de ces connaissances, nous constatons que Apptainer (Singularity) et d'autres technologies de conteneurs, à l'exception de Docker, conviennent au calcul haute performance et à la recherche reproductible. Nous pensons qu'Apptainer est la meilleure solution à utiliser et à apprendre actuellement, car il est l'outil le plus répandu sur les clusters de calcul. Cependant, comme Apptainer a récemment changé ( évolution à partir de Singularity ), une étude à jour pourrait être utile pour confirmer qu'Apptainer reste parfaitement adapté aux performances natives ou proches de celles-ci.

Un inconvénient des conteneurs est qu'ils sont initialement conçus pour le déploiement, et non pour l'archivage. Bien qu'il soit possible de créer un Dockerfile qui spécifie les étapes exactes pour construire une image de conteneur, il n'y a toujours aucune garantie que l'image résultante sera entièrement reproductible. Cela signifie que même si deux personnes utilisent le même Dockerfile, elles peuvent obtenir des images de conteneur légèrement différentes. Une des raisons de ce manque de reproductibilité est que les images de conteneurs sont des binaires, ce qui signifie qu'elles sont compilées et non facilement lisible ou modifiables. Cela rend difficile la compréhension de toutes les dépendances et configurations à l'intérieur d'une image de conteneur. Si quelqu'un souhaite reproduire les calculs effectués à l'intérieur d'un conteneur, il
travaux récents de Blanchad *et al.* (2020) et de Lange (2022) sont intéressants. L'arithmétique par intervalles est également une solution envisagée (Revol et Théveny 2014).

Certains outils ont également été développés pour améliorer la reproductibilité de l'arithmétique en virgule flottante. La bibliothèque Intel MKL présente le CNR (Reproductibilité Numérique Conditionnelle) (Rosenquist 2012). Cette fonctionnalité limite l'utilisation des extensions d'ensemble d'instructions pour garantir des résultats numériques reproductibles sur différentes architectures. Cependant, cette approche a tendance à considérablement réduire les performances, notamment sur les architectures plus récentes. De plus, elle exige un nombre de threads identique d'une exécution à l'autre pour maintenir des résultats cohérents. Verrou (Févotte et Lathuilière 2016) est un outil construit sur l'outil Valgrind qui utilise l'arithmétique de Monte Carlo (MCA) pour surveiller la précision des opérations en virgule flottante dans les simulations numériques sans nécessiter de modification du code source ou de recompilation. Conçu pour les applications à petite échelle et les codes industriels complexes, Verrou aide à diagnostiquer les inexactitudes découlant des calculs en virgule flottante, contribuant au processus de vérification et de validation dans des industries telles qu'EDF (Électricité De France), qui reposent sur des simulations numériques pour la sécurité et l'efficacité de leurs centrales nucléaires.

Cependant, pour gérer la recherche reproductible en calcul haute performance, des solutions de niveau supérieur à celles qui travaillent directement sur l'arithmétique en virgule flottante sont préférées. De bons algorithmes en virgule flottante ne peuvent pas résoudre tous les problèmes induits par la parallélisation complexe des simulations stochastiques.
devrait recréer l'environnement de conteneur exact. Cependant, en raison
de la non-reproductibilité des images de conteneurs, ce processus peut ne
pas donner des résultats identiques. Par conséquent, bien que les
conteneurs soient efficaces pour le déploiement d'applications, ils peuvent
ne pas être la solution idéale pour obtenir une reproductibilité totale dans
le contexte de la recherche scientifique. Cependant, dans la pratique, les
conteneurs sont les outils les plus utilisés et restent adaptés à la recherche
reproductible. Comme mentionné précédemment, Guix pourrait
actuellement être la meilleure solution que nous connaissons pour la
reproductibilité computationnelle. Des états de l'art complets des
conteneurs pour le calcul à hautes performances ont été récemment
publiés en 2022 et 2023, respectivement (Zhou et al. 2022) et (Keller Tesser
et Borin 2023).

6.5. Calcul parallèle

6.5.1. La reproductibilité des calculs flottants

L'arithmétique en virgule flottante n'est pas associative. Par
conséquent, lorsqu'on traite des opérations désordonnées, on peut perdre
la reproductibilité. Une méthode pour résoudre ce problème consiste à
mettre en œuvre directement des solutions algorithmiques pour gérer les
calculs en virgule flottante. Demmel et Nguyen ont largement contribué à
ce sujet. En 2013, Demmel et Nguyen (Demmel et Nguyen 2013a) ont
abordé le défi de parvenir à une reproductibilité avec les sommes en
virgule flottante, en particulier face à la planification dynamique des
processeurs qui peuvent modifier l'ordre d'exécution des opérations et à
la non-associativité des opérations en virgule flottante dans les
environnements de calcul parallèle. Ils proposent une technique de somme
en virgule flottante qui est reproductible indépendamment de l'ordre de la
### 6.5.2. Enregistrer et rejouer

Lorsqu'il s'agit de traiter des workflows et des exécutions non déterministes, tels que nous en trouvons en calcul parallèle, il peut être difficile de répéter même nos propres expériences et d'obtenir des résultats identiques bit à bit, bien que cela soit nécessaire pour le débogage. Les outils d'enregistrement et de relecture peuvent être utiles pour répéter ou reproduire un calcul non déterministe, comme suggéré par Chapp *et al.* (2018). Nous avons synthétisé ce dernier travail pour voir comment de tels outils ont été initialement proposés pour permettre le débogage de calculs parallèles sur des clusters. L'exécution dynamique modifiant l'ordre des opérations, avec des bibliothèques à haute performance comme MPI, qui peut en effet rendre les calculs non déterministes d'une exécution à l'autre. MPI est une bibliothèque largement utilisée pour gérer les communications et la concurrence sur des machines distribuées.

Tout d'abord, certains outils d'enregistrement et de relecture sont conçus pour une architecture à mémoire partagée, où tous les processeurs travaillent sur la même mémoire. L'outil ODR (Altekar et Stoica 2009) est un outil logiciel conçu pour les programmes multiprocesseurs qui a pour objectif d'obtenir une relecture déterministe du résultat en enregistrant uniquement une partie des données d'exécution et en employant une stratégie de recherche lors de la relecture pour converger vers une exécution reproduisant les sorties originales du programme. En évitant le besoin d'une reproduction bit à bit de l'ensemble de l'exécution et en contournant les problèmes de concurrences des données, ODR peut reproduire les comportements dans des applications multiprocesseurs telles qu'Apache et MySQL avec un facteur de surcoût moyen d'enregistrement de 1,6 fois. PRES (Park *et al.* 2009) utilise l'approche « enregistrement et relecture » pour le débogage d'exécution parallèle multiprocesseurs en développant des « schémas d'exécution » pendant
somme, en utilisant l'algorithme Rump (Rump et al. 2010), plus efficace que l'utilisation d'une arithmétique avec haute précision. Cette solution fait un compromis entre efficacité et précision. Les performances de cette solution sont améliorées avec l'algorithme OneReduction, toujours de Demmel et Nguyen (Demmel et Nguyen 2014), en utilisant des nombres en virgule flottante indexés et en nécessitant une seule opération de réduction pour réduire le coût de communication sur les plateformes parallèles à mémoire distribuée. Cependant, ces solutions n'améliorent pas la précision. Le résultat calculé, même s'il est reproductible, reste exposé à des problèmes de précision, en particulier lorsque l'on traite un problème où une petite modification des données d'entrée peut entraîner de grandes variations dans le résultat (Chohra et al. 2016). Selon Stodden (Stodden et al. 2013), l'utilisation du type long-double ou de la somme de Kahan peut augmenter la reproductibilité sans augmenter beaucoup le temps de calcul. En ce qui concerne les algorithmes de somme compensée rapides et précis, les travaux récents de Blanchad et al. (2020) et de Lange (2022) sont intéressant. L'arithmétique par intervalles est également une solution envisagée (Revol et Théveny 2014).

Certains outils ont également été développés pour améliorer la reproductibilité de l'arithmétique en virgule flottante. La bibliothèque Intel MKL présente le CNR (Reproductibilité Numérique Conditionnelle) (Rosenquist 2012). Cette fonctionnalité limite l'utilisation des extensions d'ensemble d'instructions pour garantir des résultats numériques reproductible sur différentes architectures. Cependant, cette approche a tendance à considérablement réduire les performances, notamment sur les architectures plus récentes. De plus, elle exige un nombre de threads identique d'une exécution à l'autre pour maintenir des résultats cohérents. Verrou (Févotte et Lathuilière 2016) est un outil construit sur l'outil
l'enregistrement. Ils explorent de manière itérative les chemins d'exécution
potentiels qui correspondent à ces schémas pour reproduire étroitement
une exécution sur laquelle nous avons eu un bogue. Selon eux, la plupart
des bogues sont fidèlement répliqués en moins de 10 essais de relecture.
Respec, proposé par Lee et al. (Lee et al. 2010) est un système de relecture
déterministe qui exécute simultanément la relecture et l'exécution, vérifiant
périodiquement les divergences entre les deux et maintenant des points de
contrôle des états mutuellement acceptés. Les évaluations révèlent un
surcoût de 18% pour les programmes à deux threads et de 55% pour les
applications à quatre threads lorsqu'ils sont testés sur les benchmarks
PARSEC et SPLASH-2. ScalaMemTrace (Budanur et al. 2011) fournit une
représentation compressée de la trace mémoire, identifiant les motifs
comportementaux récurrents à travers la hiérarchie de mémoire. Évalué
avec des charges de travail axées sur le calcul haute performance,
ScalaMemTrace maintient une taille de trace presque constante jusqu'à 64
threads. La fidélité de relecture de cet outil était reconnue comme ayant
des limitations, mais atteignant une précision de 91% sur le benchmark
AMG. PinPlay d'Intel (Patil et al. 2010), propose des capacités
d'enregistrement et de relecture adaptables, telles que la relecture de sous-
groupes, et assure la compatibilité avec d'autres outils associés à Pin, visant
la polyvalence. Lorsqu'il est évalué sur des charges de travail de calcul à
haute performance, PinPlay enregistre un surcoût de temps d'exécution
très significatif, étant de 10 à 18 fois durant la phase de « replay » de
plusieurs applications MPI. Light (Liu et al. 2015) de Liu et al. détermine et
journalise de manière succincte les traces de données essentielles pour une
relecture précise, en se concentrant spécifiquement sur la dépendance de
flux des accès à la mémoire partagée. Les évaluations sur un ensemble
diversifié de benchmarks indiquent que Light présente un surcoût de
journalisation de 44% et un surcoût d'espace de 10% par rapport aux
techniques traditionnelles. PORRidge (Utterback et al. 2017), est conçu
Valgrind qui utilise l'arithmétique de Monte Carlo (MCA) pour surveiller
la précision des opérations en virgule flottante dans les simulations
numériques sans nécessiter de modification du code source ou de
recompilation. Conçu pour les applications à petite échelle et les codes
industriels complexes, Verrou aide à diagnostiquer les inexactitudes
découlant des calculs en virgule flottante, contribuant au processus de
vérification et de validation dans des industries telles qu'EDF (Électricité
De France), qui reposent sur des simulations numériques pour la sécurité
et l'efficacité de leurs centrales nucléaires.

Cependant, pour gérer la recherche reproductible en calcul haute
performance, des solutions de niveau supérieur à celles qui travaillent
directement sur l'arithmétique en virgule flottante sont préférées. De bons
algorithmes en virgule flottante ne peuvent pas résoudre tous les
problèmes induits par la parallélisation complexe des simulations
stochastiques.

6.5.2. Enregistrer et rejouer

Lorsqu'il s'agit de traiter des workflows et des exécutions non
déterministes, tels que nous en trouvons en calcul parallèle, il peut être
difficile de répéter même nos propres expériences et d'obtenir des résultats
identiques bit à bit, bien que cela soit nécessaire pour le débogage. Les
outils d'enregistrement et de relecture peuvent être utiles pour répéter ou
reproduire un calcul non déterministe, comme suggéré par Chapp *et al.*
(2018). Nous avons synthétisé ce dernier travail pour voir comment de tels
outils ont été initialement proposés pour permettre le débogage de calculs
parallèles sur des clusters. L'exécution dynamique modifiant l'ordre des
opérations, avec des bibliothèques à hautes performances comme MPI,
qui peut en effet rendre les calculs non déterministes d'une exécution à
pour les programmes Cilk Plus, qui sont une extension des langages de
programmation C et C++ permettant de gérer le parallélisme des données
et des tâches. Cette approche utilise une technique d'enregistrement et de
relecture qui ne dépend pas du type de processeur. Elle se distingue en se
concentrant sur les enregistrements associés à chaque verrouillage, plutôt
qu'à chaque fil d'exécution (thread). Cette méthode influence le
planificateur de Cilk pour qu'il se conforme aux ordres d'accès
préalablement enregistrés, en utilisant une représentation améliorée du
graphe acyclique dirigé. Des tests réalisés sur une gamme variée de
benchmarks ont montré que le surcoût lié à l'enregistrement variait,
atteignant parfois 3,39 fois le niveau normal, avec une moyenne de 1,62
fois. Rerun (Hower et Hill 2008) est un système conçu pour les
architectures multiprocesseurs. Il introduit un mécanisme de relecture
déterministe, c'est-à-dire qu'il permet de reproduire de manière fiable et
précise le déroulement d'un programme. Au lieu de se concentrer sur
l'enregistrement de chaque conflit de mémoire individuel, Rerun tire parti
des « épisodes atomiques ». Ces épisodes sont des séquences d'instructions
exécutées par un seul thread qui ne génèrent pas de conflits avec d'autres
threads. L'avantage majeur de cette approche est qu'elle nécessite une
quantité de mémoire relativement faible pour chaque cœur du processeur.
QuickRec (Pokam et al., 2013) est une extension pour l'architecture Intel,
offrant des capacités d'enregistrement et de relecture assistées par matériel
pour les programmes multithreads sur des systèmes multicœurs. En
utilisant la plateforme d'émulation QuickIA (Chitlur et al. 2012) et un noyau
Linux modifié, QuickRec bénéficie d'une génération minimale de journaux
mémoire et de surcoût de performances, bien que sa pile logicielle
introduise un surcoût moyen d'environ 13%. Samsara (Ren et al. 2015)
capitalise sur le « hardware-assisted virtualization » (HAV), en utilisant une
méthode de relecture déterministe dans les systèmes multiprocesseurs sans
nécessiter de modifications matérielles. En utilisant un schéma
l'autre. MPI est une bibliothèque largement utilisée pour gérer les
communications et la concurrence sur des machines distribuées.

Tout d'abord, certains outils d'enregistrement et de relecture sont
conçus pour une architecture à mémoire partagée, où tous les processeurs
travaillent sur la même mémoire. L'outil ODR (Altekar et Stoica 2009) est
un outil logiciel conçu pour les programmes multiprocesseurs qui a pour
objectif d'obtenir une relecture déterministe du résultat en enregistrant
uniquement une partie des données d'exécution et en employant une
stratégie de recherche lors de la relecture pour converger vers une
exécution reproduisant les sorties originales du programme. En évitant le
besoin d'une reproduction bit à bit de l'ensemble de l'exécution et en
contournant les problèmes de concurrences des données, ODR peut
reproduire les comportements dans des applications multiprocesseurs
telles qu'Apache et MySQL avec un facteur de surcoût moyen
d'enregistrement de 1,6 fois. PRES (Park et al. 2009) utilise l'approche
« enregistrement et relecture » pour le débogage d'exécution parallèle
multiprocesseurs en développant des « schémas d'exécution » pendant
l'enregistrement. Ils explorent de manière itérative les chemins d'exécution
potentiels qui correspondent à ces schémas pour reproduire étroitement
une exécution sur laquelle nous avons eu un bogue. Selon eux, la plupart
des bogues sont fidèlement répliqués en moins de 10 essais de relecture.
Respec, proposé par Lee et al. (Lee et al. 2010) est un système de relecture
déterministe qui exécute simultanément la relecture et l'exécution, vérifiant
périodiquement les divergences entre les deux et maintenant des points de
contrôle des états mutuellement acceptés. Les évaluations révèlent un
surcoût de 18% pour les programmes à deux threads et de 55% pour les
applications à quatre threads lorsqu'ils sont testés sur les benchmarks
PARSEC et SPLASH-2. ScalaMemTrace (Budanur et al. 2011) fournit une
d'enregistrement basé sur les blocs qui évite toutes les détections d'accès
mémoire (une source principale de surcoût dans les méthodes
précédentes), les auteurs soutiennent que Samsara réduit considérablement
la taille du fichier journal à 1/70e et réduit le surcoût d'enregistrement à
une moyenne de 2,3 fois par rapport aux solutions logicielles classiques.
Plus récemment en 2017, Castor (Mashtizadeh et al. 2017) offre une
solution par défaut d'enregistrement et de relecture pour les applications
multicœurs, mettant l'accent sur des surcoûts minimes et prévisibles.
Notamment, bien que Castor atteigne un faible surcoût d'enregistrement
pour la majorité des benchmarks PARSEC, le benchmark Radiosity voit
des surcoûts atteignant 25% lors d'une exécution à 10 threads en raison
des impacts sur le cache. Castor peut fonctionner avec les langages C, C++
et Go.

D'autres outils sont conçus pour une architecture à mémoire distribuée (contrairement à la mémoire partagée vue précédemment), où chaque processeur dispose de sa propre mémoire privée, et les processeurs doivent communiquer en s'envoyant des messages les uns aux autres, le plus souvent en utilisant la bibliothèque MPI. Scala-H-Trace (Wu et al. 2011) utilise une compression de trace agressive, capturant les variations des paramètres de communication et d'E/S via des histogrammes probabilistes, garantissant des tailles de fichier de log presque constantes même avec des contextes variables. Scala-H-Trace rejoue de manière déterministe ces traces probabilistes sans blocages, ressemblant étroitement aux applications originales, avec des temps de relecture étant de 12% à 15% supérieurs aux temps d'exécution originaux. De manière similaire à Scala-H-Trace, Scalatrace II (Wu et Mueller 2013) utilise des techniques de compression de trace, efficaces pour les applications HPC aux comportements irréguliers, en employant un schéma de codage de bas niveau qui améliore l'adaptabilité et l'interprétation des données. Guermouche et al. (2011) introduisent un protocole de points de contrôle
représentation compressée de la trace mémoire, identifiant les motifs comportementaux récurrents à travers la hiérarchie de mémoire. Évalué avec des charges de travail axées sur le calcul haute performance, ScalaMemTrace maintient une taille de trace presque constante jusqu'à 64 threads. La fidélité de relecture de cet outil était reconnue comme ayant des limitations, mais atteignant une précision de 91% sur le benchmark AMG. PinPlay d'Intel (Patil et al. 2010), propose des capacités d'enregistrement et de relecture adaptables, telles que la relecture de sous-groupes, et assure la compatibilité avec d'autres outils associés à Pin, visant la polyvalence. Lorsqu'il est évalué sur des charges de travail de calcul à hautes performances, PinPlay enregistre un surcoût de temps d'exécution très significatif, étant de 10 à 18 fois durant la phase de « replay » de plusieurs applications MPI. Light (Liu et al. 2015) de Liu et al. détermine et journalise de manière succincte les traces de données essentielles pour une relecture précise, en se concentrant spécifiquement sur la dépendance de flux des accès à la mémoire partagée. Les évaluations sur un ensemble diversifié de benchmarks indiquent que Light présente un surcoût de journalisation de 44% et un surcoût d'espace de 10% par rapport aux techniques traditionnelles. PORRidge (Utterback et al. 2017), est conçu pour les programmes Cilk Plus, qui sont une extension des langages de programmation C et C++ permettant de gérer le parallélisme des données et des tâches. Cette approche utilise une technique d'enregistrement et de relecture qui ne dépend pas du type de processeur. Elle se distingue en se concentrant sur les enregistrements associés à chaque verrouillage, plutôt qu'à chaque fil d'exécution (thread). Cette méthode influence le planificateur de Cilk pour qu'il se conforme aux ordres d'accès préalablement enregistrés, en utilisant une représentation améliorée du graphe acyclique dirigé. Des tests réalisés sur une gamme variée de
non coordonnés adapté aux applications HPC avec MPI, qui ne journalise
que les messages sélectionnés et n'exige pas un redémarrage complet du
processus après une défaillance. Meneses et al. (2010) utilisent une
technique conçue pour atténuer le surcoût mémoire inhérent à la
journalisation des messages en mémoire en regroupant les processeurs en
groupe, où seuls les messages inter-groupes nécessitent une journalisation.
Xue et al. (2009) ont introduit MPIWiz, basé sur une méthode qu'ils ont
nommée relecture reproductible de sous-groupe, une technique hybride de
relecture déterministe pour les applications MPI qui équilibre les avantages
et les limitations de la relecture des données et de la relecture des
instructions dans l'ordre original. En utilisant MPIWiz, le système capture
le contenu des messages entre les groupes de processus et seulement les
ordres des messages au sein d'un groupe, montrant une augmentation de
27% du temps d'exécution lors de l'enregistrement et permettant une
relecture en seulement 53% du temps d'exécution de base de l'application.
Gioachin et al. (2010) ont présenté un mécanisme hybride de relecture en
trois étapes où les premières passes adoptent une relecture d'ordre
minimaliste, passant ensuite à des relectures de données plus intensives
mais limitées à un nombre progressivement réduit de processus, facilitant
ainsi la traçabilité ciblée des erreurs. Rex (Perianayagam et al. 2010),
introduit par Perianayagam et al., est un ensemble d'outils conçus pour
enregistrer, archiver et rejouer de manière exhaustive des expériences
logicielles, garantissant la fidélité de la reproduction malgré d'éventuels
changements dans les ensembles de données externes, l'indisponibilité du
logiciel original ou les paramètres d'entrée non documentés. Il ajoute un
surcoût minimal en termes de temps d'exécution, d'environ 1,6 %, et un
surcoût en termes d'espace d'archivage variant entre 5 et 7 Go. Un état de
l'art complet des outils d'enregistrement et de relecture se trouve dans
(Chapp et al. 2018).
benchmarks ont montré que le surcoût lié à l'enregistrement variait, atteignant parfois 3,39 fois le niveau normal, avec une moyenne de 1,62 fois. Rerun (Hower et Hill 2008) est un système conçu pour les architectures multiprocesseurs. Il introduit un mécanisme de relecture déterministe, c'est-à-dire qu'il permet de reproduire de manière fiable et précise le déroulement d'un programme. Au lieu de se concentrer sur l'enregistrement de chaque conflit de mémoire individuel, Rerun tire parti des « épisodes atomiques ». Ces épisodes sont des séquences d'instructions exécutées par un seul thread qui ne génèrent pas de conflits avec d'autres threads. L'avantage majeur de cette approche est qu'elle nécessite une quantité de mémoire relativement faible pour chaque cœur du processeur. QuickRec (Pokam et al., 2013) est une extension pour l'architecture Intel, offrant des capacités d'enregistrement et de relecture assistées par matériel pour les programmes multithreads sur des systèmes multicœurs. En utilisant la plateforme d'émulation QuickIA (Chitlur et al. 2012) et un noyau Linux modifié, QuickRec bénéficie d'une génération minimale de journaux mémoire et de surcoût de performances, bien que sa pile logicielle introduise un surcoût moyen d'environ 13%. Samsara (Ren et al. 2015) capitalise sur le « hardware-assisted virtualization » (HAV), en utilisant une méthode de relecture déterministe dans les systèmes multiprocesseurs sans nécessiter de modifications matérielles. En utilisant un schéma d'enregistrement basé sur les blocs qui évite toutes les détections d'accès mémoire (une source principale de surcoût dans les méthodes précédentes), les auteurs soutiennent que Samsara réduit considérablement la taille du fichier journal à 1/70ème et réduit le surcoût d'enregistrement à une moyenne de 2,3 fois par rapport aux solutions logicielles classiques. Plus récemment en 2017, Castor (Mashtizadeh et al. 2017) offre une solution par défaut d'enregistrement et de relecture pour
Comme nous pouvons le voir, de nombreux outils ont été proposés assez récemment car le problème du non-déterminisme est omniprésent en calcul à haute performance, et il s'intensifie avec l'avancement des technologies, notamment la diminution de la taille de gravure des processeurs et l'augmentation des puissances de calcul. Beaucoup de ces outils ont un effet négatif non négligeable sur les performances, ce qui réduit leur utilisation. Cependant, ce sont les dernières solutions possibles pour la mise au point des programmes. Il faut se rappeler sans cesse que garantir la répétabilité et la reproductibilité sont des aspects essentiels pour le débogage. En effet, bon nombre de ces outils ont été créés à des fins de débogage, et non pas pour la reproductibilité. Néanmoins, en calcul à haute performance, il est intéressant de savoir que c'est une solution existante qui permet d'effectuer des expériences reproductibles.

## 6.6. Gestion des erreurs silencieuses

Les erreurs silencieuses sont courantes dans les systèmes de calcul à haute performance, et plus encore à l'échelle des calculs « exaflopiques ». Ce phénomène a été étudié, et plusieurs solutions existent.

Au niveau de la mémoire, la technologie de correction d'erreur (ECC memory - Error Correction Code) a été conçue pour protéger les mémoires RAM. La mémoire ECC est une forme spécialisée de stockage de données informatiques qui utilise un code de correction d'erreur pour identifier et corriger les occurrences de corruption de données sur une certaine quantité de bits dans la mémoire. Elle est utilisée dans des situations où la corruption des données est inacceptable, pour le calcul scientifique mais aussi dans les systèmes de contrôle industriel, les bases de données critiques et les caches mémoire essentiels. La mémoire ECC est conçue pour empêcher les erreurs dues à un seul bit qui pourraient affecter l'intégrité de la mémoire, garantissant que les données lues correspondent
les applications multicœurs, mettant l'accent sur des surcoûts minimes et prévisibles. Notamment, bien que Castor atteigne un faible surcoût d'enregistrement pour la majorité des benchmarks PARSEC, le benchmark Radiosity voit des surcoûts atteignant 25% lors d'une exécution à 10 threads en raison des impacts sur le cache. Castor peut fonctionner avec les langages C, C++ et Go.

D'autres outils sont conçus pour une architecture à mémoire distribuée (contrairement à la mémoire partagée vu précédemment), où chaque processeur dispose de sa propre mémoire privée, et les processeurs doivent communiquer en s'envoyant des messages les uns aux autres, le plus souvent en utilisant la bibliothèque MPI. Scala-H-Trace (Wu et al. 2011) utilise une compression de trace agressive, capturant les variations des paramètres de communication et d'E/S via des histogrammes probabilistes, garantissant des tailles de fichier de log presque constantes même avec des contextes variables. Scala-H-Trace rejoue de manière déterministe ces traces probabilistes sans blocages, ressemblant étroitement aux applications originales, avec des temps de relecture étant de 12% à 15% supérieurs aux temps d'exécution originaux. De manière similaire à Scala-H-Trace, Scalatrace II (Wu et Mueller 2013) utilise des techniques de compression de trace, efficaces pour les applications HPC aux comportements irréguliers, en employant un schéma de codage de bas niveau qui améliore l'adaptabilité et l'interprétation des données. Guermouche et al. (2011) introduisent un protocole de points de contrôle non coordonnés adapté aux applications HPC avec MPI, qui ne journalise que les messages sélectionnés et n'exige pas un redémarrage complet du processus après une défaillance. Meneses et al. (2010) utilisent une technique conçue pour atténuer le surcoût mémoire inhérent à la journalisation des messages en mémoire en regroupant les processeurs en
aux données initialement écrites, même si un bit a été altéré involontairement. En revanche, la plupart des mémoires non-ECC classiques ne disposent pas de capacités de détection et de correction des erreurs, seules certaines configurations de mémoires non-ECC comportent une prise en charge de la parité, ce qui permet la détection des erreurs sans correction. Dans l'étude de Baumann (2005), Baumann a travaillé sur l'observation du taux d'erreurs pour une SRAM non protégée par ECC. « Ceci est calculé en utilisant un taux d'erreurs silencieuses (SER) dû à l'exposition aux radiations, ce qui donne un estimé de 50000 FIT (Failure-In-Time : un FIT équivaut à une défaillance sur 1 milliard d'heures de fonctionnement). Ils recommandent donc l'utilisation de l'ECC, qui divise le taux d'erreur par 1000 pour les SRAM » (Dixit et al. 2021). D'autres contre-mesures matérielles pour gérer les erreurs silencieuses incluent la redondance et la parité. La redondance consiste à dupliquer des composants ou des données critiques de manière à ce que, en cas d'erreur sur l'un d'entre eux, le composant ou les données redondants puissent prendre le relais de manière transparente. La parité, une forme plus simple de vérification d'erreur, ajoute un bit supplémentaire à un ensemble de données pour garantir une parité paire ou impaire (la somme des bits étant paire ou impaire). En cas d'erreur, le bit de parité change, ce qui indique un problème.

Des solutions logicielles existent également. Fiala *et al.* (2012) propose une bibliothèque associée à MPI pour gérer les erreurs silencieuses, basée sur la redondance. Dans (Benson *et al.* 2015), les auteurs proposent de gérer les erreurs silencieuses avec un nouveau paradigme pour détecter de telles erreurs au niveau de l'application. Cette méthode consiste à comparer régulièrement les valeurs obtenues par des calculs avec celles issues d'un processus de vérification peu coûteux. En analysant les écarts entre ces deux séries de résultats, des systèmes de détection d'erreurs sont établis. Les chercheurs emploient l'analyse numérique pour déterminer des
groupe, où seuls les messages inter-groupes nécessitent une journalisation. Xue *et al.* (2009) ont introduit MPIWiz, basé sur une méthode qu'ils ont nommée relecture reproductible de sous-groupe, une technique hybride de relecture déterministe pour les applications MPI qui équilibre les avantages et les limitations de la relecture des données et de la relecture des instructions dans l'ordre original. En utilisant MPIWiz, le système capture le contenu des messages entre les groupes de processus et seulement les ordres des messages au sein d'un groupe, montrant une augmentation de 27% du temps d'exécution lors de l'enregistrement et permettant une relecture en seulement 53% du temps d'exécution de base de l'application. Gioachin *et al.* (2010) ont présenté un mécanisme hybride de relecture en trois étapes où les premières passes adoptent une relecture d'ordre minimaliste, passant ensuite à des relectures de données plus intensives mais limitées à un nombre progressivement réduit de processus, facilitant ainsi la traçabilité ciblée des erreurs. Rex (Perianayagam *et al.* 2010), introduit par Perianayagam *et al.*, est un ensemble d'outils conçus pour enregistrer, archiver et rejouer de manière exhaustive des expériences logicielles, garantissant la fidélité de la reproduction malgré d'éventuels changements dans les ensembles de données externes, l'indisponibilité du logiciel original ou les paramètres d'entrée non documentés. Il ajoute un surcoût minimal en termes de temps d'exécution, d'environ 1,6 %, et un surcoût en termes d'espace d'archivage variant entre 5 et 7 Go. Un état de l'art complet des outils d'enregistrement et de relecture se trouve dans (Chapp *et al.* 2018).

Comme nous pouvons le voir, de nombreux outils ont été proposés assez récemment car le problème du non-déterminisme est omniprésent en calcul à hautes performances, et il s'intensifie avec l'avancement des technologies, notamment la diminution de la taille de gravure des
procédures de vérification adaptées aux problèmes de valeurs initiales rencontrés dans les équations différentielles ordinaires et les équations aux dérivées partielles. Plus précisément, ils utilisent des techniques telles que les méthodes de Runge-Kutta et les méthodes linéaires à plusieurs étapes pour les équations différentielles ordinaires, ainsi que des approches de différences finies, tant implicites qu'explicites, et pour les équations aux dérivées partielles. Pour illustrer leur méthode, les auteurs se réfèrent à des exemples comme l'équation de la chaleur et les équations de Navier-Stokes. Il est intéressant de noter que, lors de tests incluant des erreurs introduites volontairement, la stratégie proposée a démontré une capacité à identifier presque toutes les erreurs significatives sans causer de baisse notable de la performance de calcul. Hoemmen et Heroux (2011) proposent une version résiliente de la méthode itérative GMRES. Cette version résiliente est conçue pour corriger les erreurs et améliorer la tolérance aux erreurs de la méthode. Cependant, Bronevetsky et de Supinski (2008) ainsi que Casas et al. (2012) suggèrent que des études empiriques ont montré que certaines méthodes itératives pourraient être vulnérables aux erreurs. Ces études indiquent que toutes les méthodes itératives ne corrigent pas intrinsèquement les erreurs. Huang et Abraham (1984) introduisent l'utilisation de méthodes de somme de contrôle pour améliorer l'intégrité de la multiplication de matrices, en détectant efficacement les erreurs dans le processus. Du et al. (2012) proposent l'application de méthodes de somme de contrôle pour améliorer la robustesse de la décomposition LU (Lower-Upper) à hautes performances, détectant ainsi les erreurs potentielles dans le processus de factorisation LU. Dans (Aupy et al. 2013), la solution proposée pour gérer les erreurs de corruption silencieuse des données repose sur la révision des stratégies traditionnelles de sauvegarde et de récupération par retour en arrière. L'accent est spécifiquement mis sur la résolution d'erreurs latentes qui ne sont pas immédiatement détectées. Ils introduisent deux modèles pour gérer de telles erreurs. Dans
processeurs et l'augmentation des puissances de calcul. Beaucoup de ces
outils ont un effet négatif non négligeable sur les performances, ce qui
réduit leur utilisation. Cependant, ce sont les dernières solutions possibles
pour la mise au point des programmes. Il faut se rappeler sans cesse que
garantir la répétabilité et la reproductibilité sont des aspects essentiels pour
le débogage. En effet, bon nombre de ces outils ont été créés à des fins de
débogage, et non pas pour la reproductibilité. Néanmoins, en calcul à
hautes performances, il est intéressant de savoir que c'est une solution
existante qui permet d'effectuer des expériences reproductibles.

6.6. Gestion des erreurs silencieuses

Les erreurs silencieuses sont courantes dans les systèmes de calcul à
hautes performances, et plus encore à l'échelle des calculs « exaflopiques ».
Ce phénomène a été étudié, et plusieurs solutions existent.

Au niveau de la mémoire, la technologie de correction d'erreur (ECC
memory - Error Correction Code) a été conçue pour protéger les
mémoires RAM. La mémoire ECC est une forme spécialisée de stockage
de données informatiques qui utilise un code de correction d'erreur pour
identifier et corriger les occurrences de corruption de données sur une
certaine quantité de bits dans la mémoire. Elle est utilisée dans des
situations où la corruption des données est inacceptable, pour le calcul
scientifique mais aussi dans les systèmes de contrôle industriel, les bases
de données critiques et les caches mémoire essentiels. La mémoire ECC
est conçue pour empêcher les erreurs dues à un seul bit qui pourraient
affecter l'intégrité de la mémoire, garantissant que les données lues
correspondent aux données initialement écrites, même si un bit a été altéré
involontairement. En revanche, la plupart des mémoires non-ECC
classiques ne disposent pas de capacités de détection et de correction des
le premier modèle, les erreurs sont détectées après un certain délai, suivant une distribution de probabilité souvent représentée sous forme de distribution exponentielle. La solution calcule la période optimale pour la sauvegarde, dans le but de minimiser le temps perdu pendant que les nœuds ne sont pas engagés dans des calculs utiles. Étant donné que seul un nombre limité de points de sauvegarde peut être stocké en mémoire, il existe une possibilité de défaillance irrécupérable en raison de ressources limitées. Dans de tels cas, les auteurs déterminent la période minimale nécessaire pour un niveau acceptable de risque. Dans le deuxième modèle, les erreurs sont détectées grâce à un mécanisme de vérification. Contrairement au premier modèle, il n'y a pas de risque de défaillance irrécupérable car le mécanisme de vérification garantit la détection des erreurs. Cependant, les coûts introduits par ce mécanisme de vérification comptent dans le calcul du temps perdu. L'objectif principal est de trouver une période de sauvegarde optimale qui minimise le temps perdu, en tenant compte du compromis entre la détection précoce des erreurs, le stockage limité des points de sauvegarde et les surcoûts introduits par les mécanismes de vérification. Les auteurs appliquent ces modèles à des scénarios réels et tiennent compte de divers paramètres d'application et d'architecture pour démontrer leur faisabilité et leur efficacité.

Des technologies plus récentes peuvent offrir de nouvelles solutions, telles que l'apprentissage automatique. Dans (Wang et al. 2018), ils proposent un détecteur basé sur un réseau de neurones capable de détecter les corruptions silencieuses des données, même plusieurs itérations après leur injection. L'efficacité de ce détecteur proposé est évaluée à l'aide de six applications Flash et de deux mini-applications Mantevo. Les résultats des expériences montrent que ce détecteur peut identifier avec succès plus de 89 % des corruptions silencieuses des données tout en maintenant un faible taux de faux positifs de moins de 2 %. Plus d'informations sur ce sujet peuvent être trouvées dans un état de l'art sur les techniques de
erreurs, seules certaines configurations de mémoires non-ECC comportent une prise en charge de la parité, ce qui permet la détection des erreurs sans correction. Dans l'étude de Baumann (2005), Baumann a travaillé sur l'observation du taux d'erreurs pour une SRAM non protégée par ECC. « Ceci est calculé en utilisant un taux d'erreurs silencieuses (SER) dû à l'exposition aux radiations, ce qui donne un estimé de 50000 FIT (Failure-In-Time : un FIT équivaut à une défaillance sur 1 milliard d'heures de fonctionnement). Ils recommandent donc l'utilisation de l'ECC, qui divise le taux d'erreur par 1000 pour les SRAM. » (Dixit et al. 2021). D'autres contre-mesures matérielles pour gérer les erreurs silencieuses incluent la redondance et la parité. La redondance consiste à dupliquer des composants ou des données critiques de manière à ce que, en cas d'erreur sur l'un d'entre eux, le composant ou les données redondants puissent prendre le relais de manière transparente. La parité, une forme plus simple de vérification d'erreur, ajoute un bit supplémentaire à un ensemble de données pour garantir une parité paire ou impaire (la somme des bits étant paire ou impaire). En cas d'erreur, le bit de parité change, ce qui indique un problème.

Des solutions logicielles existent également. Fiala *et al.* (2012) propose une bibliothèque associée à MPI pour gérer les erreurs silencieuses, basée sur la redondance. Dans (Benson *et al.* 2015), les auteurs proposent de gérer les erreurs silencieuses avec un nouveau paradigme pour détecter de telles erreurs au niveau de l'application. Cette méthode consiste à comparer régulièrement les valeurs obtenues par des calculs avec celles issues d'un processus de vérification peu coûteux. En analysant les écarts entre ces deux séries de résultats, des systèmes de détection d'erreurs sont établis. Les chercheurs emploient l'analyse numérique pour déterminer des procédures de vérification adaptées aux problèmes de valeurs initiales
modélisation et d'amélioration de la fiabilité des systèmes informatiques
(Mittal et Vetter 2015).
rencontrés dans les équations différentielles ordinaires et les équations aux
dérivées partielles. Plus précisément, ils utilisent des techniques telles que
les méthodes de Runge-Kutta et les méthodes linéaires à plusieurs étapes
pour les équations différentielles ordinaires, ainsi que des approches de
différences finies, tant implicites qu'explicites, et pour les équations aux
dérivées partielles. Pour illustrer leur méthode, les auteurs se réfèrent à des
exemples comme l'équation de la chaleur et les équations de Navier-
Stokes. Il est intéressant de noter que, lors de tests incluant des erreurs
introduites volontairement, la stratégie proposée a démontré une capacité
à identifier presque toutes les erreurs significatives sans causer de baisse
notable de la performance de calcul. Hoemmen et Heroux (2011) proposent une version résiliente de la méthode itérative GMRES. Cette version résiliente est conçue pour corriger les erreurs et améliorer la tolérance aux erreurs de la méthode. Cependant, Bronevetsky et de Supinski (2008) ainsi que Casas et al. (2012) suggèrent que des études empiriques ont montré que certaines méthodes itératives pourraient être vulnérables aux erreurs. Ces études indiquent que toutes les méthodes itératives ne corrigent pas intrinsèquement les erreurs. Huang et Abraham (1984) introduisent l'utilisation de méthodes de somme de contrôle pour améliorer l'intégrité de la multiplication de matrices, en détectant efficacement les erreurs dans le processus. Du et al. (2012) proposent l'application de méthodes de somme de contrôle pour améliorer la robustesse de la décomposition LU (Lower-Upper) à hautes performances, détectant ainsi les erreurs potentielles dans le processus de factorisation LU. Dans (Aupy et al. 2013), la solution proposée pour gérer les erreurs de corruption silencieuse des données repose sur la révision des stratégies traditionnelles de sauvegarde et de récupération par retour en arrière. L'accent est spécifiquement mis sur la résolution d'erreurs latentes
# Chapitre 7

## Exemples pratiques de reproduction d'articles et recommandations

Pour illustrer les principes théoriques et mettre en évidence les obstacles communs, nous fournissons dans cette section quelques exemples de tentatives de reproduction d'articles scientifiques.

En 2020, Hinsen a tenté de reproduire son propre travail intitulé « Structural flexibility in proteins - impact of the crystal environment » (Hinsen 2020a). Il a rencontré des défis significatifs pour reproduire les résultats de ses recherches informatiques en raison de l'évolution des environnements logiciels et des problèmes de gestion des données. Son travail original utilisait des versions antérieures de Python et des bibliothèques telles que le Molecular Modeling Toolkit (MMTK), ScientificPython et netCDF, qui ne sont plus compatibles avec les mises à jour logicielles récentes comme Python 3 et les dernières versions de NumPy qui ont cessé de supporter les interfaces obsolètes. La transition de Python 2 à Python 3 a été particulièrement problématique en raison de changements majeurs dans l'API C de Python et une définition différente des divisions (en Python 2, « / » est un opérateur de division entière, tandis qu'il est un opérateur de division flottante en Python 3). De plus, des scripts cruciaux pour générer des graphiques et d'autres sorties n'ont pas été publiés ou ont été perdus en raison de défaillances matérielles, notamment concernant le stockage sur des CD-ROM et sur des bandes magnétiques illisibles (pour lesquelles il n'a pas été possible de trouver un lecteur fonctionnel). Ces problèmes ont été exacerbés par des changements dans les formats de données utilisés par des bases de données essentielles comme la Protein Data Bank, qui peuvent avoir mis à jour ou corrigé leurs
qui ne sont pas immédiatement détectées. Ils introduisent deux modèles pour gérer de telles erreurs. Dans le premier modèle, les erreurs sont détectées après un certain délai, suivant une distribution de probabilité souvent représentée sous forme de distribution exponentielle. La solution calcule la période optimale pour la sauvegarde, dans le but de minimiser le temps perdu pendant que les nœuds ne sont pas engagés dans des calculs utiles. Étant donné que seul un nombre limité de points de sauvegarde peut être stocké en mémoire, il existe une possibilité de défaillance irrécupérable en raison de ressources limitées. Dans de tels cas, les auteurs déterminent la période minimale nécessaire pour un niveau acceptable de risque. Dans le deuxième modèle, les erreurs sont détectées grâce à un mécanisme de vérification. Contrairement au premier modèle, il n'y a pas de risque de défaillance irrécupérable car le mécanisme de vérification garantit la détection des erreurs. Cependant, les coûts introduits par ce mécanisme de vérification comptent dans le calcul du temps perdu. L'objectif principal est de trouver une période de sauvegarde optimale qui minimise le temps perdu, en tenant compte du compromis entre la détection précoce des erreurs, le stockage limité des points de sauvegarde et les surcoûts introduits par les mécanismes de vérification. Les auteurs appliquent ces modèles à des scénarios réels et tiennent compte de divers paramètres d'application et d'architecture pour démontrer leur faisabilité et leur efficacité.

Des technologies plus récentes peuvent offrir de nouvelles solutions, telles que l'apprentissage automatique. Dans (Wang et al. 2018), ils proposent un détecteur basé sur un réseau de neurones capable de détecter les corruptions silencieuses des données, même plusieurs itérations après leur injection. L'efficacité de ce détecteur proposé est évaluée à l'aide de six applications Flash et de deux mini-applications Mantevo. Les résultats
entrées, affectant la reproductibilité des analyses basées sur les données originales. Bien que l'auteur ait pu obtenir des résultats assez proches de l'article original, il n'a pas pu reproduire exactement tous les résultats (comme les figures par exemple) en raison de la perte de certains codes comme précité.

En 2023, Legrand et Velho ont tenté de reproduire leur propre travail sur SimGrid (Legrand et Velho 2023). Dans leurs efforts pour répliquer leur précédent papier, ils ont fait face à une série d'obstacles importants, principalement en raison de l'indisponibilité de l'article original, des codes sources et des ensembles de données, exacerbés par les défis posés par les dépendances logicielles obsolètes. L'article original et les codes sources associés n'étaient pas facilement accessibles en raison de problèmes de droits d'auteur et de l'arrêt du logiciel GTNetS, crucial pour les simulations. Pour surmonter ces obstacles, les auteurs ont téléchargé les documents et codes nécessaires sur le dépôt en libre accès HAL, GitHub ou Software Heritage, garantissant ainsi que les chercheurs futurs pourraient accéder librement à ces matériaux. Ils ont également relevé le défi de recréer un environnement logiciel compatible en développant une image Docker qui émulait les anciens systèmes et en utilisant Debian snapshot archive, ce qui permet de fournir la plateforme nécessaire pour exécuter les dépendances obsolètes. Même si Paul Velho a fait des efforts pour documenter le workflow à l'époque, les auteurs concluent que d'autres scientifiques n'auraient probablement pas réussi à reproduire le travail original, principalement en raison de sa complexité et du fait que même si une partie du code source était publiquement disponible, elle restait cachée, et donc peu de scientifiques auraient pu le trouver. Les auteurs ont minutieusement documenté leur processus de reproduction, incluant des instructions détaillées de configuration et des modifications aux scripts et aux workflows de simulation pour garantir la compatibilité avec les systèmes contemporains. Cela met en évidence l'importance d'une documentation
des expériences montrent que ce détecteur peut identifier avec succès plus de 89 % des corruptions silencieuses des données tout en maintenant un faible taux de faux positifs de moins de 2 %. Plus d'informations sur ce sujet peuvent être trouvées dans un état de l'art sur les techniques de modélisation et d'amélioration de la fiabilité des systèmes informatiques (Mittal et Vetter 2015).
approfondie, de la préservation des artefacts numériques et de l'accès libre aux matériaux de recherche pour soutenir la reproductibilité académique.

Un dernier exemple sur l'apprentissage automatique illustre certains problèmes de HPC. Dans (Langezaal et al. 2023), les auteurs ont rencontré plusieurs défis dans leur tentative de reproduire l'étude « Label-free explainability for unsupervised models ». Un obstacle important était le temps considérable requis pour l'exécution des expériences, certaines prenant plus de 32 heures sur une machine à faible coût. Ce problème a imposé des exigences substantielles sur les ressources et de la patience. De plus, ils ont rencontré des complications dues à des bugs dans la base de code, qui ont ajouté de la complexité au travail de reproductibilité. Ces bugs ont transformé ce qui serait typiquement des exécutions de ligne de commande simples en une tâche plus laborieuse, compliquant davantage leurs efforts. Lorsqu'on considère des expériences qui consomment beaucoup de temps comme dans le domaine du HPC, un obstacle majeur à la reproductibilité pourrait simplement être le manque de ressources matérielles ou d'allocation de temps de calcul suffisant.

Nos recommandations pour faciliter la recherche reproductible dans le domaine du calcul haute performance incluent les directives suivantes : Choisissez d'utiliser des technologies open source et courantes. Étant donné que ces technologies ne seront pas maintenues indéfiniment, des initiatives telles que l'archive « Debian snapshot » ou Software Heritage s'avèrent très importantes. Utilisez des plateformes telles que GitHub ou GitLab pour favoriser le processus de développement par le contrôle de version. Utilisez des notebooks computationnels, tels que Org-mode ou Jupyter Notebook, pour rationaliser la gestion des données et des workflows de résultats. Il est impératif de maintenir une documentation approfondie de toutes les procédures. Une fois terminé, la plateforme Zenodo devrait être utilisée pour archiver tout le code et les données. Pour permettre à d'autres scientifiques de reproduire vos calculs avec précision,
# Chapitre 7

## Exemples pratiques de reproduction d'articles et recommandations

Pour illustrer les principes théoriques et mettre en évidence les obstacles communs, nous fournissons dans cette section quelques exemples de tentatives de reproduction d'articles scientifiques.

En 2020, Hinsen a tenté de reproduire son propre travail intitulé « Structural flexibility in proteins - impact of the crystal environment » (Hinsen 2020a). Il a rencontré des défis significatifs pour reproduire les résultats de ses recherches informatiques en raison de l'évolution des environnements logiciels et des problèmes de gestion des données. Son travail original utilisait des versions antérieures de Python et des bibliothèques telles que le Molecular Modeling Toolkit (MMTK), ScientificPython et netCDF, qui ne sont plus compatibles avec les mises à jour logicielles récentes comme Python 3 et les dernières versions de NumPy qui ont cessé de supporter les interfaces obsolètes. La transition de Python 2 à Python 3 a été particulièrement problématique en raison de changements majeurs dans l'API C de Python et une définition différente des divisions (en Python 2, « / » est un opérateur de division entière, tandis qu'il est un opérateur de division flottante en Python 3). De plus, des scripts cruciaux pour générer des graphiques et d'autres sorties n'ont pas été publiés ou ont été perdus en raison de défaillances matérielles, notamment concernant le stockage sur des CD-ROM et sur des bandes magnétiques illisibles (pour lesquelles il n'a pas été possible de trouver un lecteur fonctionnel). Ces problèmes ont été exacerbés par des changements dans les formats de données utilisés par des bases de
nous conseillons vivement l'utilisation de conteneurs légers, tels que
Apptainer ou Guix ; ces outils facilitent la reproduction sans compromettre
les performances ; notamment, Guix qui s'intègre également avec Software
Heritage et qui aide à créer un environnement spécifique à un moment fixé.
Si votre code est hautement spécialisé pour une architecture matérielle
spécifique, cette spécificité peut entraver la reproductibilité, surtout si des
optimisations agressives et une parallélisation sont employées. Malgré ces
défis, de nombreux outils offrent désormais des capacités substantielles
pour mener une recherche reproductible. L'obstacle principal reste dans
des contextes très spécifiques de calcul haute performance, où un matériel
particulier est nécessaire et le code est hautement optimisé. De plus, il
existe une réticence générale à reproduire des tâches coûteuses en calcul.
Un calcul informatique prenant des semaines voire des mois n'est pas
prévu pour être refait, de fait, l'utilisation des outils mentionnés ci-dessus
renforce la confiance dans le code et les résultats, réduisant ainsi le besoin
de reproduire de tels calculs coûteux en énergie et en temps. En fin de
compte, il ne faut pas oublier qu'une partie importante des problèmes de
reproductibilité survient initialement lorsque les auteurs échouent à
partager les artefacts.
données essentielles comme la Protein Data Bank, qui peuvent avoir mis
à jour ou corrigé leurs entrées, affectant la reproductibilité des analyses
basées sur les données originales. Bien que l'auteur ait pu obtenir des
résultats assez proches de l'article original, il n'a pas pu reproduire
exactement tous les résultats (comme les figures par exemple) en raison de
la perte de certains codes comme précité.

En 2023, Legrand et Velho ont tenté de reproduire leur propre travail
sur SimGrid (Legrand et Velho 2023). Dans leurs efforts pour répliquer
leur précédent papier, ils ont fait face à une série d'obstacles importants,
principalement en raison de l'indisponibilité de l'article original, des codes
sources et des ensembles de données, exacerbés par les défis posés par les
dépendances logicielles obsolètes. L'article original et les codes sources
associés n'étaient pas facilement accessibles en raison de problèmes de
droits d'auteur et de l'arrêt du logiciel GTNetS, crucial pour les
simulations. Pour surmonter ces obstacles, les auteurs ont téléchargé les
documents et codes nécessaires sur le dépôt en libre accès HAL, GitHub
ou Software Heritage, garantissant ainsi que les chercheurs futurs
pourraient accéder librement à ces matériaux. Ils ont également relevé le
défi de recréer un environnement logiciel compatible en développant une
image Docker qui émulait les anciens systèmes et en utilisant Debian
snapshot archive, ce qui permet de fournir la plateforme nécessaire pour
exécuter les dépendances obsolètes. Même si Paul Velho a fait des efforts
pour documenter le workflow à l'époque, les auteurs concluent que
d'autres scientifiques n'auraient probablement pas réussi à reproduire le
travail original, principalement en raison de sa complexité et du fait que
même si une partie du code source était publiquement disponible, elle
restait cachée, et donc peu de scientifiques auraient pu le trouver. Les
auteurs ont minutieusement documenté leur processus de reproduction,
# Chapitre 8

## Des problèmes ouverts concernant la recherche reproductible en calcul haute performance

### 8.1. Portabilité des algorithmes, en particulier des générateurs de nombres pseudo-aléatoires

Vérifier la justesse des algorithmes en calcul à haute performance est une tâche difficile. Un exemple frappant est l'incohérence observée lorsque l'on implémente un générateur de nombres pseudo-aléatoires dans différents langages de programmation ou technologies. Parmi les meilleurs PRNGs, Philox mentionné précédemment est un exemple où il faut être prudent sur la portabilité, MLFG est un autre exemple où nous avons rencontré des problèmes de portabilité. Lorsqu'un PRNG est initialisé avec le même état initial, nous nous attendons à obtenir une séquence identique de nombres quels que soient les différents environnements informatiques et bibliothèques (comme Numpy ou TensorFlow). Cependant, des variations apparaissent, jetant le doute sur la portabilité et la consistance de l'algorithme. Cela remet également en question la fiabilité des résultats scientifiques obtenus à partir de tels algorithmes. Les fondements de la science informatique déterministe reposent sur la prévisibilité et la fiabilité des algorithmes. Les disparités observées dans les sorties des PRNGs soulignent un problème plus large : sans mise en œuvre normalisée et vérification rigoureuse entre les plateformes, comment pouvons-nous garantir l'intégrité de nos résultats algorithmiques ? Cela appelle à un effort concerté pour développer et respecter la normalisation dans les implémentations de PRNG. De plus, cela nécessite la création de logiciels de vérification robustes pouvant garantir la fidélité et la portabilité
incluant des instructions détaillées de configuration et des modifications aux scripts et aux workflows de simulation pour garantir la compatibilité avec les systèmes contemporains. Cela met en évidence l'importance d'une documentation approfondie, de la préservation des artefacts numériques et de l'accès libre aux matériaux de recherche pour soutenir la reproductibilité académique.

Un dernier exemple sur l'apprentissage automatique illustre certains problèmes de HPC. Dans (Langezaal et al. 2023), les auteurs ont rencontré plusieurs défis dans leur tentative de reproduire l'étude « Label-free explainability for unsupervised models ». Un obstacle important était le temps considérable requis pour l'exécution des expériences, certaines prenant plus de 32 heures sur une machine à faible coût. Ce problème a imposé des exigences substantielles sur les ressources et de la patience. De plus, ils ont rencontré des complications dues à des bugs dans la base de code, qui ont ajouté de la complexité au travail de reproductibilité. Ces bugs ont transformé ce qui serait typiquement des exécutions de ligne de commande simples en une tâche plus laborieuse, compliquant davantage leurs efforts. Lorsqu'on considère des expériences qui consomment beaucoup de temps comme dans le domaine du HPC, un obstacle majeur à la reproductibilité pourrait simplement être le manque de ressources matérielles ou d'allocation de temps de calcul suffisant.

Nos recommandations pour faciliter la recherche reproductible dans le domaine du calcul haute performance incluent les directives suivantes : Choisissez d'utiliser des technologies open source et courantes. Étant donné que ces technologies ne seront pas maintenues indéfiniment, des initiatives telles que l'archive « Debian snapshot » ou Software Heritage s'avèrent très importante. Utilisez des plateformes telles que GitHub ou GitLab pour favoriser le processus de développement par le contrôle de
algorithmiques dans divers environnements informatiques, ce qui est essentiel pour l'avancement de la science.

## 8.2. Reproductibilité des données dans le cadre du « Big data »

La prolifération des données volumineuses dans le monde du calcul à haute performance introduit des défis variés en matière de reproductibilité des données. À mesure que les ensembles de données deviennent de plus en plus volumineux, les systèmes de gestion des versions de données conventionnels peinent à suivre le rythme, ce qui entraîne d'importants obstacles à la maintenance d'un environnement de données consistant et reproductible. Il s'agit non seulement d'un problème technique, mais aussi méthodologique, où la nécessité de gérer de manière évolutive et efficace ces ensembles de données volumineux est primordiale. De plus, avec l'accent de plus en plus mis sur la science basée sur les données, il est impératif d'établir des pratiques robustes de partage de données adaptées à l'échelle et à la complexité immenses des écosystèmes de données volumineuses du HPC. Ces pratiques doivent non seulement faciliter le partage, mais aussi garantir l'intégrité et la reproductibilité des données. La mise à jour de bases de données volumineuses peut entraîner une perte de reproductibilité, et il est difficile de gérer l'archivage de toutes les versions d'une telle quantité de données. Aborder ces défis est essentiel pour permettre la découverte scientifique collaborative et maintenir la crédibilité de la recherche computationnelle.

## 8.3. Reproductibilité des temps de calculs et optimisations

La quête de réalisation de calcul toujours plus rapide dans le monde du calcul haute performance conduit souvent à un compromis avec la reproductibilité, en particulier lorsqu'il s'agit de systèmes parallèles et distribués. Les techniques d'optimisation qui améliorent les performances,
version. Utilisez des notebooks computationnels, tels que Org-mode ou
Jupyter Notebook, pour rationaliser la gestion des données et des
workflows de résultats. Il est impératif de maintenir une documentation
approfondie de toutes les procédures. Une fois terminé, la plateforme
Zenodo devrait être utilisée pour archiver tout le code et les données. Pour
permettre à d'autres scientifiques de reproduire vos calculs avec précision,
nous conseillons vivement l'utilisation de conteneurs légers, tels que
Apptainer ou Guix ; ces outils facilitent la reproduction sans
compromettre les performances ; notamment, Guix qui s'intègre
également avec Software Heritage et qui aide à créer un environnement
spécifique à un moment fixé. Si votre code est hautement spécialisé pour
une architecture matérielle spécifique, cette spécificité peut entraver la
reproductibilité, surtout si des optimisations agressives et une
parallélisation sont employées. Malgré ces défis, de nombreux outils
offrent désormais des capacités substantielles pour mener une recherche
reproductible. L'obstacle principal reste dans des contextes très
spécifiques de calcul haute performance, où un matériel particulier est
nécessaire et le code est hautement optimisé. De plus, il existe une
réticence générale à reproduire des tâches coûteuses en calcul. Un calcul
informatique prenant des semaines voir des mois n'est pas prévu pour être
refait, de fait, l'utilisation des outils mentionnés ci-dessus renforce la
confiance dans le code et les résultats, réduisant ainsi le besoin de
reproduire de tels calculs couteux en énergie et en temps. En fin de
compte, il ne faut pas oublier qu'une partie importante des problèmes de
reproductibilité survient initialement lorsque les auteurs échouent à
partager les artefacts.