C ++ vs Fortran cho HPC


56

Trong chương trình tiến sĩ khoa học tính toán của tôi, chúng tôi hầu như chỉ làm việc trong C ++ và Fortran. Có vẻ như một số giáo sư thích cái này hơn cái kia. Tôi đang tự hỏi cái nào là 'tốt hơn' hoặc cái nào tốt hơn cái kia trong một hoàn cảnh nhất định.


12
Theo tôi, sự kết hợp của một ngôn ngữ cấp cao và cấp thấp tốt hơn là sử dụng một trong hai ngôn ngữ. Ví dụ: tôi sử dụng Python + C ++.
Faheem Mitha

2
Các câu trả lời cho câu hỏi này sẽ gần như hoàn toàn chủ quan và do đó tôi không chắc câu hỏi này có phù hợp không.
Jeff

Câu trả lời:


61

Như thường lệ, sự lựa chọn phụ thuộc vào (1) vấn đề bạn đang cố gắng giải quyết, (2) các kỹ năng bạn có và (3) những người bạn làm việc cùng (trừ khi đó là một dự án solo). Tôi sẽ để (3) sang một bên vì điều này phụ thuộc vào hoàn cảnh cá nhân của mọi người.

Vấn đề phụ thuộc: Fortran vượt trội trong xử lý mảng. Nếu vấn đề của bạn có thể được mô tả theo các cấu trúc dữ liệu đơn giản và trong các mảng cụ thể, Fortran thích nghi tốt. Các lập trình viên Fortran cuối cùng sử dụng các mảng ngay cả trong các trường hợp không rõ ràng (ví dụ để biểu diễn các biểu đồ). C ++ phù hợp hơn với các cấu trúc dữ liệu phức tạp và rất năng động.

Sự phụ thuộc về kỹ năng: cần nhiều kinh nghiệm lập trình để viết các chương trình C ++ tốt hơn là viết các chương trình Fortran tốt. Nếu bạn bắt đầu với ít kinh nghiệm lập trình và chỉ có quá nhiều thời gian để tìm hiểu khía cạnh công việc đó, bạn có thể nhận được lợi tức đầu tư tốt hơn khi học Fortran so với học C ++. Tất nhiên, giả sử rằng vấn đề của bạn phù hợp với Fortran.

Tuy nhiên, có nhiều thứ để lập trình hơn là chỉ Fortran và C ++. Tôi muốn giới thiệu cho bất kỳ ai đi vào khoa học tính toán để bắt đầu với một ngôn ngữ cấp cao năng động như Python. Luôn nhớ rằng thời gian của bạn có giá trị hơn thời gian của CPU!


17
"Luôn nhớ rằng thời gian của bạn có giá trị hơn thời gian của CPU!" Là một người làm việc trong HPC, tôi không đồng ý với phần đó; mọi thứ khác là tại chỗ.
Levi Morrison

19
"Luôn nhớ rằng thời gian của bạn có giá trị hơn thời gian CPU!" Là một người làm việc trong nghiên cứu khoa học, tôi không thể đồng ý nhiều hơn với phần đó.
quyết định

3
"Luôn nhớ rằng thời gian của bạn có giá trị hơn thời gian của CPU!" - Tôi muốn ném 2 xu của mình - sử dụng vài trăm nút, mỗi nút có hơn 10 lõi để chạy một số chương trình trong vài tuần có thể được hiểu là sự lãng phí khủng khiếp của một tài nguyên quý giá nhất, nếu một vài tuần nữa có thể tạo ra một mã chỉ chạy trong một vài ngày. Những cụm HPC đó là một tài nguyên chung hiếm và đắt tiền.
Dani_l

"Luôn nhớ rằng thời gian của bạn có giá trị hơn thời gian của CPU!", Mã trong một tuần nhưng chạy trong một tháng, điều này khá bình thường thưa ông!
fronthem

6
"Luôn nhớ rằng thời gian của bạn có giá trị hơn thời gian của CPU!", Tôi thà viết mã trong một tháng và chạy trong một tuần! - nhiều hơn có thể được thực hiện khi mã được viết và những người khác sẽ tìm thấy mã bạn viết cũng hữu ích hơn.
Charles

37

Tôi nghĩ rằng cả C ++ và Fortran đều đủ tốt và hoạt động tốt.

Tuy nhiên, tôi nghĩ rằng Fortran tốt hơn cho điện toán khoa học số , cho các thuật toán có thể được biểu thị bằng mảng và không cần các cấu trúc dữ liệu phức tạp khác, vì vậy trong các trường như khác biệt / phần tử hữu hạn, bộ giải PDE, tính toán cấu trúc điện tử. Fortran là một ngôn ngữ cụ thể miền. Đặc biệt tôi nghĩ rằng việc viết các chương trình nhanh ở Fortran dễ dàng hơn so với trong C ++, bởi một nhà khoa học (không nhất thiết phải là chuyên gia khoa học máy tính).

