Phiên bản không chặn của MPI_Barrier trong MPI 2


8

Tôi có một loạt các quy trình MPI trao đổi thông điệp yêu cầu qua lại. Các quy trình không biết quy trình nào khác sẽ gửi tin nhắn cho họ hoặc bao nhiêu. Với tình huống này, tôi muốn một cách hiệu quả để biết liệu tất cả các quy trình khác có cho rằng mình đã gửi tin nhắn hay không.

Điều này sẽ được thực hiện hoàn hảo bằng phiên bản không chặn của MPI_Barrier sau, chúng tôi sẽ gọi MPI_Ibarrier:

int MPI_Ibarrier(MPI_Comm comm, MPI_Request* request);

MPI_Ibarrier sẽ trở lại ngay lập tức và các hoạt động tiêu chuẩn trên đối tượng yêu cầu sẽ cho chúng tôi biết khi nào mọi người đã đạt được rào cản.

Có cách nào để mô phỏng hành vi này một cách hiệu quả trong MPI 2 (nghĩa là không có tập thể không chặn chính thức) không?


Và, thực sự, MPI_Ibarrier trên toàn Google liên quan đến nhóm làm việc MPI 3. Bây giờ chúng ta chỉ cần tương lai ...
Geoffrey Irving

Tôi không thấy nó sẽ hoạt động như thế nào. Có lẽ bạn đang dự định gọi MPI_Ibarrier trong một quy trình khi nó được thực hiện với các thông báo cho lần lặp này và sau đó gọi MPI_Wait khi nào? Nếu các nhiệm vụ sẽ tiếp tục sau MPI_Ibarrier, họ sẽ được phép đi bao xa trước khi họ phải gọi MPI_Wait? Nếu họ được phép đi xa hơn trước khi họ phải biết rằng tất cả các procs đã được thực hiện, tại sao không đặt MPI_Barrier vào thời điểm đó? IME, MPI_Barrier hầu như luôn luôn sai khi đặt mã của bạn ngoại trừ mục đích gỡ lỗi. Hầu như luôn luôn có một cách hiệu quả hơn để cấu trúc mã.
Bill Barth

Trong trường hợp này, tôi tin rằng MPI_Ibarrier là cách tối ưu, vì bất kỳ tin nhắn nào từ kỷ nguyên giao tiếp tiếp theo đều không thể được bắt đầu mà không giải phóng một khối bộ nhớ rất lớn và phân bổ lại một bộ nhớ mới. Rào cản là cần thiết để biết khi nào bộ nhớ này có thể được giải quyết, không trực tiếp khi tin nhắn trong tương lai có thể được gửi.
Geoffrey Irving

Câu trả lời:


11

Đáng chú ý, MPI_Ibarrierlà một thói quen rất hữu ích. Ví dụ: bạn có thể gửi một vòng tin nhắn không có cấu trúc đến các cấp bậc mà không biết có bao nhiêu tin nhắn nhận được bằng cách gửi với MPI_Issend(vâng, việc sử dụng gửi đồng bộ hiếm), sau đó nhập một vòng lặp xen kẽ MPI_Testall(để xem việc gửi đã hoàn thành chưa) và MPI_Iprobe(để xử lý tin nhắn đến). Khi gửi xong, bạn đăng MPI_Ibarriervà kiểm tra thay thế rào cản thăm dò các tin nhắn đến. Torsten Hoefler có một bài viết về điều này, nơi ông chứng minh sự tối ưu trong giao tiếp, xem Thuật toán 2: http://unixer.de/publications/img/hoefler-dsde-prot Protocol.pdf

Lưu ý rằng một rào cản không đảm bảo rằng các thông điệp điểm-điểm hoặc các tập thể không chặn khác được đăng trước khi rào cản hoàn thành. Nếu bạn muốn họ hoàn thành, bạn phải đảm bảo rằng họ đã hoàn thành trước khi đăng rào cản. Như Bill nói, (chặn) MPI_Barrierlà không chính xác / không cần thiết trong hầu hết các trường hợp. Một ngoại lệ là giao tiếp thông qua các kênh bên như hệ thống tập tin.

Mặc dù không có cách nào hiệu quả tương tự để mô phỏng MPI_Ibarriervới MPI-2, MPICH2 cung cấp MPIX_Ibarriertrong nhánh 1.5 (hiện tại). Các mạng của nhà cung cấp thường hỗ trợ các hoạt động này để các triển khai của nhà cung cấp (thường có nguồn gốc từ MPICH2) chỉ cần một giao diện. Ngay khi các bản vá của họ chuyển đến 1,5, MPI_Ibarriervà các tập thể không chặn khác cần được hỗ trợ. Chi nhánh phát triển Open MPI có triển khai MPI_Ibarrierdựa trên libNBC.


Tôi nghĩ rằng bạn có thể thực hiện điều đó với một thông điệp cờ / thẻ đặc biệt hiệu quả hơn một rào cản của bất kỳ loại nào có thể có. Bạn có một liên kết đến giấy của Hoefler?
Bill Barth

@BillBarth Hãy nhớ rằng điều này không có cấu trúc và bạn không biết bạn cần nhận bao nhiêu tin nhắn. Ai sẽ gửi thẻ và cho ai? Cuối cùng, bạn sẽ thực hiện Ibarrier của riêng bạn theo điểm-điểm, sẽ chậm hơn so với triển khai gốc. Bài báo có lẽ là trên trang web của mình. Chúng tôi đã nói về nó một vài tháng trước.
Jed Brown

Thực hiện giảm cây của riêng tôi theo từng điểm là chính xác những gì tôi đã làm. Chỉ có 36 cuộc gọi rào cản trong toàn bộ chương trình, do đó, việc chậm lại không phải là vấn đề.
Geoffrey Irving

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.