Bagaimana kode basis angka besar berbasis Fortran dapat dimodernisasi?

Seorang teman di dunia akademis meminta saran kepada saya (saya adalah seorang pengembang aplikasi bisnis C #).

Dia memiliki basis kode warisan yang dia tulis di Fortran di bidang pencitraan medis. Itu sejumlah besar angka-angka menggunakan vektor. Dia menggunakan cluster (30ish core) dan sekarang telah menuju satu workstation tunggal dengan 500ish GPUS di dalamnya.

Namun ke mana harus pergi berikutnya dengan basis kode jadi:

• Orang lain dapat mempertahankannya selama siklus 10 tahun berikutnya
• Lebih cepat mengutak-atik perangkat lunak
• Dapat berjalan pada infrastruktur yang berbeda tanpa kompilasi ulang

Setelah beberapa penelitian dari saya (ini adalah bidang yang sangat menarik) beberapa pilihan adalah:

• Gunakan Python dan CUDA dari Nvidia
• Menulis ulang dalam bahasa fungsional. Misalnya, F # atau Haskell
• Pergi berbasis cloud dan gunakan sesuatu seperti Hadoop dan Java
• Pelajari C

Apa pengalaman Anda dengan ini? Apa yang harus dilihat teman saya untuk memodernisasi basis kode-nya?

PEMBARUAN: Terima kasih @ark dan semua orang yang telah menjawab. Alasan teman saya mengajukan pertanyaan ini adalah karena ini adalah waktu yang tepat dalam siklus hidup proyek untuk melakukan peninjauan. Membawa asisten peneliti hingga kecepatan di Fortran membutuhkan waktu (saya suka C #, dan terutama tooling dan tidak bisa membayangkan kembali ke bahasa yang lebih tua !!)

Saya menyukai saran menjaga angka murni berderak di Fortran, tetapi membungkusnya dengan sesuatu yang lebih baru. Mungkin Python sebagai yang tampaknya mendapatkan benteng di dunia akademis sebagai bahasa pemrograman tujuan umum yang cukup mudah diambil.

Lihat Medical Imaging dan seorang pria yang telah menulis pembungkus Fortran untuk CUDA, dapatkah saya menerbitkan pembungkus Fortran 90 saya secara legal ke perpustakaan CUFFT Nvidias (dari CUDA SDK)? .

Tuntutan yang Anda masukkan sebenarnya menempatkan Fortran di bagian atas daftar, untuk masalah seperti ini:

a) angka berderak
b) dapat ditangguhkan
c) itu dan masih merupakan bahasa de facto diajarkan di luar studi cs (untuk insinyur yang bukan programmer profesional).
d) memiliki dukungan industri yang luar biasa (!), jumlah penyusun tingkat industri, dengan tidak ada vendor yang menunjukkan tanda-tanda paling sedikit meninggalkan cabang itu. Salah satu perwakilan Intel belum lama ini mengungkapkan bahwa penjualan produk Fortran mereka lebih tinggi daripada yang lain dalam alat pengembangan mereka.

Ini juga merupakan bahasa yang sangat mudah diambil. Saya tidak setuju bahwa perlu waktu untuk mempercepat asisten peneliti. Buku teks pertamaku di dalamnya tidak lebih dari, oh, aku tidak tahu, 30 (?) Halaman teks yang jarang dicetak. Ini adalah bahasa di mana setelah mempelajari 10 kata kunci, seseorang dapat menulis program ukuran sedang. Saya berani mengatakan bahwa 30 halaman yang ditulis dalam teks Word standar akan membuat "manual Fortran" yang lebih komprehensif untuk sebagian besar pengguna.

Jika Anda tertarik pada CUDA, Anda mungkin ingin memeriksa kompiler Portland Group , yang mendukungnya . Saya tidak terbiasa dengan detail yang lebih halus, tetapi orang umumnya membicarakannya dengan pujian.

Selain itu, untuk program paralel, Anda memiliki OpenMP, MPI, dan sekarang co-array yang akan datang (dan sudah lama ditunggu-tunggu), yang baru-baru ini diterapkan oleh kompiler Intel . Untuk tidak membuang-buang kata, Fortran memiliki gamma "perpustakaan" yang sangat bagus untuk memparalelkan program.

Perpustakaan numerik standar industri dikembangkan untuk itu terutama, bahasa lain mengikuti kurang lebih dalam portofolio fungsi / rutinitas.

