Ngôn ngữ lập trình được sử dụng nhiều nhất trong điện toán hiệu năng cao là gì? Và tại sao? [đóng cửa]


25

Tôi tin rằng rất nhiều Fortran được sử dụng trong HPC, nhưng không chắc đó chỉ là lý do di sản.

Các tính năng của các ngôn ngữ lập trình hiện đại như bộ sưu tập rác hoặc đa hình thời gian chạy không phù hợp với HPC vì tốc độ rất quan trọng nên không chắc chắn C # hoặc Java hoặc C ++ xuất hiện ở đâu.

Có suy nghĩ gì không?


9
C ++ không có trình thu gom rác và nó không yêu cầu bạn sử dụng đa hình thời gian chạy.
Jason Baker

@Jason Mục đích của tôi là tìm ra những tính năng nào của C ++ làm cho nó trở thành một trường hợp hấp dẫn cho HPC.
Fanatic23

@ Fanatic23 - Tôi hiểu. Chỉ muốn ghi chú về điều đó. :-)
Jason Baker

1
@Fanatic Mong muốn tôi có thể nói có, nhưng tôi không có quá nhiều ... Tôi có một loạt các liên kết liên quan đến một số vấn đề về hiệu suất trong ngôn ngữ .NET / chức năng, mặc dù. Bạn có thể ghép các khái niệm lại với nhau về mặt tinh thần để nắm bắt những hạn chế về hiệu suất nhất định: msdn.microsoft.com/en-us/l Library / 02559wtx.aspx stackoverflow.com/questions/2909282/ tựa msd.microsoft.com/en -us / tạp chí / cc163329.aspx en.wikipedia.org/wiki/Just-in-time_compilation
Rei Miyasaka

1
Tuy nhiên, tôi nghĩ rằng, nếu bạn cần thời gian phản hồi thực sự tốt, thứ bạn đang tìm kiếm là một hệ điều hành thời gian thực như QNX: en.wikipedia.org/wiki/QNX
Rei Miyasaka

Câu trả lời:


11

Tôi đã thấy rất nhiều Java được sử dụng cho HPC trong các khu vực nơi (1) có ít mã kế thừa và (2) thời gian phát triển và vấn đề chất lượng mã. Các lĩnh vực ứng dụng điển hình là tài chính, khai thác dữ liệu hoặc tin học sinh học.

Nó thực sự phụ thuộc vào ứng dụng (có sự sống bên ngoài đại số tuyến tính), nhưng hiệu năng của các JVM gần đây thường ngang bằng với mã C. Đôi khi nhanh hơn khi JVM có thể thực hiện trong tối ưu hóa thông minh thời gian chạy mà trình biên dịch tĩnh (C, Fortran) không thể làm được. Và chắc chắn nhanh hơn khi có rất nhiều tính toán tượng trưng.

Với một lượng thời gian cố định để phát triển chương trình, mã Java kết quả luôn nhanh hơn mã C. HPC trong Java chắc chắn có ý nghĩa khi mã được phát triển hoặc sửa đổi thường xuyên. Một tính năng quan trọng khác là tính di động mã trên phần cứng khác nhau.

Bạn sẽ tìm thấy tài liệu tham khảo trong http://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

Về giả định của Fortran rằng hai địa chỉ là duy nhất, chúng tôi đang nghiên cứu một công cụ phân tích tĩnh sẽ cho phép tối ưu hóa mã tương tự cho các ngôn ngữ cấp cao, nhưng không có bit "Những điều tồi tệ có thể xảy ra". Liên hệ với tôi nếu quan tâm.


14
Nitpick: Tối ưu hóa JIT có sẵn cho các trình biên dịch tĩnh nếu bạn sẵn sàng thực hiện một công việc nhỏ. Cả GCC và MS Visual Studio đều hỗ trợ Tối ưu hóa theo hướng dẫn hồ sơ nhằm tối ưu hóa việc sử dụng dữ liệu thời gian chạy đã lưu. Đó là một chút sai lầm khi đề xuất có những tối ưu hóa "mà trình biên dịch tĩnh (...) không thể làm được".
Corbin ngày

