Увеличение долговечности архива кода

Существует ли опубликованный список лучших практик, обеспечивающих долговечность кода, с учетом воспроизводимых научных результатов? (например, открытый исходный код, практика документирования, выбор зависимостей, выбор языка, виртуальные машины и т. д.).

Знайте о каких-либо исследованиях (или об их отсутствии, примерах / анекдотах), в которых пытались оценить период полураспада типичного научного кода или другого программного обеспечения (если это даже разумный вопрос?)

Запланированная долговечность 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. Давайте рассмотрим эти системы как фиксированные точки, которые через 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, который с меньшей вероятностью скоро исчезнет (хотя они отключили поиск по коду), не составляет труда.