C ++ là ngôn ngữ có mục đích chung, vì vậy người ta có thể diễn đạt bất kỳ thuật toán nào trong đó và chắc chắn tốt hơn cho các thuật toán không thể được biểu diễn bằng mảng, từ trường HPC có thể là một số biểu đồ, trình tạo lưới, thao tác biểu tượng, v.v.

Cũng có thể viết các thuật toán mảng trong C ++, nhưng theo kinh nghiệm của tôi, nó đòi hỏi nhiều kiến ​​thức khoa học máy tính hơn và nói chung là nhiều công việc hơn (tức là người ta cần tạo hoặc sử dụng lại các lớp để thao tác mảng và xử lý quản lý bộ nhớ bằng tay hoặc sử dụng một số thư viện như Teuchos từ Trilinos). Những người không phải là chuyên gia có xu hướng viết các chương trình Fortran khá tốt, nhưng các chương trình C ++ khủng khiếp (nói từ kinh nghiệm của riêng tôi).

Tuyên bố miễn trừ trách nhiệm: Cá nhân tôi thích Fortran rất nhiều và tôi thích nó hơn C ++ cho điện toán số. Tôi đã dành hơn 2 năm lập trình trong C ++ hàng ngày và gần một năm lập trình trong Fortran hiện đại hàng ngày (trong khu vực các yếu tố hữu hạn). Tôi cũng sử dụng Python và Cython rất nhiều.


1
Một trong những câu trả lời đầu tiên được cân bằng. Tôi nghĩ rằng C ++ và Fortran cho đến nay không phải là những khả năng duy nhất trong HPC đương đại. Tôi nghĩ thật tốt khi biết điểm mạnh và điểm yếu khi bạn quyết định chọn Fortran, C ++ hoặc Python (hoặc bất cứ điều gì bạn thích). Tôi đã thấy 20.000 dòng Fortran trong một tệp duy nhất, được phát triển một cách hữu cơ trong một vài thập kỷ. Cá nhân tôi sẽ không sử dụng cho bất cứ thứ gì ngoài máy tính mảng nặng bị cô lập. Thậm chí không cho bất cứ điều gì liên quan đến đầu ra. Cho đến nay cho một bình luận thiên vị.
shuhalo

6
Tôi không thể không đồng ý với phản hồi này nhiều hơn. Mã phần tử hữu hạn của chúng tôi sẽ không thể viết bằng Fortran. Trên thực tế, nó đã bắt đầu từ 15 năm trước dưới dạng hỗn hợp của C và Fortran đơn giản (phần sau dành cho các phần chuyên sâu về số lượng của phương thức), và nó dần dần chuyển sang C thuần túy và sau đó chuyển sang C ++ trong vài năm. Mã này luôn luôn ngắn hơn, nhanh hơn và dễ hiểu hơn và nó có khả năng hơn sau mỗi lần lặp. Tôi đồng ý với những người khác chỉ ra rằng C ++ cung cấp cho bạn rất nhiều dây để tự bắn. Chọn ngôn ngữ bạn thấy thoải mái nhất.
Bill Barth

6
Bill, bạn đã sử dụng Fortran hiện đại (bổ sung 90 và sau này?). Điều này rất quan trọng (đáng lẽ tôi nên nói rõ hơn trong câu trả lời của mình về điều này). Tất nhiên, "20.000 dòng Fortran", hoặc f77 thường không tốt hơn C ++ được viết tốt.
Ondřej Čertík

1
@ OndřejČertík: Tôi nghĩ rằng nếu bạn tin rằng các chương trình phần tử hữu hạn hiện đại sử dụng cấu trúc dữ liệu "đơn giản", thì bạn đã không xem xét bất kỳ cái nào trong số chúng gần đây. Hãy thử triển khai các phần tử hữu hạn thích ứng, phương pháp hp hoặc multigrid trên các mắt lưới không có cấu trúc bằng các cấu trúc dữ liệu đơn giản. Bill luôn chú ý và tôi tin rằng tôi có thể nói thay cho anh ấy khi nói rằng việc sử dụng "Fortran hiện đại" sẽ không tạo ra nhiều hơn một sự khác biệt nhỏ.
Wolfgang Bangerth

6
@WolfgangBangerth, xem ví dụ Phạml ( math.nist.gov/phaml ) để biết cách triển khai Fortran của hầu hết mọi thứ mà bạn đề cập.
Ondřej ertík

31

Tôi cũng ném hai xu của mình vào loại muộn, nhưng tôi chỉ mới nhìn thấy chủ đề này và tôi cảm thấy rằng, đối với hậu thế, có một vài điểm rất cần được thực hiện.

