MPIメッセージに優先順位を付けることはできますか？

私が理解している限り、非ブロッキングポイントツーポイントMPIメッセージ（IsendおよびIrecv）が受信される順序は、それらが送信される順序と一致しています。特定のメッセージを他のメッセージよりも優先する方法はありますか？

たとえば、マルチレベルアルゴリズムがあり、高解像度のソリューションがノンブロッキングコールで送信され、細かいメッセージが送信されている間に粗いレベルの計算が行われます。ただし、低解像度のソリューションを送信するときは、それらを優先してください（これらは本質的にブロックされています）。

また、エクサスケールに移行するときに、これが他のアルゴリズムに役立つ可能性があることも想像できます。一部のメッセージは「クリティカルパス」にあり、他のメッセージはそうではありません。

これに対する答えはノーだと思います。それらをMPIスタックにプッシュすると、それらは制御不能になり、MPIセマンティクスがメッセージの送信方法を制御します。

メッセージを送信する前にコードでキューに入れ、送信することが最も重要なメッセージを頻繁にチェックすることで、メッセージに優先順位を付けることができます。しかし、あなたが何らかの利益を得るとは私はまったく確信していません。粗いメッセージを送信する準備ができたときに、細かいメッセージが完全ではないという証拠はありますか？ない場合は、そもそも必要かどうかを調査することをお勧めします。

現在、MPIにはメッセージの優先順位付けに関する規定がなく、次期MPI 3.0標準もありません。メッセージの送信方法を決定するのはMPIの実装です。たとえば、通信機構の特定のバイパス（実装とシステムに大きく依存）が原因で、小さいメッセージはより速く送信される可能性があります。あなたは可能性があるほとんどのMPIの実装はチャンクと小さなメッセージに大きなメッセージを破るという事実を利用することができますかもしれない大規模なものの塊の間で滑ることができるように。しかし、これも実装に大きく依存しているので、私はそれに依存しません。

InfiniBand接続でOpen MPI 1.5.3を使用して簡単な実験を行いました。プログラムは、1つの非常に大きなメッセージ（1 GiB）を送信しMPI_Isend、次に2つの短いメッセージ（16バイト）をMPI_Sendで送信しMPI_Waitます。その後、大きな送信が完了するまで待機します。反対側でMPI_Irecvは、最初に大きな受信用にポストされ、次に2つの後続のMPI_Recvオペレーションが送信さMPI_Waitれ、次に大きな受信用にポストされます。大きなメッセージの受信が完了する前に、2つの短いメッセージを一貫して受信することができました。これが私のテストの出力です：

[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

約700 msの待機時間から明らかなように、両方の小さな送信は非同期送信が完了する前に成功します。最初の小さな受信は、大きな受信がバックグラウンドで開始された後、しばらくの間（約300 ms）成功すると言えます。MPI_COMM_WORLD小さなメッセージに対してのみ、または別のコミュニケーターを使用してこれを試しました-結果は同じです。ノードにはそれぞれ1つのQDR IB HCAがあり、実行中--mca btl_base_verbose 50の代替通信チャネルがないことを確認して実行されます。

これは、MPIや、私が知っている他の通信ミドルウェアではサポートされていません。これはおそらく、Blue Geneを除いて、私が知っているどのハードウェアでもサポートされていないためです。BlueGeneでは、特定の条件下で他のメッセージを追い越す制御メッセージ用の優先度の高いパケットがあります。ただし、64バイト（少なくともBlue Gene / P）では1つしか通信できないため、これらは一般的な用途には使用できません。

良いニュースは、これは必要ないということです。それを実装するためのオーバーヘッドはそれだけの価値はありません。低レベルの詳細を調査することを前提として、ネットワークに優先順位を実装しないことで、MPIがほとんどの用途で最高のパフォーマンスを提供できることがわかります。

メッセージの順序のコンテキストでこれを言及するのは少し奇妙です。あなたを引用：

私が理解している限り、非ブロッキングポイントツーポイントMPIメッセージ（IsendおよびIrecv）が受信される順序は、それらが送信される順序と一致しています。

ここで指摘する価値があるのは、MPIがその一致のみを保証することです。するのは、プロセス間メッセージが送信された順序で受信されることです。このタイプの順序を変更したくない場合は、コードが理解しやすくなり、アプリケーションプログラマとしての負担が大きくなります。

ただし、異なるタグでメッセージを送信すると、一致基準が変更され、最初のメッセージより先に2番目のメッセージを簡単に受信できます。詳細については、規格の関連部分の 2番目の例を参照してください。同時に送信する2つのコードがある場合、タグを使用して粗いメッセージと細かいメッセージをすでに分離しており、メッセージの順序に加えて独自のプロトコルを実装しようとしないことを願っています。これは、私が知っているほとんどのMPIプログラマにとって2番目の性質です。

とにかく、あなたがそうしていると仮定すると、大まかなメッセージを送信したいときに、大量の細かいメッセージがネットワークを詰まらせてしまうのではないかと心配しているでしょう。これに関する私の一般的なアドバイスは、実際に測定できるのがパフォーマンスの問題ではない場合は、まだ対処する必要がないということです。上記のコメントの1つで、まだ問題ではないことを確認しているようです。

あなたは一つの可能な解決策かもしれない考える粗大相はその解決策を送信するために行われ、準備ができていることを皆に知らせるためにBCASTやバリアのような非ブロックの集合（NBC）を用いることであろう。おそらく、NBCトラフィックが優先されることはありませんが、通知されたプロセスは、粗い送信が完了するまで、細かい解決策の塊の送信を少なくとも停止できます。NBC はMPI-3になりますか、それほど長く待てない場合はlibNBCを使用してみてください。

繰り返しになりますが、これはまだパフォーマンスの問題ではないように思えない何かのための多くの作業のようです。