派生型（Derived Type）の深淵：HPCにおける「構造」の真実とキャッシュ汚染の制御
多くのプログラマは、`TYPE`キーワードによる派生型定義を単なる「データの入れ物」と考えている。だが、数万コアがひしめくスパコンのインターコネクト、あるいはL1/L2キャッシュのわずかな揺らぎを戦場とする我々にとって、派生型は「メモリアクセスの局所性を設計するための武器」である。
今回は、単なる構文解説を超え、モダンFortranにおけるデータ構造が、いかにしてCPU/GPUのパイプラインを支配し、あるいは破滅させるかという極限の視座から論じる。
—
1. 派生型の「レイアウト」が性能を決める
Fortranの派生型は、C言語の`struct`とは異なり、メモリ上の配置について言語仕様上は比較的柔軟である。しかし、HPCの現場において最も重要なのは、「多次元配列のインデックス順序」と「派生型コンポーネントの配置」の共鳴である。
キャッシュ・ラインを意識したデータ配置
多くのコードで散見される失敗は、頻繁にアクセスする変数を派生型の中にランダムに詰め込むことだ。CPUキャッシュは64バイト程度の「ライン」単位でロードされる。
! 非推奨：アクセスパターンがバラバラな構造体
type :: particle_t
real(8) :: x, y, z ! 位置
real(8) :: vx, vy, vz ! 速度
integer :: id ! ID
real(8) :: mass ! 質量
end type particle_t
もし、全粒子の`x`座標だけを反復計算するループを回す場合、`y`, `z`, `vx`…といった不要なデータまでキャッシュに乗り、ラインを無駄に消費する（キャッシュ汚染）。
真のアーキテクトの解:
もし性能がボトルネックなら、派生型の配列（Array of Structures: AoS）ではなく、構造体の配列（Structure of Arrays: SoA）、あるいは派生型をコンポーネントとして持つ「配列の構造体」へ変換することを検討せよ。
! 高性能なSoAアプローチの例
type :: particles_t
real(8), allocatable :: x(:), y(:), z(:)
real(8), allocatable :: vx(:), vy(:), vz(:)
end type particles_t
これにより、SIMD命令（AVX-512など）のベクトルレジスタに、同じ成分のデータを隙間なく流し込むことが可能になる。
—
2. %演算子の「隠れたコスト」とコンパイラ最適化
派生型のコンポーネントアクセスに用いる `%` 演算子。これは一見シンプルだが、多重に入れ子構造になった派生型（`a%b%c%d`）をホットループ内で多用すると、コンパイラのアライアス解析を阻害し、ロード・ストアの命令数が増大する可能性がある。
デバッグのヒント：コンパイラによるインライン化の監視
`gfortran`であれば `-fopt-info-vec-optimized`、`Intel Fortran (ifort/ifx)`であれば `-qopt-report` を必ず確認せよ。派生型のメンバアクセスが原因でベクトル化が阻害されている場合、ローカル変数に一度退避させる「ポインタ剥がし（実際にはコピー）」が劇的に効く場合がある。
! ホットループ内の最適化テクニック
subroutine compute_force(p)
type(particle_t), intent(inout) :: p
real(8) :: local_x, local_y ! ローカル変数への退避
local_x = p%x
local_y = p%y
! ここでlocal_x, local_yを使って計算を行い、最後に書き戻す
! コンパイラがレジスタ上で完結させやすくなる
end subroutine
—
3. モダンFortranへの大規模移行とメモリ・リンクの泥沼
F77レガシーコードからFortran 2018/2023仕様へ移植する際、最も恐ろしいのは「COMMONブロックからの脱却」である。COMMONブロックはリンク時にメモリ配置が決定されるが、派生型は動的なアロケーションを伴うことが多く、ヒープ領域の断片化を招く。
超大規模並列（MPI+OpenMP）での注意点
派生型をMPI通信に利用する場合、`MPI_TYPE_CREATE_STRUCT`で型を定義するのがセオリーだが、これには大きな落とし穴がある。「パディング（詰め物）」だ。コンパイラやOSによって派生型のメモリ配置には微妙な余白が入る。
- 解決策: 派生型の内部メンバを常に `8バイト境界` に揃えるように設計するか、`ISO_C_BINDING` を活用してメモリレイアウトをC言語並みに厳密に制御せよ。`bind(c)` を付与した派生型は、メモリ配置が保証されるため、スパコン間の異種アーキテクチャ通信でも安定する。
—
4. プロファイリングなき最適化は「無謀な突撃」である
VTuneやScalascaを回し、「メモリアクセス・レイテンシ」が高いと出たとき、多くの場合、原因は「派生型内の非連続なアクセス」にある。
1. VTuneの「Memory Access Analysis」を確認: 派生型の要素にアクセスする際、キャッシュミスが多発していないか。
2. ストライドの確認: Fortranは列優先（Column-major）である。派生型の中の配列成分が、一番左のインデックスでループ回されているか？（例: `data(i, j)%val` であれば、`i` が内側ループでなければならない）。
結びに代えて
派生型は、コードを美しく整理するだけの道具ではない。計算機が物理的に「どうデータを読み込み、どう演算器へ運ぶか」というメモリの物理層と対話するための設計図である。
「なぜこのデータ構造なのか？」という問いに対し、メモリレイアウトとキャッシュライン、そしてSIMDレジスタの挙動を即答できない設計は、スパコンの計算資源を浪費する罪である。君たちが書くその一行が、数百万CPU時間の未来を救うかもしれない。妥協なき実装を期待する。
コメント