Lưu ý sau đây tôi sẽ nói về C chứ không phải C ++. Tại sao? Chà, nếu không, đó là táo và cam để so sánh một ngôn ngữ hướng đối tượng được đánh máy đầy đủ với một thứ gì đó tĩnh như Fortran. Vâng, một số triển khai hiện đại của các tiêu chuẩn Fortran mới nhất có thể làm được nhiều hơn thế, nhưng rất ít người thực sự sử dụng chúng, và vì vậy khi chúng ta nói về Fortran, chúng tôi nghĩ rằng ngôn ngữ đơn giản, tĩnh và bắt buộc. Đó là nơi C cũng vậy, vì vậy tôi sẽ thay thế C bằng C ++ cho các mục sau.

Trước hết, bất kỳ cuộc thảo luận nào về việc Fortran / C có trình biên dịch tốt hơn là tranh luận. Trình biên dịch C / Fortran chuyên dụng là một điều của quá khứ. Cả gcc / gfortran và icc / ifc chỉ là các giao diện người dùng khác nhau cho cùng một back-end, tức là chương trình của bạn sẽ được chuyển đổi thành một mô tả trừu tượng bởi front-end và sau đó được tối ưu hóa và lắp ráp bởi back-end. Nếu bạn viết, về mặt ngữ nghĩa, cùng một mã trong Fortran hoặc trong C, trình biên dịch, trong cả hai trường hợp, sẽ tạo ra cùng một hội đồng sẽ chạy nhanh như vậy.

Điều này bây giờ dẫn đến điểm thứ hai của tôi: tại sao chúng ta vẫn thấy sự khác biệt? Vấn đề là hầu hết các so sánh được thực hiện bởi các lập trình viên Fortran đang thử một cái gì đó bằng C hoặc ngược lại. Bạn có bao giờ nhận thấy hầu hết các tác giả hoặc nhà thơ thích viết bằng ngôn ngữ bản địa của họ không? Bạn có muốn viết thơ bằng ngôn ngữ mà bạn không cảm thấy hoàn toàn tự tin hoặc ở nhà không? Tất nhiên là không ... Bản thân tôi coi C là ngôn ngữ lập trình "bản địa" của mình. Tuy nhiên, tôi cũng đã dành ba năm làm việc trong một nhóm chỉ sử dụng Fortran, trong đó tôi đã đạt được một mức độ lưu loát nhất định. Tuy nhiên, tôi sẽ không bao giờ tự viết bất cứ điều gì ở Fortran vì tôi cảm thấy thoải mái hơn với C và do đó, mã kết quả sẽ tốt hơn , bất kể bạn định nghĩa như thế nào.

Vì vậy, sự khác biệt chính là ở lập trình viên, không phải ngôn ngữ. Vậy có khác biệt gì không? Vâng, không hoàn toàn. Đây là vài ví dụ:

  • SIMD: Cho dù đó là SSE, SSE3 hay AltiVec, nếu bạn muốn sử dụng chúng trong Fortran, bạn nên hy vọng và cầu nguyện rằng trình biên dịch sẽ đoán chính xác những gì bạn muốn và làm như vậy. Chúc may mắn. Trong C, bạn thường có các hàm nội tại cho từng kiến ​​trúc hoặc gần đây hơn là các loại vectơ SIMD chung trong gcc . Hầu hết các trình biên dịch Fortran sẽ chỉ sử dụng các hướng dẫn SIMD để hủy bỏ các vòng lặp, nhưng nếu bạn có một hạt nhân hoạt động trên các vectơ dữ liệu ngắn theo cách không rõ ràng, trình biên dịch rất có thể sẽ không nhìn thấy nó.

  • Các kiến ​​trúc phần cứng khác nhau: Toàn bộ kiến ​​trúc CUDA được xây dựng xung quanh các hạt nhân trong C. Có, Tập đoàn Portland hiện cũng có trình biên dịch fortran có khả năng CUDA , nhưng nó mang tính thương mại và quan trọng nhất là không phải từ NVIDIA. Điều tương tự cũng xảy ra với OpenCL, trong đó dự án tốt nhất tôi có thể tìm thấy là một dự án gần đây chỉ hỗ trợ một vài cuộc gọi cơ bản.

  • Lập trình song song: Có, cả MPI và OpenMP đều hoạt động tốt với cả C và Fortran. Tuy nhiên, nếu bạn muốn kiểm soát thực sự các chủ đề của mình, tức là nếu bạn có tính toán bộ nhớ chia sẻ hoàn toàn năng động, bạn sẽ bị lạnh với Fortran. Trong C, bạn có các pthread tiêu chuẩn, dù không ấm và mờ, vẫn sẽ giúp bạn vượt qua cơn bão. Nói chung, hầu hết các tính toán dựa trên quyền truy cập vào hệ điều hành, ví dụ như các luồng, quy trình, hệ thống tệp, v.v ... được phục vụ tốt hơn với C. Oh, và đừng cố gắng thực hiện kết nối mạng của riêng bạn với Fortran.

  • Dễ sử dụng: Fortran gần với Matlab hơn C. Khi bạn đã nhận được tất cả các từ khóa khác nhau và cách khai báo các biến, phần còn lại của mã trông giống như Matlab, giúp người dùng có kinh nghiệm lập trình hạn chế hơn.

  • Khả năng tương tác: Khi bạn tạo một cấu trúc trong C, bố cục của dữ liệu thực tế là đơn giản và mang tính quyết định. Trong Fortran, nếu bạn sử dụng mảng con trỏ hoặc dữ liệu có cấu trúc, bố cục thực của dữ liệu phụ thuộc nhiều vào trình biên dịch, không đơn giản và thường không hoàn toàn không có tài liệu. Bạn có thể gọi C từ Fortran và ngược lại, nhưng đừng bắt đầu nghĩ rằng có thể dễ dàng vượt qua mọi thứ hơn một mảng tĩnh từ cái này sang cái khác và ngược lại.

