MPI 特別講義まとめ

これは何か

2026-07-11 の特別講義（MPI 入門）の記録です。当日の殴り書きメモを、後から読み返せる形に整理しました。

内容は MPI の仕様（specification）レベルの基礎知識が中心です。特記がない限り、ここに書いたことは MPI 標準として定まっている情報です。実装（Open MPI など）に依存する挙動は、その旨を明記します。

• MPI（Message Passing Interface）: 分散メモリ並列プログラミングの API を定めた国際標準仕様。

1. 並列計算と分散計算

メモリモデルによる分類

補足：理論値を超える Speedup

理論上の上限を超える速度向上（super-linear speedup）が観測されることがあります。主な要因は次の通りです。

• メモリとキャッシュの効果（データが分割されて各ノードのキャッシュに載りやすくなる）
• 並列探索アルゴリズムで早く解が見つかる場合
• 単なる測定上のばらつき（偶然）

2. MPI：仕様と実装の関係

「MPI は specification（仕様）」であり、実際に動くのはその実装です。ここは混同しやすいので分けて整理します。

MPI 仕様の実装（MPI 標準に準拠したライブラリ）

いずれも mpirun / mpiexec を提供し、MPI プログラムを動かすランタイム兼ライブラリです。

GPU 向けコレクティブ通信ライブラリ（MPI 実装ではない）

NCCL / RCCL / HCCL は MPI の実装ではありません。ベンダーごとの GPU/アクセラレータ向け高速コレクティブ通信ライブラリで、allreduce、broadcast、allgather などの集合通信に特化しています。

階層イメージ

• MPI（汎用メッセージパッシングの標準仕様）
  • Open MPI / MPICH / MVAPICH / Intel MPI（仕様に沿った実装）
• NCCL / RCCL / HCCL（各社が GPU 向けに出す高速集合通信エンジン。規格ではなくプロダクト）

3. MPI Hello World

MPI 入門で最初に出てくる最小プログラムです。mpirun -np N ./a.out で起動すると、同じ実行ファイルが N プロセス立ち上がり、それぞれが自分の rank・ノード名・全体プロセス数を表示します。

int main(int argc, char** argv) {
    int world_size, world_rank, name_len;
    char processor_name[MPI_MAX_PROCESSOR_NAME];

    MPI_Init(NULL, NULL);
    MPI_Comm_size(MPI_COMM_WORLD, &world_size);
    MPI_Comm_rank(MPI_COMM_WORLD, &world_rank);
    MPI_Get_processor_name(processor_name, &name_len);

    printf("Hello world from %s, rank %d/%d\n",
           processor_name, world_rank, world_size);

    MPI_Finalize();
}

各要素の意味

覚え方: MPI プログラムの本編は「MPI_Init 〜 MPI_Finalize の間」。

スライドの色分け: 赤 = MPI 関数、緑 = MPI 定義の定数・ハンドル、黒 = 通常の C 要素。

mpicc hello.c -o hello
mpirun -np 4 ./hello

出力例（どのノードにどの rank が割り当てられたか目視で確認できる）:

Hello world from node01, rank 0/4
Hello world from node02, rank 1/4
Hello world from node02, rank 2/4
Hello world from node03, rank 3/4

4. 通信パターンと基本オブジェクト

MPI でできる通信の「地図」です。

通信パターン

基本オブジェクト

MPI プログラムは「どのコミュニケータ内で」「どのデータ型のバッファを」「どの通信パターンで」やり取りするか、の 3 つを組み合わせて設計します。

5. Tag-Matching（タグマッチング）

MPI_Send と MPI_Recv は同時に呼ぶ必要はありません。MPI ランタイムが送信キュー・受信キューを管理し、条件が合った瞬間にデータを受信バッファへ渡します。この対応付けが Tag-Matching です。

マッチングに使うパラメータ

順序が入れ替わっても正しくつながる

• Recv が先: 受信側が先に MPI_Recv を呼ぶと「未完了の受信」としてキューに登録され、データ到着時に即バッファへコピーされる。
• Send（データ）が先: データが先に届くと内部バッファにストックされ、後から MPI_Recv が呼ばれた瞬間にコピーされる。

正しい source, tag, comm さえ指定すれば、送受信のタイミングをぴったり合わせる必要はありません。

マッチングのルール

