OpenMP並列化の深淵：データ共有制御と偽共有（False Sharing）の克服
スパコンのノード内で「なぜかスレッドを増やすと遅くなる」という現象に遭遇したことはないだろうか。OpenMPにおける`PRIVATE`と`SHARED`の解釈は、単なるスコープの指定ではない。それは、メモリの物理的なレイアウトと、CPUコア間でのキャッシュ・コヒーレンシ・プロトコルの挙動を直接制御する、極めて「ハードウェアに近い」設計行為である。
今回は、数万コア規模のHPC環境で、実効性能を理論限界に近づけるためのデータ戦略を深掘りする。
—
1. PRIVATE vs SHARED：その「物理的」意味論
OpenMPの設計思想において、`SHARED`変数は全スレッドが同一のアドレス空間を参照する。一見、メモリ消費を抑える効率的な選択に見えるが、多コア環境ではこれが「キャッシュラインの奪い合い」を招く引き金となる。
特に、ループ内で`SHARED`配列に対して頻繁な更新を行うコードは、OpenMPの「悪手」の筆頭だ。各コアがキャッシュラインを更新しようとするたびに、MESIプロトコルに基づくキャッシュ・コヒーレンシのトラフィックがインターコネクトを飽和させ、スケーラビリティは破綻する。
偽共有（False Sharing）のメカニズム
複数のスレッドが、同一のキャッシュライン（通常64バイト）上に存在する異なる変数を頻繁に更新する場合、CPUはキャッシュの一貫性を保つために、そのラインの「所有権」をスレッド間で絶えず行き来させる。これにより、計算を実行していない時間が支配的になる。
! 危険なコード例：偽共有の温床
! 1次元配列の隣接要素を異なるスレッドで更新している
!$OMP PARALLEL DO
do i = 1, N
! 配列Aは各要素が8バイト。キャッシュライン64バイトには8要素が収まる。
! スレッドAがA(1)を書き換えると、同じラインにあるA(2)〜A(8)まで無効化される。
A(i) = A(i) + B(i) C(i)
end do
!$OMP END PARALLEL DO
このケースでは、各スレッドがキャッシュラインを跨がないような粒度でデータを分割（Chunking）するか、あるいは`PRIVATE`な一時変数で計算を完結させた後に書き出すのが鉄則である。
—
2. キャッシュライン最適化とパディング戦略
モダンFortranにおいて、構造体の配列や多次元配列を扱う際、明示的な「パディング」によるアラインメント調整は必須の技術だ。
特に、`!$OMP THREADPRIVATE`を利用する場合、各スレッドのローカル変数や累積用変数がメモリ上で隣接してしまうと、やはり偽共有を引き起こす。これを防ぐには、各スレッド用データ間に「ダミーの配列」を挿入し、キャッシュラインの境界を跨ぐように配置を強制する。
type thread_data
real(8) :: val
! 64バイト境界に合わせるためのパディング（ダミー変数）
real(8) :: padding(7)
end type thread_data
! 各スレッド専用の構造体配列を用意する
type(thread_data) :: per_thread_storage(MAX_THREADS)
!$OMP THREADPRIVATE(per_thread_storage)
この手法は、VTune等のプロファイラで`L1_MISS`や`HITM`（Hit Modified）イベントが異常に高い場合、即座に検討すべき改善策だ。
—
3. モダンFortranによる「データ指向」並列化
F77由来のコードをモダン化する際、単に固定形式を自由形式にするだけでは不十分だ。Fortran 2008/2018の`CONTIGUOUS`属性や`BIND(C)`を駆使し、コンパイラに対して「この配列はメモリ上で物理的に連続している」と断言させることが、ベクトル化（SIMD）の成否を分ける。
推奨される実装パターン：Reductionの最適化
`REDUCTION`句は便利だが、スレッド数が多いと内部的な集約コストが無視できなくなる。極限の環境では、以下のように「スレッドローカルな集約」を行ってから最後にメインメモリへ書き出す構造を自前で実装する方が、低レイヤの制御が効く。
subroutine compute_sum(arr, total_sum)
real(8), intent(in) :: arr(:)
real(8), intent(out) :: total_sum
real(8) :: local_sum(MAX_THREADS)
!$OMP PARALLEL
integer :: tid
tid = omp_get_thread_num() + 1
local_sum(tid) = 0.0d0
!$OMP DO
do i = 1, size(arr)
local_sum(tid) = local_sum(tid) + arr(i)
end do
!$OMP END DO
!$OMP END PARALLEL
total_sum = sum(local_sum)
end subroutine
この記述は、`local_sum`がキャッシュラインの異なる位置に配置されるように調整（上記で述べたパディング）することで、メモリバスの競合を完全に排除できる。
—
4. プロファイリングの思想：数値計算家の視点
性能解析において最もやってはいけないことは、「なんとなく」コードを弄ることだ。まずはScalascaやIntel VTuneを用い、以下のメトリクスを注視せよ。
1. CPI (Cycles Per Instruction): 1.0を超えていたら、メモリアクセスのどこかがボトルネックになっている。
2. Remote DRAM Access: NUMAノードを跨ぐメモリアクセスが発生していないか。`numactl –interleave=all`等のOS設定と、Fortran側の配列配置が整合しているか。
3. Vectorization Intensity: コンパイラのレポートを確認し、ループがSIMD化されているか。`!$OMP SIMD`句の明示的な付与と、アラインメント（`!DIR$ ATTRIBUTES ALIGN:64`）の指定が有効か。
結び：エンジニアの矜持
スパコンの演算器は、単にコードを流すためのものではない。CPUのパイプライン、キャッシュ階層、そしてメモリコントローラと対話するための、広大な「物理実験場」である。
「なぜこの変数は`PRIVATE`でなければならないのか？」
「この配列のアクセス順序は、ストライド1（列優先）になっているか？」
この問いを繰り返すことこそが、次世代のHPCコードを支えるアーキテクトの唯一の道である。コードは、機械が最も理解しやすい形で記述せよ。そして、その結果として得られる圧倒的な演算速度という果実を、研究の最前線で享受してほしい。
コメント