Đây là tất cả những thứ tầm thường, cấp độ thấp, nhưng đây là Máy tính hiệu suất cao mà chúng ta đang nói đến, phải không? Nếu bạn không quan tâm đến cách khai thác tốt nhất các mô hình phần cứng cơ bản, tức là triển khai và / hoặc phát triển các thuật toán tốt nhất cho bộ nhớ chia sẻ / phân phối, luồng, vectơ SIMD, GPU sử dụng SIMT, v.v. chỉ làm toán trên máy tính.

Điều này đã kéo dài hơn nhiều so với bất cứ điều gì tôi tham gia, vì vậy đây là một bản tóm tắt - một tập hợp các thông điệp mang về nhà:

  • Bạn sẽ viết mã tốt nhất bạn có thể bằng ngôn ngữ mà bạn biết rõ nhất.
  • Không có sự khác biệt về chất lượng mã được tạo bởi hai trình biên dịch sử dụng cùng một back-end - chính chúng ta là người viết mã xấu bằng ngôn ngữ này hay ngôn ngữ khác.
  • Mặc dù cảm thấy mức độ thấp hơn, Fortran khá trừu tượng ở mức độ cao và sẽ không cho phép bạn truy cập trực tiếp một số tính năng phần cứng / hệ điều hành, ví dụ như SIMD, luồng, kết nối mạng, v.v ...

5
Đáp ứng tốt. Tôi không nghĩ tuy nhiên nhận xét cuối cùng của bạn là nhất thiết phải đúng. Bản thân tôi là một lập trình viên C, nhưng bạn có quyền truy cập vào những thứ cấp thấp ở Fortran thông qua các thực hành lập trình tốt. Cách lý tưởng để sử dụng những thứ như SIMD ops là viết mã gợi ý mạnh mẽ (ví dụ như chặn các vòng lặp) và để trình biên dịch làm điều đó cho bạn. Để phân luồng, chỉ cần sử dụng openMP (pthreads cũng có thể sử dụng được với một số công việc phụ). Fortran có tất cả những điều bạn đề cập không có, chỉ ở mức độ quan trọng đối với người dùng thông thường của nó: số.
Reid.Atcheson

@ Reid.Atcheson: Chà, nếu bạn chặn mọi thứ mà trình biên dịch sẽ bắt được nó, thì nó sẽ hoạt động tự động cả trong C và trong Fortran. Vấn đề là, mặc dù, bạn muốn tin tưởng trình biên dịch của mình bao xa? Và tại sao bạn muốn phải tin tưởng nó trong trường hợp khi bạn biết chính xác những gì bạn muốn làm? OpenMP không phân luồng, có, nhưng khối khôn ngoan. Bạn có thể lừa nó để có được các nhóm luồng khác nhau để làm những việc khác nhau, nhưng đó chỉ là sử dụng sai OpenMP. Pthreads cho Fortran chỉ là hàm bao cho các hàm C. Tuy nhiên, tôi đồng ý rằng Fortran dễ dàng hơn nếu bạn không tìm hiểu chi tiết.
Pedro

1
Chắc chắn rằng bạn sẽ không đạt được hiệu suất cực đại 99% dựa vào trình biên dịch, nhưng bạn có thể dễ dàng đến gần. Ngoài ra, bạn phải sử dụng nội tại hoặc ASM nội tuyến. Bạn phải nhượng bộ ở đâu đó để đạt hiệu quả lập trình tổng thể, đó là lý do tại sao ngôn ngữ lập trình tồn tại ở nơi đầu tiên. Ở giai đoạn mà bạn thực sự đủ điên rồ để tìm hiểu chi tiết về nội tại hoặc ASM (tôi đã vài lần), Fortran không phải là một cái nạng. Bạn sẽ biết cách liên kết trong mọi cách mã được tối ưu hóa bằng tay.
Reid.Atcheson

@ Reid.Atcheson: Vâng, tôi muốn lập luận rằng cho các ứng dụng HPC song song, bạn cũng có thể sẽ thấp hơn nhiều so 99% hiệu suất cao nhất ... Và các loại vector gcc làm bằng intrinsics một vấn đề không :)
Pedro

1
@Pedro, Bài đăng rực rỡ. Hoàn toàn rực rỡ. Cảm ơn rất nhiều vì đã đăng. Chỉ tìm thấy nó trong khi ngẫu nhiên lục lọi trong các chủ đề thú vị.
Thắc mắc vào

