遺物からの脱却：`BIND(C)`によるグローバル変数の現代的共有とメモリ・レイアウトの最適化
スパコンの現場で今なお見かける、あの忌々しい`COMMON`ブロック。F77時代にはメモリ節約の知恵だったかもしれないが、現代のHPCにおいては、データ競合の温床であり、コンパイラの最適化を阻害する「呪い」でしかない。
今日は、モダンFortran（2008以降）において、C/C++と共有するグローバル変数を、いかにして現代的な`BIND(C)`とモジュールを用いて、ハードウェアの性能を極限まで引き出しつつ実装するかについて、現場の泥臭い知見を共有する。
1. なぜ`COMMON`は死んだのか：メモリ配置の視点から
`COMMON`ブロックは、メモリ上の配置を言語仕様として保証しない。コンパイラは、これが他の場所でどう参照されるか推論できず、結果として厳格なエイリアス解析（Alias Analysis）を諦めることになる。
一方、`MODULE`で定義し、`BIND(C)`属性を付与した変数は、バイナリ上でのアドレスがC言語のリンカから解決可能なシンボルとして確定する。これにより、コンパイラは「この変数は外部からアクセスされる可能性がある」という前提の下で、最適化の境界条件を明確に理解できるのだ。
! 現代的なグローバル変数定義の作法
module global_data_mod
use, intrinsic :: iso_c_binding
implicit none
! BIND(C)を指定し、C言語側からシンボル名で見えるようにする
! メモリ配置の連続性を保証するため、配列は必ず列優先を意識して設計する
real(c_double), bind(c, name=”global_physics_params”) :: params(1024)
! 隠蔽が必要な場合はPRIVATE属性とアクセサを用意するのが定石
! パフォーマンス重視なら、直接アクセスを許容しつつ、
! キャッシュライン（64バイト）を跨がないようなアライメントを心がける
end module global_data_mod
2. キャッシュラインと「列優先」の冷徹な事実
Fortranは列優先（Column-major order）だ。これは単なる文法の話ではない。数万コア規模のHPC環境では、このメモリレイアウトがキャッシュミス率を左右する。
C/C++側とデータを共有する際、最も多いミスが「構造体の配列（Array of Structures: AoS）」をそのままFortranに持ち込むことだ。これはFortranのループ効率を劇的に低下させる。
- AoS（C流）: `struct {double x, y, z} p[N]` → メモリが `x,y,z,x,y,z…` と並ぶ。
- SoA（HPC流）: `double x[N], y[N], z[N]` → FortranでのSIMD化には必須。
`BIND(C)`を使うなら、必ずSoA（Structure of Arrays）形式でデータを定義せよ。さもなくば、Intel VTuneでプロファイリングした際、L1キャッシュミス率が跳ね上がり、ベクトル化率（Vectorization Intensity）が驚くほど低いという冷徹な結果に直面することになる。
3. ハイブリッド並列化（MPI + OpenMP）における落とし穴
MPIプロセス間で`BIND(C)`されたグローバル変数を共有する場合、注意が必要だ。`BIND(C)`はあくまで「リンカから見えるシンボル」を作るだけであり、物理メモリの共有を意味しない。
もし、共有メモリ領域（Shared Memory）として扱いたいのであれば、`MPI_Win_allocate_shared`を用いて、Fortran側でポインタとして受け取る実装が推奨される。
! ポインタで共有メモリを指し示す現代的アプローチ
real(c_double), pointer :: shared_array(:)
type(c_ptr) :: base_ptr
! MPI_Win_allocate_sharedで確保したアドレスをC_F_POINTERでFortran配列にキャスト
call c_f_pointer(base_ptr, shared_array, [n_elements])
この手法を使えば、OpenMPのスレッド間で同じメモリ領域を叩く際、キャッシュコヒーレンシを意識した「偽共有（False Sharing）」を避けるためのパディングが必要になる。パディングを無視して変数を詰め込むと、数千コアでスケールするはずのコードが、メモリバスの競合により、コア数を増やせば増やすほど性能が落ちるというパラドックスに陥る。
4. 最適化のトドメ：プロファイラによる検証
最後に、実装が正しいかどうかを判断するのはコンパイラではなくプロファイラだ。
1. Scalasca / Score-P: 実行時間のボトルネックがMPI通信なのか、局所的な計算（メモリI/O）なのかを特定する。
2. Intel VTune: `BIND(C)`した変数が、適切にSIMD命令に載っているかを確認する。もしメモリアクセスが「Scalar Load」で止まっていれば、それはアライメントの失敗だ。
コンパイラのフラグは、`-O3 -xHost -qopt-report=5` をデフォルトとせよ。特に`qopt-report`を確認し、ループがベクトル化されていない理由が「データ依存性の可能性」によるものか、「メモリ配置の不整合」によるものかを見極めるのだ。
結論：技術至上主義の設計を
レガシーな固定形式コードからの脱却は、単なる書き換えではない。それは、CPUのパイプラインを止める「隠れた制約」を一つずつ取り除いていく作業だ。`BIND(C)`とモジュールを活用し、メモリレイアウトを物理層から設計する。この泥臭い積み重ねこそが、スパコンの性能を理論限界まで引き出す唯一の道である。
諸君、コードを書き換える前に、まずキャッシュラインの並びを想像せよ。それがプロのアーキテクトというものだ。
コメント