Tăng tuổi thọ lưu trữ của mã

Có một danh sách được công bố về các thực tiễn tốt nhất để đảm bảo tuổi thọ của mã, hướng đến các kết quả khoa học có thể tái tạo? (ví dụ nguồn mở, thực hành tài liệu, chọn phụ thuộc, chọn ngôn ngữ, máy ảo, v.v.).

Biết về bất kỳ nghiên cứu nào (hoặc thiếu đó, ví dụ / giai thoại) đã cố gắng ước tính thời gian bán hủy của mã khoa học điển hình hoặc phần mềm khác (nếu đó thậm chí là một câu hỏi hợp lý?)

tuổi thọ dự kiến ​​của TeX xuất hiện trong tâm trí:

Kể từ khi bắt đầu vào năm 1977, dự án nghiên cứu TeX mà tôi bắt đầu thực hiện được thúc đẩy bởi hai mục tiêu chính. Mục tiêu đầu tiên là chất lượng: chúng tôi muốn tạo ra những tài liệu không chỉ đẹp mà còn thực sự tốt nhất. (Hoài) Mục tiêu chính thứ hai là lưu trữ: tạo ra các hệ thống độc lập với những thay đổi trong công nghệ in càng nhiều càng tốt. Khi thế hệ tiếp theo của thiết bị in xuất hiện, tôi muốn có thể giữ lại chất lượng tương tự đã đạt được, thay vì phải giải quyết tất cả các vấn đề một lần nữa. Tôi muốn thiết kế một cái gì đó vẫn có thể sử dụng được trong 100 năm. Mùi - Donald E. Knuth: Kiểu chữ kỹ thuật số, tr. 559 (trích từ http://de.wikipedia.org/wiki/TeX )

Dựa trên các cuốn sách của Knuth về kiểu chữ kỹ thuật số, thậm chí có thể thực hiện lại hoàn toàn TeX và METAFONT. Chúng bao gồm các chú thích và giải thích cho tất cả các mã.

Bằng cách yêu cầu rằng kết quả của bạn sẽ ổn định trong nhiều thập kỷ, bạn sẽ rơi vào tình trạng khó xử đóng băng. Một mặt, bạn muốn làm cho nó dễ dàng tái tạo kết quả của bạn 100%, vì vậy bạn đóng băng phần mềm / môi trường của bạn. Mặt khác, ai đó quan tâm đến việc tái tạo kết quả của bạn trong tương lai chắc chắn sẽ muốn xây dựng dựa trên nó. Người này sẽ bị mắc kẹt với phần mềm rất cũ, khiến cho việc thay đổi bất cứ điều gì trở nên rất khó khăn. Đối với bất cứ điều gì được xây dựng trên một số gói bên ngoài, một vài năm là đủ để làm cho mọi thứ thực tế không thể thay đổi.

Đối với TeX, đóng băng được công bố trong bài viết năm 1990

Tương lai của TEX và METAFONT http://www.ntg.nl/maps/05/34.pdf

"Tôi tin tưởng mạnh mẽ rằng một hệ thống không thay đổi có giá trị lớn, mặc dù điều đó là tiên quyết rằng bất kỳ hệ thống phức tạp nào cũng có thể được cải thiện. các hệ thống như các điểm đã xác định, sẽ cho kết quả tương tự 100 năm kể từ bây giờ chúng tạo ra ngày hôm nay. "

Hệ thống lý tưởng sẽ kết hợp khả năng tái tạo với khả năng thay đổi. Cố gắng là khép kín, đơn giản và được kiểm tra tốt nhất có thể chắc chắn sẽ giúp ích.

Xin lỗi nếu tôi đã vi phạm quá nhiều từ câu hỏi ban đầu. [đăng chéo từ 'Các nhà khoa học cho nghiên cứu sinh sản', tái sản xuất-research@googlegroups.com]

Có rất nhiều thách thức kỹ thuật khiến cho khả năng tái tạo bit-bit-bit chính xác của các kết quả tính toán cực kỳ khó đạt được.

Ở cấp độ phần mềm, các thay đổi đối với mã hoặc bất kỳ thư viện nào được sử dụng bởi mã rõ ràng có thể gây ra các kết quả khác nhau được tạo ra. Bạn sẽ ngạc nhiên bởi số lượng thư viện hỗ trợ cuối cùng có thể được liên kết thành một mã khoa học điển hình.

Ở cấp độ thấp hơn, biên dịch lại bất kỳ mã nào hoặc bất kỳ thư viện nào được sử dụng bởi mã với trình biên dịch mới hoặc với các tối ưu hóa trình biên dịch khác nhau được bật cũng có thể gây ra sự cố. Một lý do là các hoạt động khác nhau trong mã có thể được thực hiện theo một thứ tự khác khi mã được biên dịch lại. Vì phép cộng dấu phẩy động không liên kết (a + b) + c <> a + (b + c), điều này có thể cho kết quả khác nhau.

OK, vậy nếu chúng ta bảo vệ toàn bộ môi trường phần mềm (HĐH, thư viện và mã được biên dịch) bằng cách (ví dụ) ghi nó vào đĩa CD-Rom có ​​thể khởi động sẽ chạy mã. Bây giờ chúng ta có thể chắc chắn rằng chúng ta sẽ nhận được kết quả tương tự nếu chúng ta chạy mã này trên một máy tính khác không?

Đáng ngạc nhiên, một số mã thực sự thay đổi thứ tự tính toán dựa trên các khía cạnh của mô hình bộ xử lý cụ thể mà chúng đang chạy. Ví dụ, các thư viện đại số tuyến tính được tối ưu hóa thường phá vỡ các phép nhân ma trận để làm việc trên các khối sẽ phù hợp với bộ đệm. Khi Intel phát hành bộ vi xử lý mới với bộ đệm lớn hơn, mã có thể tự động điều chỉnh kích thước khối, dẫn đến số học được thực hiện theo thứ tự khác nhau và cho kết quả khác nhau. Các mã khác tự động điều chỉnh thứ tự tính toán dựa trên dung lượng bộ nhớ khả dụng - nếu bạn chạy mã trên máy tính có nhiều bộ nhớ hơn có thể khiến số học được thực hiện theo thứ tự khác và do đó cho kết quả khác nhau.

Mọi thứ trở nên phức tạp hơn đáng kinh ngạc khi bạn ném mã đa luồng, vì lịch sử thực hiện chính xác của các luồng khác nhau thường không mang tính quyết định và điều này một lần nữa có thể khiến các phép toán số học được thực hiện theo thứ tự khác nhau từ lần chạy này sang lần chạy tiếp theo.

Trong thực tế, hầu hết những gì bạn thực sự có thể hy vọng là các kết quả tương tự từ máy này sang máy khác, cho đến dung sai chính xác của các thuật toán được sử dụng. ví dụ: nếu tôi gặp vấn đề tìm kiếm gốc và sử dụng phép chia đôi để lấy gốc trong vòng + -1.0e-10, thì tôi nên vui mừng miễn là các máy khác nhau tạo ra câu trả lời đồng ý trong phạm vi dung sai đó.

Đã có nhiều nỗ lực để làm cho khả năng tái tạo xảy ra và có cả một tài liệu về chủ đề này. Ý kiến ​​cá nhân của tôi từ 15 năm về phần mềm khoa học là nó không thực tế, không thỏa đáng như tôi thấy câu trả lời đó. Vấn đề là (i) phần mềm phức tạp có lỗi và do đó không thể bị đóng băng; (ii) phần mềm không bao giờ là tính năng hoàn chỉnh và vì vậy sự phát triển vẫn tiếp tục; (iii) giá trị của việc phân phối với một tờ giấy vài trăm ngàn dòng mã là gì?

Như tôi nói, tôi thấy câu trả lời này không thỏa đáng. Tôi tin rằng với tư cách là một lĩnh vực, khoa học tính toán đã không thành công lắm trong việc sản xuất văn học mà thấm nhuần niềm tin rằng kết quả chúng tôi công bố là chính xác và có thể tái tạo. Đồng thời, tôi không thể thực sự nghĩ ra cách nào để làm mọi thứ tốt hơn. Chắc chắn, phát hành mã nguồn đi kèm với một tờ giấy là hữu ích. Đồng thời, mọi người trung thực sẽ đồng ý rằng các kết quả trong một bài báo thường sẽ được tạo ra bởi các phiên bản mã khác nhau, trong hầu hết các trường hợp có chứa các bản hack mô tả các điều kiện biên khác nhau, các mặt bên phải khác nhau, v.v. đi kèm với các phiên bản khác nhau của cùng một mã. Điều này gây khó xử cho người đọc khi bắt đầu, nhưng hoàn toàn không có tác dụng nếu mã lớn như ngày nay thường xảy ra - hai bài báo gần đây nhất của tôi đã sử dụng mã có khoảng 20.000 dòng mã và được xây dựng trên deal.II (600.000 dòng mã) và Trilinos (dòng 1.5M mã). Những thông tin nào cung cấp cho một người đọc tiềm năng? (Tôi nên nói rằng mã của tôi vẫn có sẵn.)

Để biết giải pháp khả thi cho vấn đề này, hãy xem dự án ActivePapers của tôi . Tóm lại, nó mô tả cách dữ liệu và mã có thể được đóng gói cùng với các phụ thuộc rõ ràng vào các phiên bản cụ thể của từng thành phần phần mềm. Điều này cho phép tái tạo chính xác một tính toán, đồng thời cho phép chạy phần mềm cập nhật trên cùng một dữ liệu.

Tôi nên thêm rằng ActivePapers không hơn gì một bằng chứng về khái niệm và không có khả năng sử dụng thực tế trong tương lai gần. Lý do là nó dựa trên nguyên tắc tất cả các mã thực thi phải tồn tại dưới dạng mã byte JVM. Hiện tại, điều này loại trừ quá nhiều thư viện khoa học phổ biến. Tuy nhiên, một khi khả năng tái tạo được công nhận là quan trọng, các ưu tiên trong các công cụ lập trình cũng có thể thay đổi.

Tôi tin rằng theo như sự lựa chọn của ngôn ngữ, sử dụng một ngôn ngữ được tiêu chuẩn hóa (ví dụ C / Fortran / C ++) sẽ đủ điều kiện là "thực hành tốt nhất". Nếu một gói phụ thuộc vào 10 lib / gói khác, đặc biệt là các gói được viết bằng ngôn ngữ tối nghĩa thì điều đó rõ ràng là không tốt cho tuổi thọ. Nhiều dự án cuối cùng đã mồ côi sau một thời gian. Tôi không nghĩ các lib / api lớn như BLAS / LAPACK, PETSc, FFTW, MPI, vv sẽ biến mất bất cứ lúc nào sớm. BLAS đã khá cũ.

Đoạn mã sau (bị đánh cắp từ http://www.math.utah.edu/software/c-with-fortran.html ) có trước Fortran 77, sử dụng hằng số Hollerith để thao tác char nhưng chỉ biên dịch tốt 40-50 năm sau với Trình biên dịch 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

Tìm nguồn mở / đưa nó lên một nơi nào đó như googlecode mà ít có khả năng biến mất sớm (mặc dù họ đã tắt tìm kiếm mã) là không có trí tuệ.