Збільшення архівної довговічності коду

Чи є опублікований перелік найкращих практик щодо забезпечення довговічності коду з огляду на відтворювані наукові результати? (наприклад, з відкритим кодом, практикою документації, вибором залежностей, вибором мови, віртуальних машин тощо).

Знати про будь-які дослідження (чи їх бракує, приклади / анекдоти), які намагалися оцінити період напіввиведення типового наукового коду чи іншого програмного забезпечення (якщо це навіть розумне питання?)

приходить в очі заплановане довголіття TeX:

«Починаючи з тих початків у 1977 році, дослідницький проект TeX, який я взяв на себе, був зумовлений двома основними цілями. Першою метою була якість: ми хотіли виготовити документи, які були не просто приємними, а насправді найкращими. (...) Другою основною метою було архівне: створити системи, які були б максимально незалежними від змін технології друку. Коли з'явилися друкарські пристрої наступного покоління, я хотів зберегти ту ж якість, що вже досягнута, замість того, щоб вирішувати всі проблеми заново. Я хотів спроектувати щось, що було б корисним ще через 100 років. ”- Дональд Е. Кнут: Цифрова типографія, с. 559 (цитується з http://de.wikipedia.org/wiki/TeX )

На підставі книг Кнута про цифрову типографіку має бути можливим навіть повне реалізація TeX і METAFONT. Вони містять примітки та пояснення до всього коду.

Вимагаючи, щоб ваші результати були стабільними протягом десятиліть, ви потрапляєте у своєрідну замерзаючу дилему. З одного боку, ви хочете, щоб на 100% було легше відтворювати свої результати, тому ви заморожуєте програмне забезпечення / оточення. З іншого боку, той, хто зацікавлений у відтворенні ваших результатів у майбутньому, неодмінно захоче базуватися на цьому. Ця людина буде застряг із дуже старим програмним забезпеченням, що дуже важко щось змінити. Для всього, що базується на декількох зовнішніх пакетах, вже достатньо кількох років, щоб зробити речі практично незмінними.

Для TeX заморожування оголошено в статті 1990 року

Майбутнє TEX та METAFONT http://www.ntg.nl/maps/05/34.pdf

"Я переконаний, що незмінна система має велику цінність, навіть якщо це аксіоматично, що будь-яка складна система може бути вдосконалена. Тому я вважаю, що нерозумно робити подальші" вдосконалення "в системах під назвою TEX та METAFONT. системи, як fi xed крапки, які повинні дати ті самі результати за 100 років від того, що вони виробляють сьогодні ».

Ідеальна система поєднала б відтворюваність із змінністю. Намагатися бути максимально автономним, простим і добре перевіреним, безумовно, допомагає.

Вибачте мене, якщо я занадто сильно відступаю від початкового питання. [крос, опублікований у статті "Вчені для відтворюваних досліджень", reproducible-research@googlegroups.com]

Існує безліч технічних проблем, які роблять точну відтворюваність обчислювальних результатів вкрай важко досягти.

На програмному рівні зміни коду або будь-якої бібліотеки, що використовується кодом, очевидно можуть спричинити отримання різних результатів. Ви здивуєтеся кількості бібліотек підтримки, які можуть зв'язатись із типовим науковим кодом.

На нижчому рівні перекомпіляція будь-якого коду або будь-якої з бібліотек, використовуваних кодом, з новим компілятором або з увімкненою різною оптимізацією компілятора, також може спричинити проблеми. Однією з причин є те, що різні операції з кодом можуть виконуватися в іншому порядку, коли код перекомпілюється. Оскільки додавання з плаваючою комою не є асоціативним (a + b) + c <> a + (b + c), це може дати різні результати.

Гаразд, що робити, якщо ми збережемо все програмне середовище (ОС, бібліотеки та скомпільований код) шляхом (наприклад) запису його на завантажувальний CD-Rom, який запустить код. Тепер ми можемо бути впевнені, що ми отримаємо однакові результати, якщо запустити цей код на іншому комп’ютері?

