Bukankah paradigma fungsional terlalu berbeda dengan perangkat keras yang mendasari agar efisien secara umum?

Terinspirasi oleh pertanyaan dari SO: /programming/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

Ini bisa menjadi perdebatan panjang tentang berbagai kelebihan dan kekurangan FP, tetapi untuk sekarang, saya ingin mempersempit ruang lingkup efisiensi utama FP pada perangkat keras modern.

Tesis:

Paradigma fungsional menyiratkan kekekalan dan kewarganegaraan (?), Tetapi perangkat keras yang kita jalankan program fungsionalnya adalah stateata automata terbatas. Penerjemahan program 'fungsional murni' ke representasi 'stateful hardware' menyisakan sedikit kendali bagi programmer, membawa overhead (?) Dan membatasi penggunaan kapabilitas perangkat keras (?).

Apakah saya benar atau salah dalam pernyataan yang dipertanyakan?

Bisakah dibuktikan bahwa FP tidak / tidak menyiratkan hukuman kinerja utama pada arsitektur komputer serba guna modern?

EDIT: Seperti yang sudah saya nyatakan dalam menanggapi beberapa komentar, pertanyaannya bukan tentang kinerja dan detail implementasi. Ini tentang ada atau tidaknya overhead pokok , yang menjalankan FP pada stateata automata dapat membawa.

Ada kesalahpahaman besar dalam hal kekekalan.

Keabadian adalah fitur semantik, tetapi itu tidak menyiratkan keabadian dalam implementasi.

Contoh sederhana adalah penerapan kemalasan.

Ketika perhitungan malas, hasil dari ekspresi secara konseptual adalah nilai, tetapi implementasi yang mendasarinya adalah thunk yang berisi argumen untuk dievaluasi dan fungsi untuk menciptakan nilai, serta slot untuk menyimpan nilai dalam.

Pertama kali Anda akan bertanya (dalam bahasa) untuk nilainya, perhitungan akan benar-benar dilakukan, hasilnya dievaluasi, dan nilai yang diberikan kembali kepada Anda (atau pegangan).

Ini transparan dalam semantik bahasa, dan yang Anda tahu adalah bahwa variabel ini telah terikat dengan nilai (atau nilai masa depan) dan bahwa setelah selesai Anda tidak dapat mengubah nilai yang akan dikembalikan. Representasi memori yang mendasarinya akan berubah, tetapi Anda tidak akan mengetahuinya.

Perbedaan semantik / implementasi yang sama ada dalam tentang bahasa apa pun, dan sebenarnya merupakan inti dari optimasi . Apa pun bahasanya, semantik menjamin beberapa hal, tetapi biarkan yang lain tidak ditentukan untuk meninggalkan ruang untuk pengoptimalan.

Sekarang, memang benar bahwa bahasa fungsional praktis tidak secepat C ++, misalnya. Namun, Go(yang masih cukup hype) lebih lambat dari Haskell atau Lisp, dan begitu juga C # Mono ( sumber ).

Saat Anda melihat betapa tidak dapat diandalkannya C ++ atau C untuk membuat Anda mendapatkan kinerja itu, Anda mungkin ingin sedikit melepaskannya.

Ketika Anda menyadari bahwa Haskell tumbuh cepat hari ini, dan masih ada banyak ruang untuk optimasi dalam kompiler / runtime-nya (GHC baru saja beralih ke LLVM misalnya, Microsoft Research secara aktif mendanai perbaikan runtime), Anda mungkin berani bertaruh bahwa itu akan segera membaik.

Kegembiraan: Permainan pada Ekspresi Reguler atau bagaimana tim Haskell membuat pencocokan ekspresi reguler yang mengungguli re2, perpustakaan C dari Google, dalam sejumlah skenario.

Paradigma fungsional berguna untuk membagi hal dalam lingkup yang sempit. Ini adalah hal yang sangat bagus mengingat bagaimana komputer berkembang.

CPU Multicore memiliki masalah besar dalam berurusan dengan sumber daya bersama dan biaya sinkronisasi sangat mahal. Paradigma fungsional memungkinkan cara alami untuk mengekspresikan program yang tidak memiliki masalah. Ini sangat bagus untuk paralelisme.

Selain itu, kami menggunakan server farm semakin banyak dengan SaaS dan cloud computing. Dengan demikian, aplikasi yang sama harus dijalankan pada beberapa mesin. Dalam posisi ini, biaya sinkronisasi bahkan lebih mahal. Google telah melakukan beberapa pekerjaan dan menerbitkan beberapa makalah penelitian tentang pemrograman fungsional dan algoritma yang dapat Anda tulis. Ini adalah hal utama bagi mereka karena mereka memiliki masalah skalabilitas.

Selain itu, Anda dapat dengan mudah melakukan tumpukan di tumpukan komputer, dan bahkan yang tidak kontinu menggunakan daftar tertaut. Ini juga telah dilakukan untuk menghasilkan jejak stack dalam banyak bahasa program. Jadi ini bukan masalah.

OK, pemrograman functionnal menyiratkan beberapa batasan. Tetapi itu juga membawa cara alami untuk mengekspresikan problematika yang kita miliki dalam komputer modern, yang sangat sulit untuk ditangani dalam paradigma yang biasa digunakan. Skalabilitas adalah salah satunya, dan itu menjadi masalah nyata.

Setiap orang yang sudah berurusan dengan sistem paralel yang kompleks tahu apa yang saya bicarakan.

Jadi saya akan nuansa jawabannya. Ya, fungsional memiliki masalah dengan perangkat keras modern, tetapi pemrograman lama juga memiliki beberapa. Seperti biasa, Anda akan menemukan kelebihan dan kekurangan. Intinya adalah untuk mengetahui apa itu sehingga Anda dapat membuat pilihan yang tepat ketika Anda harus.

Saya tidak benar-benar memiliki jawaban, karena saya tidak tahu keadaan saat ini atau bahkan betapa sulitnya, tetapi hanya karena kompiler akan memastikan hal-hal dari input, tidak berarti bahwa output akan memilikinya . Secara teori, kompiler yang cukup pintar bisa melewati semua masalah ini, tetapi dalam praktiknya, mungkin akan selalu ada.

Namun, cara lain untuk melihatnya adalah dengan melihat sejarah mesin Lisp. Jika saya ingat dengan benar, mereka pada awalnya dirancang untuk mengatasi masalah yang sama yang dimiliki Lisp dengan perbedaannya dari mesin pada saat itu. Pengembangan mesin ini akhirnya berhenti, karena desktop menjadi cukup cepat untuk membuat inefisiensi lebih murah untuk hidup daripada mendukung mesin lain.

Secara umum, kecuali untuk aplikasi paling kritis kinerja, bahasa FP masih cukup cepat. Memilih bahasa tingkat tinggi mana pun, Anda akan bersedia menurunkan prioritas pada kendali fine tune dan kinerja untuk lebih aman, lebih mudah, lebih dapat dipelihara, atau beberapa prioritas lainnya.

Pada akhirnya, pemrograman adalah tentang pertukaran, jadi kita hanya perlu memilih apa yang lebih penting untuk proyek yang ada.

Memang benar bahwa paradigma fungsional menyiratkan keabadian dan kewarganegaraan, tetapi kami tidak memiliki bahasa pemrograman yang sepenuhnya murni. Bahkan yang paling murni, Haskell, memungkinkan efek samping.

Yang mengatakan, untuk menjawab pertanyaan Anda tentang efisiensi, saya telah menggunakan Haskell dan Clojure, dan belum melihat ada masalah kinerja dengan baik.