オールツーワンの通信を順不同で行おうとしています。基本的に、整数IDで識別される、同じサイズの複数の浮動小数点配列があります。
各メッセージは次のようになります。
<int id><float array data>
受信側では、アレイがいくつあるかを正確に把握しているため、正確な数の受信を設定します。メッセージを受信すると、IDを解析し、データを適切な場所に配置します。問題は、メッセージが他のプロセスから受信プロセスに送信される可能性があることです。(たとえば、プロデューサーにはワークキュー構造があり、キューで使用可能なIDを処理します。)
MPIは注文配信でP2Pのみを保証するため、整数IDとFPデータを2つのメッセージに簡単に入れることはできません。そうしないと、受信者がIDとデータを照合できない可能性があります。MPIでは、1回の送信で2種類のデータを使用することもできません。
私は2つのアプローチしか考えられません。
1)受信者はサイズm(source [m])の配列を持ち、mは送信ノードの数です。送信者は最初にIDを送信し、次にデータを送信します。受信者は、送信者iから整数メッセージを受信した後、idをsource[i]に保存します。送信者iからFP配列を受信すると、source [i]をチェックし、IDを取得して、データを適切な場所に移動します。MPIが順序どおりのP2P通信を保証するために機能します。受信者は、送信者ごとに状態情報を保持する必要があります。さらに悪いことに、単一の送信プロセスでデータの前に2つのIDを送信できる場合(マルチスレッドなど)、このメカニズムは機能しません。
2)idとFPをバイトとして扱い、それらを送信バッファーにコピーします。それらをMPI_CHARとして送信すると、レシーバーはそれらを整数とFP配列にキャストバックします。次に、送信側のバイトバッファにコピーするための追加コストを支払う必要があります。MPIプロセス内のスレッドの数が増えると、一時バッファーの合計も増えます。
どちらも完璧なソリューションではありません。プロセス内で何もロックしたくありません。もっと良い提案がありますか?
編集:コードは、infinibandを使用する共有クラスターで実行されます。マシンはランダムに割り当てられます。したがって、TCPソケットがここで私を助けることはできないと思います。さらに、IPoIBは高価に見えます。通信には40Gbpsのフルスピードが必要で、CPUが計算を続けます。