【テクニカル・上級編】配列の形状引継ぎ(Assumed-Shape)と明示的形状(Explicit-Shape)の性能差 – モダンFortran言語仕様と実践実践マスター

形状引継ぎ配列(Assumed-Shape)の罠：スパコンのメモリ階層を制する真の設計論

計算科学の最前線で「なぜコードがスケーリングしないのか」という壁に突き当たったとき、多くのエンジニアはMPIの通信コストやOpenMPの同期オーバーヘッドを疑う。しかし、真のボトルネックは、その遥か手前、サブルーチンの引数渡しという、あまりにも日常的なコードの裏側に潜んでいることが多い。

今日は、Fortranにおける「形状引継ぎ配列（Assumed-Shape）」と「明示的形状（Explicit-Shape）」の挙動を、コンパイラの最適化パスとメモリ階層の視点から解剖する。

1. コンパイラが隠蔽する「一時配列」の悪夢

形状引継ぎ配列 `real(8), intent(in) :: a(:, :)` を使うとき、我々は利便性と引き換えに、コンパイラに「配列記述子（Descriptor）」の生成を委ねている。

もし、呼び出し側の実引数が、受け取り側の期待するメモリレイアウト（連続性）と一致していない場合、何が起きるか。コンパイラは「一時配列（Temporary Array）」をスタックあるいはヒープ上に自動生成し、値をコピーしてサブルーチンに渡すという暴挙に出ることがある。

! 形状引継ぎの例
subroutine compute_kernel(a)
real(8), intent(in) :: a(:, 🙂 ! 記述子経由でアクセス
! …
end subroutine

このコピー処理は、数万回呼び出されるループの内側にあれば、キャッシュラインを汚染し、メモリアクセスの帯域を食いつぶす。特に、多次元配列の転置や部分スライスを渡す際、このオーバーヘッドは致命的だ。VTune等でプロファイルを取ると、`memcpy` 関連の命令が上位を占めているのを目撃することになる。

2. 明示的形状（Explicit-Shape）への回帰とインターフェースの制約

対して、`real(8), intent(in) :: a(n, m)` とサイズを明示した旧来の形式は、コンパイラに対して「このメモリレイアウトはこうなっている」という強い型保証を与える。これにより、コンパイラはアドレス計算を最適化し、ループ不変量展開（LICM）やベクトル化を阻害する「コピーのオーバーヘッド」を回避しやすくなる。

しかし、現代のFortranでレガシーなF77形式に戻る必要はない。我々が取るべき戦略は、`interface` ブロックの厳格な管理と、`contiguous` 属性の活用だ。

推奨される実装パターン

Fortran 2008以降であれば、`contiguous` 属性を付与することで、コンパイラに「この配列はメモリ上で連続している」と断言させ、コピーの生成を抑制できる。

subroutine compute_kernel(a)
! 形状引継ぎだが、連続メモリであることをコンパイラに確約させる
real(8), contiguous, intent(in) :: a(:, 🙂

! SIMDレジスタへのロード効率が劇的に向上する
!$omp simd
do j = 1, size(a, 2)
do i = 1, size(a, 1)
a(i, j) = a(i, j) 2.0d0
end do
end do
end subroutine

3. 数万コア並列におけるキャッシュミスヒット対策

スパコン環境において、L3キャッシュのヒット率は性能の生命線だ。形状引継ぎ配列を使うと、コンパイラが自動生成する記述子の読み出しそのものがキャッシュを圧迫する。

特にOpenMPで数万コアを動かす際、各スレッドがスタックメモリ上でコピーを作成し始めると、メモリコントローラの帯域が飽和し、メモリ・ウォール（Memory Wall）に直面する。この事態を避けるためのアーキテクトとしての心得は以下の通りだ。

• インターフェースの自動生成（Module利用）: `interface`を明示的に書くか、`module`内に手続きを収めることで、コンパイラに引数の形状情報を伝播させる。これがないと、コンパイラは保守的な挙動（コピーの生成）を選択する。
• コンパイラオプションの選別: `ifort` や `gfortran` を使う際、`-assume contiguous` や `-check noarg_temp_created` といったフラグで、意図しないコピーが発生した際に警告を出すようにせよ。これはデバッグの必須儀式である。
• アライメントの強制: `!DIR$ ATTRIBUTES ALIGN: 64 :: array` 等を用い、ベクトル化命令がロード時に整列アクセス（Aligned Access）を行えるよう物理メモリレイアウトを制御せよ。

4. 結び：最適化は「コンパイラとの対話」である

Fortranは、古くからのコードを現代のスパコンで動かすために進化し続けてきた。形状引継ぎ配列が「遅い」のではなく、「コンパイラにメモリレイアウトを伝えないこと」が遅いのである。

我々アーキテクトがやるべきは、言語仕様の表面をなぞることではない。コンパイラが生成するアセンブリを読み、`vmovapd` がキャッシュラインをまたいでいないかを確認し、`array descriptor` の生成コストを排除することだ。

計算科学の現場において、0.1%の性能改善は、数百万時間のCPU時間を節約することと同義である。次にコードを書くとき、その `(:, :)` が、果たしてコンパイラにとって「親切な定義」になっているか、自問してほしい。

真のモダンFortranは、書きやすさと計算効率の極限の妥協点ではなく、その両方を技術力でねじ伏せる場所にある。