Tôi nên đầu tư vào mô hình lập trình nào nếu tôi muốn mã của mình chạy trên các máy petascale trong tương lai?

Rõ ràng từ một cuộc khảo sát của top500 rằng ngành công nghiệp đang có xu hướng gia tăng theo cấp số nhân trong các lõi xử lý . Các siêu máy tính lớn nhất đều sử dụng MPI để liên lạc giữa các nút, mặc dù dường như không có xu hướng rõ ràng cho song song trên nút, với cách tiếp cận đơn giản nhất (nhưng không nhất thiết là hiệu quả nhất) để ánh xạ một quy trình MPI duy nhất cho từng lõi, tự động song song hóa từ trình biên dịch, OpenMP, pthreads, CUDA, Cilk và OpenCL.

Tôi là một trong những nhóm các nhà khoa học đang duy trì và phát triển một mã có tiềm năng được sử dụng trên một số siêu máy tính lớn nhất trên thế giới. Giả sử thời gian dành cho nhà phát triển hữu hạn, làm cách nào để chứng minh bản thân trong tương lai để tôi có thể tận dụng hiệu suất của cỗ máy mạnh nhất thế giới? Tôi nên đưa ra giả định nào về quy trình kiến ​​trúc kết nối? Những mô hình nào sẽ phải chịu khi chúng ta bước vào kỷ nguyên nhiều người? Các ngôn ngữ không gian địa chỉ toàn cầu được phân vùng sẽ có sẵn "trong sản xuất" trên các máy petascale?

Quan điểm lịch sử

Thật sự không thể nói những mô hình mới sẽ như thế nào trong tương lai, ví dụ như một viễn cảnh lịch sử tốt đẹp mà tôi khuyên bạn nên đọc Rise and Fall of HPF của Ken Kennedy . Kennedy đưa ra một tài khoản gồm hai mẫu mới nổi, MPI so với trình biên dịch thông minh và chi tiết làm thế nào MPI có số lượng người chấp nhận sớm và linh hoạt để thống trị. HPF cuối cùng đã khắc phục vấn đề của mình nhưng đã quá muộn.

Theo nhiều cách, một số mô hình, chẳng hạn như PGAS và OpenMP, đang theo xu hướng HPF tương tự. Các mã ban đầu không đủ linh hoạt để sử dụng tốt và để lại nhiều hiệu suất trên bàn. Nhưng lời hứa không phải viết mọi iota của thuật toán song song là một mục tiêu hấp dẫn. Vì vậy, việc theo đuổi các mô hình mới luôn luôn được theo đuổi.

Rõ ràng xu hướng trong phần cứng

Bây giờ thành công của Bộ KH & ĐT thường được trích dẫn là gắn chặt với cách thức mô hình hóa phần cứng mà nó chạy. Khoảng mỗi nút có một số quy trình và việc truyền thông điệp đến điểm cục bộ hoặc thông qua các hoạt động tập thể phối hợp được thực hiện dễ dàng trong không gian cụm. Vì điều này, tôi không tin tưởng bất cứ ai đưa ra một mô hình không theo sát xu hướng phần cứng mới, tôi thực sự bị thuyết phục bởi ý kiến ​​này bởi công trình từ Vivak Sarakar .

Để phù hợp với điều đó, đây là ba xu hướng rõ ràng đang đi đầu trong các kiến ​​trúc mới. Và hãy để tôi nói rõ, hiện có mười hai kiến trúc khác nhau đang được bán trên thị trường trong HPC. Điều này tăng từ cách đây chưa đầy 5 năm chỉ có tính năng x86, vì vậy những ngày tới sẽ có nhiều cơ hội sử dụng phần cứng theo những cách khác nhau và thú vị

• Chips mục đích đặc biệt: Hãy nghĩ rằng các đơn vị vectơ lớn như máy gia tốc (được xem bởi Bill Dally của Nvidia)
• Chip công suất thấp: Các cụm dựa trên ARM (để chứa ngân sách năng lượng)
• Ốp lát chip: nghĩ rằng ốp lát chip với các thông số kỹ thuật khác nhau (công việc của Avant Argwal )

Mô hình hiện tại