4
Tôi không biết tại sao đây là câu trả lời được chấp nhận, không có gì trong bài viết này chứa bất kỳ sự hiểu biết nào về sự thật. Các ngôn ngữ dựa trên C sẽ luôn vượt trội hơn Java, vì Java là một máy ảo có bản lề trên ngôn ngữ khác vốn có. Hơn nữa, bất cứ điều gì bạn có thể đạt được trong Java bạn có thể đạt được trong C với ít chi phí hơn. Các ngôn ngữ dựa trên C sẽ không bao giờ hết là ngôn ngữ 'biểu diễn'.
Mike

31

Trong những năm kinh nghiệm của tôi, cho đến 5 năm trước, nó luôn là Fortran và C. Cái nào phụ thuộc chủ yếu vào việc mọi người đến từ kỹ thuật hay nhiều hơn từ trường tư tưởng CS (Tôi không biết làm thế nào để nói điều này tốt hơn , okey ?:-)

Trong những gì chúng tôi đã làm, Fortran hầu như chỉ được sử dụng.

Từ những gì tôi đọc được ngày hôm nay, với các bản cập nhật mới cho Tiêu chuẩn F2003 / 08 và với việc giới thiệu Co-Arrays, nó dường như đang lấy lại được động lực.

Ngoài ra, một, nếu không phải là một bài viết thiên vị - Ngôn ngữ lập trình HPC lý tưởng


16

Tôi nghĩ đối với bàn đạp thực sự cho kim loại, sự lựa chọn thực sự duy nhất là Fortran. Lý do là điều quan trọng nhất đối với việc khai thác ILP cấp thấp (Parallism cấp độ hướng dẫn) là định hướng địa chỉ bộ nhớ. Các quy tắc defacto trong Fortran cho phép trình biên dịch xác định rằng hai địa chỉ là duy nhất (và do đó thứ tự tải và lưu trữ, hoặc thậm chí các cửa hàng và cửa hàng có thể được thay thế mà không có nguy cơ tạo mã không chính xác). C để lại quá nhiều phạm vi cho các con trỏ chồng chéo cho trình biên dịch để trích xuất càng nhiều mức độ song song mức thấp từ mã.

Ngoài ra, căn chỉnh mảng, dòng bộ đệm wrt và ranh giới SSE / AVX rất quan trọng đối với việc tạo và thực hiện các vòng lặp hiệu quả. Nếu các mảng được truyền qua các khối chung, trình biên dịch / trình tải có thể đảm bảo rằng tất cả các mảng bắt đầu trên cùng một ranh giới căn chỉnh địa chỉ, và có thể sử dụng các tải và lưu trữ SSE / AVX hiệu quả hơn. Phần cứng mới hơn có thể xử lý các truy cập bộ nhớ chưa được phân bổ, nhưng vì quyền truy cập bộ nhớ không được căn chỉnh đúng cách sử dụng một phần các dòng bộ đệm dẫn đến hiệu suất thấp hơn. Ngay cả khi một lập trình viên C sắp xếp đúng tất cả các mảng của mình, liệu có một cơ chế để truyền đạt điều này đến trình biên dịch không?

Tóm lại, hai vấn đề quan trọng nhất là sự độc lập của địa chỉ bộ nhớ và sự nhận biết của trình biên dịch rằng các cấu trúc dữ liệu được truy cập có cùng căn chỉnh "tự nhiên" mà phần cứng muốn. Cho đến nay Fortran thực hiện công việc tốt nhất trong hai nhiệm vụ đó.


2
Gần đây tôi đã làm một thí nghiệm nhỏ, tìm thấy số lượng pop của một chuỗi 64000 bit, được biểu diễn dưới dạng một mảng dài không dấu. Tôi đã sử dụng cùng một thuật toán bằng cách sử dụng rất nhiều công cụ số học boolean thú vị và đóng gói. Trong C với -O3, nó mất 10clocks mỗi lần dài, trong khi với Intel Fortran 10.1, với tối ưu hóa mặc định là 6,5! Và mọi lập trình viên đều nghĩ rằng C là vượt trội đối với việc xoay vòng một chút! Các giả định của Fortran defacto cho phép mã hóa hướng dẫn mức thấp hiệu quả hơn được tạo ra một cách an toàn.
Omega Centauri

4
Điều đó sẽ đọc "Các quy tắc defacto trong Fortran cho phép trình biên dịch ASSUME rằng hai địa chỉ là duy nhất ...". Tất cả các hướng dẫn đều cho bạn biết rằng trình biên dịch được phép thừa nhận điều này và cảnh báo bạn TRONG CHI TIẾT rằng những điều tồi tệ có thể xảy ra nếu bạn vi phạm giả định đó.
John R. Strohm

