Ngôn ngữ chức năng nhanh nhất

Gần đây tôi đã đào sâu vào lập trình chức năng, đặc biệt là Haskell và F #, trước đó cũng vậy. Sau một vài lần loay hoay, tôi không thể tìm thấy một so sánh chuẩn của các ngôn ngữ chức năng nổi bật hơn (Scala, F #, v.v.).

Tôi biết rằng nó không nhất thiết phải công bằng với một số ngôn ngữ (Scala đến với tâm trí) cho rằng chúng là giống lai, nhưng tôi chỉ muốn biết cái nào vượt trội hơn những gì hoạt động và tổng thể.

Theo Great Benchmark Game , ATS nhanh hơn phần còn lại với Haskell, Scala và một trong những biến thể của Common Lisp trong một chiếc cà vạt thô ráp cho tốc độ gần phía sau đó. Sau đó, Ocaml và F # thuộc cùng một loại tốc độ với Vợt và Clojure tụt lại phía sau ...

Tuy nhiên, hầu như không có điều này có nghĩa là bất cứ điều gì thực sự. Đó là tất cả một câu hỏi về vấn đề, máy móc, trình biên dịch, kỹ thuật mã hóa, và trong một số trường hợp, may mắn. Nói chung, các ngôn ngữ được mã hóa trực tiếp bằng máy như Haskell sẽ vượt trội hơn các ngôn ngữ được biên dịch VM như F # và vượt trội hoàn toàn so với các ngôn ngữ được giải thích thuần túy. Nói chung, các ngôn ngữ gõ tĩnh nhanh hơn gõ động do phân tích tĩnh cho phép tất cả các hoạt động loại được tính toán khi biên dịch thay vì thời gian chạy. Một lần nữa, đây là những quy tắc chung, sẽ luôn có ngoại lệ. "Nghịch lý" có rất ít liên quan đến nó.

Cũng cần chỉ ra rằng bạn không thể đo / định lượng hiệu suất của ngôn ngữ lập trình . Điều tốt nhất bạn có thể làm là đo lường hiệu suất của việc triển khai ngôn ngữ cụ thể trên các nền tảng cụ thể, chạy các chương trình cụ thể.

Vì vậy, khi bạn hỏi về "ngôn ngữ chức năng nhanh nhất", những gì bạn thực sự hỏi về cách triển khai tốt nhất của ngôn ngữ hiện tại.

Nhận xét của @ igouy nêu lên quan điểm rằng có các biện pháp thực hiện khác để thực hiện ngôn ngữ; ví dụ thời gian biên dịch. Nhưng điều đó không thay đổi thực tế rằng thời gian chạy của chương trình ứng dụng là thước đo (gián tiếp) cho việc thực hiện ngôn ngữ, không phải là thước đo của chính ngôn ngữ đó.

Hãy xem xét Java chẳng hạn. Giả sử tôi viết một điểm chuẩn đơn luồng chỉ sử dụng các tính năng ngôn ngữ của Java cổ điển (Java 1.0). Nếu tôi biên dịch và chạy bằng JDK 1.0, tôi sẽ có hiệu năng kém ('vì JDK 1.0 không có trình biên dịch mã gốc). Nếu tôi đi từ JDK 1.1 đến ... JDK 1.7, rất có thể tôi sẽ nhận được kết quả tốt hơn dần dần. Nhưng điều này không phải do thay đổi ngôn ngữ Java ... bởi vì điểm chuẩn của tôi đang sử dụng cùng một tập hợp ngôn ngữ. Thay vào đó, việc tăng tốc là do những cải tiến trong trình biên dịch, hệ thống thời gian chạy và / hoặc việc thực hiện các thư viện lớp. Đây là tất cả các vấn đề thực hiện .

Điểm khác là những khác biệt thực hiện này có thể thực sự có ý nghĩa (ví dụ: thứ tự cường độ) cho cùng một ngôn ngữ. Vì vậy, thực tế là việc triển khai tốt nhất cho ngôn ngữ X nhanh hơn so với việc thực hiện tốt nhất (hoặc duy nhất) ngôn ngữ Y không nhất thiết phải cho bạn biết nhiều về chính ngôn ngữ đó.

Nếu bạn chỉ nhìn vào các ngôn ngữ về tốc độ thực hiện, bạn đang thiếu một số điểm chính. Tốc độ là một điều tốt, nhưng nó không phải là điều duy nhất.

Haskell sử dụng một hệ thống loại rất mạnh mẽ để tạo ra các chương trình sẽ có nhiều khả năng không có lỗi và mạnh mẽ.

Erlang sử dụng hệ thống giám sát tích hợp của nó để cho phép bạn tạo các hệ thống lỗi có thể cung cấp cho bạn mức độ tin cậy rất lớn khi đối mặt với các loại lỗi khác nhau. Ngoài ra, Erlang có thể cung cấp cho bạn một mức độ tương tranh khó có thể sánh được với các ngôn ngữ khác.

Trong thực tế, tôi sẽ coi tốc độ thực hiện trong thời hiện đại là khá xa trong danh sách những gì tôi sẽ xem xét trong hầu hết các trường hợp. (OK nếu tôi đang thực hiện tính toán số lượng lớn, tôi có thể muốn sử dụng fortran cho tốc độ nhưng nếu không thì nó không đủ quan trọng để quan trọng)