16

Từ 15 năm suy nghĩ của tôi về phần mềm khoa học: Nếu mã của bạn chạy nhanh hơn 25% vì bạn viết nó bằng Fortran, nhưng bạn phải mất 4 lần để viết nó (không có STL, khó thực hiện các cấu trúc dữ liệu phức tạp, v.v.), thì Fortran chỉ thắng nếu bạn dành một phần đáng kể trong ngày để xoay ngón tay cái và chờ đợi việc tính toán của bạn kết thúc. Vì hầu hết tất cả chúng ta, điều quý giá nhất là thời gian của chúng ta, kết luận là: sử dụng ngôn ngữ cho phép bạn phát triển, gỡ lỗi và kiểm tra mã của bạn nhanh nhất, trong lý do bỏ qua rằng nó có thể chậm hơn có thể nếu bạn đã viết nó ở Fortran.


13

Cách tiếp cận của tôi là sử dụng C ++ cho mọi thứ trừ hạt nhân tính toán, thường được viết tốt nhất trong lắp ráp; Điều này mua cho bạn tất cả hiệu suất của phương pháp HPC truyền thống nhưng cho phép bạn đơn giản hóa giao diện, ví dụ, bằng cách nạp quá nhiều hạt nhân tính toán như SGEMM / DGEMM / CGEMM / ZGEMM vào một thói quen duy nhất, Gemm nói. Rõ ràng mức độ trừu tượng có thể được nâng lên cao hơn nhiều bằng cách tránh các con trỏ thô và chuyển sang các lớp mờ, nhưng đó là một bước đầu tiên tốt đẹp.

Tôi thấy nhược điểm lớn nhất của C ++ là sự gia tăng thời gian biên dịch, nhưng, theo kinh nghiệm của tôi, sự tiết kiệm trong thời gian phát triển nhiều hơn là bù đắp cho nó. Một nhược điểm khác là trình biên dịch C ++ của nhà cung cấp có xu hướng có nhiều lỗi hơn trình biên dịch C và Fortran của nhà cung cấp. Trong năm qua, tôi nghĩ rằng tôi đã gặp phải gần mười lỗi trong trình biên dịch C ++.

Với tất cả những gì đã nói, tôi nghĩ rằng việc hoàn tác các gói khoa học được viết bằng các ngôn ngữ cấp thấp (và Fortran) là sự miễn cưỡng để lộ các giao diện thuận tiện cho các cấu trúc dữ liệu tinh vi: hầu hết mọi người đều hài lòng với giao diện Fortran BLAS, vì nó chỉ yêu cầu con trỏ và kích thước hàng đầu để mô tả ma trận, nhưng ít người cho rằng giao diện bộ giải trực tiếp thưa thớt 40 số thông thường là bất cứ thứ gì gần với thuận tiện (xem UHM, SuperLU, PETSc và Trilinos).

Tóm lại, tôi lập luận cho việc sử dụng lắp ráp cho các hạt nhân tính toán cấp thấp, nhưng các ngôn ngữ cấp cao hơn cho mọi thứ khác, đặc biệt là khi hoạt động trên các cấu trúc dữ liệu không tầm thường.

Lưu ý rằng bài đăng này dẫn đến việc so sánh hiệu suất của C và Fortran trên kernely:=αx+y .


2
Tại sao bạn không tin tưởng một trình biên dịch C tiêu chuẩn với tối ưu hóa phù hợp được kích hoạt cho mục đích biên dịch các hạt nhân nhỏ? Ở mức độ kích thước và độ phức tạp của mã, sự khác biệt về những gì trình biên dịch có thể rút ra khỏi nó là không rõ ràng.
Peterangu

1
Tôi đã nói chuyện với một số người đã nói với tôi rằng, ngay cả khi sử dụng hạn chế thích hợp, Fortran của họ vẫn nhanh hơn mã C và / hoặc C ++ của họ cho một số hoạt động như chuyển đổi ma trận rõ ràng. Tôi không nói rằng không thể tạo mã C hoặc C ++ nhanh như vậy, nhưng trình biên dịch Fortran có xu hướng làm tốt hơn.
Jack Poulson

Tôi có cùng trải nghiệm với từ khóa "hạn chế" (mã Fortran đơn giản của tôi luôn nhanh hơn một chút). Nhưng chuyên môn của tôi còn hạn chế và đơn giản là tôi không có thời gian để đầu tư vào việc tìm hiểu lắp ráp được tạo ra từ gcc. Vì vậy, tôi chỉ cần sử dụng Fortran, nó đơn giản và nhanh chóng.
Ondřej Čertík