15

Chỉ cần một số ghi chú giai thoại. Tôi đã không thực hiện bất kỳ tính toán hiệu suất cao bản thân mình.

Đối với các tính toán (crunching số), Fortran và C. Có, đó là vì lý do di sản:

  • Có sẵn nhiều mã nguồn và công thức nấu ăn.
  • Cả hai đều hỗ trợ Bộ KH & ĐT .
  • Cả hai ngôn ngữ được biên dịch.
  • Trình biên dịch cho cả hai ngôn ngữ được cung cấp bởi tất cả các hệ điều hành và nhà cung cấp HPC.
  • Trình biên dịch Vectorizing có sẵn.
  • Cả hai đều yêu cầu mức độ tinh chỉnh điên rồ để có hiệu suất cao khi được chuyển sang một cụm khác (kích thước bộ nhớ khác nhau, số lượng CPU, v.v.)
    • Điều này thực sự giải thích tại sao mã nguồn mở là quan trọng: điều chỉnh là cần thiết, do đó công thức ban đầu phải được viết bằng ngôn ngữ tốt cho việc điều chỉnh thủ công.

Xu hướng hiện nay cho việc bẻ khóa số là viết các trình tạo chương trình tự động hóa việc điều chỉnh mã nguồn để tối ưu hóa hiệu suất với các đặc điểm của cụm. Những máy phát điện này thường xuất ra C.

Xu hướng thứ hai là viết bằng một số phương ngữ chuyên biệt của C cho các GPU hoặc Cell BE cụ thể.

Đối với công việc không phải là số, chẳng hạn như các chương trình xử lý dữ liệu từ cơ sở dữ liệu (chứ không phải cơ sở dữ liệu), sẽ rẻ hơn nhiều khi chạy trên các cụm máy "hàng hóa" mà không có các thiết bị mạng tùy chỉnh đắt tiền. Điều này thường được gọi là "Tính toán thông lượng cao". Và Python là ngôn ngữ số 1 ở đây (sử dụng Bản đồ thu nhỏ nổi tiếng). Trước Python, các dự án xử lý hàng loạt có thể được viết bằng bất kỳ ngôn ngữ nào và thường được gửi bởi Condor .


1
Bạn có thể nói rõ hơn một chút về phần "mức độ tinh chỉnh điên rồ" không?
Rook

Trung tâm điện toán thuê các sinh viên tốt nghiệp sắp xếp lại các cuộc gọi MPI để làm cho nó chạy nhanh hơn.
rwong

(?) Từ đầu tiên ở đây, nhưng tôi đoán thực tiễn khác nhau.
Rook

Đó là một trung tâm nghiên cứu mô hình khí hậu.
rwong

4

Tôi đã làm việc với một số mã chuyên sâu tính toán RẤT trong (gasp!) C #.

Tôi đang xây dựng một triển khai GPGPU của FDTD cho mô hình quang học. Trên một cụm nhỏ (128 bộ xử lý), nhiều mô phỏng của chúng tôi mất vài tuần để chạy. Tuy nhiên, việc triển khai GPU có xu hướng chạy nhanh hơn khoảng 50 lần - và đó là trên thẻ NVidia cấp độ người tiêu dùng. Chúng tôi hiện có một máy chủ với hai thẻ xử lý kép GTX295 (vài trăm lõi) và sẽ sớm nhận được một số Teslas.

Làm thế nào điều này liên quan đến ngôn ngữ của bạn? Cũng giống như mã CTD FDTD mà chúng ta đang sử dụng trước đây bị ràng buộc bởi CPU, chúng bị ràng buộc bởi GPU, do đó, sự khác biệt mã lực ( rất nhỏ) của mã được quản lý so với mã gốc không bao giờ được sử dụng. Ứng dụng C # hoạt động như một dây dẫn - tải hạt nhân OpenCL, truyền dữ liệu đến và từ GPU, cung cấp giao diện người dùng, báo cáo, v.v. - tất cả các tác vụ gây khó khăn cho C ++.

