Hiệu suất của Fortran

Question

Biểu diễn của Fortran trên Computer Language Benchmark Game đáng ngạc nhiên là xấu. Kết quả hôm nay đặt Fortran 14 và 11 vào hai bài kiểm tra quad-core, 7 và 10 trên các lõi đơn.

Bây giờ, tôi biết điểm chuẩn không bao giờ là hoàn hảo, nhưng vẫn là Fortran (thường là) thường được coi là ngôn ngữ cho tính toán hiệu năng cao và có vẻ như loại vấn đề được sử dụng trong điểm chuẩn này là lợi thế của Fortran. Trong một bài báo gần đây về vật lý tính toán, Landau (2008) wrote:

Tuy nhiên, [Java] không phải là hiệu quả hoặc cũng hỗ trợ cho HPC và song song chế biến cũng như FORTRAN và C, sau hai đã rất phát triển trình biên dịch và nhiều thư viện khoa học khác có sẵn . FORTRAN, đến lượt nó, vẫn là ngôn ngữ thống trị cho HPC, với FORTRAN 90/95 là một ngôn ngữ đẹp, hiện đại và hiệu quả đáng ngạc nhiên ; nhưng than ôi, nó hầu như không được giảng dạy bởi bất kỳ bộ phận CS , và trình biên dịch có thể là tốn kém.

Chỉ vì trình biên dịch được sử dụng bởi loạt đá luân lưu ngôn ngữ (trình biên dịch miễn phí của Intel dành cho Linux)?

Answer 1

Không, điều này không chỉ vì trình biên dịch.

Điểm chuẩn như thế này - nơi chương trình khác với điểm chuẩn đến điểm chuẩn - phần lớn là nỗ lực (và chất lượng nỗ lực) mà lập trình viên đưa vào viết bất kỳ chương trình nào.Tôi nghi ngờ rằng Fortran là một bất lợi đáng kể trong số liệu cụ thể đó - không giống như C và C++, nhóm các lập trình viên muốn thử làm cho chương trình chuẩn tốt hơn là khá nhỏ và không giống như bất kỳ thứ gì khác, họ có thể không cảm thấy như họ có cái gì đó để chứng minh. Vì vậy, không có động cơ cho một người nào đó dành một vài ngày poring qua mã lắp ráp tạo ra và lược tả chương trình để làm cho nó đi nhanh hơn.

Điều này khá rõ ràng so với kết quả thu được. Nói chung, với nỗ lực lập trình đầy đủ và trình biên dịch tốt, cả C, C++, cũng như Fortran sẽ chậm hơn đáng kể so với mã assembly - chắc chắn không quá 5-10%, ở mức tồi tệ nhất, ngoại trừ trường hợp bệnh lý. Thực tế là các kết quả thực tế thu được ở đây là nhiều biến thể hơn cho thấy rằng "nỗ lực lập trình đầy đủ" đã không được chi tiêu. Có những trường hợp ngoại lệ khi bạn cho phép assembly sử dụng hướng dẫn vector, nhưng không cho phép C/C++/Fortran sử dụng trình biên dịch nội tại tương ứng - vector hóa tự động thậm chí không gần đúng và có thể sẽ không bao giờ . Tôi không biết có bao nhiêu người có thể áp dụng ở đây.

Tương tự, ngoại lệ là những thứ như xử lý chuỗi, nơi bạn phụ thuộc nhiều vào thư viện thời gian chạy (có thể có chất lượng khác nhau; Fortran hiếm khi là trường hợp thư viện chuỗi nhanh sẽ kiếm tiền cho nhà cung cấp trình biên dịch!) và trên định nghĩa cơ bản về "chuỗi" và cách chuỗi đó được thể hiện trong bộ nhớ.

Answer 2

Xem xét họ đã không xuất bản các tùy chọn trình biên dịch chính xác mà họ đã sử dụng cho Trình biên dịch Intel Fortran, tôi có ít niềm tin vào điểm chuẩn của họ.

Tôi cũng nhận xét rằng cả thư viện toán học của Intel, MKL và thư viện toán học của AMD, ACML, sử dụng Trình biên dịch Intel Fortran.

Chỉnh sửa:

Tôi đã tìm thấy tùy chọn biên dịch khi bạn nhấp vào tên của điểm chuẩn. Kết quả là đáng ngạc nhiên vì mức tối ưu hóa có vẻ hợp lý. Nó có thể đi đến hiệu quả của thuật toán.

Answer 3

Vài suy nghĩ ngẫu nhiên:

Fortran sử dụng để làm rất tốt vì nó dễ dàng hơn để xác định bất biến vòng lặp mà thực hiện một số tối ưu hóa dễ dàng hơn cho các trình biên dịch. Kể từ đó,

1. Trình biên dịch đã nhận được phức tạp hơn. Nỗ lực to lớn đã được đưa vào các trình biên dịch c và C++ nói riêng. Có các trình biên dịch fortran giữ lên? Tôi cho rằng các gfortran sử dụng cùng một kết thúc trở lại của gcc và g + +, nhưng những gì của trình biên dịch intel? Nó được sử dụng để được tốt, nhưng nó vẫn còn?
2. Một số ngôn ngữ đã nhận được rất nhiều từ khóa và cú pháp chuyên biệt để giúp trình biên dịch (restricted và const int const *p trong c và inline bằng C++). Không biết fortran 90 hoặc 95 Tôi không thể nói nếu chúng có tốc độ.

