Zwiększenie trwałości archiwalnej kodu

Czy istnieje opublikowana lista najlepszych praktyk zapewniających długowieczność kodu, z myślą o odtwarzalnych wynikach naukowych? (np. open source, praktyki dokumentacji, wybór zależności, wybór języka, maszyny wirtualne itp.).

Wiedz o wszelkich badaniach (lub ich brak, przykładach / anegdotach), które próbowały oszacować okres półtrwania typowego kodu naukowego lub innego oprogramowania (czy to w ogóle uzasadnione pytanie?)

przychodzi na myśl planowana żywotność TeX-a:

„Od czasu tych początków w 1977 r. Realizowany przeze mnie projekt badawczy TeX miał dwa główne cele. Pierwszym celem była jakość: chcieliśmy stworzyć dokumenty, które były nie tylko ładne, ale w rzeczywistości najlepsze. (…) Drugim głównym celem była archiwizacja: stworzenie systemów, które byłyby możliwie najbardziej niezależne od zmian w technologii drukowania. Kiedy pojawiła się kolejna generacja urządzeń drukujących, chciałam móc zachować tę samą jakość, którą już osiągnąłem, zamiast ponownie rozwiązywać wszystkie problemy. Chciałem zaprojektować coś, co będzie nadal użyteczne za 100 lat. ”- Donald E. Knuth: Cyfrowa typografia, s. 1 559 (cytowany z http://de.wikipedia.org/wiki/TeX )

Na podstawie książek Knutha o typografii cyfrowej powinna być możliwa nawet całkowita reimplementacja TeXa i METAFONT-a. Zawierają adnotacje i objaśnienia dla całego kodu.

Domagając się, aby twoje wyniki były stabilne przez dziesięciolecia, popadasz w rodzaj lodowatego dylematu. Z jednej strony chcesz ułatwić odtwarzanie wyników w 100%, więc zamrozisz swoje oprogramowanie / środowisko. Z drugiej strony ktoś, kto jest zainteresowany odtworzeniem twoich wyników w przyszłości, z pewnością będzie chciał je wykorzystać. Ta osoba utknie z bardzo starym oprogramowaniem, co bardzo utrudni zmianę. Na wszystko, co opiera się na kilku zewnętrznych pakietach, wystarczy już kilka lat, aby uczynić rzeczy praktycznie niezmiennymi.

W przypadku TeX zamrożenie zostało ogłoszone w artykule z 1990 roku

Przyszłość TEX i METAFONT http://www.ntg.nl/maps/05/34.pdf

„Mocno wierzę, że niezmienny system ma wielką wartość, mimo że aksjomatyczne jest, że każdy złożony system można ulepszyć. Dlatego uważam, że nierozsądne jest wprowadzanie dalszych„ ulepszeń ”do systemów o nazwie TEX i METAFONT. Przyjrzyjmy się tym systemy jako punkty stałe, które powinny dać te same wyniki za 100 lat od chwili obecnej. ”

Idealny system łączyłby odtwarzalność ze zmiennością. Pomaganie w byciu tak samodzielnym, prostym i sprawdzonym, jak to możliwe, z pewnością pomaga.

Proszę mi wybaczyć, jeśli zbytnio denerwuję się z pierwotnego pytania. [wysłano z „Scientists for Reproducible Research”, reproducible-research@googlegroups.com]

Istnieje wiele wyzwań technicznych, które sprawiają, że dokładna powtarzalność wyników obliczeniowych jest bardzo trudna do osiągnięcia.

Na poziomie oprogramowania zmiany w kodzie lub dowolnej bibliotece używanej przez kod mogą oczywiście powodować różne wyniki. Byłbyś zaskoczony liczbą bibliotek pomocniczych, które mogą ostatecznie zostać połączone w typowy kod naukowy.

Na niższym poziomie rekompilacja dowolnego kodu lub dowolnej biblioteki używanej przez kod przy użyciu nowego kompilatora lub przy różnych włączonych optymalizacjach kompilatora może również powodować problemy. Jednym z powodów jest to, że różne operacje w kodzie mogą być wykonywane w innej kolejności podczas rekompilacji kodu. Ponieważ dodawanie zmiennoprzecinkowe nie jest asocjacyjne (a + b) + c <> a + (b + c), może to dać różne wyniki.

OK, co z tego, jeśli zachowamy całe środowisko oprogramowania (system operacyjny, biblioteki i skompilowany kod) poprzez (np.) Wypalenie go na rozruchowej płycie CD-ROM, która uruchomi kod. Czy możemy być pewni, że uzyskamy takie same wyniki, jeśli uruchomimy ten kod na innym komputerze?

Co zaskakujące, niektóre kody w rzeczywistości zmieniają kolejność obliczeń w oparciu o aspekty konkretnego modelu procesora, na którym są uruchomione. Na przykład zoptymalizowane biblioteki algebry liniowej zwykle dzielą mnożenia macierzy, aby pracować na blokach, które zmieszczą się w pamięci podręcznej. Gdy Intel wypuszcza nowy mikroprocesor z większą pamięcią podręczną, kod może dynamicznie dostosowywać rozmiar bloku, co skutkuje arytmetyką, która jest wykonywana w innej kolejności i daje różne wyniki. Inne kody dynamicznie dostosowują kolejność obliczeń na podstawie ilości dostępnej pamięci - jeśli uruchomisz kod na komputerze z większą ilością pamięci, co może spowodować, że arytmetyka zostanie wykonana w innej kolejności, a tym samym da inne wyniki.

Sprawy stają się niezwykle skomplikowane, gdy dodaje się wielowątkowy kod, ponieważ dokładna historia wykonania różnych wątków jest często niedeterministyczna, co może ponownie powodować wykonywanie operacji arytmetycznych w innej kolejności od jednego uruchomienia do następnego.

W praktyce najbardziej, na co naprawdę można liczyć, są wyniki, które są podobne w zależności od maszyny, aż do tolerancji dokładności zastosowanych algorytmów. np. jeśli mam problem ze znalezieniem roota i używam bisekcji, aby uzyskać root w granicach + -1.0e-10, to powinienem być szczęśliwy, dopóki różne maszyny generują odpowiedzi, które są zgodne w ramach tej tolerancji.

Podjęto wiele prób zapewnienia powtarzalności i istnieje cała literatura na ten temat. Moim osobistym zdaniem z 15 lat oprogramowania naukowego jest to, że jest nierealne, tak samo satysfakcjonujące, jak uważam tę odpowiedź. Problem polega na tym, że (i) w złożonym oprogramowaniu występują błędy i dlatego nie można ich zawiesić; (ii) oprogramowanie nigdy nie jest kompletne, dlatego rozwój jest kontynuowany; (iii) jaka jest wartość dostarczania za pomocą papieru kilkuset tysięcy wierszy kodu?

Jak mówię, uważam tę odpowiedź za niezadowalającą. Uważam, że dziedzina informatyki nie odniosła dużego sukcesu w tworzeniu literatury, która budzi zaufanie, że publikowane przez nas wyniki są poprawne i powtarzalne. Jednocześnie nie jestem w stanie wymyślić sposobów na robienie rzeczy lepiej. Na pewno przydatne jest wydanie kodu źródłowego dołączonego do papieru. W tym samym czasie każdy, kto jest uczciwy, zgodzi się, że wyniki w pracy będą zazwyczaj wytwarzane przez różne wersje kodu, które w większości przypadków zawierają hacki opisujące różne warunki brzegowe, różne prawe strony itp. Wówczas artykuł pochodzą z różnymi wersjami tego samego kodu. Na początku jest to niewygodne dla czytelnika, ale jest to całkowicie bezproduktywne, jeśli kod jest duży, jak to często się dzisiaj zdarza - moje dwa ostatnie artykuły używały kodów zawierających około 20 000 linii kodu i opartych na transakcji. II (600 000 linii kodu) i Trilinos (1,5 mln linii) kodu). Jakie informacje udostępnia potencjalnemu czytelnikowi? (Powinienem powiedzieć, że mimo to moje kody są dostępne).

