Meningkatkan panjang umur arsip kode

Apakah ada daftar praktik terbaik yang dipublikasikan untuk memastikan umur kode yang panjang, dengan pandangan terhadap hasil ilmiah yang dapat direproduksi? (mis. open source, praktik dokumentasi, memilih dependensi, memilih bahasa, mesin virtual, dll).

Tahu ada studi (atau kurang itu, contoh / anekdot) yang telah mencoba memperkirakan paruh waktu kode ilmiah khas atau perangkat lunak lain (jika itu bahkan pertanyaan yang masuk akal?)

umur panjang yang direncanakan dari TeX muncul dalam pikiran:

“Sejak permulaan tahun 1977, proyek penelitian TeX yang saya jalankan didorong oleh dua tujuan utama. Tujuan pertama adalah kualitas: kami ingin menghasilkan dokumen yang tidak hanya bagus, tetapi sebenarnya yang terbaik. (...) Tujuan utama kedua adalah pengarsipan: untuk menciptakan sistem yang independen terhadap perubahan dalam teknologi cetak sebanyak mungkin. Ketika generasi berikutnya dari perangkat pencetakan datang, saya ingin dapat mempertahankan kualitas yang sama yang telah dicapai, daripada harus menyelesaikan semua masalah baru. Saya ingin merancang sesuatu yang masih dapat digunakan dalam 100 tahun. ”- Donald E. Knuth: Digital Typography, hlm. 559 (dikutip dari http://de.wikipedia.org/wiki/TeX )

Berdasarkan buku-buku Knuth tentang tipografi digital, bahkan implementasi ulang lengkap TeX dan METAFONT harus dimungkinkan. Mereka menyertakan anotasi dan penjelasan untuk semua kode.

Dengan menuntut bahwa hasil Anda harus stabil selama beberapa dekade, Anda mengalami semacam dilema pembekuan. Di satu sisi, Anda ingin membuatnya mudah mereproduksi hasil Anda 100%, sehingga Anda membekukan perangkat lunak / lingkungan Anda. Di sisi lain, seseorang yang tertarik untuk mereproduksi hasil Anda di masa depan pasti ingin membangun di atasnya. Orang ini akan terjebak dengan perangkat lunak yang sangat lama, sehingga sangat sulit untuk mengubah apa pun. Untuk apa pun yang dibangun di atas beberapa paket eksternal, sudah beberapa tahun sudah cukup untuk membuat hal-hal praktis tidak berubah.

Untuk TeX, pembekuan diumumkan pada artikel 1990

Masa depan TEX dan METAFONT http://www.ntg.nl/maps/05/34.pdf

"Saya sangat percaya bahwa sistem yang tidak berubah memiliki nilai yang besar, meskipun itu adalah aksiomatis bahwa setiap sistem yang kompleks dapat ditingkatkan. Oleh karena itu saya percaya bahwa tidak bijaksana untuk melakukan" perbaikan "lebih lanjut pada sistem yang disebut TEX dan METAFONT. Mari kita perhatikan ini sistem sebagai titik tetap, yang akan memberikan hasil yang sama 100 tahun dari sekarang yang mereka hasilkan hari ini. "

Sistem yang ideal akan menggabungkan reproduktifitas dengan perubahan. Mencoba menjadi mandiri, sesederhana dan teruji sebaik mungkin tentu membantu.

Maafkan saya jika saya terlalu banyak menyimpang dari pertanyaan awal. [cross diposting dari 'Scientists for Reproducible Research', [email protected]]

Ada banyak tantangan teknis yang membuat reproduktifitas bit-for-bit hasil komputasi yang tepat sangat sulit untuk dicapai.

Pada tingkat perangkat lunak, perubahan pada kode atau perpustakaan apa pun yang digunakan oleh kode jelas dapat menyebabkan hasil yang berbeda. Anda akan terkejut dengan jumlah pustaka dukungan yang akhirnya dapat dihubungkan dengan kode ilmiah tipikal.

Pada tingkat yang lebih rendah, kompilasi ulang salah satu kode atau perpustakaan yang digunakan oleh kode dengan kompiler baru atau dengan optimisasi kompiler yang berbeda dihidupkan juga dapat menyebabkan masalah. Salah satu alasannya adalah bahwa berbagai operasi dalam kode dapat dilakukan dalam urutan yang berbeda ketika kode tersebut dikompilasi ulang. Karena penambahan floating point tidak asosiatif (a + b) + c <> a + (b + c), ini dapat memberikan hasil yang berbeda.

OK, jadi bagaimana jika kita menjaga seluruh lingkungan perangkat lunak (OS, perpustakaan, dan kode yang dikompilasi) dengan (misalnya) membakarnya ke CD-Rom bootable yang akan menjalankan kode. Sekarang bisakah kita memastikan bahwa kita akan mendapatkan hasil yang sama jika kita menjalankan kode ini di komputer lain?

Anehnya, beberapa kode sebenarnya memvariasikan urutan perhitungan berdasarkan aspek-aspek model prosesor tertentu yang mereka jalankan. Misalnya, pustaka aljabar linier yang dioptimalkan biasanya memecah perkalian matriks untuk bekerja pada blok yang akan masuk ke dalam cache. Ketika Intel merilis mikroprosesor baru dengan cache yang lebih besar, kode mungkin secara dinamis menyesuaikan ukuran blok, menghasilkan aritmatika yang dilakukan dalam urutan yang berbeda dan memberikan hasil yang berbeda. Kode lain secara dinamis menyesuaikan urutan perhitungan berdasarkan jumlah memori yang tersedia - jika Anda menjalankan kode pada komputer dengan lebih banyak memori yang dapat menyebabkan aritmatika dilakukan dalam urutan yang berbeda dan dengan demikian memberikan hasil yang berbeda.

Banyak hal menjadi lebih rumit ketika Anda memasukkan kode multithreaded, karena riwayat eksekusi yang tepat dari utas yang berbeda sering kali tidak deterministik dan ini lagi-lagi dapat menyebabkan operasi aritmatika dilakukan dalam urutan yang berbeda dari satu putaran ke putaran berikutnya.

Dalam praktiknya, yang paling bisa Anda harapkan adalah hasil yang serupa dari satu mesin ke mesin lain, hingga toleransi akurasi dari algoritma yang digunakan. misalnya jika saya memiliki masalah pencarian root dan menggunakan pembagian dua untuk mendapatkan root dalam + -1.0e-10, maka saya harus senang selama mesin yang berbeda menghasilkan jawaban yang setuju dalam toleransi itu.

Ada banyak upaya untuk mewujudkan reproduktifitas dan ada banyak literatur tentang topik ini. Pendapat pribadi saya dari 15 tahun perangkat lunak ilmiah adalah bahwa itu tidak realistis, tidak memuaskan ketika saya menemukan jawaban itu. Masalahnya adalah (i) perangkat lunak kompleks memiliki bug sehingga tidak dapat dibekukan; (ii) perangkat lunak tidak pernah fitur lengkap dan pengembangan terus berlanjut; (iii) apa nilai pengiriman dengan kertas beberapa ratus ribu baris kode?

Seperti yang saya katakan, saya menemukan jawaban ini tidak memuaskan. Saya percaya bahwa sebagai sebuah bidang, ilmu komputasi belum terlalu berhasil dalam menghasilkan literatur yang menanamkan kepercayaan bahwa hasil yang kami terbitkan adalah benar dan dapat direproduksi. Pada saat yang sama, saya tidak dapat menemukan cara untuk melakukan hal-hal dengan lebih baik. Yang pasti, merilis kode sumber yang sesuai dengan kertas berguna. Pada saat yang sama, setiap orang yang jujur ​​akan setuju bahwa hasil dalam makalah biasanya akan diproduksi oleh versi berbeda dari kode yang, dalam banyak kasus berisi peretasan yang menggambarkan kondisi batas yang berbeda, sisi kanan yang berbeda, dll. Makalah kemudian akan datang dengan versi berbeda dari kode yang sama. Ini aneh bagi pembaca untuk memulai, tetapi sama sekali tidak produktif jika kodenya besar seperti yang sering terjadi hari ini - dua makalah saya yang terakhir menggunakan kode yang sekitar 20.000 baris kode dan yang dibuat berdasarkan kesepakatan. II (600.000 baris kode) dan Trilinos (1,5M baris) kode). Informasi apa yang diberikan kepada pembaca potensial? (Saya harus mengatakan bahwa kode saya tetap tersedia.)

