Aumentare la longevità archivistica del codice

Esiste un elenco pubblicato delle migliori pratiche per garantire la longevità del codice, con un occhio verso risultati scientifici riproducibili? (ad esempio open source, pratiche di documentazione, selezione di dipendenze, selezione di una lingua, macchine virtuali, ecc.).

Sei a conoscenza di studi (o carenti, esempi / aneddoti) che hanno cercato di stimare l'emivita del tipico codice scientifico o di altri software (se questa è anche una domanda ragionevole?)

mi viene in mente la longevità pianificata di TeX:

“Sin dagli inizi del 1977, il progetto di ricerca TeX che ho intrapreso è stato guidato da due obiettivi principali. Il primo obiettivo era la qualità: volevamo produrre documenti che non fossero solo belli, ma in realtà i migliori. (...) Il secondo obiettivo principale era l'archiviazione: creare sistemi che fossero il più possibile indipendenti dai cambiamenti nella tecnologia di stampa. Quando è arrivata la prossima generazione di dispositivi di stampa, volevo essere in grado di mantenere la stessa qualità già raggiunta, invece di dover risolvere nuovamente tutti i problemi. Volevo progettare qualcosa che sarebbe ancora utilizzabile tra 100 anni. "- Donald E. Knuth: tipografia digitale, p. 559 (citato da http://de.wikipedia.org/wiki/TeX )

Sulla base dei libri di Knuth sulla tipografia digitale, dovrebbe essere possibile anche una completa reimplementazione di TeX e METAFONT. Includono annotazioni e spiegazioni per tutto il codice.

Esigendo che i risultati siano stabili per decenni, si entra in una sorta di dilemma congelante. Da un lato, vuoi semplificare la riproduzione dei risultati al 100%, in modo da bloccare il tuo software / ambiente. D'altra parte, qualcuno che è interessato a riprodurre i risultati in futuro vorrà sicuramente basarsi su di esso. Questa persona rimarrà bloccata con un software molto vecchio, rendendo molto difficile cambiare qualcosa. Per tutto ciò che si basa su più pacchetti esterni, già pochi anni sono sufficienti per rendere le cose praticamente immutabili.

Per TeX, il congelamento è annunciato nell'articolo del 1990

Il futuro di TEX e METAFONT http://www.ntg.nl/maps/05/34.pdf

"Sono fermamente convinto che un sistema immutabile abbia un grande valore, anche se è assiomatico che qualsiasi sistema complesso possa essere migliorato. Pertanto, non è saggio apportare ulteriori" miglioramenti "ai sistemi chiamati TEX e METAFONT. Consideriamo questi sistemi come punti fissi, che dovrebbero dare gli stessi risultati tra 100 anni che producono oggi ".

Il sistema ideale combinerebbe la riproducibilità con la mutabilità. Cercare di essere il più autonomo, semplice e ben testato possibile aiuta sicuramente.

Scusami se disonora troppo dalla domanda originale. [cross pubblicato da "Scientists for Reproducible Research", riproducible-research@googlegroups.com]

Esistono molte sfide tecniche che rendono estremamente difficile la esatta riproducibilità bit per bit dei risultati computazionali.

A livello di software, le modifiche al codice o ad una qualsiasi delle librerie utilizzate dal codice possono ovviamente produrre risultati diversi. Saresti sorpreso dal numero di librerie di supporto che possono finire collegate in un tipico codice scientifico.

A un livello inferiore, anche la ricompilazione di uno dei codici o delle librerie utilizzate dal codice con un nuovo compilatore o con diverse ottimizzazioni del compilatore attivate può causare problemi. Uno dei motivi è che varie operazioni nel codice potrebbero essere eseguite in un ordine diverso quando il codice viene ricompilato. Poiché l'aggiunta in virgola mobile non è associativa (a + b) + c <> a + (b + c), ciò può dare risultati diversi.

OK, quindi se conserviamo l'intero ambiente software (sistema operativo, librerie e codice compilato) (ad es.) Masterizzandolo su un CD-ROM di avvio che eseguirà il codice. Ora possiamo essere sicuri che otterremo gli stessi risultati se eseguiamo questo codice su un altro computer?