Mô hình hiện tại thực sự là 3 cấp độ sâu. Mặc dù có nhiều mã sử dụng tốt hai trong số các cấp độ này, nhưng không có nhiều mã đã xuất hiện bằng cả ba cấp độ. Tôi tin rằng trước tiên để có được exascale, người ta cần đầu tư vào việc xác định xem mã của bạn có thể chạy ở cả ba cấp độ hay không. Đây có lẽ là con đường an toàn nhất để lặp lại tốt với các xu hướng hiện tại.

Hãy để tôi lặp lại trên các mô hình và cách chúng sẽ cần thay đổi dựa trên các quan điểm phần cứng mới được dự đoán.

Phân phối

Những người chơi ở cấp độ phân phối phần lớn rơi vào ngôn ngữ MPI và PGAS. MPI là một người chiến thắng rõ ràng ngay bây giờ, nhưng các ngôn ngữ PGAS như UPC và Nhà nguyện đang tiến vào không gian. Một dấu hiệu tốt là Thử thách Điểm chuẩn HPC. Các ngôn ngữ PGAS đang đưa ra các triển khai rất chuẩn của các điểm chuẩn.

Điểm thú vị nhất ở đây là trong khi mô hình này hiện chỉ hoạt động ở cấp độ nút, nó sẽ là một mô hình quan trọng bên trong một nút cho các kiến ​​trúc Tiled. Một dấu hiệu là chip Intel SCC, về cơ bản hoạt động giống như một hệ thống phân tán. Nhóm SCC đã tạo ra triển khai MPI của riêng họ và nhiều nhóm đã thành công trong việc chuyển các thư viện cộng đồng sang kiến ​​trúc này.

Nhưng thành thật mà nói PGAS thực sự có một câu chuyện hay để bước vào không gian này. Bạn có thực sự muốn lập trình MPI internode và sau đó phải thực hiện cùng một intranode lừa không? Một vấn đề lớn với các kiến ​​trúc lát gạch này là chúng sẽ có tốc độ xung nhịp khác nhau trên chip và sự khác biệt lớn về băng thông cho bộ nhớ, do đó, các mã hiệu suất phải tính đến điều này.

Bộ nhớ chia sẻ trên nút

Ở đây chúng ta thấy MPI thường "đủ tốt", nhưng PThread (và các thư viện xuất phát từ các PThread như Intel Parallel Building Blocks) và OpenMP vẫn được sử dụng thường xuyên. Quan điểm chung là sẽ có lúc có đủ các luồng bộ nhớ được chia sẻ mà mô hình ổ cắm của MPI sẽ bị hỏng cho RPC hoặc bạn cần một quy trình trọng lượng nhẹ hơn chạy trên lõi. Bạn đã có thể thấy các dấu hiệu của các hệ thống IBM Bluegene có vấn đề với MPI bộ nhớ dùng chung.

Như Matt nhận xét, hiệu suất tăng lớn nhất cho các mã chuyên sâu tính toán là vector hóa mã nối tiếp. Mặc dù nhiều người cho rằng điều này là đúng trong các máy gia tốc, nhưng nó cũng rất quan trọng đối với các máy trên nút. Tôi tin rằng West 4.0.3 có 4 FPU rộng, do đó người ta chỉ có thể nhận được một phần tư số flops mà không cần vector hóa.

Mặc dù tôi không thấy OpenMP hiện tại bước vào không gian này, nhưng có một nơi dành cho các chip năng lượng thấp hoặc gạch để sử dụng nhiều luồng ánh sáng hơn. OpenMP gặp khó khăn khi mô tả cách thức luồng dữ liệu hoạt động và khi sử dụng nhiều luồng hơn, tôi chỉ thấy xu hướng này trở nên cường điệu hơn, chỉ cần nhìn vào các ví dụ về những gì người ta phải làm để có được tìm nạp trước thích hợp với OpenMP.

Cả OpenMP và PThread ở một mức độ đủ khóa học đều có thể tận dụng lợi thế của vector hóa cần thiết để có được tỷ lệ phần trăm cao nhất, nhưng làm như vậy đòi hỏi phải phá vỡ các thuật toán của bạn theo cách mà vector hóa là tự nhiên.

Đồng xử lý