Trong những năm trước, sự khác biệt về hiệu năng giữa mã được quản lý và không được quản lý là đủ quan trọng đến mức đôi khi đáng để đưa ra mô hình đối tượng khủng khiếp của C ++ để có thêm vài phần trăm tốc độ. Ngày nay, chi phí phát triển của C ++ so với C # vượt xa lợi ích cho hầu hết các ứng dụng.

Ngoài ra, hầu hết sự khác biệt về hiệu suất của bạn sẽ không đến từ sự lựa chọn ngôn ngữ của bạn, mà từ kỹ năng của nhà phát triển của bạn. Vài tuần trước, tôi đã di chuyển một thao tác phân chia duy nhất từ ​​bên trong vòng lặp ba lần (lồng ngang mảng 3D), giúp giảm 15% thời gian thực hiện cho một miền tính toán nhất định. Đó là kết quả của kiến ​​trúc bộ xử lý: sự phân chia chậm, đó là một trong những khuôn mặt mà bạn chỉ cần chọn ở đâu đó.


1
c ++ có mô hình đối tượng? Nhưng có vẻ như bạn nên sử dụng ngôn ngữ script để viết bộ điều khiển của mình - nếu C # tốt hơn C ++ vì tốc độ dev, thì python (hoặc lua, v.v.) cũng tốt hơn C #.
gbjbaanb

3
@gbjbaanb Không nhất thiết. Việc triển khai này bị ràng buộc bởi GPU, nhưng việc chuyển sang ngôn ngữ kịch bản có thể dễ dàng thay đổi điều đó. C # được biên dịch và có một trình tối ưu hóa rất đẹp. Các ngôn ngữ được biên dịch, đánh máy mạnh là bạn của bạn! Các ngôn ngữ kịch bản ít nghiêm ngặt hơn có xu hướng gây tăng thời gian phát triển cho bất kỳ dự án phức tạp hợp lý nào.
3Dave

1
Đã bảy năm rồi. Tôi đã học được rất nhiều. c ++ khá tuyệt vời, C # cũng tuyệt vời, tôi thực sự thích python và: CPU perf vẫn còn vấn đề.
3Dave

3

Fortran là phổ biến nhất, chủ yếu là do di sản (mọi người vẫn chạy mã cũ) và sự quen thuộc (hầu hết những người làm HPC không quen thuộc với các loại ngôn ngữ khác).

Các tính năng của các ngôn ngữ lập trình hiện đại như bộ sưu tập rác hoặc đa hình thời gian chạy không phù hợp với HPC vì tốc độ rất quan trọng nên không chắc chắn C # hoặc Java hoặc C ++ xuất hiện ở đâu.

Điều đó không đúng nói chung. HPC cổ điển chủ yếu thực hiện đại số tuyến tính với các số chính xác của máy. Tuy nhiên, HPC hiện đại đang ngày càng sử dụng siêu máy tính cho nhiều loại giòn hơn, như tính toán tượng trưng với các biểu thức toán học tùy ý thay vì số chính xác của máy. Điều này đặt các đặc điểm khá khác nhau trên các công cụ bạn sử dụng và không có gì lạ khi sử dụng các ngôn ngữ lập trình khác ngoài Fortran vì việc tính toán biểu tượng có thể rất khó khăn nếu không có GC và các loại trình biên dịch tối ưu hóa khác như trình biên dịch khớp tối ưu hóa mẫu của OCaml.

Ví dụ, đọc bài viết này của Fischbacher et al. trong đó nói rằng "các tác giả có lý do mạnh mẽ để tin rằng đây có thể là phép tính tượng trưng lớn nhất được thực hiện cho đến nay".


Fortran là phổ biến vì nhiều người sử dụng thời gian siêu máy tính để chạy mô phỏng các hệ thống vật lý, như dự báo thời tiết toàn cầu và việc thực hiện các thuật toán cần thiết trong Fortran rất rõ ràng và súc tích.
Sharpie

3

Fortran, vì một số lý do tốt và một số lý do không tốt. Đối với môn toán nặng, một lý do chính đáng là có các thư viện rộng lớn (BLAS, LAPACK) của các chương trình con đã thử và đúng, tất cả được viết bằng Fortran (mặc dù chúng có thể được gọi từ C và C ++).

Một lý do không chính đáng là lợi thế về hiệu suất được cho là của Fortran so với C / C ++. Tối ưu hóa là khá tốt, và ít người hiểu rằng lợi ích của việc tối ưu hóa một đoạn mã tỷ lệ thuận với phần trăm thời gian bận rộn, trong hầu hết tất cả các mã gần như bằng không.

