メモリの「足取り」を支配せよ：Fortranにおける多次元配列最適化の極意
数値計算の現場において、アルゴリズムの正しさは前提条件に過ぎません。シミュレーションの真価は、計算資源をどれだけ「使い切るか」にあります。特に我々が扱うような数百万次元の疎行列や巨大なテンソル演算において、コンパイラの最適化性能を左右するのは「メモリへのアクセス順序」という、極めてプリミティブかつ破壊的な要因です。
今日は、Fortranのメモリレイアウトの深淵に触れ、キャッシュ効率を最大化するための鉄則を伝授します。
—
1. Fortranの宿命：列優先順位（Column-Major）を味方につける
Fortranは、メモリ上で配列を「列優先（Column-Major）」で展開します。これは、多次元配列において「一番左の添字」がメモリ上で最も速く変化することを意味します。
例えば `A(100, 100)` という配列があるとき、`A(i, j)` と `A(i+1, j)` はメモリ上で隣接していますが、`A(i, j)` と `A(i, j+1)` はメモリ上で `100` 個分（約800バイト）も離れているのです。
もしループの入れ替えを間違えれば、CPUは毎回メインメモリまでデータを取りに行く羽目になり、キャッシュミスが多発してパフォーマンスは10分の1以下にまで低下します。これを防ぐための鉄則はただ一つ。「一番左の添字を、一番内側のループで回せ」です。
—
2. ループ入れ替え（Loop Interchange）の実践的コード
以下のコードは、初心者がやりがちな「キャッシュをドブに捨てる」実装と、それを最適化したコードの比較です。
subroutine compute_optimal(n, m, mat)
implicit none
integer, intent(in) :: n, m
real(8), intent(inout) :: mat(n, m)
integer :: i, j
! 【悪い例】キャッシュ効率最悪
! 外部ループがi、内部ループがj。メモリを跳び越えながらアクセスしている
! do j = 1, m
! do i = 1, n
! mat(i, j) = mat(i, j) 2.0d0
! end do
! end do
! 【良い例】列優先を活かしたストライド1アクセス
! 内部ループで左側の添字(i)を動かすことで、メモリを連続的に読む
! これによりCPUのプリフェッチャーが機能し、ベクトル化が加速する
do j = 1, m
do i = 1, n
mat(i, j) = mat(i, j) 2.0d0
end do
end do
! 補足：Fortranの多次元配列は「暗黙のループ」も強力
! mat = mat 2.0d0
! と書けば、コンパイラが最適な順序でループを生成してくれる
end subroutine compute_optimal
—
3. ベクトル化を阻害しないための堅牢な設計ルール
単にループを入れ替えるだけでは不十分です。コンパイラによる自動ベクトル化（SIMD）を確実に誘発させるために、以下のルールを設計指針に加えてください。
1. 配列の形状を明示せよ：
`real(8), pointer :: arr(:,:)` のような可変サイズ配列（ポインタ）は、コンパイラがメモリ配置を予測しにくく、最適化が鈍ります。可能な限り `allocatable` を使用し、構造体の中に埋め込む場合は `contiguous` 属性を付与して、メモリが連続していることをコンパイラに保証しましょう。
2. ストライド（歩幅）を1に保て：
多次元配列のインデックス計算で `A(1:n:2, j)` のように飛び石でアクセスするのは、キャッシュ効率の観点からは悪手です。どうしても必要な場合は、一度連続領域にコピーしてから計算を行う「パッキング」の手法が、結果的に計算時間を短縮させることがあります。
3. コンパイラフラグによる「厳格化」：
ビルド時には最適化フラグだけでなく、ベクトル化のレポートを出力させるのがプロの作法です。
- ifort/ifx: `-O3 -xHost -qopt-report=5`
- gfortran: `-O3 -march=native -fopt-info-vec-optimized`
これを確認し、「loop was vectorized」というメッセージが出ない限り、そのコードは未完成だと見なしてください。
—
4. シニアの知見：なぜ「モダン」Fortranなのか
近年のFortran規格（F2008, F2018）では、`do concurrent` を用いた並列実行指定や、`contiguous` キーワードによるメモリレイアウトの最適化が言語仕様レベルで洗練されています。
レガシーなコードをリファクタリングする際は、単に古い構文を置き換えるのではなく、「データのメモリ上での配置と、計算の走査順序が一致しているか」を常に自問してください。
ハードウェアの進化は目覚ましいですが、メモリの物理構造が変わらない限り、この「列優先」という鉄則は永遠の真理です。貴方の書くコードが、計算機の性能を極限まで引き出せるよう、心より応援しています。
次の記事では、`ISO_C_BINDING` を用いたC言語とのデータ共有における、メモリ境界（アライメント）の罠について掘り下げます。お楽しみに。
コメント