継承という名の「禁断の果実」：高並列HPCにおける型階層の最適化戦略
Fortran 2003で導入された`EXTENDS`による型継承は、大規模コードのモジュール化において強力な武器となる。しかし、我々のような数値計算の現場で「C++のノリ」で安易に継承を多用すれば、数万コア規模のスパコン上では、いとも簡単に計算性能が崩壊する。
なぜか。それは、「型継承による動的ディスパッチ（ポリモーフィズム）の導入が、CPUのパイプラインを止める最大の要因になり得るから」だ。
今回は、単なる構文解説ではなく、継承を用いた設計がメモリ・アーキテクチャといかに衝突するか、そしてそれをどう飼いならすかについて、現場の知見を叩き込む。
—
1. 仮想関数テーブル(vtable)とキャッシュの泥沼
`PASS`属性を用いた手続きのオーバーライドは、内部的にはC++と同様の仮想関数テーブル（vtable）参照を伴う。これがなぜHPCで危険か。
- 分岐予測の失敗: ループ内でポリモーフィズムを多用すると、CPUは次に実行する命令のアドレスを予測できず、パイプラインがフラッシュされる。
- キャッシュ効率の低下: 継承された派生型がメモリ上に散らばっていると、L1/L2キャッシュのプリフェッチが効かない。
実践的コード：ポリモーフィズムを「脱却」する設計
オーバーライドが必要な場合でも、「ホットループ内では継承を使わない」のが鉄則だ。
! 非推奨：ループ内での動的ディスパッチ
do i = 1, N
call my_object(i)%compute() ! 毎回vtableを参照し、分岐予測が死ぬ
end do
! 推奨：型を分離し、データ構造をフラット化する
! コンパイル時に型が確定する静的ディスパッチを強制する
subroutine compute_all(data)
class(base_type), intent(in) :: data(:)
! ここで一気に静的型にキャストするか、あるいは
! 構造体配列(AoS)ではなく配列構造体(SoA)でループを回す
end subroutine
—
2. メモリレイアウトと連続アクセスの「血の滲む」真実
`EXTENDS`で親型を継承すると、メモリ上の配置は「親メンバ + 派生メンバ」となる。ここで注意すべきは、派生型を派生型として扱うか、親型として扱うかでメモリレイアウトが複雑化することだ。
特にMPI通信時、`TYPE`の継承構造をそのまま送受信しようとすると、`MPI_TYPE_CREATE_STRUCT`で無理やりオフセット計算をする羽目になる。これはスパコンのインターコネクト帯域を殺す。
キャッシュミスヒットを最小化するアライメント
現代のプロセッサは64バイトのキャッシュラインを基本単位とする。派生型でメンバを増やす際、そのデータがキャッシュラインの境界を跨ぐか跨がないかで、ロード性能は10倍変わる。
type, extends(base_type) :: physics_data
real(8) :: density ! 8 bytes
real(8) :: pressure ! 8 bytes
! ここでパディングを意識して、SIMD幅(AVX-512なら64バイト)に合わせる
! コンパイラ指令でアライメントを強制する
!DIR$ ATTRIBUTES ALIGN : 64 :: density
end type
—
3. レガシーからモダンへの移行：`MODULE`と`PROCEDURE`の境界
古いFortran 77コードを移植する際、`COMMON`ブロックを`TYPE`で包むのは良いが、そこに`EXTENDS`を適用して継承階層を作ろうとすると、リンク時のシンボル解決が重くなる。
特に、`IFORT`や`GFORTRAN`でのビルド時、継承関係が深いと`vtable`の静的生成に時間がかかり、リンクステージでメモリ不足になるケースが多発する。
現場の最適化フラグの勘所:
- `-fno-polymorphic-inline`: インライン展開が不要に肥大化する場合に抑制する。
- `-qopt-report=5`: Intelコンパイラで、実際にどこでインライン展開が失敗し、どこでvtable参照が発生しているかを確認する。これが現代の数値計算屋の「健康診断書」だ。
—
4. 結論：継承は「静的」に使え
継承の目的を「実行時の柔軟性」に求めると、HPC環境では必ずしっぺ返しを食らう。「コードの再利用性」のためにのみ継承を使い、性能が求められるホットパスでは、コンパイル時に型が完全に決定されている状態（静的ディスパッチ）を維持すること。
`CLASS`ではなく`TYPE`を使い、必要であれば`TYPE-BOUND PROCEDURE`でインターフェースを整理する。これが、スパコンのピーク性能を引き出すための唯一無二の最適化道である。
次のプロジェクトでは、`EXTENDS`の階層を深くする前に問うてほしい。「この抽象化は、コンパイル時に解決できるか？」と。もし答えがNoなら、その設計は再考の余地がある。
現場からは以上だ。コードを書き、プロファイラを回し、L1ミスヒット率が0.1%を下回るまでループを回せ。それがエンジニアの矜持というものだ。
コメント