Semua yang dikatakan, saya akan (tergantung pada saat awalnya ditulis) merekomendasikan jika itu katakanlah, kode F77 atau lebih tua, menulis ulang sebagian melalui waktu ke dialek yang lebih baru - setidaknya F90, jika mungkin dengan fitur F2003. Sebuah makalah / tesis tentang topik itu baru-baru ini diterbitkan (file PDF ukuran sedang di depan). Tidak hanya itu, jika dilakukan dengan benar, memastikan portabilitas di beberapa platform, tetapi juga akan membuatnya lebih mudah untuk pemeliharaan di masa depan.

PS Sejauh "pemeliharaan masa depan" berjalan, hanya sebuah anegdote yang kadang-kadang saya suka sebutkan. Saat menulis tesis saya, saya menggunakan kembali beberapa kode dari mentor saya, yang ditulis 35 tahun yang lalu sejak saat penulisan. Ini dikompilasi dengan hanya satu kesalahan; pernyataan hilang di bagian akhir, karena kesalahan penyalinan :)

@DaveMateer (balas komentar) - Saya akan memberikan komentar di bawah ini yang mungkin agak tidak sopan, tapi tolong jangan salah paham, karena itu adalah niat yang adil.

Sepertinya saya Anda menangani "masalah" ini dengan cara yang salah. Apa yang saya maksudkan dalam beberapa poin singkat (karena sudah sangat terlambat di sini, dan kemampuan saya untuk membuat kalimat yang dapat dibaca (apalagi dimengerti) membuat saya setelah pukul 10 malam)

a) Anda menyebutkan Anda mencoba meminimalkan waktu pengkodean tambahan, namun Anda sedang mempertimbangkan penulisan ulang dari bahasa yang dikhususkan untuk komputasi numerik menjadi satu dari pilihan bahasa yang penuh warna , jika Anda akan memaafkan ekspresi saya

• beberapa di antaranya tidak memiliki dukungan untuk array multidimensi, antara lain
• kebanyakan dari mereka tidak cocok untuk pekerjaan numerik berat (kemampuan pemrosesan paralel Haskell dan Hadoop saya akui, saya tidak tahu apa-apa tentang ... tetapi belum pernah mendengar mereka bahkan disebutkan di kalangan itu)
• mungkin telah dicoba, tetapi saya belum pernah mendengar penulisan ulang dari Fortran, bahasa untuk masalah yang didiskritisasi, ke bahasa fungsional
• telah ada diskusi baru-baru ini di comp.lang.fortran (coba cari melalui grup google) pada aspek komputasi ilmiah "di awan"
  (tidak ingin memotivasi Anda, tetapi untuk bersikap adil, tidak ada yang benar-benar yakin apa istilah itu bahkan mewakili, kurang sendiri memiliki contoh aplikasi yang sukses. Sebagian besar orang setuju bahwa ada potensi tetapi sejauh ini mereka senang cara kerjanya sekarang.). Banyak masalah yang tidak cocok untuk paralisis semacam itu juga.

b) berapa biaya penulisan ulang seperti itu? orang / jam.

c) - versi yang benar dari perpustakaan untuk dikompilasi ...- adalah masalah dalam bahasa apa pun, yang tidak dapat dihindari, namun Anda melihatnya.

d) Saya pernah mendengar tentang Python (bahasa yang sangat bagus) yang digunakan dalam aplikasi paralel pada beberapa kesempatan, tetapi penetrasi pasar itu tampaknya tidak meningkat, dan sifatnya yang terus berubah menjadikannya pilihan yang sangat buruk untuk proyek jangka panjang (pikirkan kompatibilitas ke belakang). Beberapa orang sangat menyukainya sebagai bahasa "perekat".

Ugh, jika saya memikirkan hal lain, akan menambahkannya besok. Harus tidur ...

Saya ragu Fortran akan pernah mati - ia memiliki banyak sekali perangkat lunak dan lib yang ditulis di dalamnya sehingga orang-orang masih mengerjakannya, hanya menstabilkan situasi ini. Selain itu masih merupakan bahasa yang sangat baik jika Anda tidak ingin melakukan apa pun selain angka-angka - sintaksisnya sangat elegan dan logis, ditambah kompiler dapat dengan mudah menebak apa yang terjadi. Dengan demikian dijamin bahwa setiap teknologi akselerator perangkat keras baru akan mendukung C, Fortran dan semacam OpenCL (ketika akhirnya akan menyatu dengan sesuatu yang solid).