Aby znaleźć możliwe rozwiązanie tego problemu, zobacz mój projekt ActivePapers . Podsumowując, opisuje, w jaki sposób można spakować dane i kod wraz z wyraźnymi zależnościami od konkretnych wersji każdego komponentu oprogramowania. Umożliwia to dokładne odtworzenie obliczeń, jednocześnie umożliwiając uruchomienie zaktualizowanego oprogramowania na tych samych danych.

Powinienem dodać, że ActivePapers jest jedynie dowodem koncepcji i raczej nie będzie praktycznego zastosowania w najbliższej przyszłości. Powodem jest to, że opiera się na zasadzie, że cały kod wykonywalny musi istnieć jako kod bajtowy JVM. W tej chwili wyklucza to zbyt wiele popularnych bibliotek naukowych. Jednak, gdy odtwarzalność zostanie uznana za ważną, priorytety w narzędziach programistycznych również mogą ulec zmianie.

Uważam, że jeśli chodzi o wybór języka, użycie standardowego (np. C / Fortran / C ++) kwalifikuje się jako „najlepsza praktyka”. Jeśli pakiet zależy od 10 innych bibliotek / pakietów, zwłaszcza tych napisanych w nieznanych językach, to oczywiście szkodzi to długowieczności. Po pewnym czasie wiele projektów zostaje osieroconych. Nie sądzę, aby główne biblioteki lib / api, takie jak BLAS / LAPACK, PETSc, FFTW, MPI itp., Zniknęłyby w najbliższym czasie. BLAS jest już dość stary.

Poniższy fragment kodu (skradziony z http://www.math.utah.edu/software/c-with-fortran.html ) poprzedza Fortran 77, używa stałych Hollerith do manipulacji char, ale kompiluje się dobrze 40-50 lat później z kompilator 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

Otwarte pozyskiwanie / umieszczanie go gdzieś jak kod googlowy, który rzadziej wkrótce zniknie (chociaż zamknęli wyszukiwanie kodu) nie jest żadnym problemem.