SIMDの壁を突破せよ：コンパイラを「その気」にさせるモダンFortran最適化術
数値シミュレーションの世界において、計算速度は正義だ。しかし、最新のAVX-512命令セットを備えたCPUを積んでいても、コンパイラが吐き出すアセンブリがスカラー演算の山であれば、それはただの高級な文鎮に過ぎない。
多くのエンジニアが「なぜかベクトル化されない」という壁にぶつかる。その原因は、コンパイラの「怠慢」ではなく、我々が書いたコードに含まれる「依存関係のノイズ」にある。今回は、コンパイラを最大限に働かせ、計算リソースを極限まで引き出すための「ベクトル化の作法」を伝授する。
—
1. 依存関係の罠：コンパイラは「安全」を優先する
コンパイラは、少しでも「データ依存関係（Data Dependency）」の疑いがあれば、安全側（スカラー演算）に倒す。特に、配列のインデックス計算や条件分岐が複雑に絡み合うループは、SIMDの天敵だ。
阻害要因の典型：ループ搬送依存
以下のコードを見てほしい。
! 最適化の敵：ループ搬送依存
do i = 2, n
a(i) = a(i-1) + b(i) ! a(i)の計算に直前のa(i-1)が必要
end do
この場合、`a(i)`の計算が終わるまで`a(i+1)`を計算できない。コンパイラはこれをベクトル化できないと判断する。これを解消するには、依存関係を断ち切るか、アルゴリズム自体をSIMDフレンドリーな形式（例えば、再帰的な計算を避け、計算順序を入れ替えるなど）へ書き換える必要がある。
—
2. 実践：ベクトル化を阻害しないための堅牢な実装
コンパイラに「このループは独立している」と確信させるためには、モダンFortranの機能を駆使し、メモリレイアウトを最適化するのが鉄則だ。
推奨される実装パターン
`contiguous`属性と`do concurrent`を活用し、コンパイラにヒントを与える。
subroutine compute_physics(n, a, b, c)
implicit none
integer, intent(in) :: n
! メモリが連続していることを明示することで、SIMDのロード効率が劇的に向上する
real(8), contiguous, intent(inout) :: a(n)
real(8), contiguous, intent(in) :: b(n), c(n)
integer :: i
! do concurrentは、各反復が独立しており、実行順序を問わないことをコンパイラに保証する
! これにより、コンパイラは迷わずベクトル化を選択できる
do concurrent (i = 1:n)
a(i) = b(i) c(i) + 0.5d0
end do
end subroutine compute_physics
ポイント:
- `contiguous`属性: 配列がメモリ上で隙間なく並んでいることを保証する。これがないと、コンパイラは「ストライドアクセス（飛び飛びのアクセス）」を想定し、安全のためにスカラー演算に逃げることが多い。
- `do concurrent`: 従来の`do`ループに比べ、コンパイラに対して「順序依存がない」という強力なメタデータを付与できる。
—
3. コンパイラレポートを「解読」し、ボトルネックを特定する
「なんとなく速くなった気がする」ではプロ失格だ。コンパイラの最適化レポート（最適化ログ）を読み込む癖をつけよう。
主要コンパイラのフラグ設定（Intel Fortran / ifort, ifx）
ビルド時に以下のオプションを追加して、コンパイラの「思考」を覗き見る。
最適化レベル3とベクトル化レポートの出力
-qopt-report:5 : レベル5の詳細レポートを出力
-qopt-report-phase:vec : ベクトル化フェーズのみに絞る
ifort -O3 -xHost -qopt-report:5 -qopt-report-phase:vec main.f90 -o simulation
出力された `main.optrpt` を開けば、「ループがベクトル化されなかった理由」が明確に記されているはずだ。
- `vectorization possible` なら成功。
- `proven dependence` なら、その行の変数を再確認せよ。
- `not vectorized: vector length is 1` なら、ループの反復回数が少なすぎるか、条件分岐が複雑すぎる可能性が高い。
—
4. 最後に：メモリの「列優先」を忘れるな
Fortranは伝統的に「列優先（Column-major）」だ。多次元配列を扱う際、最も左の添字を最も速く回すのが鉄則である。
! NG：行優先に近いアクセス順序（キャッシュ効率が悪く、SIMDも効きにくい）
do j = 1, m
do i = 1, n
arr(i, j) = …
end do
end do
もし`arr(j, i)`のようなアクセスをしているなら、それはCPUのキャッシュラインを無駄に汚し、SIMDユニットへのデータ供給を滞らせている。現場のシミュレーションコードでは、この「添字の順序」一つで計算時間が数倍変わることは珍しくない。
コンパイラは魔法の杖ではない。我々が書いた論理的な依存関係の「解釈」を助け、メモリレイアウトを整えてやることで初めて、その真価を発揮する。まずは手元のループを一つ、`do concurrent`で書き換え、レポートを眺めることから始めてほしい。それが、計算科学のエンジニアとしての最短距離だ。
コメント