@JackPoulson: Đối số trình biên dịch là thứ tôi nghe được khá nhiều từ cộng đồng Fortran. Thật không may, hầu hết các trình biên dịch, ví dụ gcc hoặc ifc / icc, sử dụng các giao diện ngôn ngữ khác nhau cho cùng một back-end. Các máy móc thực hiện tối ưu hóa và tạo mã là giống hệt nhau và do đó, sự khác biệt trong kết quả có lẽ là do sự khác biệt về sự quen thuộc của lập trình viên với ngôn ngữ cơ bản ...
Pedro

1
Chỉ cần đưa ra một chút quan điểm về tuyên bố thường được lặp đi lặp lại, hiếm khi được xác thực rằng Fortran nhanh hơn trên các hạt nhân số: Một lúc trước, chúng tôi nhận thấy rằng vectơ ma trận thưa thớt nhân lên trong gói Epetra của Trilinos chậm hơn 30% so với trong thỏa thuận.II. Cái trước được viết thẳng về phía trước Fortran 77, cái sau viết thẳng C mà không sử dụng 'hạn chế'. Cả hai đều có khoảng 10-15 dòng mã. Ngày nay, Trilinos sử dụng đoạn mã được nâng lên từ deal.II. Tôi chắc chắn người ta có thể tìm thấy rất nhiều trường hợp trong đó F77 nhanh hơn C. Điểm quan trọng là ngày nay không còn phổ biến nữa.
Wolfgang Bangerth

8

Vì tôi mới ở đây, tôi đã xem qua những câu hỏi cũ và tìm thấy câu hỏi này. Hy vọng nó không phải là điều cấm kỵ để trả lời những người cũ!

Vì không có ai khác đề cập đến điều này, nên tôi nghĩ. Fortran 2003 gần như được hỗ trợ đầy đủ bởi hầu hết các trình biên dịch chính (intel, ibm, cray, NAG, PCG) thậm chí gcc với phiên bản mới nhất (sắp có) 4.7. Fortran 2003 (và 2008) là một ngôn ngữ hướng đối tượng, mặc dù dài dòng hơn một chút so với C ++. Một trong những điều mà tôi nghĩ là hay về Fortran là việc ủy ​​ban tiêu chuẩn coi máy tính khoa học là đối tượng chính (tôi cảm ơn Damian Rouson vì đã chỉ ra điều này cho tôi vào một ngày khác).

Tôi đưa ra tất cả những điều này không phải để các lập trình viên C ++ trở thành lập trình viên Fortran, nhưng để mọi người biết rằng họ có nhiều lựa chọn hơn ngoài việc chuyển sang C ++ hoặc mô phỏng các khái niệm hướng đối tượng trong Fortran 90/95.

Một điều lưu ý tôi sẽ nói thêm là có một chi phí nằm ở khía cạnh chảy máu của những gì được thực hiện trong trình biên dịch. Nếu bạn thực hiện một dự án lớn trong Fortran 2003 ngay bây giờ, bạn sẽ vấp phải các lỗi và liên tục cần cập nhật trình biên dịch của mình (đặc biệt là nếu bạn sử dụng gcc), mặc dù điều này đã tốt hơn đáng kể trong vài tháng qua!


7

Vấn đề với C ++ là bạn có rất nhiều cơ hội để phá hỏng hiệu năng, ví dụ bằng cách sử dụng STL, ngoại lệ, các lớp (vấn đề ảo cộng với vấn đề căn chỉnh), quá tải toán tử (lỗi mới / xóa) hoặc các mẫu (biên dịch không bao giờ kết thúc và lỗi mật mã Có vẻ lành tính, nhưng bạn có thể lãng phí hàng giờ theo cách này).

Tuy nhiên, nhiều hơn bạn có quyền truy cập tốt hơn vào các thư viện chung và có thể hiển thị rõ hơn mã của bạn (mặc dù điều này phụ thuộc nhiều vào trường và bạn vẫn có C thuần túy). Và bạn vẫn có thể bù đắp sự thiếu linh hoạt của Fortran bằng cách gói mã của nó bằng ngôn ngữ kịch bản như R, Lush, Matlab / Scilab hoặc thậm chí Python, Ruby hoặc Lua.


1
Nói chung là một ý tưởng tồi để áp dụng các kỹ thuật cấp thấp trong các ngôn ngữ cấp cao. Ví dụ, STL được thiết kế để hoạt động ở mức rất trừu tượng. Người ta phải nhận thức được giao diện được thiết kế để làm gì, sử dụng nó cho nhiệm vụ này và sau đó thoát ra khỏi trình biên dịch.
shuhalo

2
Tôi nghĩ rằng cả điểm của mbq và Martin đều không công bằng. Có, có nhiều cách để tự bắn vào chân bạn nếu bạn cố gắng thực hiện một vectơ số cho mục đích đại số tuyến tính bằng cách sử dụng std :: list <double>. Nhưng đó là một lập luận ngớ ngẩn: ít nhất C ++ một lớp danh sách được liên kết mà bạn có thể sử dụng, trong khi Fortran thì không. Nó giống như nói rằng "Ô tô lái xe với tốc độ cao đến mức bạn có thể đâm vào tường và bị thương; thay vào đó bạn nên sử dụng xe ngựa kéo." Đó chỉ là một ý tưởng ngớ ngẩn để loại bỏ một ngôn ngữ cấp cao cũng hỗ trợ các công cụ cấp thấp (ví dụ C ++) để các tính năng cấp cao.
Wolfgang Bangerth