Cuối cùng, sự xuất hiện của bộ đồng xử lý (GPU, MIC, bộ tích hợp di động) đã được giữ vững. Nó trở nên rõ ràng rằng không có con đường đến exascale sẽ được hoàn thành mà không có họ. Tại SC11, mọi thí sinh đạt giải Bell đều sử dụng chúng rất hiệu quả để đến được các petaflop thấp. Trong khi CUDA và OpenCL đã thống trị thị trường hiện tại, tôi có hy vọng cho trình biên dịch OpenACC và PGAS vào không gian.

Bây giờ để có được exascale, một đề xuất là ghép các chip có công suất thấp với nhiều bộ đồng xử lý. Điều này sẽ tiêu diệt khá tốt lớp giữa của ngăn xếp hiện tại và sử dụng các mã quản lý các vấn đề quyết định trên chip chính và tắt công việc cho các bộ đồng xử lý. Điều này có nghĩa là để mã hoạt động khá hiệu quả, một người phải suy nghĩ lại về các thuật toán về các hạt nhân (hoặc bảng mã), đó là đoạn mã song song ở mức hướng dẫn không phân nhánh. Theo tôi biết, một giải pháp cho sự tiến hóa này là khá rộng mở.

Điều này ảnh hưởng đến nhà phát triển ứng dụng như thế nào

Bây giờ để có được câu hỏi của bạn. Nếu bạn muốn bảo vệ bản thân khỏi sự phức tạp sắp tới của máy exascale, bạn nên làm một số điều:

• Phát triển các thuật toán của bạn để phù hợp với ít nhất ba cấp độ phân cấp song song.
• Thiết kế các thuật toán của bạn theo các hạt nhân có thể được di chuyển giữa chế độ bá đạo.
• Thư giãn nhu cầu của bạn cho bất kỳ quá trình tuần tự, tất cả các hiệu ứng này sẽ xảy ra không đồng bộ bởi vì thực thi đồng bộ là không thể.

Nếu bạn muốn trở thành người biểu diễn ngay hôm nay, MPI + CUDA / OpenCL là đủ tốt nhưng UPC đang đến đó vì vậy không phải là ý tưởng tồi để mất vài ngày và tìm hiểu nó. OpenMP giúp bạn bắt đầu nhưng dẫn đến các vấn đề một khi mã cần được cấu trúc lại. PThreads yêu cầu hoàn toàn viết lại mã của bạn theo phong cách của nó. Điều này làm cho MPI + CUDA / OpenCL là mô hình tốt nhất hiện tại.

Những gì không được thảo luận ở đây

Trong khi tất cả các cuộc nói chuyện về exascale này là tốt đẹp, một điều không thực sự được thảo luận ở đây là nhận dữ liệu vào và ra khỏi máy. Mặc dù đã có nhiều tiến bộ trong các hệ thống bộ nhớ, chúng ta không thấy chúng trong cụm hàng hóa (quá đắt đỏ). Giờ đây, máy tính chuyên sâu dữ liệu đang trở thành một trọng tâm lớn của tất cả các hội nghị siêu máy tính, chắc chắn sẽ có một chuyển động lớn hơn vào không gian băng thông bộ nhớ cao.

Điều này mang đến xu hướng khác có thể xảy ra (nếu các cơ quan tài trợ phù hợp tham gia). Máy móc sẽ ngày càng trở nên chuyên biệt hơn cho loại máy tính cần thiết. Chúng ta đã thấy các máy "thâm dụng dữ liệu" được NSF tài trợ, nhưng các máy này nằm trên một đường đua khác so với Thử thách lớn Exascale 2019.

Điều này trở nên dài hơn dự kiến ​​yêu cầu tham khảo nơi bạn cần chúng trong các ý kiến

Hãy bắt đầu bằng cách thảo luận một chiến lược cho mã intranode (điện toán không chạm vào kết nối), vì tôi nghĩ MPI là một lựa chọn tốt cho mã liên mã. Tôi nghĩ thật vô nghĩa khi nói về các nút có ít hơn 100 lõi, vì vậy ít nhất là một GPU hoặc MIC hiện tại.