Sorprendentemente, alcuni codici in realtà variano l'ordine dei calcoli in base agli aspetti del particolare modello di processore su cui sono in esecuzione. Ad esempio, le librerie di algebra lineare ottimizzata in genere interrompono le moltiplicazioni di matrici per lavorare su blocchi che si adattano alla cache. Quando Intel rilascia un nuovo microprocessore con una cache più grande, il codice potrebbe regolare dinamicamente la dimensione del blocco, determinando un'aritmetica che viene eseguita in un ordine diverso e dando risultati diversi. Altri codici regolano dinamicamente l'ordine dei calcoli in base alla quantità di memoria disponibile, se si esegue il codice su un computer con più memoria che potrebbe causare l'aritmetica in un ordine diverso e quindi dare risultati diversi.

Le cose diventano incredibilmente più complicate quando si inserisce il codice multithread, poiché l'esatta cronologia di esecuzione dei diversi thread è spesso non deterministica e ciò può nuovamente comportare l'esecuzione di operazioni aritmetiche in un ordine diverso da una corsa all'altra.

In pratica, il massimo che puoi davvero sperare sono risultati simili da una macchina all'altra, fino alle tolleranze di precisione degli algoritmi utilizzati. ad esempio, se ho un problema di ricerca della radice e utilizzo la bisection per ottenere una radice entro + -1,0e-10, allora dovrei essere felice finché macchine diverse stanno producendo risposte che concordano con quella tolleranza.

Ci sono stati molti tentativi per far sì che la riproducibilità avvenga e c'è un'intera letteratura su questo argomento. La mia opinione personale di 15 anni di software scientifico è che non è realistico, tanto insoddisfacente quanto trovo quella risposta. I problemi sono che (i) software complessi hanno bug e quindi non possono essere congelati; (ii) il software non è mai completo di funzionalità e quindi lo sviluppo continua; (iii) qual è il valore della consegna con un documento di diverse centinaia di migliaia di righe di codice?

Come ho detto, trovo questa risposta insoddisfacente. Credo che, come campo, la scienza computazionale non abbia avuto molto successo nella produzione di pubblicazioni che instillino fiducia nel fatto che i risultati che pubblichiamo siano corretti e riproducibili. Allo stesso tempo, non riesco davvero a trovare modi per fare le cose meglio. Di sicuro, è utile rilasciare il codice sorgente che accompagna un documento. Allo stesso tempo, tutti coloro che sono onesti concorderanno sul fatto che i risultati in un documento saranno generalmente prodotti da diverse versioni del codice che, nella maggior parte dei casi contengono hack che descrivono diverse condizioni al contorno, diversi lati a destra, ecc. vieni con diverse versioni dello stesso codice. È imbarazzante per il lettore cominciare, ma è assolutamente improduttivo se il codice è grande come spesso accade oggi - i miei due articoli più recenti hanno usato codici che sono circa 20.000 righe di codice e che si basano su affare. II (600.000 righe di codice) e Trilinos (1.5M righe di codice). Quali informazioni fornisce a un potenziale lettore? (Devo dire che i miei codici sono comunque disponibili.)

Per una possibile soluzione a questo problema, vedere il mio progetto ActivePapers . In breve, descrive come i dati e il codice possono essere impacchettati insieme a dipendenze esplicite su versioni specifiche di ciascun componente software. Ciò consente di riprodurre esattamente un calcolo, consentendo al contempo di eseguire software aggiornato sugli stessi dati.

Dovrei aggiungere che ActivePapers non è altro che una dimostrazione del concetto e probabilmente non sarà di alcun utilità pratica nel prossimo futuro. Il motivo è che si basa sul principio secondo cui tutto il codice eseguibile deve esistere come bytecode JVM. Al momento, questo esclude troppe biblioteche scientifiche popolari. Tuttavia, una volta che la riproducibilità è riconosciuta come importante, anche le priorità negli strumenti di programmazione possono cambiare.

Credo che, per quanto riguarda la scelta della lingua, l'uso di una standardizzata (ad es. C / Fortran / C ++) si qualificherebbe come "best practice". Se un pacchetto dipende da altri 10 pacchetti / librerie, specialmente quelli scritti in lingue oscure, ciò ovviamente è negativo per la longevità. Molti progetti finiscono per rimanere orfani dopo qualche tempo. Non credo che le principali librerie / API come BLAS / LAPACK, PETSc, FFTW, MPI ecc. Sparirebbero presto. BLAS è già piuttosto vecchio.

Il seguente pezzo di codice (rubato da http://www.math.utah.edu/software/c-with-fortran.html ) precede Fortran 77, utilizza le costanti di Hollerith per la manipolazione dei caratteri ma si compila ben 40-50 anni dopo con il compilatore 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

Aprire sourcing / metterlo da qualche parte come googlecode che è meno probabile che scompaia presto (anche se hanno chiuso la ricerca del codice) è un gioco da ragazzi.