Erhöhung der Archivierungslebensdauer von Code

11

Gibt es eine veröffentlichte Liste bewährter Verfahren zur Gewährleistung der Langlebigkeit von Code mit Blick auf reproduzierbare wissenschaftliche Ergebnisse? (z. B. Open Source, Dokumentationspraktiken, Auswahl von Abhängigkeiten, Auswahl einer Sprache, virtueller Maschinen usw.).

Kennen Sie Studien (oder fehlen diese, Beispiele / Anekdoten), die versucht haben, die Halbwertszeit von typischem wissenschaftlichem Code oder anderer Software abzuschätzen (wenn das überhaupt eine vernünftige Frage ist?)

cboettig
quelle

Antworten:

8

Die geplante Langlebigkeit von TeX fällt mir ein:

„Seit diesen Anfängen im Jahr 1977 wurde das von mir begonnene TeX-Forschungsprojekt von zwei Hauptzielen vorangetrieben. Das erste Ziel war Qualität: Wir wollten Dokumente produzieren, die nicht nur schön, sondern auch die besten sind. (…) Das zweite Hauptziel war die Archivierung: Systeme zu schaffen, die so weit wie möglich unabhängig von Änderungen in der Drucktechnologie sind. Als die nächste Generation von Druckgeräten auf den Markt kam, wollte ich die bereits erreichte Qualität beibehalten können, anstatt alle Probleme neu lösen zu müssen. Ich wollte etwas entwerfen, das in 100 Jahren noch brauchbar ist. ”- Donald E. Knuth: Digitale Typografie, p. 559 (zitiert aus http://de.wikipedia.org/wiki/TeX )

Basierend auf Knuths Büchern über digitale Typografie sollte sogar eine vollständige Neuimplementierung von TeX und METAFONT möglich sein. Sie enthalten Anmerkungen und Erklärungen für den gesamten Code.

Wenn Sie verlangen, dass Ihre Ergebnisse über Jahrzehnte stabil bleiben, geraten Sie in eine Art eiskaltes Dilemma. Einerseits möchten Sie es einfach machen, Ihre Ergebnisse zu 100% zu reproduzieren, damit Sie Ihre Software / Umgebung einfrieren. Auf der anderen Seite wird jemand, der daran interessiert ist, Ihre Ergebnisse in Zukunft zu reproduzieren, sicherlich darauf aufbauen wollen. Diese Person wird mit sehr alter Software stecken bleiben, was es sehr schwierig macht, etwas zu ändern. Für alles, was auf mehreren externen Paketen aufbaut, reichen bereits einige Jahre aus, um die Dinge praktisch unveränderlich zu machen.

Für TeX wird das Einfrieren im Artikel von 1990 angekündigt

Die Zukunft von TEX und METAFONT http://www.ntg.nl/maps/05/34.pdf

"Ich bin der festen Überzeugung, dass ein unveränderliches System von großem Wert ist, auch wenn es selbstverständlich ist, dass jedes komplexe System verbessert werden kann. Daher halte ich es für unklug, weitere" Verbesserungen "an den Systemen TEX und METAFONT vorzunehmen. Betrachten wir diese Systeme als Fixpunkte, die in 100 Jahren die gleichen Ergebnisse liefern sollten, die sie heute produzieren. "

Das ideale System würde Reproduzierbarkeit mit Veränderbarkeit verbinden. Der Versuch, so eigenständig, einfach und erprobt wie möglich zu sein, hilft sicherlich.

Verzeihen Sie mir, wenn ich zu sehr von der ursprünglichen Frage abwich. [Kreuz gepostet von 'Scientists for Reproducible Research', [email protected]]

Matthias Liegeplatz
quelle
Danke, dass du das über Matthias gebracht hast. Und willkommen bei scicomp!
Aron Ahmadia
2
Ich denke, dass das TeX-Beispiel eigentlich kein sehr gutes ist, obwohl es allgemein als der klassische Fall für ein eingefrorenes System angesehen wird. Der Grund, warum ich denke, ist, dass niemand TeX mehr direkt verwendet. Menschen verwenden Latex zusammen mit seiner Unendlichkeit an Verpackungen und sie sind sehr viel nicht gefroren. Infolgedessen denke ich, dass (La) TeX-Dokumente ebenso Änderungen unterliegen können wie alles andere. Für mich ist TeX wie eine virtuelle Maschine - Sie können diese eingefroren lassen, aber solange sich der darauf aufgebaute Code ständig ändert, wird nichts gewonnen.
Wolfgang Bangerth
Vielen Dank, ich denke, dies ist eine ausgezeichnete Fallstudie aus Sicht der Softwareentwicklung, die sich möglicherweise von der wissenschaftlichen Sicht unterscheidet. Die Tatsache, dass jeder indirekt auf TeX aufbauen muss, ist möglicherweise nicht ideal für weit verbreitete Software, kann jedoch ein idealer Beweis dafür sein, dass wissenschaftlicher Code noch Jahrzehnte später erfolgreich ausgeführt und aufgebaut werden kann. Aber sicherlich hat Knuth Änderungen und Aktualisierungen einfacher vermieden, um eine 100-jährige Stabilität zu erreichen?
Cboettig
4

Es gibt viele technische Herausforderungen, die es äußerst schwierig machen, eine genaue Bit-für-Bit-Reproduzierbarkeit der Rechenergebnisse zu erreichen.

Auf Softwareebene können Änderungen am Code oder an einer der vom Code verwendeten Bibliotheken offensichtlich dazu führen, dass unterschiedliche Ergebnisse erzielt werden. Sie werden überrascht sein, wie viele Support-Bibliotheken zu einem typischen wissenschaftlichen Code verknüpft werden können.

Auf einer niedrigeren Ebene kann das Neukompilieren eines Codes oder einer der vom Code verwendeten Bibliotheken mit einem neuen Compiler oder mit aktivierten verschiedenen Compileroptimierungen ebenfalls Probleme verursachen. Ein Grund ist, dass verschiedene Operationen im Code möglicherweise in einer anderen Reihenfolge ausgeführt werden, wenn der Code neu kompiliert wird. Da die Gleitkommaaddition nicht assoziativ ist (a + b) + c <> a + (b + c), kann dies zu unterschiedlichen Ergebnissen führen.

OK, was ist, wenn wir die gesamte Softwareumgebung (Betriebssystem, Bibliotheken und kompilierten Code) erhalten, indem wir sie (z. B.) auf eine bootfähige CD-Rom brennen, auf der der Code ausgeführt wird? Können wir jetzt sicher sein, dass wir die gleichen Ergebnisse erzielen, wenn wir diesen Code auf einem anderen Computer ausführen?

Überraschenderweise variieren einige Codes tatsächlich die Reihenfolge der Berechnungen basierend auf Aspekten des jeweiligen Prozessormodells, auf dem sie ausgeführt werden. Beispielsweise lösen optimierte lineare Algebra-Bibliotheken normalerweise Matrixmultiplikationen auf, um an Blöcken zu arbeiten, die in den Cache passen. Wenn Intel einen neuen Mikroprozessor mit einem größeren Cache veröffentlicht, passt der Code möglicherweise die Blockgröße dynamisch an, was zu einer Arithmetik führt, die in einer anderen Reihenfolge ausgeführt wird und unterschiedliche Ergebnisse liefert. Andere Codes passen die Reihenfolge der Berechnungen dynamisch an die Größe des verfügbaren Speichers an. Wenn Sie den Code auf einem Computer mit mehr Speicher ausführen, kann dies dazu führen, dass die Arithmetik in einer anderen Reihenfolge ausgeführt wird und somit unterschiedliche Ergebnisse erzielt werden.

Die Dinge werden erstaunlich komplizierter, wenn Sie Multithread-Code einwerfen, da der genaue Ausführungsverlauf der verschiedenen Threads häufig nicht deterministisch ist und dies wiederum dazu führen kann, dass arithmetische Operationen von Lauf zu Lauf in einer anderen Reihenfolge ausgeführt werden.

In der Praxis können Sie höchstens auf Ergebnisse hoffen, die von einer Maschine zur nächsten ähnlich sind, bis hin zu den Genauigkeitstoleranzen der verwendeten Algorithmen. Wenn ich beispielsweise ein Problem mit der Wurzelfindung habe und die Halbierung verwende, um eine Wurzel auf + -1,0e-10 zu bringen, sollte ich glücklich sein, solange verschiedene Maschinen Antworten liefern, die innerhalb dieser Toleranz übereinstimmen.

Brian Borchers
quelle
Das Problem mit verschiedenen Compilerversionen erklärt übrigens, warum es wirklich nicht ausreicht, eine "eingefrorene" Version des Quellcodes zu verteilen. Der erstellte kompilierte Code kann je nach verwendeter Compilerversion variieren zu unterschiedlichen Ergebnissen führen.
Brian Borchers
2

Es gab viele Versuche, Reproduzierbarkeit zu erreichen, und es gibt eine ganze Literatur zu diesem Thema. Meine persönliche Meinung aus 15 Jahren wissenschaftlicher Software ist, dass es unrealistisch ist, so unbefriedigend, wie ich diese Antwort finde. Die Probleme sind, dass (i) komplexe Software Fehler aufweist und daher nicht eingefroren werden kann; (ii) Software ist niemals vollständig und die Entwicklung wird fortgesetzt. (iii) Welchen Wert hat es, mit einem Papier mehrere hunderttausend Codezeilen zu liefern?

Wie gesagt, ich finde diese Antwort unbefriedigend. Ich glaube, dass die Computerwissenschaft als Fachgebiet nicht sehr erfolgreich Literatur produziert hat, die das Vertrauen weckt, dass die von uns veröffentlichten Ergebnisse korrekt und reproduzierbar sind. Gleichzeitig kann ich mir keine Möglichkeiten einfallen lassen, um die Dinge besser zu machen. Natürlich ist es nützlich, den zu einem Papier gehörenden Quellcode freizugeben. Gleichzeitig wird jeder, der ehrlich ist, zustimmen, dass die Ergebnisse in einem Papier normalerweise von verschiedenen Versionen des Codes erzeugt werden, die in den meisten Fällen Hacks enthalten, die unterschiedliche Randbedingungen, unterschiedliche rechte Seiten usw. beschreiben. Ein Papier würde dann kommen mit verschiedenen Versionen des gleichen Codes. Dies ist für den Leser zunächst unangenehm, Aber es ist geradezu unproduktiv, wenn der Code so groß ist, wie es heute häufig vorkommt. In meinen beiden jüngsten Veröffentlichungen wurden Codes verwendet, die etwa 20.000 Codezeilen umfassen und auf Deal.II (600.000 Codezeilen) und Trilinos (1,5 Millionen Zeilen) aufbauen von Code). Welche Informationen liefert das einem potenziellen Leser? (Ich sollte sagen, dass meine Codes trotzdem verfügbar sind.)

