Tin nhắn MPI có thể được ưu tiên?

Theo như tôi hiểu, thứ tự mà các tin nhắn MPI điểm-điểm không chặn (Isend và Irecv) được nhận phù hợp với thứ tự chúng được gửi. Có bất kỳ kỹ thuật để ưu tiên tin nhắn nhất định hơn những người khác?

Ví dụ: chúng tôi có một thuật toán đa cấp trong đó các giải pháp độ phân giải cao được gửi với các cuộc gọi và tính toán không chặn ở các mức độ thô được thực hiện trong khi các thông điệp tốt được gửi. Tuy nhiên, khi đến lúc gửi các giải pháp độ phân giải thấp, chúng tôi muốn các giải pháp đó được ưu tiên (về cơ bản chúng đang chặn).

Tôi cũng có thể tưởng tượng rằng điều này có thể hữu ích cho các thuật toán khác khi chúng ta chuyển sang exascale: một số tin nhắn nằm trong "đường dẫn quan trọng" trong khi các thuật toán khác thì không.

Tôi nghĩ rằng câu trả lời cho điều này là không. Khi bạn đã đẩy chúng vào ngăn xếp MPI, chúng nằm ngoài tầm kiểm soát của bạn và ngữ nghĩa của MPI chi phối cách gửi tin nhắn.

Bạn chắc chắn có thể ưu tiên các tin nhắn bằng cách xếp hàng chúng trong mã của bạn trước khi gửi chúng, và sau đó kiểm tra thường xuyên, điều quan trọng nhất để gửi. Nhưng tôi hoàn toàn không tin rằng bạn sẽ nhận được bất kỳ lợi ích nào. Có bằng chứng nào cho thấy những thông điệp tốt đẹp của bạn không hoàn thành khi bạn sẵn sàng gửi những tin nhắn thô? Nếu không có, thì bạn có thể muốn điều tra xem có cần thiết ở nơi đầu tiên không.

Hiện tại MPI không có quy định về mức độ ưu tiên của tin nhắn và cũng không có tiêu chuẩn MPI 3.0 sắp tới. Tùy thuộc vào việc triển khai Bộ KH & ĐT để quyết định cách truyền tải các thông điệp. Ví dụ, các tin nhắn nhỏ hơn có thể được gửi nhanh hơn do có một số bỏ qua trong bộ máy truyền thông (thực hiện cao và phụ thuộc hệ thống). Bạn có thể khai thác thực tế là hầu hết các triển khai MPI chia các thông điệp lớn thành nhiều phần và các thông điệp nhỏ hơn có thể trượt giữa các phần của các phần lớn. Nhưng, một lần nữa, điều này phụ thuộc rất nhiều vào việc thực hiện và tôi sẽ không dựa vào điều đó.

Tôi đã thực hiện một thử nghiệm đơn giản bằng Open MPI 1.5.3 qua kết nối InfiniBand. Chương trình sẽ gửi một tin nhắn rất lớn (1 GiB) MPI_Isendvà sau đó là hai tin nhắn ngắn (16 byte) MPI_Sendvà sau đó, nó sẽ chờ gửi lớn để hoàn thành MPI_Wait. Mặt khác, một MPI_Irecvđầu tiên được đăng cho nhận lớn và sau đó hai MPI_Recvhoạt động tiếp theo, tiếp theo MPI_Waitcho nhận lớn. Tôi đã liên tục có thể nhận được hai tin nhắn ngắn trước khi nhận được tin nhắn lớn đã hoàn thành. Đây là đầu ra của bài kiểm tra của tôi:

[0] Rank 0 running on host1
[0] Starting big send at 0.000019s
[0] Starting small send at 0.215448s
[0] Starting small send 2 at 0.224105s
[0] Starting wait at 0.224114s
[0] Finished wait at 0.935843s
[1] Rank 1 running on host2
[1] Starting big receive at 0.000020s
[1] Starting small recv at 0.000037s
[1] Starting small recv 2 at 0.548396s
[1] Starting wait at 0.548418s
[1] Finished wait at 0.935780s

