CLR của F # và C# giống nhau tại sao F # nhanh hơn C#

Question

Tôi bối rối và sẽ đánh giá cao nếu bạn khai sáng cho tôi. F # sử dụng cùng một CLR như C# và mã cơ bản là giống nhau thì làm thế nào người ta có thể gợi ý rằng một hàm chạy nhanh hơn khi được viết bằng F # so với C#? Nếu tôi chỉ sử dụng các biến không thay đổi trong C# và hiệu năng cần phải càng cao càng tốt thì tại sao lại sử dụng F #?

Answer 1

Có this câu hỏi về stackoverflow một số thời gian trước đây, nó có thể giúp bạn tìm ra một số lý do tại sao F # có thể nhanh hơn. Hiệu suất đạt được phụ thuộc rất nhiều vào ứng dụng và các tính năng mã hóa bạn đang sử dụng mặc dù.

Answer 2

Có thể có một số lý do mã được viết bằng một ngôn ngữ nhanh hơn mã được viết bằng ngôn ngữ khác, ngay cả khi chúng sử dụng cùng một thư viện thời gian chạy. Tuy nhiên, thư viện thời gian chạy .NET không phải là thư viện thời gian chạy duy nhất có liên quan. Như tôi đã hiểu, có một thư viện thời gian chạy khá lớn F # thực hiện những thứ có F # -specific. Trình biên dịch F # biết về thư viện đó. Trình biên dịch C# không. Vì vậy trình biên dịch F # có thể thực hiện các cuộc gọi đến mã thư viện thời gian chạy được tối ưu hóa cao mà trình biên dịch C# không có quyền truy cập.

Nếu cả hai đều sử dụng cùng một bộ thư viện thời gian chạy, thì tôi cho rằng các chương trình sẽ gần giống nhau, nhưng không chính xác. Các trình biên dịch riêng lẻ có thể tạo ra ít hoặc nhiều mã tối ưu cho các cấu trúc cụ thể.

Answer 3

1) Nếu bạn viết mã C# và mã F # được biên dịch thành chính xác cùng một IL (ngôn ngữ trung gian của CLR), thì mã sẽ hiển thị các đặc tính hiệu suất giống nhau. Tuy nhiên, việc thực hiện cùng một thuật toán trong C# và F # không đảm bảo rằng chính xác cùng một IL sẽ được tạo ra, vì vậy hiệu năng thế giới thực có thể thay đổi. Tôi tin rằng trong thực tế đôi khi mã F # sẽ nhanh hơn nhưng lần khác C# sẽ nhanh hơn.

2) Có nhiều lý do để chọn ngôn ngữ triển khai ngoài hiệu suất. Ví dụ, một số người tìm thấy F # để gọn gàng hơn, dễ đọc hơn và dễ dàng hơn lý do hơn C# cho một số miền vấn đề nhất định, đó sẽ là một lý do để thích nó. Đối với phần lớn các chương trình, sự khác biệt 5% hoặc 10% về hiệu suất sẽ không thể nhận thấy đối với người dùng, vì vậy nếu một ngôn ngữ cung cấp hiệu suất tương đương gần nhưng năng suất cao thì sẽ có ý nghĩa khi sử dụng ngôn ngữ đó.

Answer 4

Bạn có thể quan tâm đến bài viết Performance-Related Features in F# and C#. Đối với "lý do tại sao sử dụng F #" Tôi không thể nói cho bạn, nhưng đối với bản thân mình tôi sử dụng F # vì tôi thích nó tốt hơn.

Answer 5

mã cơ bản giống hệt nhau? Nghi ngờ. Nói chung, F # sẽ nhanh hơn ở một số thứ và chậm hơn ở những thứ khác. Điều này cũng đúng với C#. Hoặc thậm chí VB. Mỗi ngôn ngữ đều có điểm cộng. Nếu có một hiệu suất tổng thể cộng với trong hầu hết các lĩnh vực, nó nằm trong trình biên dịch.

Nếu tôi chỉ sử dụng các biến không thay đổi trong C# và hiệu suất cần càng cao càng tốt thì tại sao lại sử dụng F #? Không có lý do để chuyển đổi cho hiệu suất một mình, nếu trong thực tế có một sự khác biệt thực sự, trừ khi perf là ​​vấn đề của bạn. Theo như tại sao chuyển đổi nếu bạn chỉ sử dụng các tính năng tốt trong C#, tôi sẽ nói "không chuyển đổi".

Tôi thích F #. Có một số "vấn đề" nó giải quyết tốt hơn nhiều so với C#. Nhưng, ngay cả khi tôi có một vấn đề nó giải quyết tốt hơn, tôi không nhất thiết phải chuyển đổi, vì tôi phải xem xét các nhà phát triển trong hỗn hợp. Hiện tại, tôi biết rất ít trong tổ chức này biết bất cứ điều gì về F #, vì vậy tôi sẽ phải thực hiện một trường hợp kinh doanh tốt để chuyển đổi.

Cuối cùng, bạn phải xem xét "vấn đề kinh doanh" và xác định đường dẫn. Bạn phải xem xét ngôn ngữ "tốt hơn" như một phần của bản mix, nhưng bạn cũng phải kiểm tra năng lực cốt lõi, v.v.

Answer 6