Thực tế là một mình pthreads không thể giúp bạn đạt được hiệu suất tối đa trên bất kỳ chip hiện đại nào, bởi vì bạn phải tận dụng đơn vị vectơ (đúng kể từ Cray đầu tiên). Trên Intel và AMD, bạn có thể sử dụng nội tại, nhưng những thứ này không thể mang theo được, và theo tôi là khó hiểu. CUDA và OpenCL có vector hóa được tích hợp vào thư viện và giúp dễ dàng đạt được hiệu suất tối đa. Tất cả các phần cứng mới mà tôi biết đều có yêu cầu vectơ này, vì vậy mọi giải pháp nên tính đến điều này. Đối với tôi, CUDA / OpenCL là cách hiện tại để đi.

Tiếp theo, tất cả các máy này sẽ là NUMA, khó lập trình hơn, nhưng tôi nghĩ rằng chiến lược kernel hoạt động. Bạn chia công việc và dữ liệu thành các đơn vị nhỏ. Chúng có thể sẽ được tự động lên lịch, như hiện đang xảy ra trong CUDA và OpenCL, nhưng bạn có thể chỉ định các phụ thuộc. Đối với các vấn đề phù hợp với mô hình phát trực tuyến, phần này cũng có thể được thực hiện tự động. Intel TBB thực hiện điều này, nhưng tôi thích cách tiếp cận thư viện cấp cao hơn được minh họa bởi Thrust và Cusp , có thể nhắm mục tiêu CUDA hoặc (sớm) TBB.

Tôi sẽ thử một câu trả lời ngắn hơn một số đồng nghiệp quý của tôi về chủ đề này ;-)

Thông điệp của tôi cho tất cả các sinh viên của mình luôn là thời gian của nhà phát triển có giá trị hơn thời gian của CPU. Điều đó có nghĩa là nếu bạn có thời gian để chuyển đổi 100% mã với hiệu suất 80% để chạy trên các máy lớn - sử dụng phương pháp cấp cao - thì bạn sẽ tốt hơn so với khi bạn sử dụng mức thấp tốn thời gian Cách tiếp cận mang lại cho bạn hiệu quả 100% trên 20% mã của bạn. Kết quả là, tôi là một fan hâm mộ lớn của các thư viện cấp cao. Yêu thích của tôi trong lĩnh vực này là các khối xây dựng luồng (TBB) vì nó cho phép tôi xem xét các thuật toán ở các vòng ngoài cùng và ở mức cao. Nó cũng có thể thực hiện tất cả những điều bạn có thể muốn làm với pthread mà không cần phải xử lý các chức năng của hệ điều hành, v.v. - vì vậy không có OpenMP,

Tôi không thể nói với chính quyền về OpenCL, CUDA, v.v.

Các câu trả lời được đăng trước đây rất tuyệt vời nhưng chủ yếu tập trung vào kiến ​​trúc nút, mà tôi nghĩ phản ánh thực tế rằng MPI thường được coi là đủ như các mô hình lập trình internode trong hầu hết các trường hợp và đó là sự song song nội bộ nơi chúng ta đấu tranh.

Dưới đây là những nỗ lực của tôi để trả lời hai câu hỏi chưa được trả lời hoặc trả lời theo cách tương đối hạn chế:

Tôi nên đưa ra giả định nào về quy trình kiến ​​trúc kết nối?

Tôi sẽ xem xét ba thuộc tính của mạng:

1. độ trễ,
2. băng thông, và
3. đồng thời.

Độ trễ tỷ lệ nghịch với tần số. Chúng tôi biết rằng quy mô tần số đã bị đình trệ. Do đó, người ta có thể kết luận rằng độ trễ không có khả năng giảm đáng kể trong tương lai. Độ trễ gửi-recv MPI trên Blue Gene / Q là khoảng 2 chúng tôi, tương ứng với 3200 chu kỳ. Hơn một nửa độ trễ đó là phần mềm, nhưng một phần tốt của nó được yêu cầu bởi tiêu chuẩn MPI; điều chỉnh mở rộng có thể giảm độ trễ xuống gần 1 chúng tôi, đặc biệt nếu người ta có thể khẳng định rằng các ký tự đại diện MPI sẽ không được sử dụng.

Trong mọi trường hợp, độ trễ phần cứng cho việc tiêm gói trên hệ thống Blue Gene và Cray là khoảng 1 chúng tôi. Nếu bất cứ điều gì, việc tăng đồng thời mức nút làm cho việc giữ con số này quá thấp, nhưng tôi lạc quan rằng các nhà thiết kế phần cứng sẽ tìm cách giữ độ trễ dưới 5 chúng tôi trong tương lai gần.