Jadi saya akan mengatakan Anda harus memisahkan bagian numerik dengan jelas, meninggalkannya di Fortran, membuat ikatan yang jelas dan menulis sisanya dalam apa pun yang Anda inginkan.

Python memang mendapatkan banyak daya tarik dalam komunitas komputasi ilmiah (untuk tampilan yang agak ketinggalan zaman, lihat volume 9 nomor 3 dari CiSE ). Saya pikir hibrida Python / Fortran adalah cara terbaik untuk pergi. Untuk memanfaatkan semua GPU itu, Anda bisa menggunakannya PyCUDA atau PyOpenCL .

Saya seorang ahli matematika yang menganalisis dan menulis pemecah numerik untuk persamaan diferensial parsial. Saya baru-baru ini dalam situasi yang sama dengan teman Anda; kode Fortran 77 yang dimaksud adalah yang terkenal perangkat lunak Clawpack yang . Kami menulis ulang kode tingkat atas (semua bagian yang tidak perlu cepat) dengan Python dan menggunakan f2py untuk secara otomatis membungkus bagian tingkat rendah.

Hasil yang sangat kuat dari ini adalah bahwa kami kemudian dapat menghubungkan hampir sepele kode hybrid Python / Fortran (dijuluki PyClaw ) dengan perpustakaan paralel PETSc, menciptakan untuk pertama kalinya versi paralel yang dapat diskalakan dari Clawpack yang berkinerja baik pada 65K core. Semua kode paralel yang harus kami tulis terkandung dalam kurang dari 300 baris Python . Kami sekarang sedang memecahkan masalah yang tidak mungkin diselesaikan hanya dengan kode lawas. Sama pentingnya, sekarang lebih mudah bagi pengguna baru untuk mengambil kode, karena Python adalah bahasa yang ramah dan hampir semuanya dapat dimodifikasi pada saat dijalankan daripada waktu kompilasi.

Jika Anda ingin melihat lebih detail dari pendekatan dan hasil kami, kami punya makalah tentang arXiv .

Permintaan maaf untuk iklan-sendiri, tetapi tampaknya pengalaman pribadi saya akan relevan di sini. Jika Anda ingin mendengar lebih banyak ide, Anda dapat memposting ini juga di http://scicomp.stackexchange.com baru .

Saya saat ini dalam situasi yang sangat mirip dengan teman Anda. Saya juga ingin "memodernisasi" kode warisan 40-sesuatu KLOC Fortran-77 saya. Dan meskipun Fortran masih dianggap sebagai raja dalam aplikasi angka, saya ingin mengatakan bahwa semuanya tidak hilang. (Berikut ini adalah kata-kata kasar jadi bersabarlah dengan saya).

Hanya karena Fortran adalah bahasa terbaik untuk kode numerik, tidak berarti kita harus membawa bagasi besar yang berantakan dan rumit ini bersama kita sepanjang waktu (Ya, kode Fortran pasti berantakan, terutama Fortran-77 yang merupakan bahasa yang secara harfiah tidak memedulikan rekayasa perangkat lunak, ketika melintasi KLOC tertentu). Mereka yang mengadvokasi Fortran untuk angka-angka lupa pengamatan umum bahwa ketika Anda melakukan analisis kinerja kode seperti itu, hanya 5% atau 10% dari kode yang intensif kinerja dan sisanya 90% + Fortran adalah overhead yang tidak berguna, hanya di sana untuk menjadikan hidup Anda sebagai "insinyur perangkat lunak" seperti neraka.

Ketika Anda pindah ke Fortran-90 dari Fortran-77, Anda pada dasarnya bersedia untuk menukar kinerja dengan fitur bahasa hingga batas tertentu. Fortran adalah pembuat angka yang kuat terutama karena Fortran-77. Anda mungkin mengatakan Fortran-90 secepat, tetapi jenis masalah optimasi penulis kompiler harus berurusan dengan sambil menambahkan fitur Fortran-90/2003 dan tetap menjaga kinerja Fortran-77 tidak jauh berbeda dari masalah yang harus ditangani oleh penulis kompiler C dengan (dan sebagai hasilnya C dianggap juga cepat, belum lagi C memungkinkan inline-assembly juga). Jadi mengapa tidak mulai menambahkan kode C sedikit demi sedikit (bukan Fortran-90) ke dalam kode Fortran-77. Kode saya sudah memiliki kepingan dalam C dan kepingan di Fortran-77 dan itu berfungsi sangat baik untuk beberapa masalah seperti melewati string, nol-pengindeksan / satu-pengindeksan dll. Tapi keuntungan yang saya dapatkan dari C,