Câu trả lời không phải là hiệu suất về tốc độ hoặc tài nguyên BC chúng gần như giống nhau. Một số cải tiến và nhược điểm được tranh luận ... Lý do cho F # là thời gian phát triển và triển khai. F # được sắp xếp hợp lý hơn và mong muốn xây dựng với mã an toàn hơn. Ít sai sót và chính xác hơn mà không phải lo lắng về những thứ đơn giản như vòng lặp quầy và kiểm tra loại, qua luồng vv Vì vậy nó không chỉ dễ dàng hơn và nhanh hơn để viết nhưng ít lỗi hơn. Bạn nhận được nhiều hơn những gì bạn thực sự muốn mà không cần lo lắng về những điều nhỏ nhặt. Điều này có nghĩa là ít thử nghiệm và triển khai trực tiếp hơn, mã đáng tin cậy hơn và các chức năng chính xác hơn không mang chi phí không cần thiết. Do đó, kết quả cuối cùng là mã được viết nhanh hơn, hiệu năng được tối ưu hóa theo bản chất, và tin cậy như nhau với ít lỗi hơn.

Answer 7

Không có lý do gì để chuyển đổi nhưng tôi đề xuất các thành phần được xây dựng để đáp ứng các tiêu chuẩn tốt nhất. F # thực thi rất nhiều tiêu chuẩn, làm cho việc kiểm tra thời gian thực trong quá trình phát triển đơn giản, và chữa các vấn đề về khả năng biến đổi, phụ thuộc vòng tròn, cũng như hầu hết các tham chiếu kiểm tra kiểu/null. C# mặt khác có phần lớn các nhà phát triển và các công cụ và có thể được phát triển với một mô hình chức năng trong tâm trí nhưng không phải luôn luôn chính xác. Tôi là một C# fan và hầu như luôn luôn chọn C# nhưng tôi thấy nhiều lần khi F # là những gì tôi cần nhất để xây dựng mã mạnh mẽ hơn. Tôi đoán, cá nhân tôi thích pha trộn hai ngôn ngữ khi tôi có thể nhưng như đã đề cập, điều quan trọng hơn là làm việc với những gì nhóm dev của bạn cũng có thể duy trì và xem xét. Trong nhiều tình huống, nhóm dev sẽ chống lại nó nhưng trong một số họ sẽ cho nó bởi vì họ cũng muốn không chỉ làm cho cơ sở mã càng mạnh càng tốt mà còn học được những điều mới. Chỉ cần không lãng phí quá nhiều thời gian quyết định ngôn ngữ chính xác, nếu bạn chắc chắn F # là tốt nhất, trình bày nó và xem bạn có một sự đồng thuận để hoàn thành nó theo cách đó không. Giữ cho dự án của bạn riêng biệt, ngay cả khi chúng nằm trong cùng một giải pháp và sử dụng F # khi nó hoạt động tốt nhất và C# khi nó hoạt động tốt nhất. F # không phải là khó để tìm hiểu, nhưng với một nhà phát triển hoàn toàn bắt buộc nó có thể trông xấu xí và khó hiểu lúc đầu. Chỉ cần giải thích nó một số và tôi nghĩ rằng nó được bóng lăn. Thời gian để xem xét F # sẽ được trong các thuật toán mà bạn không chỉ muốn thực hiện nhưng ngay lập tức thử nghiệm các kết quả. Điều này tăng tốc thời gian và thời gian chạy, giành chiến thắng. Những người khác có thể là mô hình nếu các mô hình bao gồm nhiều giá trị bất biến. F # hoạt động trong mọi lĩnh vực nhưng đối với tôi giao diện người dùng được thực hiện dễ dàng hơn trong C# cũng như những thứ như ViewModels nơi logic hơi khác nhưng đó là một ý kiến. Bạn sẽ ngạc nhiên trước những lợi ích bạn nhận được từ sự kết hợp ngọt ngào của cả hai. Bên cạnh đó, lập trình chức năng trở nên dễ dàng hơn với cú pháp C#, LINQ, và C# mới, trong đó C# về cơ bản có vẻ chức năng nên độ cao của bạn để sử dụng F # có thể không khó khăn như năm trước.
Tôi đã không bao gồm bất cứ điều gì để tối đa nhưng bạn có được ý tưởng ... F # là mạnh mẽ, sử dụng nó khi nó hoạt động tốt nhất và giống nhau cho C#. Tôi bắt đầu với VB.NET nhưng sẽ không khuyên bạn nên nó nữa đơn giản chỉ vì công nghệ mới hơn như .NET Core không hỗ trợ nó. Tuy nhiên, đó cũng là một lợi ích để sử dụng nó vào những thời điểm ... Mặc dù nó ít hơn nhiều so với lợi ích của F #. Về vấn đề đó, tôi chỉ dính vào hai nguyên tố C#, F #. Một điều nữa, đừng để một đường cong học tập ngăn cản bạn trở thành tốt nhất ... Gần đây tôi đã phỏng vấn Wells Fargo không ít tiền lương tốt hơn, những người đang cập nhật hệ thống kế thừa để cắt 4.6.2 .NET và họ từ chối để chấp nhận cú pháp async/await bc quá nhiều để học và họ nói đó chỉ là cú pháp cú pháp ... (oh dear) Điều đó đối với tôi là một câu nói hay, nói rằng chúng ta thích sử dụng cái mới và làm cái cũ là một sai lầm lớn, đặc biệt là đối với các dự án lớn. Đừng để một dự án lớn bị phân nửa do đường cong học tập nhỏ. Kỹ sư được xây dựng để tìm hiểu và nâng cấp không chỉ để duy trì di sản trong thời hiện đại.