@WolfgangBangerth Không, bây giờ bạn đang làm tổn thương Fortran - đó là "cấp độ thấp" vì vi khuẩn "ít tiến hóa" hơn con người. Nếu bạn muốn một chiếc xe tương tự, nó sẽ giống như "bạn có thể sử dụng cả xe jeep và xe Lexus để băng qua một con đường đầm lầy, nhưng sử dụng chiếc đầu tiên sẽ ít đau hơn".
mbq

1
Tôi đánh giá cao ý kiến ​​của bạn, nhưng tôi khẳng định rằng Fortran không phát triển như C ++ là :-)
Wolfgang Bangerth

7

Ba sự thật:

  • Mảng n chiều kiểu F77 trong C: Không có vấn đề gì khi sử dụng CnD (một phích cắm không biết xấu hổ, phải thừa nhận)

  • Hệ thống mô-đun của F90 được thiết kế kém và thù địch để xây dựng môi trường. (Tên của mô-đun không phải khớp với tên tệp của nó, ví dụ)

  • Fortran không hỗ trợ tái cấu trúc tốt. Việc kéo một số chức năng ra khỏi chức năng yêu cầu bạn chạm vào bốn vị trí: Mã thực tế, khai báo biến, khai báo đối số và danh sách đối số. C được bằng hai nơi để chạm vào. Điều này kết hợp ảnh hưởng của việc không quản lý tốt dữ liệu (được mô tả bên dưới): Vì mô đun quy mô nhỏ rất đau đớn, nên mọi người đều viết các chương trình con khổng lồ.

Một ấn tượng cá nhân:

  • Fortran không hoạt động tốt để quản lý dữ liệu. Hãy thử trả về một con trỏ tới cấu trúc dữ liệu mờ của người dùng trong F77 hoặc F90. ( transfer(), chúng tôi đến đây)

Xin chào Andreas! CnD rất thú vị, tôi không biết về nó. Ah, bạn đã viết nó. :) (f90 cũng hỗ trợ cắt, phân bổ cho mảng và quan trọng nhất - cú pháp mảng để nhân, thêm vào, v.v.) Tôi sử dụng CMake với Fortran và nó hoạt động rất tốt với các mô-đun. Chính xác thì "danh sách đối số" là gì? Tôi không nghĩ rằng tôi sử dụng những thứ này, vì vậy chỉ cần 3 nơi để sửa đổi. Trong C, thông thường bạn cần sửa đổi mã thực tế, tham số và tệp tiêu đề, do đó, nó cũng có 3 vị trí (chắc chắn nhất là trong C ++). Đúng, transfer () không đẹp lắm, nhưng thông thường bạn không cần nó trong thực tế.
Ondřej Čertík

3
Tái cấu trúc fortran hiện đại là chuyện nhỏ với các IDE thích hợp, như Photran trong nhật thực.

2
"Tên của một mô-đun không phải khớp với tên tệp của nó, ví dụ:" Bạn phải nói đùa, bạn có thể có nhiều mô-đun trong một tệp. Một số trong số họ chỉ kéo dài một vài dòng. Chúng dễ dàng hơn nhiều để tạo nếu bạn không phải tạo một tệp cho mỗi tệp.
Vladimir F

1
Chỉ muốn thêm vào những gì @ user389 nói rằng, trong khi Photran là tuyệt vời và là Fortran IDE duy nhất cho phép tái cấu trúc, trình phân tích cú pháp của nó luôn thất bại. Mặt khác, không cần bình luận về thực tế rằng Eclipse đang đói bộ nhớ.
astrojuanlu

5

Fortran được tối ưu hóa cho các tính toán mảng / ma trận và là một nỗi đau triệt để để làm việc với bất kỳ loại phân tích văn bản nào. C và C ++ có thể không khớp với Fortran trong điện toán số (nó gần), nhưng tôi thấy việc xử lý văn bản và sắp xếp dữ liệu (nghĩa là cấu trúc dữ liệu tùy chỉnh) dễ dàng hơn nhiều với C / C ++.

Như những người khác đã đề cập, không tính các ngôn ngữ diễn giải động (Python et al). Họ có thể không cung cấp tốc độ làm tan chảy khuôn mặt của Fortan, nhưng họ cho phép bạn tập trung hơn vào việc giải quyết vấn đề tính toán của bạn hơn tất cả các chi tiết thực hiện. Thường thì bạn có thể triển khai một giải pháp trong Python và nếu hiệu suất không được chấp nhận, hãy thực hiện một số lược tả, xác định các khu vực có vấn đề và tối ưu hóa mã đó bằng Cython hoặc thực hiện lại toàn bộ chương trình bằng ngôn ngữ được biên dịch. Một khi bạn có logic giải quyết vấn đề, phần còn lại chỉ là triển khai và, với sự hiểu biết tốt về các nguyên tắc tính toán, nên đơn giản để thể hiện bằng bất kỳ ngôn ngữ lập trình nào.


