異端の境界線：FortranとCのメモリレイアウトを調停する「形状」の作法
スパコンの演算ノードを使い潰す際、最大の敵は常に「メモリアクセスの局所性」だ。Fortranの列優先（Column-major）とCの行優先（Row-major）の衝突は、単なる言語仕様の差異ではない。これはキャッシュラインを食いつぶし、ベクトル演算ユニットを空転させる「性能の墓場」への入り口である。
多くのエンジニアが「`ISO_C_BINDING`を使えば解決する」と安易に考えるが、それは半分正解で半分は破滅への道だ。今日は、Fortranの配列形状（Shape）をCの領域へいかに無敗で引き渡すか、その「極限の知見」を共有する。
—
1. 「形状情報の不整合」が招く悲劇
FortranからCへ配列を渡す際、単にポインタ（`type(c_ptr)`）を投げるだけでは、C側は「それが何次元で、どの方向へ伸びているか」を知る術を持たない。
C側で強引に `double A[N][M]` と定義して受け取れば、インデックスアクセス `A[i][j]` はFortranの意図とは正反対のメモリアドレスを参照する。これが数万コア規模のHPC環境で起きると、キャッシュミスヒットの嵐となり、理論演算性能の数％すら出ない惨状となる。
対策の鉄則：
- C側には「ポインタとサイズ情報」のみを渡し、多次元アクセスを隠蔽するラッパーをC側に用意する。
- Fortran側で次元情報を隠蔽せず、明示的に渡す。
—
2. 実装の核心：`ISO_C_BINDING` によるインターフェース設計
以下は、FortranからCへ多次元配列を渡し、C側で正しい列優先順位を維持しつつ演算を行うための推奨パターンだ。
! Fortran側のインターフェース定義
subroutine c_kernel_wrapper(data, n, m) bind(c, name=”c_computation_kernel”)
use iso_c_binding
implicit none
real(c_double), intent(inout) :: data(n, m) ! 明示的に形状を伝える
integer(c_int), value :: n, m
end subroutine
! 呼び出し側
! メモリレイアウトはFortranの流儀を維持したままCへ渡す
call c_computation_kernel(my_array(1,1), size(my_array, 1), size(my_array, 2))
// C側での受け取り：あえて多次元配列として定義しない
void c_computation_kernel(double data, int n, int m) {
// Fortranの(i, j)は、C側では [j n + i] となる（0-based index換算）
// これにより、列優先アクセスを維持し、キャッシュラインを汚染しない
for (int j = 0; j < m; j++) {
for (int i = 0; i < n; i++) {
data[j n + i] = 2.0; // 連続したメモリ領域を順次ロード
}
}
}
この実装において重要なのは、C側で `double data[m][n]` と宣言してはならない点だ。もしそうすればコンパイラは行優先の計算式を生成し、キャッシュラインを跨ぐ最悪のアクセスパターンを誘発する。常に一次元ポインタとして受け取り、インデックス計算をコード側で制御するのが、我々数値計算アーキテクトの矜持だ。
---
3. プロファイラが暴く「見えないオーバーヘッド」
ScalascaやIntel VTuneでボトルネックを解析すると、しばしば「メモリアクセス遅延（L3 Cache Miss）」が支配的になる。これは配列の形状がサブサブルーチンへの受け渡し時にコピー（一時配列の生成）されている可能性があることを示唆している。
- 対策： `target` 属性と `contiguous` 属性を組み合わせ、コンパイラに「この配列はメモリ上で連続しているから、コピーなしで直接アドレスを渡せ」と強いることだ。
! 性能を極限まで絞り出すための宣言
real(c_double), target, contiguous :: my_array(n, m)
これを怠ると、コンパイラは境界外参照を恐れて安全側に倒し、スタック上にテンポラリ配列を確保する。数GB単位の計算では、これだけで性能が20〜30％削られる。
—
4. 数万コア並列における設計思想
MPIを用いたハイブリッド並列において、このインターフェース設計は「通信コスト」に直結する。Fortranで計算し、Cで高速なカーネル（CUDAやAVX-512インラインアセンブラなど）を叩く場合、配列の形状情報が正しく伝わっていないと、MPIの送受信バッファの指定で致命的なバグを生む。
特に、ドメイン分割されたサブドメインの境界データを交換する際、Fortranの列優先順位と、MPIのバッファ送受信が一致しているか常に意識せよ。私たちが設計するシステムでは、「データ定義はFortran、演算はC、管理はMPI」という役割分担を徹底し、決してC側にデータの所有権を移さない。
結びに代えて
モダンFortran（2018/2023）は、もはや古い遺物ではない。`ISO_C_BINDING` は、低レイヤのメモリ制御と高次元の抽象化を両立させるための強力な武器だ。
貴殿が取り組んでいるコードが、もしコンパイル時に `-O3` だけで満足しているなら、それはまだ本当の性能を引き出せていない。プロファイラの山を登り、アセンブラの羅列を読み、配列の形状一つひとつに「なぜそこにあるべきか」を問い直せ。
数値計算の世界において、妥協は常に演算時間の増大という形で、我々に報復してくるのだから。
コメント