Một lý do không chính đáng khác là khoảng cách văn hóa giữa các lập trình viên CS và không CS. Các lập trình viên khoa học có xu hướng được dạy những thói quen xấu ở Fortran, và xem thường các lập trình viên CS và những thói quen xấu họ đã được dạy, và những người coi thường trước đây.


"khoảng cách văn hóa giữa các lập trình viên CS và không CS. Các lập trình viên khoa học có xu hướng được dạy những thói quen xấu ở Fortran, và xem thường các lập trình viên CS và những thói quen xấu mà họ đã được dạy, và những người coi thường trước đây." Một phần điều này chỉ là họ đang tập trung vào các khía cạnh khác nhau của vấn đề. Fortran có nghĩa là FORmula TRANslation, và nó khá hiệu quả trong việc dịch các công thức toán học thành mã. Đối với các loại lập trình CS thường làm, các ngôn ngữ khác là ưu việt.
Omega Centauri

1
@Omega: Bạn nói đúng. Những người được Fortran dạy có xu hướng không có khái niệm về định dạng, không thích "ẩn ý" và nhồi nhét mã với nhau vì họ vẫn xử lý các dòng 72 ký tự và nghĩ rằng việc tạo mã dễ hiểu là cho các wimps. Những người được CS dạy tạo ra các kim tự tháp của các lớp được xếp bằng đa hình, thông báo và trừu tượng, khi một cái gì đó đơn giản sẽ thực hiện công việc. Vì vậy, họ xứng đáng với nhau :)
Mike Dunlavey

7
câu trích dẫn từng là "các nhà vật lý đang giải quyết các vấn đề về ngày mai trên phần cứng của ngày hôm nay - trong khi các nhân viên CS đang giải quyết các vấn đề của ngày hôm nay trên phần cứng của ngày mai"
Martin Beckett

@Martin: Tôi nghĩ có lẽ tôi đã nghe thấy điều đó ở đâu đó. Nó chắc chắn nhẫn thật.
Mike Dunlavey

Martin: Vì vậy, những người làm phần cứng là những người làm việc hiệu quả nhất :)
Dhaivat Pandya

2

Về cơ bản, tất cả các chương trình thực hiện công việc bẻ khóa số vẫn là FORTRAN (blas cũ, lapack, arnoldi, v.v. vẫn là chương trình được sử dụng) ... Tuy nhiên, khi nói đến cấu trúc cấp cao hơn ... mọi người đang sử dụng ngày càng nhiều C ++.

Sự phức tạp của mô phỏng liên quan đến mã lớn và để có được bất kỳ loại lợi ích nào từ việc viết một cái là làm cho nó có thể tái sử dụng. Ngoài ra, các khái niệm được sử dụng cũng trở nên rất phức tạp. Nó gần như điên rồ khi đại diện cho thông tin đó bằng cách sử dụng FORTRAN. Đó là nơi C ++ xuất hiện vì nó vốn hỗ trợ Thiết kế hướng đối tượng. Tuy nhiên, đa hình thời gian chạy hiếm khi được ưa thích. Thay vào đó, mọi người hầu như luôn sử dụng Đa hình tĩnh (được triển khai trong C ++ với lập trình meta mẫu)

Ngoài ra, bây giờ trình biên dịch thực sự tốt, do đó rất nhiều tối ưu hóa được dành cho trình biên dịch.


1

Có hai loại vấn đề cần được giải quyết trong các ứng dụng HPC: một là số bị khủng hoảng và thứ hai là quản lý các tính toán. Cái đầu tiên thường được tiếp cận với mã được viết bằng Fortran, C hoặc C ++ vì tốc độ và vì thực tế là đã có rất nhiều thuật toán khoa học được viết bằng ngôn ngữ này. Việc chỉ đạo tính toán được thực hiện thuận tiện hơn trong các ngôn ngữ cấp cao hơn. Python là ngôn ngữ "keo" được lựa chọn để xử lý logic ứng dụng và gọi các phần mở rộng được triển khai bằng các ngôn ngữ được biên dịch. Java thường được sử dụng bởi các dự án trong đó quản lý mạng và điện toán phân tán là điều cần thiết.

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.