Không phải mô hình chức năng quá khác nhau với phần cứng cơ bản nói chung là hiệu quả?

Lấy cảm hứng từ một câu hỏi từ SO: /programming/6623391/how-to-gain-control-of-a-5gb-heap-in-haskell

Nó có thể là một cuộc tranh luận dài về nhiều ưu điểm và nhược điểm của FP, nhưng hiện tại, tôi muốn thu hẹp phạm vi đối với hiệu quả chính của FP trên phần cứng hiện đại.

Luận văn:

Mô hình chức năng ngụ ý tính bất biến và không trạng thái (?), Nhưng phần cứng chúng tôi chạy các chương trình chức năng trên là automata hữu hạn trạng thái. Dịch chương trình 'chức năng thuần túy' sang đại diện 'phần cứng trạng thái' để lại ít quyền kiểm soát cho lập trình viên, mang lại chi phí hoạt động (?) Và hạn chế sử dụng các khả năng của phần cứng (?).

Tôi đúng hay sai trong các câu hỏi?

Có thể chứng minh rằng FP không / không bao hàm các hình phạt hiệu suất chính đối với kiến ​​trúc máy tính đa năng hiện đại?

EDIT: Như tôi đã nêu khi trả lời một số ý kiến, câu hỏi không phải là về hiệu suất và chi tiết thực hiện. Đó là về sự hiện diện hoặc vắng mặt của chi phí chính , hoạt động của FP trên automata trạng thái có thể mang lại.

Có một sự hiểu lầm rất lớn trong sự bất biến.

Tính bất biến là một đặc điểm của ngữ nghĩa, nhưng nó không bao hàm sự bất biến trong việc thực hiện.

Một ví dụ đơn giản là việc thực hiện sự lười biếng.

Khi tính toán lười biếng, kết quả của một biểu thức về mặt khái niệm là một giá trị, nhưng việc triển khai cơ bản là một thunk chứa các đối số được ước tính và một hàm để tạo giá trị, cũng như một vị trí để lưu trữ giá trị.

Lần đầu tiên bạn sẽ hỏi (bằng ngôn ngữ) về giá trị, việc tính toán sẽ thực sự được thực hiện, kết quả được đánh giá và giá trị được trả lại cho bạn (hoặc một tay cầm).

Điều này là minh bạch trong ngữ nghĩa ngôn ngữ và tất cả những gì bạn biết là biến này đã được liên kết với một giá trị (hoặc giá trị tương lai) và một khi đã xong, bạn không thể thay đổi giá trị sẽ được trả về. Biểu diễn bộ nhớ cơ bản sẽ thay đổi, nhưng bạn sẽ không biết về nó.

Sự khác biệt về ngữ nghĩa / triển khai giống nhau tồn tại ở bất kỳ ngôn ngữ nào và trên thực tế là cốt lõi của việc tối ưu hóa . Dù là ngôn ngữ nào, ngữ nghĩa đảm bảo một số thứ, nhưng để lại những thứ khác không xác định để rời khỏi phòng để tối ưu hóa.

Bây giờ, đúng là các ngôn ngữ chức năng thực tế không nhanh như C ++, chẳng hạn. Tuy nhiên, Go(vẫn khá cường điệu) chậm hơn Haskell hoặc Lisp, và C # Mono cũng vậy ( nguồn ) cũng vậy.

Khi bạn thấy C ++ hoặc C không đáng tin cậy như thế nào để có được những màn trình diễn đó, bạn có thể muốn cho đi một chút.

Khi bạn nhận ra rằng Haskell đang phát triển nhanh ngày hôm nay và vẫn còn nhiều chỗ để tối ưu hóa trong trình biên dịch / thời gian chạy của nó (ví dụ GHC mới chuyển sang LLVM, Microsoft Research đang tích cực tài trợ cho các cải tiến thời gian chạy), bạn có thể sẵn sàng đặt cược rằng nó sẽ sớm được cải thiện

Thú vị: Chơi trên Biểu thức chính quy hoặc cách nhóm Haskell tạo trình so khớp biểu thức chính quy vượt trội hơn re2, thư viện C từ Google, trong một số tình huống.

Mô hình chức năng là hữu ích để phân chia mọi thứ trong một phạm vi hẹp. Đây là một điều thực sự tốt khi xem xét cách thức máy tính phát triển.

