インターフェースの抽象化と「機械の都合」の狭間で：MODULE PROCEDUREによるオーバーロードの真価
Fortran 90以降、我々は`INTERFACE`と`MODULE PROCEDURE`という武器を手に入れた。多くの若手エンジニアは、これを「単なるコードの整理術」と勘違いしている。だが、スパコンのノード内で数百万の計算セルを回し、メモリバスの帯域を限界まで使い切る現場においては、これは「命令パイプラインとキャッシュラインをいかに汚さずに計算を回すか」というハードウェア設計への回答に他ならない。
今日は、汎用性と性能を両立させるための「極限のオーバーロード戦略」について語ろう。
—
1. 「汎用性」の代償：静的ディスパッチを味方につける
Fortranの`MODULE PROCEDURE`によるオーバーロードは、C++の仮想関数のような実行時の動的ディスパッチ（vtable参照）とは全くの別物だ。コンパイル時に呼び出し先が確定する「静的ディスパッチ」であるため、オーバーヘッドはゼロだ。
しかし、ここで一つ注意が必要だ。コンパイラがどの手続きを選択すべきか迷うような曖昧なインターフェース定義は、最適化の阻害要因になる。特に、`INTENT(IN)`の属性や、配列のランク（次元数）が異なる手続きを混在させる場合、コンパイラが「どの最適化パスを適用すべきか」を判断するヒントを適切に与えなければならない。
MODULE math_kernel_mod
IMPLICIT NONE
PRIVATE
PUBLIC :: compute_flux
! インターフェースを明示的に定義
! コンパイラに推論させず、静的にルーチンを割り振る
INTERFACE compute_flux
MODULE PROCEDURE flux_scalar_real64
MODULE PROCEDURE flux_array_real64
END INTERFACE
CONTAINS
! スカラー用：レジスタに保持されやすく、SIMD化の対象外
SUBROUTINE flux_scalar_real64(val)
REAL(8), INTENT(IN) :: val
! 局所的な最適化
END SUBROUTINE
! 配列用：ここが肝。メモリ連続アクセスを保証する
SUBROUTINE flux_array_real64(arr)
REAL(8), INTENT(IN) :: arr(:)
! 列優先(Column-major)を意識したループ構造
! プロセッサのストリームバッファを効率的に活用する
END SUBROUTINE
END MODULE
2. キャッシュライン境界とアライメントへの配慮
オーバーロードされた手続きを呼ぶ際、引数が「メモリ上のどこにあるか」がパフォーマンスを左右する。特に`MODULE PROCEDURE`で複数の型やランクを扱う場合、注意すべきは「アライメントの不一致」だ。
例えば、`flux_array_real64`に渡す配列が、境界条件処理などで不連続なメモリ（スライス）を参照している場合、いくらモダンなFortranで綺麗に書いても、ハードウェアプリフェッチャーは空振りを起こす。
- 極限の最適化のヒント:
- オーバーロードの入り口で、配列が`CONTIGUOUS`であるかを確認せよ。
- `INTERFACE`側で`CONTIGUOUS`属性を明示することで、コンパイラはポインタ演算の複雑さを排除した、アグレッシブなSIMDベクトル化を強行できる。
3. 数万コア規模のハイブリッド並列における注意点
MPI+OpenMPのハイブリッド環境では、一つのノード内で複数のスレッドが同じ`MODULE`内の手続きを叩く。ここで重要なのは、「手続きがスレッドセーフか、かつ静的領域を汚染していないか」だ。
現代のFortranでは`SAVE`文を不用意に使うのは禁忌である。`MODULE`変数に状態を持たせる設計は、スレッド間でのキャッシュコヒーレンシの競合（False Sharing）を誘発する。オーバーロードされた手続き内では、計算に必要な定数は`MODULE`レベルで`PARAMETER`として定義するか、あるいは`ISO_C_BINDING`を用いて読み取り専用の共有メモリ領域に配置せよ。
4. プロファイリングの泥臭い事実
VTuneやScalascaで解析すると、`MODULE PROCEDURE`の切り替え地点がボトルネックに見えることがある。しかし、それは多くの場合、手続きの呼び出し自体ではなく、「自動的に生成されたテンポラリアレイ（一時配列）」が原因だ。
オーバーロードした手続きに、表現の簡略化のために式をそのまま渡していないか？
! NG: ここで一時的な配列が生成され、メモリコピーが発生する可能性がある
CALL compute_flux(A + B)
! OK: 演算済み結果をスタック、あるいは明示的に割り当てた領域から渡す
TMP = A + B
CALL compute_flux(TMP)
コンパイラが「この式の結果をどこに格納すべきか」を迷う状況を作ってはならない。オーバーロードされた手続きの引数には、必ずメモリレイアウトが確定している変数を渡すのが、スパコンで生き残るための鉄則である。
最後に：モダンFortranは「直感」ではなく「物理」に従う
`MODULE PROCEDURE`によるオーバーロードは、コードの可読性を高め、開発のスピードを加速させる素晴らしい機能だ。しかし、それは計算機の物理限界を理解した上でのみ、真の威力を発揮する。
移植や最適化を行う際は、「コンパイラが生成するアセンブラコード」を眺める勇気を持ってほしい。`ifort -S`や`gfortran -S`で出力されるループが、SIMD命令（AVX-512等）に落とし込まれているかを確認する。オーバーロードの抽象化の裏で、コンパイラが余計な型変換やコピーを行っていないか、自分の目で確かめること。
それが、何千ノードもの計算資源を使いこなす、真のアーキテクトに求められる「最後の一手」である。
コメント