Apakah Haskell / Clojure sebenarnya tidak cocok untuk sistem dinamis seperti simulasi partikel?

Saya telah diberitahu dalam pertanyaan sebelumnya bahwa bahasa pemrograman fungsional tidak cocok untuk sistem dinamis seperti mesin fisika, terutama karena mahal untuk bermutasi objek. Seberapa realistis pernyataan ini, dan mengapa?

— Viktor Maia
sumber

Anda mungkin menemukan github.com/linneman/particles-clj menarik.

Due to the functional programming style the computational load will be distributed  over  the  available  CPU cores  which  can  dramatically increase processing speed in some cases

Siapa yang bilang mereka tidak cocok? Tautan ke jawaban / komentar?

— Andres F.

@ Dokkat: Saya skeptis bahwa komentator di sana tahu banyak tentang pemrograman fungsional, jujur saja. Saya akan mengambilnya dengan sebutir garam besar.

— CA McCann

Selain itu, saya juga mengabaikan jawaban yang dimulai dengan "Pendekatan fungsional murni tidak cocok untuk permainan ..." kecuali jika penulis membuktikan bahwa dia benar-benar mencoba menulis program fungsional. Jika tidak, ia hanya menebak apa yang dia pikir masalah mungkin terjadi.

— Andres F.

Pengembangan game @Dokkat memiliki kendala tambahan bukan hanya simulator partikel dan mesin fisika (yang dapat masuk dengan baik ke dalam pemrograman fungsional) - menjalankan kinerja waktu menjadi kunci untuk pengembangan game (dan lebih penting daripada fisika itu sendiri di waktu). Mesin fisika untuk perusahaan pertambangan yang memprediksi ledakan meminta akurasi lebih dari sekadar kinerja. Dengan pemrograman fungsional, lebih banyak kinerja dapat diperoleh dengan lebih mudah dengan melemparkan lebih banyak perangkat keras padanya (sesuatu yang tidak dapat dilakukan mesin game).

Jawaban:

Haskell dan Clojure memungkinkan mutabilitas yang sebenarnya, jadi itu bukan masalah.

Lebih dari itu, jika data Anda yang "bisa berubah-ubah" terdiri dari nilai-nilai menengah yang diperbarui secara bertahap sebagai bagian dari beberapa perhitungan yang lebih besar, Anda bahkan mungkin tidak perlu mutabilitas untuk menjadi efisien! Sebagai contoh, ada penelitian yang sedang berlangsung di Haskell mengenai teknik yang disebut aliran fusi , di mana kompiler sekering memproses loop, produsen data, dan konsumen data untuk menghilangkan struktur data menengah sepenuhnya.

Masalah utama dengan Haskell di sini adalah kemalasan - dalam program angka-angka di mana Anda memiliki banyak data input dan banyak data output dan semua itu penting, kemalasan yang Anda lakukan sangat sedikit nikmat tetapi masih membebankan biaya overhead. Itu tidak berarti Anda tidak dapat menulis program seperti itu di Haskell (orang-orang melakukannya, pada kenyataannya) tetapi ini tidak sesuai dengan kekuatan bahasa dan Anda perlu memiliki pemahaman yang lebih baik tentang model evaluasi untuk mendapatkan kinerja yang Anda inginkan.

Yang mengatakan, angka-angka berat tidak bermain dengan kekuatan JVM, baik. Program semacam itu adalah mengapa FORTRAN masih ada.

— CA McCann
sumber

patut dicatat: GHC versi 8.0 yang akan datang akan mendukung mode evaluasi ketat per modul.

— Erik Kaplun

Saya tidak dapat berbicara untuk Clojure, tetapi saya dapat mengatakan Haskell memiliki banyak paket IO yang sangat disetel yang tersedia yang memungkinkan semua mutasi yang Anda inginkan.

Inilah jawaban untuk pertanyaan yang saya tulis di mana seseorang merinci 3 yang paling umum dan menganggap kinerja mereka: /programming/15439966/when-why-use-an-mvar-over-a-tvar/15440286 # 15440286

Anda juga dapat melihat di sini grafik sederhana yang menunjukkan metrik kinerja server web haskell yang disebut Warp, yang merupakan aplikasi intensif IO.

Ada banyak kebingungan tentang ini tentang Haskell, sebenarnya itu memiliki fasilitas IO yang fantastis dengan banyak paket peretasan untuk menggunakan IO dalam banyak cara yang berbeda, banyak di antaranya telah sangat disetel. Alasan orang menganggap ini bukan masalahnya adalah karena Haskell berusaha keras untuk memisahkan IO dari yang lain, tetapi itu tidak berpengaruh pada karakteristik kinerja.

Namun sekarang untuk berbicara tentang karakteristik kinerja, alasan orang mengenalinya memiliki kinerja yang buruk adalah karena evaluasi yang malas menyebabkannya berperilaku dengan cara yang tidak selalu intuitif. Namun ini adalah sesuatu yang Anda harus khawatirkan jauh lebih sedikit ketika Anda mulai bekerja dalam konteks IO melakukan pembaruan yang merusak seperti dalam sistem yang Anda maksud. Lebih lanjut orang cenderung menemukan bahwa ketika mereka mengalami masalah kinerja, fasilitas yang dibangun untuk instrumen dan mengidentifikasi di mana sumber daya akan banyak membantu.

Monad lain yang layak dicari untuk sistem seperti yang Anda gambarkan adalah ST monad yang khusus untuk pembaruan destruktif yang dilakukan oleh panggilan IO yang sangat kecil sehingga memberikan kinerja yang luar biasa.

Maaf saya benar-benar tidak dapat berbicara dengan Clojure, semoga orang lain dapat memberikan rincian di sana.

— Jimmy Hoffa
sumber