• マッチング条件（source, dest, comm, tag）は一意である必要はない。同じ条件のメッセージが複数流れてよい。
• Matching in the order posted: 複数がマッチしうる場合、先にポストされた Recv から順に、先にポストされた Send とマッチする（FIFO）。これにより「送った順＝受け取った順」が保たれ、追い越し（overtaking）が起きない。

アプリからのヒント（info オブジェクト）

コミュニケータに info を付けて「自分はこういうことをしない」と宣言すると、実装がマッチング処理を最適化しやすくなります（実際のキー名・サポート状況は実装依存）。

6. ブロッキング Send/Recv の完了条件と引数

ブロッキングな MPI_Send / MPI_Recv は、安全なタイミングまで戻ってこない設計です。

注意: 関数が戻る前に、Send は送信バッファを書き換えない、Recv は受信バッファを読まないこと。

引数の役割（3 分割）

int MPI_Send(void* buf, int count, MPI_Datatype datatype,
             int dest, int tag, MPI_Comm comm)

int MPI_Recv(void* buf, int count, MPI_Datatype datatype,
             int source, int tag, MPI_Comm comm,
             MPI_Status* status)

7. 送信モード（communication modes）

同じ「送る」でも、何をもって送信完了とみなすかがモードで違います。各モードにブロッキング版とノンブロッキング版があります。

モード × ブロッキング / ノンブロッキング

8. Point-to-Point 通信の保証

MPI 標準がどこまで保証し、どこから実装依存かを整理します。キーワードは Order / Progress / Fairness / Resource limitations。

Quality implementation: MPI 標準の保証は最小限（Order 以外はかなり緩い）。実際の良い実装（Open MPI、MPICH、Intel MPI など）は、高速・公平・安定・良い進行性といった望ましい性質を最適化で提供している。「標準の最低ライン」と「実装が提供する挙動」にはギャップがある点に注意。

HPC コンペでチューニングまで踏み込むなら、実装ごとの Progress 性・背景進行の有無はかなり効いてくる。

9. ノンブロッキング通信の完了確認

MPI_Isend / MPI_Irecv は即戻り、MPI_Request を返します。実際の完了は以下のルーティンで確認します。

完了の意味

• 送信（Isend）の完了 → 送信バッファを安全に上書きできる。
• 受信（Irecv）の完了 → 受信バッファにメッセージが入っている。

単一操作の完了

複数のうちどれか 1 個の完了（ANY）

MPI_Request の配列を渡し、そのうち 1 つが完了したら教えてくれます。

典型パターン: 多数の Isend / Irecv を投げておき、Waitany / Testany で「終わった順」に処理して通信と計算を重ねる。

MPI_Request reqs[N];
/* Isend / Irecv をセットアップして reqs に入れる */
for (int finished = 0; finished < N; ++finished) {
    int index;
    MPI_Status status;
    MPI_Waitany(N, reqs, &index, &status);
    /* index 番目の通信の後処理 */
}

10. 集団通信（Collective）

集団通信はコミュニケータ単位で定義されます（defined in the context of a communicator）。そのコミュニケータに属するランクが、全員または特定パターンで同じ collective 関数を呼ぶのが前提です。

10-1. 3 つの分類軸

「nonblocking + persistent + neighborhood」を組み合わせると強力な性能チューニングができる、という布石。

10-2. 入出力パターンによる 4 分類

「誰がデータを出し、誰が結果を受け取るか」で分類します。

グラフでのイメージ

• One-To-All: ルート 1 個 → 全ノードへ広がる木（Bcast, Scatter）
• All-To-One: 全ノード → ルート 1 個へ集まる木（Gather, Reduce）
• All-To-All: 全ノード間の多重エッジ（Allgather, Alltoall, Allreduce）
• Other: 部分和や同期など、単純な送受図で表しづらいもの（Scan, Barrier）

この型を頭に入れておくと、「Allreduce を Allgather + Reduce に分解できるか」「Bcast の木構造はどうか」といった議論が整理しやすくなる。

大会との関係（メモ）

• OpenFOAM 課題（テーマ①）は分散メモリ並列 = MPI が中核。領域分割・ランク配置・通信量・MPI I/O が性能に直結する。
• 実装ごとの Progress 性・背景進行・コレクティブアルゴリズムの違いは、チューニング時の検討対象になりうる。
• 関連ページ: MPI通信最適化、領域分割（decomposePar）、NCCL通信最適化

参考文献

• MPI Forum（MPI 標準仕様）
• Open MPI Documentation
• MPICH Documentation