キャッシュを味方につけろ：Fortranにおける「列優先」とストライド最適化の真髄
宇宙開発の現場で数十億セル規模の流体解析（CFD）を回していると、コードの正しさは前提として、「計算機がどれだけストレスなくデータを食えるか」が勝敗を分けます。
現代のCPUにとって、計算そのものよりも遥かに高くつくのが「メモリアクセス」です。特にFortranを操る我々にとって、メモリレイアウトの理解は嗜みであり、生存戦略そのものです。今日は、教科書には載っていない、現場で生き残るための「ストライド最適化」の極意を伝授します。
なぜ「列優先」がこれほどまでに神聖視されるのか
Fortranは歴史的に、配列をメモリ上で「列優先（Column-major）」に配置します。これは `A(i, j)` と `A(i+1, j)` がメモリ上で隣り合っていることを意味します。
もし、貴方のコードで `do j = 1, N` を外側ループにし、`do i = 1, M` を内側ループに配置していないとしたら、それはCPUのL1/L2キャッシュラインを自らドブに捨てているのと同じです。キャッシュライン（通常64バイト）から読み込まれたデータが使われないまま破棄され、次のループでまたメインメモリまでデータを取りに行く……この「ストライド・ミス」が、貴方のシミュレーションを数倍から数十倍遅くする主犯です。
ベクトル化を阻害する「非連続アクセス」を排除せよ
コンパイラの最適化フラグ `-O3` や `-march=native` は魔法ではありません。データが連続して並んでいない限り、コンパイラはSIMD（ベクトル命令）を生成できません。
実践：最適化された行列演算のテンプレート
以下は、大規模データ構造を扱う際に私が必ず守る「メモリレイアウト設計」の基本形です。
module matrix_ops_mod
implicit none
private
public :: compute_flux_optimized
contains
subroutine compute_flux_optimized(u, flux, nx, ny)
integer, intent(in) :: nx, ny
real(kind=8), intent(in) :: u(nx, ny) ! 列優先順序で定義
real(kind=8), intent(out) :: flux(nx, ny)
integer :: i, j
! 【極意】内側ループを第1インデックス（i）にする
! これにより、キャッシュライン上のデータが順次消費される
! コンパイラはこのループをベクトル化の好機と判断する
do j = 1, ny
!$omp simd ! ベクトル化を明示的にヒント（状況に応じて）
do i = 1, nx
flux(i, j) = u(i, j) 2.0_8 + 0.5_8
end do
end do
end subroutine compute_flux_optimized
end module matrix_ops_mod
なぜこれが必要か
1. 空間的局所性（Spatial Locality）の最大化: `u(i, j)` の次に `u(i+1, j)` を読むことで、一度のメモリロードでキャッシュライン全体（8バイトの倍精度なら8要素分）が活用されます。
2. ストライド1アクセス: メモリ上の物理的な移動距離が最小となり、メモリアクセスのレイテンシを最小化します。
現場で遭遇する「罠」：構造体配列（AOS）の誘惑を断つ
若手のエンジニアがやりがちなのが、`type(cell) :: grid(nx, ny)` のように、構造体の配列を作ってしまう設計です。これを行うと、`grid(i, j)%pressure` にアクセスする際、メモリ上で `pressure` が離れた場所に飛び散り、ストライドが壊滅します。
設計ルール:
- データ構造は「配列の構造体（SOA: Structure of Arrays）」にせよ。
- `pressure(nx, ny)`, `velocity_x(nx, ny)` のように、個別の物理量ごとに連続した配列を用意する。
これが、数百ギガバイトのメモリを扱うシミュレーションで、計算速度を維持するための鉄則です。
コンパイラを飼いならすためのビルド設定（Intel Fortran例）
コードを書き換えたら、次はコンパイラに「俺のコードはベクトル化可能だぞ」と教え込む必要があります。
Intel Fortranコンパイラ (ifort/ifx) の推奨フラグ
-O3: 最適化レベル最大
-xHost: 実行環境のCPU命令セットをフル活用
-qopt-report: 最適化レポートを出力（どこでベクトル化に失敗したかを確認）
ifort -O3 -xHost -qopt-report=5 -qopt-report-phase=vec -c main.f90
特に `qopt-report` は見てください。「なぜここでベクトル化されなかったのか」が記述されています。そこに「非連続アクセスによる依存関係」と書かれていたら、そこが貴方のコードの急所です。
最後に：計測こそがすべて
「速くなったはずだ」という直感ほど信頼できないものはありません。
私は、`omp_get_wtime()` を用いた計時と、`perf` や `VTune` といったプロファイラを必ずセットで使います。ストライドを最適化し、キャッシュミス率が20%から3%に下がった瞬間、貴方のシミュレーションは別次元の速度で走り出します。
Fortranは古臭い言語ではありません。メモリの物理配置を直接制御できる、現代の科学技術計算における最高峰の「ハードウェアに近い高級言語」です。皆さんもぜひ、キャッシュラインを意識した泥臭いチューニングを楽しんでください。そこにこそ、数値計算の真の喜びがあります。
コメント