Chính sách MPI cho nhiều lần chuyển không đồng bộ

Chính sách của nhiều lần chuyển giao không đồng bộ chồng chéo trong MPI là gì?

Tôi có một chương trình với một số irecvhoạt động không đồng bộ mở . Tôi thấy rằng các giao dịch chuyển tiền có thể diễn ra (tương ứng isendđã được gọi) chờ trên các chuyển khoản khác chưa sẵn sàng (tương ứng isendchưa được gọi). Để rõ ràng sự không hiệu quả này không xuất phát từ sự tranh chấp mạng; mạng của tôi là không cần thiết.

Chương trình của tôi trông như sau:

Máy 1

call irecv(variable A from machine 2)
call irecv(variable B from machine 2)
call irecv(variable C from machine 2)
call wait(variable C from machine 2)
call do_important_work_with(variable C)
....

Máy 2

call isend(variable C to machine 1)
call isend(variable B to machine 1)
call do a bunch of costly work
call isend(variable A to machine 1)
....

Vấn đề

Việc chuyển giao Cdường như bị chặn không cần thiết bởi việc chuyển giao A.

Tôi thấy rằng waittrên variable Ctrên máy 1 không hoàn thành cho đến khi sau khi công việc tốn kém trên máy 2 hoàn tất. Điều này thật đáng tiếc vì việc chuyển tiền này có thể đã bắt đầu khi bắt đầu chương trình của tôi. Dường như phải chờ đợi để chuyển Ahoàn thành.

Câu hỏi

Đặc biệt tôi có một tính toán như sau.

Đây có phải là mong đợi?
Chính sách của nhiều lần chuyển giao không đồng bộ chồng chéo là gì?
Điều này có thể tránh được mà không cần sắp xếp lại mã của tôi (có một số cài đặt nội bộ có liên quan) không?
Tôi nên đi đâu để tìm hiểu thêm về chính sách của Bộ KH & ĐT cho nhiều lần chuyển trực tiếp?

parallel-computing software mpi

— MRocklin
nguồn

Làm thế nào lớn là chuyển? Chuyển có cùng chữ ký được yêu cầu xảy ra theo thứ tự. Bạn có sử dụng các thẻ khác nhau cho các lần chuyển khác nhau không? Ngoài ra, bạn không nên sử dụng ngăn xếp MPI nào. Các ngữ nghĩa của thứ tự chuyển giao được xác định bởi các tiêu chuẩn MPI.

— Bill Barth

Chuyển khoản lớn (khoảng 1MB) và có cùng kích thước / nguồn / đích (đây có phải là chữ ký không?). Họ có các thẻ khác nhau.

— MRocklin

Các thẻ khác nhau sẽ cho phép chúng đi theo bất kỳ thứ tự nào, nhưng phần cứng phải thực sự di chuyển dữ liệu và nó thực sự không thể làm điều đó song song. Vì vậy, nếu đó là một thông báo lớn, bạn có thể đang chờ phần cứng bên dưới để sao chép A và B vào bộ đệm nội bộ hoặc DMA nó vào NIC (tùy thuộc vào phần cứng bạn có). Tôi khuyên bạn nên thay đổi thứ tự mà bạn gửi nhận và cũng thử sử dụng một ngăn xếp khác (MPICH, MVAPICH, Intel MPI, v.v.) tùy thuộc vào phần cứng của bạn. Ngoài ra, bạn có thể thử bật chủ đề tiến độ.

— Bill Barth

Nếu bạn có kiểu mẫu giao tiếp này, đã qua Ethernet, tôi thực sự khuyên bạn nên sử dụng zmq thay vì mpi.

— meawoppl

Không có gì đảm bảo trong tiêu chuẩn rằng mọi tiến trình được thực hiện đối với việc gửi không chặn cho đến khi bạn thực sự gọi MPI_WAIT. Đó là một triển khai hoàn toàn hợp lệ để chỉ xếp hàng các hoạt động và khi bạn gọi MPI_WAIT, tất cả các MPI_ISENDhoạt động hoàn thành cùng một lúc. Trong thực tế, họ thường có cơ hội tiến bộ bất cứ khi nào bạn vào thư viện MPI và nếu bạn bật các luồng tiến trình không đồng bộ, họ có cơ hội tiến triển tốt hơn trong nền.

Đối với vấn đề chữ ký, Bộ KH & ĐT đảm bảo rằng các tin nhắn trên cùng một người truyền tin đến cùng một cấp bậc sẽ được nhận theo cùng thứ tự mà chúng được gửi.

Từ phiên bản tiêu chuẩn MPI 3.0:

Tin nhắn đặt hàng không vượt quá: Nếu người gửi gửi hai tin nhắn liên tiếp đến cùng một đích và cả hai đều khớp với cùng một nhận, thì thao tác này không thể nhận được tin nhắn thứ hai nếu tin nhắn đầu tiên vẫn đang chờ xử lý. Nếu một người nhận gửi hai lần nhận liên tiếp và cả hai khớp với cùng một tin nhắn, thì hoạt động nhận thứ hai không thể được thỏa mãn bởi tin nhắn này, nếu lần đầu tiên vẫn đang chờ xử lý.

Điều này không nói lên bất cứ điều gì về cách triển khai chọn gửi tin nhắn, nhưng ít nhất chúng sẽ được nhận theo đúng thứ tự.

Lời khuyên của tôi là trước tiên hãy đảm bảo rằng bạn đã kích hoạt các chuỗi tiến trình, sau đó đảm bảo rằng bạn đang gọi chờ ở nơi bạn thực sự cần các tin nhắn được gửi (mặc dù với các chuỗi tiến trình, rất có thể bạn sẽ ổn).

— Wesley Bland
nguồn