Дивно, але деякі коди фактично змінюють порядок обчислень на основі аспектів конкретної моделі процесора, на якій вони працюють. Наприклад, оптимізовані бібліотеки лінійної алгебри зазвичай розбивають матричні множення для роботи над блоками, які впишуться в кеш. Коли Intel випускає новий мікропроцесор з більшим кешем, код може динамічно регулювати розмір блоку, що призводить до арифметики, яка виконується в іншому порядку і дає різні результати. Інші коди динамічно регулюють порядок обчислень, виходячи з обсягу наявної пам’яті - якщо ви запускаєте код на комп’ютері з більшою кількістю пам’яті, що могло б спричинити арифметику в іншому порядку і таким чином давати різні результати.

Речі стають напрочуд складнішими при введенні багатопотокового коду, оскільки точна історія виконання різних потоків часто не є детермінованою, і це може знову спричинити виконання арифметичних операцій в іншому порядку від одного запуску до іншого.

На практиці найбільше, на що ви можете сподіватися, - це результати, подібні від однієї машини до другої, аж до точності допуску використовуваних алгоритмів. Наприклад, якщо у мене є проблема з кореневим знаходженням і використовую бісекцію, щоб отримати корінь в межах + -1,0e-10, то я повинен бути щасливим, якщо різні машини дають відповіді, які згодні в межах цієї допуску.

Було багато спроб домогтися відтворення, і є ціла література на цю тему. Моя особиста думка з 15 років наукового програмного забезпечення полягає в тому, що це нереально, настільки незадовільно, як я вважаю цю відповідь. Проблеми полягають у тому, що (i) складне програмне забезпечення має помилки, і тому їх неможливо заморозити; (ii) програмне забезпечення ніколи не є повноцінним, і тому розвиток триває; (iii) яка цінність доставки з папером декількох сотень тисяч рядків коду?

Як я кажу, я вважаю цю відповідь незадовільною. Я вважаю, що обчислювальна наука не була дуже успішною у створенні літератури, яка вселяє довіру, що результати, які ми публікуємо, є правильними та відтворюваними. У той же час я не можу реально придумати способи зробити щось краще. Безумовно, вивільнення вихідного коду, який йде разом з папером, є корисним. У той же час кожен, хто чесний, погодиться з тим, що результати в документі зазвичай створюються різними версіями коду, які в більшості випадків містять хаки, що описують різні граничні умови, різні праві сторони тощо. поставляються з різними версіями одного і того ж коду. Для читача це незручно, але це абсолютно непродуктивно, якщо код великий, як це часто трапляється сьогодні - в моїх двох останніх документах були використані коди, які містять близько 20 000 рядків коду, і які ґрунтуються на deal.II (600 000 рядків коду) і Trilinos (1,5 млн рядків коду). Яку інформацію надає потенційному читачеві? (Я повинен сказати, що мої коди все-таки доступні.)

Для можливого вирішення цієї проблеми дивіться мій проект ActivePapers . Підсумовуючи це, описується, як дані та код можуть бути упаковані разом із явними залежностями від конкретних версій кожного компонента програмного забезпечення. Це дає можливість точно відтворити обчислення, одночасно дозволяючи запускати оновлене програмне забезпечення на одних і тих же даних.

Варто додати, що ActivePapers - це не що інше, як доказ концепції, і навряд чи буде корисним у найближчому майбутньому. Причина полягає в тому, що він заснований на принципі, що весь виконуваний код повинен існувати як байт-код JVM. На даний момент це виключає занадто багато науково-популярних бібліотек. Однак, коли відтворюваність буде визнана важливою, пріоритети в інструментах програмування можуть змінитися.

Я вважаю, що в частині вибору мови, використання стандартизованої (наприклад, C / Fortran / C ++) було б кваліфіковано як "найкраща практика". Якщо пакет залежить від 10 інших вкладок / пакетів, особливо тих, які написані незрозумілими мовами, то це, очевидно, погано для довголіття. Багато проектів через деякий час залишаються сиротами. Я не думаю, що великі губи / api, такі як BLAS / LAPACK, PETSc, FFTW, MPI тощо, незабаром зникнуть. BLAS вже досить старий.

Наступний фрагмент коду (викрадений з http://www.math.utah.edu/software/c-with-fortran.html ) передує Fortran 77, використовує константи Голлеріта для маніпуляцій із чар, але збирається чудово 40-50 років потому компілятор 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

Відкрити пошук / поставити його кудись, як googlecode, який, швидше за все, зникне незабаром (хоча вони закрили пошук коду) - це не головне.