PUREの真価：計算ノードの深淵で「副作用」を殺すということ
スパコンの数万コアを回し、HPCの極致を目指す諸君にとって、`PURE`属性は単なる「お作法」ではない。それは、コンパイラに対する最強の宣戦布告であり、並列計算の不確実性を排除するための「絶対契約」である。
多くのエンジニアは「副作用がないことを保証する」という教科書的な説明で満足するが、現場のリアリティは違う。`PURE`を指定するということは、コンパイラに対し「この手続きはメモリアクセスの競合を一切発生させない」と保証し、結果としてコンパイラがレジスタ割り当てや命令パイプラインのスケジューリングを極限まで最適化するための「安全領域」を確保することに他ならない。
1. なぜ「PURE」がOpenMP/DO CONCURRENTの鍵となるのか
数万スレッドを動かす際、最大の敵は「データ競合（Data Race）」と、それを防ぐために無駄に挿入される「同期プリミティブ（バリア同期やアトミック操作）」のオーバーヘッドだ。
`DO CONCURRENT`はFortran 2008以降の標準だが、単に記述しただけでは不十分だ。内部で呼ばれる手続きが`PURE`でない場合、コンパイラはグローバル状態の破壊を恐れ、並列化の恩恵を自ら放棄するようなコードを吐き出す。
! 良い例: 局所的な計算に徹し、外部状態を汚染しない
pure function calculate_flux(u, v) result(flux)
real(8), intent(in) :: u, v
real(8) :: flux
! 外部変数へのアクセスがないため、コンパイラは
! この関数をSIMD化（ベクトル化）し、ループ展開を躊躇なく行う
flux = u2 – v2
end function
ここでの最大のポイントは、`PURE`であることを明示することで、コンパイラが「この関数内ではメモリのエイリアシング（同一メモリ領域を複数の名前で参照すること）が起きない」と確信できる点にある。これが、現代のAVX-512やSVEといったSIMDユニットをフル活用するための前提条件となる。
2. キャッシュラインとメモリ配置の泥沼
どれほど`PURE`なコードを書いても、メモリレイアウトが崩壊していれば意味がない。Fortranの列優先（Column-major）規則は、キャッシュライン（通常64バイト）を意識した実装において強力な武器となる。
`DO CONCURRENT`内で多次元配列を扱う際、最も内側のループでアクセスする添字が「一番左」に来るように設計するのは常識だが、`PURE`手続きの中でこれを再帰的に呼び出す場合、スタック領域の圧迫がボトルネックになることがある。
- スパコン最適化の定石:
大規模配列を引数として渡す際、`intent(in)`であっても`contiguous`属性を付与せよ。これにより、コンパイラはストライドアクセスを排除し、SIMDロード命令を生成する確実性が飛躍的に向上する。
subroutine compute_kernel(field)
! fieldが連続メモリ空間にあることを保証し、SIMDロードを加速させる
real(8), intent(in), contiguous :: field(:,:)
do concurrent (j=1:size(field, 2))
! 内部の関数呼び出しはpureであることを必須とする
! これにより、コンパイラは各反復が完全に独立していると断定できる
call update_inner(field(:,j))
end do
end subroutine
3. プロファイラが語る「真実」：Scalasca/VTuneの先へ
最適化の現場では、VTuneやScalascaのレポートがすべてだ。`PURE`手続きを多用したコードと、そうでないコードを比較すると、命令キャッシュ（I-cache）のヒット率に顕著な差が出る。
なぜか？ `PURE`手続きは副作用を持たないため、コンパイラが「インライン展開（Inlining）」を積極的に行うからだ。関数呼び出しのオーバーヘッドを消し去り、ループ本体の中に計算ロジックを直接埋め込むことで、CPUは分岐予測を外すリスクを最小限に抑えられる。
もし君のコードが、数千コアで並列効率（Speedup）が頭打ちになっているなら、一度「副作用の可能性」を疑え。モジュール変数や`COMMON`ブロックを隠蔽し、すべてを引数として渡す設計（Functional programmingに近いアプローチ）こそが、スパコンを支配するための第一歩だ。
4. 最後に：F77の亡霊を浄化せよ
レガシーな固定形式コードからの移植において、`COMMON`ブロックをそのまま残すのは自殺行為だ。あれはメモリ空間のスパゲッティであり、コンパイラから最適化の機会を奪う呪縛である。
`PURE`手続きという「現代的な規律」を導入することは、単なるコードの近代化ではない。それは、コンパイラという究極の最適化エンジンに対して、君のアルゴリズムを最も効率的に解釈させるための「言語」を教え込むことなのだ。
理論上のピーク性能（FLOPS）と、実効性能（Actual performance）の乖離を埋めるのは、こうした泥臭い「副作用排除」の積み重ねしかない。諸君、次回のジョブ投入時には、是非ともプロファイラの数値でその成果を証明してほしい。
最適化は、妥協なき規律の先にのみ存在する。
コメント