精度定義の「その場しのぎ」がスパコンの性能を殺す：SELECTED_REAL_KINDの最適解
「`real8`を使えばとりあえず安心」――そんな時代は、とっくに終わった。
君たちが今、数千ノード規模のHPCクラスターでジョブを流しているなら、その「とりあえず」の代償が、キャッシュラインの浪費や、SIMD命令のベクトル化阻害という形で確実に跳ね返ってきていることに気づくべきだ。
今日は、ポータブルな精度定義の決定版である `SELECTED_REAL_KIND` を、単なる「型定義の儀式」から「ハードウェアの性能を極限まで引き出すための設計図」へと昇華させる話をしよう。
1. なぜ「ハードウェア依存のKIND」が地雷なのか
レガシーな `real8` や `real(8)` は、Fortran 90以降の標準規格では「非推奨」に近い。なぜか？ それは、コンパイラやアーキテクチャによって「8バイト」の解釈が必ずしも一致しないからだ。
特に、浮動小数点演算の精度をハードウェアレベルで制御する際、`SELECTED_REAL_KIND` を使わずにベタ書きされたコードは、異なるスパコンプラットフォームへ移植した瞬間、コンパイラの最適化フラグ（例えば `-Ofast` や `-ffast-math`）との相性で、単なる数値誤差以上の「パフォーマンスの断絶」を引き起こす。
2. 真のアーキテクトが用いる「定数モジュール」の設計
単に `SELECTED_REAL_KIND` を呼ぶだけなら誰でもできる。現場で重要なのは、「計算精度をコンパイル時に制御可能な形で抽象化する」ことだ。以下に、大規模並列計算のベースとなるモジュール構成を示す。
module precision_constants
implicit none
private
! 目的：倍精度を保証しつつ、SIMD化を意識したアライメントを考慮する
! 精度(p=15桁)と指数範囲(r=307)を要求
integer, parameter, public :: wp = selected_real_kind(15, 307)
! メモリアライメントを意識したパディング用定数など
! キャッシュライン境界(64バイト)を考慮した構造体設計に繋げる
integer, parameter, public :: cache_line_size = 64
public :: wp
end module precision_constants
この `wp` (Working Precision) をすべての変数宣言に適用することで、将来的に「特定の計算ルーチンだけ4倍精度（`real(kind=selected_real_kind(30))`）に上げる」といったチューニングが、コードの整合性を崩さずに可能になる。
3. メモリレイアウトとキャッシュ効率への影響
数値計算のボトルネックは、CPUの演算能力ではなく、常に「メモリからのデータ転送」にある。
`SELECTED_REAL_KIND` で定義した変数を配列として確保する際、注意すべきは「データ密度」だ。特にGPU/AVX-512環境では、データがキャッシュラインの境界をまたぐと、ロード性能は劇的に低下する。
- 構造体配列 (Array of Structures: AoS) を避け、配列構造体 (Structure of Arrays: SoA) に変換せよ。
- `SELECTED_REAL_KIND` で確保した変数を並列計算する際、OpenMPの `!$omp simd` 指令と組み合わせることで、コンパイラに「このループはベクトル化可能である」という強いヒントを与えることができる。
subroutine compute_stencil(n, field)
use precision_constants, only: wp
implicit none
integer, intent(in) :: n
real(kind=wp), intent(inout) :: field(n)
integer :: i
! SIMDベクトル化を強力に推奨するアライメント指示
!$omp simd aligned(field:64)
do i = 2, n – 1
field(i) = (field(i-1) + field(i+1)) 0.5_wp
end do
end subroutine compute_stencil
4. プロファイリングなき最適化は「ギャンブル」である
`SELECTED_REAL_KIND` を適切に配置したとしても、それがキャッシュミスヒットを減らしているかどうかは、VTuneやScalascaのようなプロファイラで確認しなければならない。
現場でよくある失敗は、精度の高い型を使いすぎてメモリ帯域を飽和させているケースだ。もし特定のサブドメインでそこまでの精度が不要なら、`selected_real_kind(6, 37)`（単精度相当）に落とすだけで、メモリ転送量が半分になり、キャッシュ効率が劇的に向上する。
アーキテクトからの提言
現代のFortran開発において、「移植性」とは単に動くことではない。「どのマシンでも、そのハードウェアの限界性能（Peak Performance）を叩き出せること」を意味する。
1. 暗黙の型宣言を撲滅せよ: `implicit none` は全モジュールで必須。
2. KINDの集中管理: 全ての型定義を `SELECTED_REAL_KIND` 経由の定数モジュールに集約せよ。
3. データ構造を疑え: 配列アクセスが `k, j, i` の順（Fortranの列優先順序）でメモリを叩いているか、VTuneでL1/L2キャッシュヒット率を計測せよ。
コードは数学であり、同時に物理でもある。メモリという物理的制約を無視した精度定義は、計算機の上で空回りするだけの無駄な電力消費に過ぎない。君たちの書くFortranが、スパコンの真の能力を解放する鍵となることを期待している。
コメント