Wolfgang Bangerth
quelle
2
Ich bin weniger pessimistisch, aber immer noch unzufrieden. Sie können das Revisionskontroll-Tag oder die Revisionsnummer, die dem Code zugeordnet sind, der die Ergebnisse in einem bestimmten Artikel erzeugt hat, problemlos melden, und ein absolut gewissenhafter Autor würde alle für einen bestimmten Artikel wichtigen Ergebnisse mit einer Codebasis erneut ausführen. Ich glaube nicht, dass Sie den Code selbst bereitstellen müssen, wenn ein Revisionskontrollsystem vorhanden ist, öffentlich zugänglich ist und die Tags veröffentlicht werden.
Bill Barth
Klar, das könntest du machen. Die Frage ist einfach, was ein Leser mit der Menge an Code machen würde, die Sie auf sie werfen. Ja, Sie können es ausführen und überprüfen, ob die Ergebnisse mit den angezeigten übereinstimmen. Aber was zeigt das? Wie kann jemand - in der Praxis, nicht in der Theorie - überprüfen, ob die Ergebnisse korrekt sind?
Wolfgang Bangerth
Nein, dem stimme ich voll und ganz zu. Wenn ich nicht denke, dass Sie eine skrupellose Person sind, muss ich Ihren Code nicht erneut ausführen, um die Antworten genau wiederzugeben. Ich denke, die größere Frage ist, ob Sie ausreichend nachgewiesen haben, dass Sie Ihre Implementierung überprüft haben, und ob dies anhand von Experimenten validiert werden kann oder nicht.
Bill Barth
Danke, aber ich denke, das geht die Frage nicht an. Es gibt sicherlich genügend Raum, um zu diskutieren, warum es nützlich ist , 15 Jahre später Code zur Verfügung zu haben , aber in dieser Frage frage ich einfach, ob dieser Code für die meisten Menschen noch ausgeführt werden würde, da Sie ihn archiviert haben. Ich bin mit der Literatur vertraut, die die Archivierung von Code fördert, aber vor 40 Jahren hat niemand ein globales Archiv für Lochkarten gefördert. Hat die Technologie die Halbwertszeit von Software erhöht oder verringert? Wenn archivierter Code in 5 Jahren den Weg des Telegraphen geht, sind die anderen Probleme ohnehin stumm.
Cboettig
Ich bin mir ziemlich sicher, dass Sie Code vor 15 Jahren schreiben können, um ihn heute auszuführen, wenn Sie viel Arbeit haben. Ich bin zuversichtlich, dass Sie ab heute gut geschriebene Codes erhalten, die in 15 Jahren ausgeführt werden können.
Wolfgang Bangerth
2

