メモリの「深淵」を制する：Fortranにおける列優先順序（Column-Major）とキャッシュ階層の極致
スパコンの演算性能がいくらペタフロップス、エクサフロップスと伸びようとも、数値計算の現場で我々を苦しめるのはいつだって「メモリ帯域」という名のボトルネックだ。
多くの若手エンジニアが、抽象化されたアルゴリズムの美しさに酔いしれる一方で、我々のような現場の人間は、CPUとメモリの間にある「絶望的な距離」をいかに縮めるかに心血を注ぐ。Fortranの真髄は、このハードウェアの物理的制約をコードの記述レベルで御せることにある。今回は、Fortranの設計思想の根幹である「列優先（Column-Major）アクセス」を武器に、数万コア規模のHPC環境で数％の演算性能を絞り出すための深淵を掘り下げよう。
1. なぜ「列優先」を身体に叩き込む必要があるのか
Fortranの配列は、メモリ上で第一インデックスが最も速く変化するように配置される。C言語系の行優先（Row-Major）とは根本的に異なるこの仕様は、単なる歴史的な名残ではない。
キャッシュライン（通常64バイト）を最大限に活用し、プリフェッチャーを働かせるためには、内側のループで「メモリ上の隣接するアドレス」を叩く必要がある。これが疎かなコードは、どんなに高度なアルゴリズムを用いても、キャッシュミスによるストールでCPUを遊ばせるだけの「計算機を温める装置」と化す。
キャッシュを殺すアンチパターンと最適解
! — 絶望的なアンチパターン —
! 内側のループで第二インデックスを変化させているため、
! メモリ上で巨大なストライドが発生し、キャッシュラインを無駄に消費する
do j = 1, n
do i = 1, m
a(i, j) = b(i, j) c
end do
end do
! — Fortranの鉄則：内側ループは第一インデックスに —
! これにより、メモリ上を連続して走査でき、ハードウェアプリフェッチャーが
! 次のデータを先読みし続けることが可能になる
do j = 1, n
do i = 1, m
a(i, j) = b(i, j) c
end do
end do
※上の例は一見同じだが、大規模データになると `a(i,j)` のインデックス `i` が連続していることが、L1/L2キャッシュのヒット率に直結する。
2. 数万コアの並列化における「メモリの局所性」
MPI+OpenMPのハイブリッド並列化において、最も見落とされがちなのが「キャッシュの共有」と「NUMAノードの壁」だ。
数千コア規模で走らせる際、ノード内でのメモリ配置が不適切なままだと、どんなに高速なインターコネクト（InfiniBand等）を使っても、メモリコントローラーで飽和する。ここで重要なのは、OpenMPの `do` ループにおける「ループスケジューリングの最適化」だ。
!$omp parallel do collapse(2) schedule(static)
! collapse(2)を使い、ループの粒度を増やすことで
! スレッド間のワークロードバランスを最適化する。
! ただし、キャッシュの局所性が崩れる場合は注意が必要。
do j = 1, n
do i = 1, m
a(i, j) = …
end do
end do
プロファイラ（Intel VTuneやScalasca）で「L3 Cache Misses」が異常に高い場合、ループのネスト順序だけでなく、配列のデータレイアウトそのものを「構造体の配列（AoS）」から「配列の構造体（SoA）」へ、あるいはその逆へと再設計する必要がある。Fortran 2018の `CONTIGUOUS` 属性を使い、コンパイラにメモリの連続性を明示することで、ベクトル化（SIMD）の阻害要因を排除することが現代の定石だ。
3. レガシーからの脱却とコンパイラの最適化フラグ
F77形式のコードを最新のFortran 2023へ移植する際、最も注意すべきは「暗黙的なコピー」だ。サブルーチンに配列を渡す際、仮引数と実引数のメモリ配置が不整合だと、コンパイラは裏でこっそりと「一時配列の生成とコピー」を行う。これが大規模計算では致命的な性能低下を招く。
究極のビルド設定例（Intel Fortran/ifxの場合）
-O3: 基本の最適化
-xHost: 実行環境のCPU命令セット（AVX-512等）をフル活用
-ipo: プロシージャ間最適化（ソースを跨いだインライン展開）
-qopt-report: 最適化レポートを出力し、ベクトル化の成否を確認する
-heap-arrays: スタックオーバーフローを防ぎつつ、メモリ配置を制御する
ifx -O3 -xHost -ipo -qopt-report=5 -heap-arrays 64 source.f90 -o simulation.exe
この `-qopt-report` を無視するエンジニアは、たとえスパコンを使ってもそのポテンシャルの50%も引き出せていない。ベクトル化が失敗しているループを見つけ出し、データ依存性の排除（あるいは `DIR$ IVDEP` 指示文の使用）を行うことこそ、我々アーキテクトの腕の見せ所だ。
最後に：計測こそが唯一の真実
「コードの見た目」が綺麗であることは重要だが、スパコンの世界において正しいのは「プロファイラの数値」だけだ。
コードをいじった後は、必ずVTuneでホットスポットを特定し、キャッシュミス率と命令の実行効率（CPI）を追え。もし貴方のコードがメモリ帯域の限界に達していないのであれば、まだ改善の余地がある。Fortranという言語が持つ、ハードウェアを剥き出しにする力を最大限に利用し、物理現象の極限をシミュレートしてほしい。
数値計算に魔法はない。あるのは、メモリの配置とキャッシュの挙動に対する、徹底した執着心だけである。
コメント