Answer 4

Tôi đã xem xét các thử nghiệm này. Nó không giống như trình biên dịch là sai hoặc một cái gì đó. Trong hầu hết các thử nghiệm, Fortran có thể so sánh với C++ ngoại trừ một số nơi nó bị đánh bại bởi hệ số 10. Những thử nghiệm này chỉ phản ánh những gì người ta biết từ việc bắt đầu - rằng Fortran không đơn giản là ngôn ngữ lập trình có khả năng tương thích. tính toán, có hoạt động danh sách tốt & công cụ nhưng ví dụ IO hút trừ khi bạn đang làm nó với các phương pháp cụ thể giống như Fortran - ví dụ như 'chưa định dạng' IO.

Hãy để tôi cung cấp cho bạn một ví dụ - chương trình 'bổ sung đảo ngược' được cho là đọc một tệp lớn (có thứ tự là 10^8 B) từ dòng stdin theo dòng, thực hiện điều gì đó với nó & in kết quả là tập tin lớn để stdout. Chương trình Fortran khá căng thẳng chậm hơn khoảng 10 lần so với một lõi đơn (~ 10s) so với một C++ tối ưu hóa HEAVILY (~ 1s). Khi bạn cố gắng chơi với chương trình, bạn sẽ thấy rằng chỉ có định dạng đơn giản đọc & ghi mất hơn 8 giây. Theo cách của Fortran, nếu bạn quan tâm đến hiệu quả, bạn chỉ cần viết cấu trúc chưa được định dạng thành một tệp & đọc nó trở lại trong thời gian ngắn (không hoàn toàn không di động). nhanh & được tối ưu hóa cho một máy cụ thể, không thể chạy ở mọi nơi). Vì vậy, câu trả lời ngắn gọn là - đừng lo lắng, chỉ cần làm công việc của bạn - và nếu bạn muốn viết một hệ điều hành siêu hiệu quả, hơn xin lỗi - Fortran không phải là cách cho loại hiệu suất đó.

Answer 5

Điểm chuẩn này là ngu xuẩn.

Ví dụ: chúng đo thời gian CPU cho the whole program to run. Như mcmint stated (và nó có thể thực sự đúng) Fortran I/O sucks *. Nhưng ai quan tâm chứ? Trong các công việc trong thế giới thực, người ta đọc đầu vào trong vài giây hơn là tính toán số giờ/ngày/tháng và cuối cùng là viết kết quả đầu ra trong vài giây. Thats lý do tại sao trong hầu hết các tiêu chuẩn I/O hoạt động được loại trừ từ các phép đo thời gian (nếu bạn tất nhiên không điểm chuẩn I/O của chính nó).

Norber Wiener trong cuốn sách của mình Thiên Chúa & Golem, Inc.đã viết

Hiển thị cho mọi người những thứ thuộc về máy tính và của con người.

Theo tôi việc sử dụng nguyên tắc này trong khi thực hiện thuật toán trong bất kỳ ngôn ngữ lập trình có nghĩa là:

Viết mã như có thể đọc được và đơn giản như bạn có thể và để cho trình biên dịch thực hiện tối ưu hóa.

Đặc biệt nó quan trọng trong các ứng dụng thực tế (rất lớn). Thủ đoạn bẩn thỉu (được sử dụng rất nhiều trong nhiều điểm chuẩn) ngay cả khi chúng có thể cải thiện hiệu quả ở một mức độ nào đó (5%, có thể 10%) không dành cho các dự án trong thế giới thực.

/* C/C++ sử dụng luồng I/O, nhưng Fortran theo truyền thống sử dụng I/O dựa trên bản ghi. Further reading. Dù sao I/O trong tiêu chuẩn đó là rất đáng ngạc nhiên. Việc sử dụng chuyển hướng stdin/stdout cũng có thể là nguồn gốc của vấn đề. Tại sao không chỉ đơn giản là sử dụng khả năng đọc/ghi các tập tin được cung cấp bởi ngôn ngữ hoặc thư viện chuẩn? Một lần nữa, điều này càng trở nên thực tế hơn.

Answer 6

Tôi muốn nói rằng ngay cả khi điểm chuẩn không mang lại kết quả tốt nhất cho FORTRAN, ngôn ngữ này vẫn sẽ được sử dụng và trong một thời gian dài. Lý do sử dụng không chỉ là hiệu suất mà còn một số thứ được gọi là sự dễ dàng lập trình. Rất nhiều người đã học cách sử dụng nó vào những năm 60 và 70 giờ đã quá già để có được công cụ mới và họ biết cách sử dụng FORTRAN khá tốt. Ý tôi là, có rất nhiều yếu tố con người cho một ngôn ngữ được sử dụng. Lập trình viên cũng quan trọng.