Eine mögliche Lösung für dieses Problem finden Sie in meinem ActivePapers- Projekt. Zusammenfassend wird beschrieben, wie Daten und Code zusammen mit expliziten Abhängigkeiten von bestimmten Versionen jeder Softwarekomponente gepackt werden können. Dies ermöglicht es, eine Berechnung exakt zu reproduzieren und gleichzeitig aktualisierte Software mit denselben Daten auszuführen.

Ich sollte hinzufügen, dass ActivePapers nur ein Proof of Concept ist und in naher Zukunft wahrscheinlich keinen praktischen Nutzen haben wird. Der Grund ist, dass es auf dem Prinzip basiert, dass der gesamte ausführbare Code als JVM-Bytecode existieren muss. Dies schließt derzeit zu viele populärwissenschaftliche Bibliotheken aus. Sobald jedoch die Reproduzierbarkeit als wichtig erkannt wird, können sich auch die Prioritäten in den Programmierwerkzeugen ändern.

Khinsen
quelle
1

Ich glaube, dass in Bezug auf die Wahl der Sprache die Verwendung einer standardisierten Sprache (z. B. C / Fortran / C ++) als "Best Practice" gelten würde. Wenn ein Paket von 10 anderen Bibliotheken / Paketen abhängt, insbesondere von solchen, die in obskuren Sprachen geschrieben sind, ist dies offensichtlich schlecht für die Langlebigkeit. Viele Projekte werden nach einiger Zeit verwaist. Ich glaube nicht, dass wichtige Bibliotheken / APIs wie BLAS / LAPACK, PETSc, FFTW, MPI usw. bald verschwinden würden. BLAS ist schon ziemlich alt.

Der folgende Code (gestohlen von http://www.math.utah.edu/software/c-with-fortran.html ) ist älter als Fortran 77, verwendet Hollerith-Konstanten für die Manipulation von Zeichen, kompiliert aber 40-50 Jahre später mit der GNU Fortran Compiler:

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

Open Sourcing / Platzierung irgendwo wie Google Code, der weniger wahrscheinlich bald verschwindet (obwohl die Codesuche beendet wurde), ist ein Kinderspiel.

stali
quelle
Danke für das Beispiel! Ich wäre gespannt auf Vergleiche in anderen Sprachen, einschließlich Skriptsprachen. Führen die ersten Codes, die jemals in Perl, Python oder R geschrieben wurden, immer noch dieselben Ergebnisse aus? Ist dies wahrscheinlicher oder weniger wahrscheinlich als bei C oder Fortran?
cboettig