Đúng rồi. Để phân tích cú pháp văn bản tôi cũng sử dụng Python.
Ondřej Čertík

Bạn cũng có thể triển khai một phần của tập lệnh Python bằng ngôn ngữ được biên dịch, ví dụ C ++ và nối nó vào. Ví dụ: Boost Python, Swig, v.v.
Faheem Mitha

4

Tôi hiện đang làm việc tại một trong những phòng thí nghiệm quốc gia. Hầu hết những người xung quanh tôi là kỹ sư cơ khí. Trò chuyện với một số người trong nhóm HPC, họ chủ yếu làm Linux và chủ yếu là C ++. Nhóm tôi hiện đang làm hầu hết các ứng dụng trên máy tính để bàn và chúng tôi sử dụng Windows và theo thứ tự giảm dần: C #, FORTRAN, Python, VBA và VB (6, không phải .NET). Một số công cụ mô phỏng chúng tôi sử dụng đã được viết tại các phòng thí nghiệm quốc gia khác ở FORTRAN.


4

Xin lỗi vì đã đào một chủ đề cũ nhưng dường như ngay cả trong năm 2015, Fortran vẫn đang được sử dụng rất nhiều.

Tôi chỉ tình cờ gặp này (thay thế liên kết ) danh sách mà về cơ bản là một danh sách 13 mã bằng cơ sở OCLF DOE để chạy trên máy Hội nghị thượng đỉnh 300-petaflop mà sẽ được cung cấp cho các nhà nghiên cứu trong năm 2018. phê duyệt tôi đã cố gắng để tìm thấy những ngôn ngữ chính được sử dụng cho mã (dựa trên tìm kiếm nhanh trên google) và đây là những gì tôi tìm thấy:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Vì vậy, trong số 13 mã, ít nhất 10 mã (dựa trên tìm kiếm nhanh của tôi) dường như được viết bằng Fortran. Không tệ cho một ngôn ngữ 50 tuổi.

LƯU Ý: Tôi nhận thức rõ rằng so sánh ngôn ngữ là vô ích nhưng với số lượng người (đặc biệt là người dùng C ++) mà Fortran nói xấu, tôi nghĩ rằng có thể đáng để đề cập đến nó.


3
Tôi không đồng ý, vì kinh nghiệm của tôi tại các phòng thí nghiệm quốc gia, nếu có, thì ngược lại. Hầu hết các dự án mới mà tôi thấy tại Lawrence Livermore đều được viết bằng C ++ và hầu hết các thư viện mã nguồn mở mới (hoặc được duy trì tích cực) trong các bộ giải ODE, phân biệt FEM và thư viện máy tính khoa học đa năng dường như là trong C hoặc C ++. Fortran dường như chủ yếu được sử dụng trong các dự án sử dụng các thư viện hiện có / cũ; Tôi không thấy nhiều dự án lớn, mới sử dụng Fortran, độc lập với những gì tôi nghĩ về ngôn ngữ.
Geoff Oxberry

Một số mã lý thuyết chức năng mật độ cũng được viết bằng Fortran bao gồm VASPCASTEP , mặc dù như @GeoffOxberry chỉ ra, các dự án mới có lẽ có xu hướng hướng tới C ++.
dr.blochwave

@blochwave Như bạn có thể đọc trong liên kết, các dự án dành cho một máy mới (có máy gia tốc, v.v.) sẽ trực tuyến vào năm 2018. Vì vậy, không giống như họ lấy mã 25 năm và biên dịch nó, hy vọng sẽ chạy tốt hiệu suất. Tôi khá chắc chắn rằng phần lớn các mã trong danh sách trên đã hoặc đang được viết lại, như trong mã mới. Một số mã khí hậu "mới" cũng có ở Fortran và được sử dụng bởi nhiều cơ quan ở một số quốc gia.
stali

0

Điều mà Jack P. tôi nghĩ đang cố gắng nói là bạn nên kết hợp và kết hợp. Một phần mềm tốt được xếp lớp cẩn thận. Các lớp khác nhau có thể ánh xạ tự nhiên hơn hoặc hiệu quả hơn sang các ngôn ngữ khác nhau. Bạn nên chọn ngôn ngữ phù hợp nhất cho mỗi lớp. Bạn cũng nên hiểu làm thế nào các ngôn ngữ có thể tương tác với nhau, điều này có thể ảnh hưởng đến ngôn ngữ bạn chọn cho lớp nào.

Một câu hỏi hay hơn là những ví dụ nào về phần mềm được thiết kế xuất sắc ngoài kia đáng để nghiên cứu để tìm hiểu về cách thiết kế phần mềm lớp.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.