SIMDの果実を食い荒らす「エイリアシング」という亡霊
スパコンのノード性能を限界まで引き出す際、我々が最も憎むべき敵の一つが「エイリアシング」だ。
Fortranは歴史的に、C言語のような「ポインタの奔流」から隔離された安全な言語と見なされてきた。しかし、モダンFortranにおける`pointer`属性や、サブルーチン引数としての`target`、あるいはモジュール変数へのアクセスが絡むと、コンパイラは突如として臆病になる。
「この配列 `A` と `B` は、メモリ上の同じ領域を指していないか？」
コンパイラがこの疑念を拭えない限り、ベクトル化（SIMD）のパイプラインは閉ざされる。ロード・ストアの依存関係チェックのために生成される膨大なガードコードが、本来の演算サイクルを侵食し、AVX-512やSVEの真価を無に帰す。今日は、この「見えない制約」を物理的に粉砕し、キャッシュ効率を最大化する戦術を伝授する。
—
1. コンパイラの臆病さを矯正する：CONTIGUOUSの鉄則
Fortran 2008で導入された `CONTIGUOUS` 属性は、単なるメタデータではない。これはコンパイラに対する「宣戦布告」だ。「このデータはメモリ上で完璧に連続しており、他のいかなる識別子とも重複しない」と宣言することで、コンパイラは安心してロード命令をパイプラインの深部にまで押し込めるようになる。
特に、多次元配列のスライス（例えば `A(1:N, k)`）をサブルーチンに渡す際、Fortranは非連続なメモリレイアウトを許容する。しかし、それがSIMD化を阻害する元凶となる。
subroutine compute_kernel(n, a, b)
integer, intent(in) :: n
! 明示的に連続性を保証し、コンパイラに最適化の余地を与える
real(8), intent(inout), contiguous :: a(:), b(:)
integer :: i
! $OMP SIMD
do i = 1, n
a(i) = a(i) + b(i) 2.0_8
end do
end subroutine
もし `contiguous` を指定しなければ、コンパイラは「スライスが渡された場合に備えて、一時バッファへのコピー（いわゆるCopy-in/Copy-out）を行うか？」という判定コードをループ前後に挿入する。数万コアで回すシミュレーションにおいて、この微小な分岐がどれほどのオーバーヘッドになるか、VTuneで計測したことがあれば明白だろう。
—
2. 配列エイリアシングとRESTRICT相当の挙動
C言語の `restrict` キーワードが持つ強力なエイリアシング排除能力。Fortranにはそれに相当する直接的な仕様は存在しないが、`pointer` 属性の使用を避け、`intent` 属性を正しく付与することで、コンパイラは `alias` が発生しないと推論する。
問題は、複雑なデータ構造（例えば、構造体の配列 `type(particle) :: p(N)`）を扱うときだ。特定のメンバにアクセスする際、Fortranのメモリ配置（列優先：Column-major order）を無視したアクセスパターンは、キャッシュライン（通常64バイト）の浪費を招く。
最適化の解：構造体配列（AoS）から配列構造体（SoA）へ
HPCにおける鉄則だが、依然として守られないコードが多い。
! 悪い例 (AoS): キャッシュミスを誘発しSIMDが効かない
type :: Particle
real(8) :: x, y, z
end type
type(Particle) :: p(N)
! 良い例 (SoA): キャッシュラインにx座標が並び、SIMDが爆速で走る
type :: Particles
real(8) :: x(N), y(N), z(N)
end type
SoA形式に変換した上で、`contiguous` を付与すれば、コンパイラは自信を持って `vaddpd` (AVX) や `fmla` (ARM SVE) 命令を生成する。
—
3. HPC環境でのコンパイラフラグとボトルネック解析
いくらコードをクリーンにしても、コンパイラフラグが適切でなければ意味がない。Intel Fortran (ifx) や GCC を用いる場合、以下の設定は「必須の礼儀」だ。
- `-qopt-report` (Intel) / `-fopt-info-vec` (GCC):
最適化レポートを常に出力し、「Vectorization failed: dependence distance」というログが出ていないか監視する。これが出たら、そのループはエイリアシングに食い殺されている。
- `-fno-alias` / `-alias-args`:
もしコードベースが巨大で、すべての引数に `contiguous` をつけるのが現実的でない場合、コンパイラ全体に対して「エイリアスは存在しない」と強制するフラグを検討する。ただし、これは劇薬だ。コードの安全性をプログラマが担保できる場合にのみ使うこと。
—
究極の知見：デバッグの魂
パフォーマンス解析において、ScalascaやVTuneで「L1 Cache Miss」や「Frontend Bound」が多発している場合、それはメモリレイアウトの不整合か、コンパイラによるSIMD回避のどちらかである。
私が現場でよくやるのは、「あえて `pointer` を使った複雑なコードを、あえて `target` 属性を外したシンプルな配列演算に書き換えてみる」という手法だ。これで性能が倍になるなら、原因は言語仕様の複雑さにある。
Fortran 2018/2023の仕様を追うのも良いが、スパコンで最後に勝つのは「メモリをいかに連続して叩き、いかにコンパイラを迷わせないか」という、古き良き計算科学の物理的な直感だ。
コードは、コンパイラへの手紙だ。君が意図を明確に伝えれば、コンパイラはハードウェアの限界までその処理を加速させる。曖昧な記述は、ハードウェアの性能をドブに捨てることに他ならない。今すぐソースを確認し、`contiguous` の一言が欠けていないか、再確認してほしい。
コメント