Cả hai lần gửi nhỏ đều thành công trước khi việc gửi async hoàn thành rõ ràng từ thời gian chờ ~ 700 ms. Tôi sẽ nói rằng nhận nhỏ đầu tiên thành công một thời gian (~ 300 ms) sau khi nhận lớn đã bắt đầu trong nền. Tôi đã thử điều này bằng cách chỉ sử dụng MPI_COMM_WORLDhoặc sử dụng một bộ truyền thông riêng cho các tin nhắn nhỏ - kết quả là như nhau. Các nút có một QĐR IB HCA mỗi và chạy với --mca btl_base_verbose 50xác nhận rằng không có kênh truyền thông thay thế nào được sử dụng.

Điều này không được MPI hỗ trợ cũng như bất kỳ phần mềm trung gian giao tiếp nào tôi biết. Điều này có lẽ là do nó không được hỗ trợ bởi bất kỳ phần cứng nào tôi biết, ngoại trừ Blue Gene, nơi có các gói ưu tiên cao cho các tin nhắn điều khiển sẽ vượt qua các tin nhắn khác trong một số điều kiện. Tuy nhiên, đây không phải là để sử dụng chung vì chúng chỉ cho phép một người giao tiếp 64 byte (ít nhất là trên Blue Gene / P).

Tin tốt là bạn không cần điều này. Chi phí để thực hiện nó sẽ không có giá trị và bạn sẽ thấy - giả sử bạn đã từng điều tra các chi tiết cấp thấp - rằng việc không thực hiện các ưu tiên trong mạng cho phép MPI cung cấp hiệu suất tốt nhất trong hầu hết các ứng dụng.

Có một chút kỳ lạ khi bạn đề cập đến điều này trong bối cảnh đặt hàng tin nhắn. Trích dẫn bạn:

Theo như tôi hiểu, thứ tự mà các tin nhắn MPI điểm-điểm không chặn (Isend và Irecv) được nhận phù hợp với thứ tự chúng được gửi.

Điều đáng nói ở đây là Bộ KH & ĐT chỉ đảm bảo rằng các thông điệp phù hợp giữa các quy trình sẽ được nhận theo thứ tự chúng được gửi. Bạn thực sự không muốn loại đặt hàng này thay đổi, bởi vì nó làm cho mã của bạn dễ hiểu hơn và giảm bớt gánh nặng lớn cho bạn với tư cách là lập trình viên ứng dụng.

Tuy nhiên, nếu bạn đã gửi tin nhắn với các thẻ khác nhau, điều đó sẽ thay đổi tiêu chí phù hợp và bạn có thể dễ dàng nhận được tin nhắn thứ hai trước số thứ nhất. Xem ví dụ thứ hai trong phần có liên quan của tiêu chuẩn để biết chi tiết. Tôi hy vọng rằng nếu bạn có hai đoạn mã được gửi đồng thời rằng bạn đã tách các thông điệp thô và tốt bằng cách sử dụng các thẻ và không cố gắng thực hiện một số giao thức của riêng bạn khi đặt hàng tin nhắn. Đây là bản chất thứ hai đối với hầu hết các lập trình viên MPI mà tôi biết.

Dù sao, giả sử bạn đang làm điều đó, có lẽ bạn lo ngại rằng các tin nhắn chi tiết có khối lượng lớn sẽ làm tắc nghẽn mạng của bạn khi bạn muốn gửi những tin nhắn thô. Lời khuyên chung của tôi về vấn đề này là nếu đó không phải là vấn đề về hiệu suất mà bạn thực sự có thể đo lường ngay bây giờ, thì bạn thực sự không nên bận tâm giải quyết nó. Bạn dường như xác nhận rằng đó không phải là một vấn đề trong một trong những ý kiến ​​trên.

Một giải pháp khả thi mà bạn có thể cân nhắc là sử dụng một tập thể không chặn (NBC) như Bcast hoặc Barrier để thông báo cho mọi người rằng giai đoạn thô đã được thực hiện và sẵn sàng gửi giải pháp của nó. Trong tất cả khả năng, lưu lượng truy cập NBC sẽ không được ưu tiên, nhưng các quy trình được thông báo ít nhất có thể dừng gửi gobs các giải pháp tốt cho đến khi việc gửi thô được thực hiện. NBC sẽ ở MPI-3 hoặc bạn có thể thử sử dụng libNBC nếu bạn không thể đợi lâu như vậy.

Mặc dù vậy, một lần nữa, điều này có vẻ như rất nhiều công việc cho một cái gì đó không có vẻ như đó là một vấn đề hiệu suất.