CPU đa lõi có vấn đề lớn liên quan đến tài nguyên được chia sẻ và chi phí đồng bộ hóa thực sự rất cao. Mô hình chức năng cho phép một cách tự nhiên để thể hiện các chương trình không có vấn đề. Điều này thực sự tốt cho song song.

Ngoài ra, chúng tôi đang sử dụng các trang trại máy chủ ngày càng nhiều hơn với SaaS và điện toán đám mây. Do đó, cùng một ứng dụng phải chạy trên một số máy. Ở vị trí này, chi phí đồng bộ hóa thậm chí còn tốn kém hơn. Google đã thực hiện một số công việc và xuất bản một số tài liệu nghiên cứu về lập trình và thuật toán chức năng mà bạn có thể viết. Đây là một điều quan trọng đối với họ vì họ có vấn đề về sai lầm.

Hơn nữa, bạn có thể dễ dàng thực hiện một ngăn xếp trong đống máy tính và thậm chí là một ngăn không liên tục bằng cách sử dụng danh sách được liên kết. Điều này được thực hiện để tạo dấu vết ngăn xếp trong nhiều ngôn ngữ lập trình. Vì vậy, đây không phải là một vấn đề.

OK, lập trình chức năng ngụ ý một số hạn chế. Nhưng nó cũng mang lại cách tự nhiên để diễn đạt các vấn đề chúng ta có trong tính toán hiện đại, điều cực kỳ khó xử lý trong các mô hình wa được sử dụng. Khả năng mở rộng là một trong số đó, và nó đang trở thành một vấn đề thực sự.

Mọi người đã đối phó với một hệ thống song song phức tạp đều biết tôi đang nói về cái gì.

Vì vậy, tôi sẽ sắc thái câu trả lời. Vâng, chức năng có vấn đề với phần cứng hiện đại, nhưng lập trình cũ đơn giản cũng có một số. Như mọi khi, bạn sẽ tìm thấy lợi thế và nhược điểm. Vấn đề là phải biết chúng là gì để bạn có thể đưa ra lựa chọn phù hợp khi bạn phải.

Tôi thực sự không có câu trả lời, vì tôi không biết trạng thái hiện tại hoặc thậm chí là khó khăn như thế nào, nhưng chỉ vì trình biên dịch sẽ đảm bảo những điều đó từ đầu vào, không nhất thiết có nghĩa là đầu ra sẽ có chúng . Về lý thuyết, một trình biên dịch đủ thông minh có thể bằng cách vượt qua tất cả các vấn đề này, nhưng trong thực tế, nó có thể sẽ luôn tồn tại.

Tuy nhiên, một cách khác để xem xét nó là nhìn vào lịch sử của máy Lisp. Nếu tôi nhớ lại một cách chính xác, ban đầu chúng được thiết kế để vượt qua những vấn đề tương tự mà Lisp gặp phải với sự khác biệt so với các máy móc vào thời điểm đó. Sự phát triển của những chiếc máy này cuối cùng đã dừng lại, vì máy tính để bàn trở nên đủ nhanh để làm cho sự thiếu hiệu quả để sống rẻ hơn so với việc hỗ trợ một máy khác.

Nói chung, ngoại trừ ứng dụng quan trọng nhất về hiệu năng, các ngôn ngữ FP vẫn đủ nhanh. Chọn bất kỳ ngôn ngữ cấp cao hơn, bạn sẽ sẵn sàng hạ mức ưu tiên về kiểm soát và hiệu suất tinh chỉnh để an toàn hơn, dễ dàng hơn, dễ bảo trì hơn hoặc một số ưu tiên khác.

Cuối cùng, lập trình là tất cả về sự đánh đổi, vì vậy người ta chỉ cần chọn những gì quan trọng hơn cho dự án trong tay.

Đúng là mô hình chức năng ngụ ý sự bất biến và không trạng thái, nhưng chúng ta không có bất kỳ ngôn ngữ lập trình hoàn toàn thuần túy nào. Ngay cả tinh khiết nhất, Haskell, cho phép tác dụng phụ.

Điều đó nói rằng, để trả lời câu hỏi của bạn về hiệu quả, tôi đã sử dụng cả Haskell và Clojure và không nhận thấy bất kỳ vấn đề nào về hiệu suất.