Băng thông mạng được tăng lên đáng kể bằng cách tăng số lượng liên kết mạng. Đây chỉ là một phần của câu chuyện, tuy nhiên. Người ta đặt 1000 liên kết ngoài vào một nút và không thể sử dụng chúng nếu bộ xử lý không thể điều khiển mạng ở băng thông đầy đủ. Ví dụ, một số siêu máy tính bị tắc nghẽn trong xe buýt (ví dụ HyperTransport) chứ không phải mạng, về mặt băng thông tiêm.

Không có giới hạn cơ bản cho băng thông mạng, chỉ có những cái thực tế. Băng thông tốn tiền và điện. Các nhà thiết kế hệ thống sẽ phải tính đến sự đánh đổi giữa băng thông mạng và các bộ phận khác của máy khi phát triển các hệ thống trong tương lai. Nhiều mã không bị giới hạn băng thông mạng, vì vậy có vẻ như chúng ta sẽ không thấy các máy có băng thông trên mỗi kết nối nhiều hơn đáng kể trong tương lai. Tuy nhiên, băng thông trên mỗi nút sẽ tăng tỷ lệ thuận với công suất tính toán nên cần có nhiều kết nối trên mỗi nút để mở rộng quy mô.

Thuộc tính thứ ba của các mạng thường bị bỏ qua trong các mô hình chính thức là có bao nhiêu tin nhắn có thể được gửi một lần. Có một mạng với độ trễ 1 ns và / hoặc 1 TB / s băng thông chỉ có thể gửi 1 tin nhắn tại một thời điểm sẽ hoàn toàn vô dụng đối với hầu hết các ứng dụng. Điều quan trọng là có thể gửi nhiều tin nhắn từ nhiều luồng cùng một lúc và để mạng không bị sụp đổ dưới sự tranh chấp. Cả hai hệ thống Cray và Blue Gene hiện đạt được hơn 1 MMPS (triệu tin nhắn mỗi giây). Tôi không thể nhớ các con số chính xác, nhưng cả hai đều có thể đạt được một phần đáng kể băng thông cao điểm với các tin nhắn nhỏ. Một mạng lý tưởng có thể có thể đạt băng thông cao nhất với bất kỳ thông báo kích thước nào, nhưng thực tế điều này là không thể do tiêu đề gói và các chi phí kế toán liên quan. Tuy nhiên,

Đây là một câu trả lời không đầy đủ và không hoàn hảo. Những người khác được hoan nghênh để cố gắng cải thiện nó hoặc đề xuất những điều tôi nên cải thiện.

Các ngôn ngữ không gian địa chỉ toàn cầu được phân vùng sẽ có sẵn "trong sản xuất" trên các máy petascale?

Các hệ thống Cray XE, XK và XC có trình biên dịch UPC và CAF chất lượng sản xuất. Các hệ thống Blue Gene có thể được phân phối với XLUPC và XLCAF nhưng không ai yêu cầu điều này vì vậy nó không được phân phối. PERCS có trình biên dịch XLUPC và XLCAF cấp sản xuất nhưng không có cài đặt quy mô lớn nào có thể truy cập được cho cộng đồng khoa học.

Coarrays là một phần của Fortran 2008, mặc dù các triển khai trong Intel và GNU Fortran vẫn chưa có chất lượng cao. Việc triển khai Intel được cho là có hiệu quả nhưng cũng khá chậm (có một bài viết tại PGAS12 về nó).

Đối với mô hình lập trình PGAS (vì các mô hình lập trình - không phải ngôn ngữ lập trình - là chủ đề của câu hỏi ban đầu), thư viện Global Arrays là một xấp xỉ hợp lý với chất lượng sản xuất trong nhiều trường hợp. Là một bộ thực thi, nó không mạnh bằng MPI, nhưng MPI khá độc đáo về chất lượng triển khai. Việc triển khai ARMCI-MPI của ARMCI làm cho Mảng toàn cầu ổn định hơn nhiều, mặc dù trong một số trường hợp chậm hơn.