Saya akan melangkah lebih jauh. Bahkan C (dan tentunya Fortran-90/95/2003) terlalu rendah levelnya jika Anda menginginkan antarmuka "manusiawi" yang bagus untuk kode angka-angka. Saya sedang berpikir untuk pindah ke hibrida Python-Fortran-77 atau Python-C. Kode di mana 90% dari kode adalah Python (termasuk Numpy, Scipy, plotability, dan semua yang manis) dan hanya intensif kinerja 5% -10% tetap sebagai Fortran-77 atau kode C.

Saat ini saya sedang dalam proses memperbarui basis kode FORTRAN95 lama untuk digunakan pada lingkungan industri modern karena versi sebelumnya hanya akan berjalan pada mesin Windows2000 paling lambat. Basis kode FORTRAN sendiri melakukan sejumlah besar angka-angka yang terlibat dengan simulasi irigasi.

Jadi yang saya lakukan adalah alih-alih menulis ulang FORTRAN dalam bahasa yang lebih modern, saya hanya menggunakan kompiler komersial yang disebut Silverfrost FTN95 untuk mengkompilasi basis kode FORTRAN ke perpustakaan .Net 4.0 yang saya gunakan sebagai backend aplikasi WPF . Dengan cara ini saya tidak menjalankan risiko membawa bug yang dikenal ke dalam kode simulasi dan saya memodernkannya dengan memindahkan basis kode ke kerangka .Net 4.0 sehingga akan berjalan di lingkungan yang lebih modern.

Tetapi tergantung pada seberapa besar simulasi Anda, Anda mungkin ingin hanya cukup menulis ulang semuanya dalam bahasa yang lebih modern seperti C #, saya sendiri berencana untuk melakukan ini setelah saya memiliki versi simulasi yang berjalan untuk membandingkan keluaran.

Semoga pengalaman saya membantu, Terima kasih, Alex.

Saya memimpin dev pada proyek dari 2001-2003 yang porting aplikasi windows 100KLOC dari FORTRAN ke C #. Itu adalah aplikasi pengolah angka yang memiliki binding GUI khusus untuk pustaka Win32. Port ke C # dan WinForms membuat pengelolaan kode jauh lebih sederhana dan memberi semua orang lingkungan pengembangan yang lebih kaya di Visual Studio. Ada sedikit perlawanan awal (terutama dalam hal pernyataan format), tetapi pada akhirnya itu pasti bermanfaat.

Menurut pendapat saya masuk akal untuk menggigit peluru dan menyingkirkan jumlah maksimum kode FORTRAN mungkin. Kecepatan tidak pernah menjadi masalah - tes awal menjalankan kode dalam C # dibandingkan dengan FORTRAN menemukan perbedaan kinerja dapat diabaikan, meskipun C # menjalankan kode yang dikelola. Namun, kebutuhan Anda dengan vektor mungkin sedikit berbeda, dan memiliki sedikit kode FORTRAN yang tersisa juga dapat diterima.

Alasan lain untuk melakukannya tentu saja adalah ketersediaan jangka panjang dari orang-orang dengan pengalaman FORTRAN yang dapat mempertahankan kode Anda dibandingkan dengan pengembang C #. Juga, ini membantu semangat tim untuk bekerja dalam bahasa modern yang didukung dengan baik.

Saya telah diberitahu bahwa dalam banyak konteks, MATLAB menggantikan FORTRAN untuk aplikasi komputasi ilmiah. Tidak hanya modern dan tingkat tinggi, ini juga cukup cepat dalam fungsinya. Banyak pengembang yang bekerja pada perangkat lunak pencitraan medis sudah menggunakan MATLAB, sehingga memiliki beberapa perpustakaan yang didedikasikan untuk imajinasi medis. Ini berarti Anda akan menemukan alat dan dukungan pakar domain jika Anda menggunakan MATLAB.