Untuk solusi yang mungkin untuk masalah ini, lihat proyek ActivePapers saya . Singkatnya, ini menjelaskan bagaimana data dan kode dapat dikemas bersama dengan dependensi eksplisit pada versi spesifik dari setiap komponen perangkat lunak. Ini memungkinkan untuk mereproduksi perhitungan dengan tepat, sementara juga mengizinkan untuk menjalankan perangkat lunak yang diperbarui pada data yang sama.

Saya harus menambahkan bahwa ActivePapers tidak lebih dari bukti konsep dan tidak mungkin menjadi penggunaan praktis dalam waktu dekat. Alasannya adalah bahwa hal itu didasarkan pada prinsip bahwa semua kode yang dapat dieksekusi harus ada sebagai bytecode JVM. Saat ini, ini tidak termasuk terlalu banyak perpustakaan ilmiah populer. Namun, setelah reproduktifitas diakui sebagai hal yang penting, prioritas dalam alat pemrograman dapat berubah juga.

Saya percaya bahwa sejauh pilihan bahasa berjalan, menggunakan bahasa standar (misalnya C / Fortran / C ++) akan memenuhi syarat sebagai "praktik terbaik". Jika sebuah paket tergantung pada 10 lib / paket lain, terutama yang ditulis dalam bahasa yang tidak jelas maka itu jelas buruk untuk umur panjang. Banyak proyek yang akhirnya menjadi yatim setelah beberapa waktu. Saya tidak berpikir lib / api besar seperti BLAS / LAPACK, PETSc, FFTW, MPI dll akan menghilang dalam waktu dekat. BLAS sudah cukup tua.

Sepotong kode berikut (dicuri dari http://www.math.utah.edu/software/c-with-fortran.html ) sebelum Fortran 77, menggunakan konstanta Hollerith untuk manipulasi arang tetapi mengkompilasi dengan baik 40-50 tahun kemudian dengan 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

Buka sumber / menaruhnya di suatu tempat seperti googlecode yang kecil kemungkinannya akan segera hilang (meskipun mereka mematikan pencarian kode) adalah sesuatu yang sulit.