疎結合なモジュール設計が、スパコンの性能を極限まで引き出す：モダンFortranの「作法」
数値計算の現場において、コードの「汚さ」は単なる保守性の欠如に留まりません。それはコンパイラの最適化パスを阻害し、キャッシュミスを誘発し、最終的には計算機資源の浪費という形で我々に牙を剥きます。
今回は、大規模シミュレーションにおける「モジュール（MODULE）による名前空間の管理」と、それに伴うビルド依存関係の最適解について、現場の泥臭い経験から得た知見を共有します。
—
1. モジュールは「単なる名前空間」ではない：インターフェースの防波堤
Fortran 77時代の`COMMON`ブロックを未だに使っているなら、それは今すぐ捨ててください。`COMMON`は型安全性を破壊し、コンパイラのエイリアス解析を阻害する、最適化の最大の敵です。
モダンFortranの`MODULE`は、強力なインターフェースチェックの盾です。`USE`文で明示的にインポートすることで、コンパイラは引数の数や型が一致しているかをコンパイル時に静的に検証できます。これは、数百万行規模のコードベースで発生する「引数の渡し間違い」というデバッグ地獄を未然に防ぐ唯一の手段です。
実装の鉄則：`ONLY`句による限定公開
すべてのモジュールを丸ごとインポートしてはいけません。名前空間が汚染され、意図しない変数の衝突が発生します。必ず`ONLY`句を使ってください。
! 良い例：依存関係を最小限に絞る
MODULE solver_core
USE precision_mod, ONLY: dp ! 倍精度定数のみをインポート
IMPLICIT NONE
PRIVATE ! デフォルトで全て非公開にする
PUBLIC :: solve_step ! 公開すべきAPIのみを明示的に晒す
CONTAINS
SUBROUTINE solve_step(u, dt)
REAL(dp), INTENT(INOUT) :: u(:,:)
REAL(dp), INTENT(IN) :: dt
! … 計算ロジック …
END SUBROUTINE solve_step
END MODULE solver_core
`PRIVATE`宣言を徹底することで、モジュール内部の補助ルーチンや一時変数を外部から隠蔽できます。これにより、コンパイラはモジュール内での変数のライフサイクルや依存性をより正確に把握でき、レジスタ割り当ての最適化が利きやすくなります。
—
2. コンパイル依存関係の「負の連鎖」を断ち切る
モジュール化を進めると、今度は「モジュールの依存関係」という新たな壁にぶつかります。AモジュールがBモジュールを`USE`している場合、Bを先にコンパイルしなければならない。この順序管理を怠ると、大規模開発ではビルド時間が非線形に増大します。
Makefile構築の「作法」
Fortranのモジュールファイル（`.mod`）は、コンパイラのバージョンやオプションによってバイナリ互換性が崩れることがあります。したがって、ビルドフローには以下の指針を適用してください。
1. モジュール生成と実装を分ける: `.mod`ファイルはビルドディレクトリに集約する。
2. 依存関係の自動生成: `gfortran -M`や`ifort -gen-dep`を活用し、ソースコード間の依存グラフをMakefileに自動で流し込む。
Makefileの断片的な設計指針
FC = ifort
FFLAGS = -O3 -xHost -ipo -assume byterecl # -ipoでモジュール間最適化を有効化
依存関係を自動生成させるためのパターン
%.o: %.f90
$(FC) $(FFLAGS) -c $< -o $@
モジュール間の依存関係を明示的に記述する（例）
solver_core.o: precision_mod.o
main.o: solver_core.o
特に`-ipo`（Inter-Procedural Optimization）や`-flto`（Link Time Optimization）を使う場合、モジュール間の境界を越えたインライン展開が可能になります。これにより、小さな関数を頻繁に呼び出すような設計でも、パフォーマンス低下をゼロに抑えることができます。
---
3. パフォーマンスを最大化するメモリ配置とアクセス
モジュール化の設計で忘れてはならないのが、Fortranの「列優先（Column-major）」アクセスです。どんなに優れたモジュール構造を組んでも、ループの添字順序を間違えればキャッシュヒット率は壊滅します。
! 最適化を意識した配列アクセス
DO j = 1, ny
DO i = 1, nx
! メモリは列優先で並んでいるため、内側ループは第一添字（i）を変化させる
u(i, j) = u(i, j) + dt f(i, j)
END DO
END DO
もし、モジュール内で定義した派生型（`TYPE`）の配列を扱う場合、構造体の配列（Array of Structures）ではなく、配列の構造体（Structure of Arrays）の形にデータを保持するようにモジュールを設計してください。ベクトル演算（SIMD）の恩恵を受けるためには、データがメモリ上で連続していることが絶対条件だからです。
—
結論：コードは「疎結合・高凝集」に
モジュールによる名前空間の管理は、単なるコードの整理整頓ではありません。それは、「コンパイラに最適化の余地をどこまで与えるか」を制御する高度なエンジニアリングです。
- `PRIVATE`をデフォルトにする。
- `ONLY`句で依存を可視化する。
- モジュール間最適化（IPO/LTO）を前提としたMakefileを構築する。
この3点を守るだけで、あなたの書く数値計算コードは、保守性が向上するだけでなく、実行速度においてもスパコンの計算ノードの性能を余すことなく引き出す「一流のソフトウェア」へと変貌するはずです。
現場のデバッグで疲弊する前に、まずは`MODULE`の境界線を見直すことから始めてみてください。それが、最強の数値解析コードへの最短ルートです。
コメント