Augmenter la longévité archivistique du code

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?)

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», [email protected]]

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.

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.)

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.

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.