Việc thực hiện các cấu trúc kiểu PGAS theo cách chất lượng sản xuất sử dụng MPI-3 RMA tương đối dễ dàng. Nếu ai đó đăng một câu hỏi mới về điều này, tôi sẽ vui lòng trả lời nó.

Số lượng lớn các lõi thực sự cũng mở ra viễn cảnh hữu ích nhưng đáng ngạc nhiên - chỉ để sử dụng nó để chạy nhiều lần lặp lại của toàn bộ mô phỏng.

Phần quan trọng của nghiên cứu tính toán hiện nay tập trung vào việc quét một số không gian tham số, sàng lọc một lượng lớn các điều kiện ban đầu hoặc tính toán phân phối một số kết quả theo cách lấy mẫu lại; tất cả các nhiệm vụ đó là song song lúng túng, do đó Amdahl-Proof.

Tôi nghi ngờ rằng ngay cả những câu trả lời được suy nghĩ kỹ lưỡng nhất cho câu hỏi này sẽ bị lỗi thời trong năm đến mười năm. Với sự không chắc chắn của các mô hình lập trình trong tương lai, có thể không đáng để dành nhiều thời gian để tối ưu hóa trước cơ sở mã của bạn.

Tôi chỉ định đăng câu trả lời này cho câu hỏi này , nhưng nó đã bị đóng như là một bản sao của này, vì vậy đây là:

Điều này nghe có vẻ hơi Solomonic, nhưng theo kinh nghiệm của tôi, tương lai thuộc về hybrid phương pháp trong đó một số nút đa lõi bộ nhớ dùng chung chạy các hạt nhân đa luồng được kết nối thông qua mô hình bộ nhớ phân tán như MPI.

Tuy nhiên, có một vài vấn đề và chúng không liên quan đến phần cứng. Trước hết, hầu hết các lập trình viên song song đều đầu tư rất nhiều vào mã loại MPI và rất miễn cưỡng trở thành người đầu tiên thực hiện lại các phần, hoặc tất cả, dựa trên cơ sở mã của họ bằng cách sử dụng mô hình mới. Việc thiếu người sử dụng các phương pháp tiếp cận bộ nhớ chia sẻ dẫn đến tiến độ chậm hơn trong các thuật toán cho khu vực đó, điều này khiến cho bất kỳ khoản đầu tư nào dường như thậm chí còn vô nghĩa hơn.

Một vấn đề thứ hai là mọi người đều liên kết song song bộ nhớ chia sẻ với OpenMP . Mặc dù OpenMP là một cách nhanh chóng và bẩn thỉu để giải quyết các vấn đề nhỏ, đơn giản trên một số lượng nhỏ bộ xử lý, nhưng đây là một mô hình lập trình hoàn toàn khủng khiếp cho song song bộ nhớ chia sẻ thực . Mặc dù tất cả chúng ta, vào lúc này hay lúc khác, đã học được một số mô hình lập trình song song đơn giản và hiệu quả, ví dụ: Nhóm luồng hoặc Trình lập lịch biểu , những điều này không dễ thực hiện bằng OpenMP và, thật lòng mà nói, đây không phải là kiểu song song OpenMP lôi kéo các lập trình viên sử dụng.

Tóm lại, rào cản chuyển từ bộ nhớ phân tán thuần túy sang mô hình bộ nhớ chia sẻ thuần túy / một phần là khá cao. Nếu bạn muốn sử dụng các luồng hiệu quả, bạn phải quên OpenMP và tự quản lý các luồng và đồng thời (xin chào pthreads , tạm biệt Fortran).

Nhưng tại sao lại chuyển sang một cách tiếp cận lai? Chà, mặc dù MPI có quy mô lên tới hàng ngàn lõi, mô hình cơ bản là một trong những kiểu đồng bộ hóa và bước giao tiếp tĩnh. Điều này tốt cho một số vấn đề, ví dụ như mô phỏng tỷ hạt, nhưng tối ưu phụ cho các vấn đề khó hơn hoặc chi tiết hơn. Các mô hình bộ nhớ chia sẻ làm cho việc cân bằng tải động và / hoặc giao tiếp không đồng bộ dễ dàng hơn nhiều, nhưng thực hiện liên quan đến một nỗ lực lập trình lớn.