Augmenter la longévité archivistique du code


11

Existe-t-il une liste publiée des meilleures pratiques pour assurer la longévité du code, en vue de résultats scientifiques reproductibles? (par exemple open source, pratiques de documentation, sélection des dépendances, sélection d'une langue, machines virtuelles, etc.).

Connaître des études (ou, à défaut, des exemples / anecdotes) qui ont tenté d'estimer la demi-vie d'un code scientifique typique ou d'un autre logiciel (si c'est même une question raisonnable?)


Réponses:


8

la longévité prévue de TeX vient à l'esprit:

«Depuis ces débuts en 1977, le projet de recherche TeX dans lequel je me suis lancé était motivé par deux objectifs majeurs. Le premier objectif était la qualité: nous voulions produire des documents non seulement agréables, mais en fait les meilleurs. (…) Le deuxième objectif majeur était l'archivage: créer autant que possible des systèmes indépendants des évolutions de la technologie d'impression. Lorsque la prochaine génération de périphériques d'impression est arrivée, je voulais pouvoir conserver la même qualité déjà atteinte, au lieu d'avoir à résoudre tous les problèmes à nouveau. Je voulais concevoir quelque chose qui serait encore utilisable dans 100 ans. »- Donald E. Knuth: typographie numérique, p. 559 (cité sur http://de.wikipedia.org/wiki/TeX )

Sur la base des livres de Knuth sur la typographie numérique, même une réimplémentation complète de TeX et METAFONT devrait être possible. Ils incluent des annotations et des explications pour tout le code.

En exigeant que vos résultats soient stables pendant des décennies, vous vous retrouvez dans une sorte de dilemme glacial. D'une part, vous voulez faciliter la reproduction à 100% de vos résultats, vous gelez donc votre logiciel / environnement. D'un autre côté, quelqu'un qui souhaite reproduire vos résultats à l'avenir voudra certainement en tirer parti. Cette personne sera coincée avec de très vieux logiciels, ce qui rendra très difficile tout changement. Pour tout ce qui s'appuie sur plusieurs packages externes, déjà quelques années suffisent pour rendre les choses pratiquement immuables.

Pour TeX, le gel est annoncé dans l'article de 1990

L'avenir de TEX et METAFONT http://www.ntg.nl/maps/05/34.pdf

"Je crois fermement qu'un système immuable a une grande valeur, même s'il est évident que tout système complexe peut être amélioré. Par conséquent, je pense qu'il n'est pas judicieux d'apporter de nouvelles" améliorations "aux systèmes appelés TEX et METAFONT. systèmes sous forme de points fixes, qui devraient donner les mêmes résultats dans 100 ans qu'ils produisent aujourd'hui. "

Le système idéal allierait reproductibilité et évolutivité. Essayer d'être aussi autonome, simple et bien testé que possible aide certainement.

Excusez-moi si je dégoûtais trop de la question d'origine. [Croix publiée par «Scientists for Reproductible Research», reproductible-research@googlegroups.com]


Merci d'avoir apporté cela à Matthias. Et bienvenue sur scicomp!
Aron Ahmadia

2
Je pense que l'exemple de TeX n'est en fait pas très bon même s'il est généralement considéré comme le cas classique d'un système gelé. La raison pour laquelle je pense que c'est parce que personne n'utilise plus directement TeX. Les gens utilisent le latex avec son infinité de paquets et ils ne sont pas du tout congelés. En conséquence, je pense que les documents (La) TeX sont autant sujets à changement que tout le reste. Pour moi, TeX est comme une machine virtuelle - vous pouvez garder cela figé mais tant que le code construit dessus change, rien n'est gagné.
Wolfgang Bangerth

Merci, je pense que c'est une excellente étude de cas du point de vue du développement logiciel, qui peut être assez différent du point de vue scientifique. Le fait que tout le monde a besoin de s'appuyer indirectement sur TeX peut ne pas être idéal pour les logiciels largement utilisés, mais peut être une démonstration idéale que le code scientifique pourrait toujours fonctionner avec succès et s'appuyer sur des décennies plus tard. Mais sûrement Knuth a-t-il fait plus simplement en évitant les changements et les mises à jour afin de poursuivre la stabilité à 100 ans?
cboettig

4

Il existe de nombreux défis techniques qui rendent la reproductibilité bit à bit exacte des résultats de calcul extrêmement difficile à réaliser.

Au niveau logiciel, les modifications apportées au code ou à l'une des bibliothèques utilisées par le code peuvent évidemment entraîner des résultats différents. Vous seriez surpris du nombre de bibliothèques de support qui peuvent finir par être liées dans un code scientifique typique.

À un niveau inférieur, la recompilation du code ou des bibliothèques utilisées par le code avec un nouveau compilateur ou avec différentes optimisations de compilateur activées peut également provoquer des problèmes. L'une des raisons est que diverses opérations dans le code peuvent être effectuées dans un ordre différent lorsque le code est recompilé. Étant donné que l'addition en virgule flottante n'est pas associative (a + b) + c <> a + (b + c), cela peut donner des résultats différents.

OK, que se passe-t-il si nous préservons l'ensemble de l'environnement logiciel (système d'exploitation, bibliothèques et code compilé) en (par exemple) en le gravant sur un CD-Rom amorçable qui exécutera le code. Maintenant, pouvons-nous être sûrs que nous obtiendrons les mêmes résultats si nous exécutons ce code sur un autre ordinateur?

Étonnamment, certains codes varient en fait l'ordre des calculs en fonction des aspects du modèle de processeur particulier sur lequel ils s'exécutent. Par exemple, les bibliothèques d'algèbre linéaire optimisées cassent généralement les multiplications matricielles pour travailler sur des blocs qui tiendront dans le cache. Lorsque Intel publie un nouveau microprocesseur avec un cache plus grand, le code peut ajuster dynamiquement la taille du bloc, ce qui entraîne une arithmétique qui est effectuée dans un ordre différent et donne des résultats différents. D'autres codes ajustent dynamiquement l'ordre des calculs en fonction de la quantité de mémoire disponible - si vous exécutez le code sur un ordinateur avec plus de mémoire, ce qui pourrait bien faire effectuer l'arithmétique dans un ordre différent et donner ainsi des résultats différents.

Les choses deviennent incroyablement plus compliquées lorsque vous ajoutez du code multithread, car l'historique d'exécution exact des différents threads est souvent non déterministe et cela peut à nouveau entraîner des opérations arithmétiques dans un ordre différent d'une exécution à l'autre.

Dans la pratique, on ne peut vraiment espérer que des résultats similaires d'une machine à l'autre, jusqu'aux tolérances de précision des algorithmes utilisés. Par exemple, si j'ai un problème de recherche de racine et que j'utilise la bissection pour obtenir une racine à + -1.0e-10, je serais heureux tant que différentes machines produisent des réponses qui correspondent à cette tolérance.


Soit dit en passant, le problème avec les différentes versions du compilateur explique pourquoi il n'est vraiment pas suffisant de distribuer une version "figée" du code source - le code compilé qui est produit peut varier selon la version du compilateur utilisée et cela peut conduire à des résultats différents.
Brian Borchers

2

Il y a eu de nombreuses tentatives pour rendre la reproductibilité possible et il existe toute une littérature sur ce sujet. Mon opinion personnelle de 15 ans de logiciels scientifiques est que c'est irréaliste, aussi insatisfaisant que je trouve cette réponse. Les problèmes sont que (i) les logiciels complexes ont des bogues et ne peuvent donc pas être gelés; (ii) le logiciel n'est jamais complet et le développement se poursuit donc; (iii) quelle est la valeur de livrer avec un papier plusieurs centaines de milliers de lignes de code?

Comme je l'ai dit, je trouve cette réponse insatisfaisante. Je crois qu'en tant que domaine, la science informatique n'a pas très bien réussi à produire de la littérature qui incite à la confiance que les résultats que nous publions sont corrects et reproductibles. En même temps, je n'arrive pas vraiment à trouver des moyens de mieux faire les choses. Bien sûr, la publication du code source qui accompagne un document est utile. En même temps, tous ceux qui sont honnêtes conviendront que les résultats dans un document seront généralement produits par différentes versions du code qui, dans la plupart des cas, contiennent des hacks décrivant différentes conditions aux limites, différents côtés à droite, etc. venir avec différentes versions du même code. C'est gênant pour le lecteur pour commencer, mais il est carrément improductif si le code est volumineux comme cela arrive souvent aujourd'hui - mes deux articles les plus récents ont utilisé des codes qui sont environ 20 000 lignes de code et qui s'appuient sur deal.II (600 000 lignes de code) et Trilinos (1,5 M lignes de code). Quelles informations cela fournit-il à un lecteur potentiel? (Je dois dire que mes codes sont néanmoins disponibles.)


2
Je suis moins pessimiste mais toujours insatisfait. Vous pouvez facilement signaler la balise de contrôle de révision ou le numéro de révision associé au code qui a produit les résultats dans un article donné, et un auteur totalement scrupuleux réexécutera tous les résultats importants pour un article donné avec une seule base de code. Je ne pense pas que vous ayez besoin de fournir le code lui-même si un système de contrôle des révisions est en place, est accessible au public et que les balises sont publiées.
Bill Barth

Bien sûr, vous pourriez le faire. La question est simplement de savoir ce qu'un lecteur ferait avec la masse de code que vous lui lancez. Oui, vous pouvez l'exécuter et vérifier que les résultats sont les mêmes que ceux affichés. Mais qu'est-ce que cela démontre? Comment peut-on vérifier - dans la pratique, pas en théorie - que les résultats sont corrects?
Wolfgang Bangerth

Non, c'est la partie avec laquelle je suis entièrement d'accord. À moins que je pense que vous êtes une personne sans scrupules, je n'ai pas besoin de relancer votre code pour reproduire exactement les réponses. Je pense que la plus grande question est de savoir si vous avez suffisamment démontré que vous avez vérifié votre mise en œuvre et si cela peut être validé par rapport aux expériences.
Bill Barth

Merci, mais je pense que cela ne règle pas la question. Il y a certainement beaucoup de place pour débattre de la raison pour laquelle avoir du code disponible 15 ans plus tard est utile , mais dans cette question, je demande simplement si ce code fonctionnerait toujours pour la plupart des gens, étant donné que vous l'avez archivé. Je connais la littérature encourageant l'archivage de code, mais personne n'a encouragé une archive mondiale pour les cartes perforées il y a 40 ans. La technologie a-t-elle augmenté ou diminué la demi-vie des logiciels? Si le code archivé fait le chemin du télégraphe dans 5 ans, les autres problèmes sont quand même muets.
cboettig

Je suis presque sûr que vous pouvez obtenir du code écrit il y a 15 ans pour qu'il s'exécute aujourd'hui, si vous avez beaucoup de travail. Je suis convaincu que vous pouvez obtenir des codes bien écrits à partir d'aujourd'hui pour les exécuter dans 15 ans.
Wolfgang Bangerth

2

Pour une solution possible à ce problème, consultez mon projet ActivePapers . En résumé, il décrit comment les données et le code peuvent être regroupés avec des dépendances explicites sur des versions spécifiques de chaque composant logiciel. Cela permet de reproduire exactement un calcul, tout en permettant d'exécuter des logiciels mis à jour sur les mêmes données.

Je dois ajouter qu'ActivePapers n'est rien de plus qu'une preuve de concept et qu'il est peu probable qu'il soit utile dans un avenir proche. La raison en est qu'il est basé sur le principe que tout le code exécutable doit exister en tant que bytecode JVM. Pour le moment, cela exclut trop de bibliothèques scientifiques populaires. Cependant, une fois que la reproductibilité est reconnue comme importante, les priorités des outils de programmation peuvent également changer.


1

Je pense qu'en ce qui concerne le choix de la langue, l'utilisation d'une langue standardisée (par exemple C / Fortran / C ++) serait considérée comme une "meilleure pratique". Si un package dépend de 10 autres bibliothèques / packages, en particulier ceux écrits dans des langages obscurs, cela est évidemment mauvais pour la longévité. De nombreux projets finissent par devenir orphelins après un certain temps. Je ne pense pas que les principales bibliothèques / API comme BLAS / LAPACK, PETSc, FFTW, MPI, etc. disparaîtraient de sitôt. BLAS est déjà assez vieux.

Le morceau de code suivant (volé à http://www.math.utah.edu/software/c-with-fortran.html ) est antérieur à Fortran 77, utilise les constantes de Hollerith pour la manipulation des caractères mais se compile très bien 40-50 ans plus tard avec le compilateur GNU Fortran:

stali@x61:~$ cat olde.f

       CALL S(12HHello, world, 12)
       END
       SUBROUTINE S(MSG,N)
       INTEGER K, N, M
       INTEGER MSG(1)
       M = (N + 3) / 4
       WRITE (6,'(20A4)') (MSG(K), K = 1,M)
       END

stali@x61:~$ gfortran -std=legacy olde.f; ./a.out
Hello, world

L'open source / le mettre quelque part comme googlecode qui est moins susceptible de disparaître bientôt (bien qu'ils aient arrêté la recherche de code) est une évidence.


Merci pour l'exemple! Je serais curieux de voir des comparaisons dans d'autres langages, y compris les langages de script - les premiers codes jamais écrits en perl, python ou R fonctionnent-ils toujours avec les mêmes résultats? Sont-ils plus susceptibles de le faire ou moins susceptibles que C ou Fortran?
cboettig
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.