手続きポインタが切り拓く、HPCの「動的ディスパッチ」の限界と真実
スパコンのノード内で数百万の計算メッシュを回し、MPIで数万ランクを束ねる――そんな極限の環境において、我々が最も忌み嫌うのは「予測不可能な分岐」だ。
C++の仮想関数や動的ポリモーフィズムをHPCコードに持ち込んではいけない、という教訓は今や常識に近い。しかし、物理モデルの切り替えや境界条件の動的設定といった「柔軟性」を犠牲にすれば、コードはメンテナンス不能なスパゲッティと化す。ここでFortran 2003以降の遺産である「手続きポインタ（Procedure Pointer）」と「抽象インターフェース（Abstract Interface）」が、計算科学者の最後の砦となる。
今日は、単なる文法解説ではなく、CPUのパイプラインを止めることなく、コンパイラの最適化を阻害せずに「動的ディスパッチ」を実現する現場の知見を共有する。
—
1. 抽象インターフェース：コンパイル時の静的保証
手続きポインタを扱う際、最もやってはならないのは「インターフェースを省略すること」だ。もしあなたがプロシージャポインタを定義する際に具体的なシグネチャを指定せず、曖昧な呼び出しを行えば、コンパイラは引数の整合性を検証できず、インライン展開を諦める。
! 抽象インターフェースで「契約」を定義する
abstract interface
subroutine physics_kernel(u, f)
real(8), intent(in) :: u(:)
real(8), intent(out) :: f(:)
end subroutine physics_kernel
end interface
ここで重要なのは、この`abstract interface`が単なる型チェックのためではないという点だ。コンパイラに対し、「このポインタが指す先は、このシグネチャを必ず満たす」と明言することで、LTO（Link Time Optimization）の効きが劇的に変わる。
2. キャッシュを殺さない実装：関数テーブルの局所性
手続きポインタを構造体（Derived Type）の中に埋め込み、オブジェクト指向的に扱うことは強力だが、メモリ配置には細心の注意が必要だ。
プロシージャポインタは単なる関数のアドレス（8バイトのポインタ）に過ぎない。しかし、このポインタを配列の要素として大量に保持し、ループ内で頻繁に切り替えると、CPUの分岐予測器が破綻する。
極限の最適化テクニック：
ポインタを叩く前に、ループを「同じ処理を行うグループ」ごとにチャンク化せよ。
! 悪い例：条件ごとにバラバラに関数を呼ぶ
do i = 1, N
call ptr_array(i)%func(u(:,i), f(:,i)) ! 分岐予測がミスヒットの山を築く
end do
! 良い例：同じ関数ポインタを持つ要素をソート/グルーピングする
do k = 1, num_kernels
do i = start_idx(k), end_idx(k)
call kernel_list(k)%ptr(u(:,i), f(:,i)) ! 予測器が安定し、SIMD化の道が開ける
end do
end do
このように「関数ポインタの配列」を走査する際、ポインタそのものもキャッシュライン（64バイト）に整列させ、データ構造側のメモリレイアウトを工夫することで、メモリアクセスと命令フェッチの競合を回避できる。
3. コンパイラ最適化の「壁」を突破する
Intel `ifort` や `ifx`、あるいは `nvfortran` を使う際、`-O3` を積んでもなお最適化されないケースがある。手続きポインタはコンパイラにとって「エイリアス解析」の最大の敵だ。
ポインタ経由の呼び出しがあると、コンパイラは「その関数の内部で何が起きるか」を予測できないため、ループ不変量の移動（Loop Invariant Code Motion）やベクトル化を抑制する。これを回避するために、ポインタを呼び出すスコープ内に以下のヒントを埋め込むのが現場の定石だ。
! !DIR$ ASSUME_ALIGNED などのディレクティブと組み合わせる
! コンパイラに、この呼び出しが副作用を持たないことを伝える
!$OMP SIMD
do i = 1, N
call proc_ptr(u(:,i), f(:,i))
end do
もし、プロファイラ（VTuneやScalasca）で「Call Overhead」が無視できない値を示しているなら、それはポインタの問題ではなく、ポインタ先の手続きが小さすぎることが原因だ。手続きポインタを多用する場合、個々のルーチンをある程度の粒度（少なくとも数千FLOPs以上）にまとめるのが、ベクトル長を稼ぐための基本である。
4. 大規模並列環境への適応：MPIとの親和性
数万コアのMPI環境において、ランク間で異なる関数ポインタを保持させることは、コードの保守性を高めるが、シリアライズ（MPI_Pack等）時には注意が必要だ。関数ポインタ自体はプロセス空間内のアドレスであり、他のランクへ送信しても意味をなさない。
動的ディスパッチをMPI環境で扱う場合は、ポインタそのものではなく「インデックス（ID）」を管理し、ランクごとにローカルな関数テーブルへマッピングする設計を推奨する。
最後に：アーキテクトからの助言
「Fortranは古臭い」と吐き捨てる若手プログラマにこそ伝えたい。最新のFortran（2018/2023）は、手続きポインタや抽象インターフェースを駆使することで、C++のテンプレートメタプログラミングに匹敵する柔軟性を、圧倒的に高い「数値計算の信頼性」と共に提供できる。
パフォーマンスを極限まで追い込むなら、コンパイラの生成するアセンブラを読み、`vmovups` が発行されているか、あるいは `call` 命令がループ内に埋め込まれてパイプラインを停滞させていないか、血の滲むようなデバッグを繰り返すしかない。
あなたの書いたコードが、スパコンの計算リソースを1％でも無駄なく使い切ることを願っている。それが、我々数値計算エンジニアの矜持だ。
コメント