導入：なぜ並列計算で速度が頭打ちになるのか
数値計算エンジニアが並列プログラムを書く際、スレッド数を増やしても期待したほどの性能向上が見られないことがあります。その主因の一つが「偽の共有（False Sharing）」です。これは、異なるスレッドが物理的に異なる変数を更新しているにもかかわらず、それらが同一のキャッシュラインに存在するために発生する競合現象です。本記事では、この問題を物理的に遮断する「アライメント・パディング」の手法を解説します。
基礎知識：キャッシュラインと偽の共有
CPUはメモリからデータを読み書きする際、数バイト単位ではなく「キャッシュライン（一般的に64バイト）」という塊単位でキャッシュにロードします。
もし、スレッドAが変数Xを、スレッドBが変数Yを更新する際、XとYが同じキャッシュライン上に配置されていると、CPUのキャッシュコヒーレンシ機構が「同じメモリ領域の書き換え」と誤認してしまいます。その結果、キャッシュラインの所有権を巡る激しい競合（ピンポン現象）が発生し、並列効率が著しく低下します。これを防ぐには、各スレッドが専有する変数を、キャッシュラインの境界を跨いで配置する必要があります。
実装・解決策：アライメント・パディング
解決策は単純で、構造体のサイズをキャッシュラインの倍数に強制的に合わせる「パディング」を導入することです。これにより、スレッドごとのデータが異なるキャッシュラインに配置され、物理的な競合を完全に排除できます。
サンプルプログラム：Fortranによるパディング実装例
以下は、並列処理用データの構造体にパディングを加え、キャッシュラインの競合を防ぐコード例です。
! キャッシュラインサイズが64バイトと仮定した場合のパディング例
module parallel_data
implicit none
! 構造体を定義
! real(8)は8バイト。15個のパディング(815=120バイト)と本体(8バイト)で計128バイト。
! 128バイトは64バイトの倍数であるため、キャッシュラインの境界に収まる。
type :: padded_t
real(8) :: value ! 計算に使用する本体データ
real(8) :: pad(15) ! 競合を防ぐためのパディング領域
end type padded_t
! スレッドごとの結果を格納する配列
type(padded_t), dimension(8) :: thread_data
end module parallel_data
! 使用イメージ
subroutine update_thread_data(id)
use parallel_data
integer, intent(in) :: id
! 各スレッドはthread_data(id)のみにアクセスするため、
! 他のスレッドとキャッシュラインを共有せず、高速に動作する
thread_data(id)%value = thread_data(id)%value + 1.0d0
end subroutine update_thread_data
応用・注意点：現場で役立つアドバイス
1. キャッシュラインサイズの確認
最近のCPUのキャッシュラインは64バイトが主流ですが、アーキテクチャによっては異なる場合があります。`getconf LEVEL1_DLINESIZE`（Linux環境）などのコマンドで、ターゲット環境のキャッシュラインサイズを事前に確認してください。
2. パディングのやりすぎに注意
パディングはメモリ効率を低下させます。大きな配列を定義する場合、パディングによってメモリ使用量が肥大化し、逆にキャッシュミス（容量不足による追い出し）を引き起こす可能性があります。必要最小限のパディングに留めるのが鉄則です。
3. コンパイラの最適化オプション
現代のコンパイラにはアライメントを自動調整するオプションが存在する場合もあります。まずは手動でパディングを行い、パフォーマンスプロファイラ（Intel VTuneなど）で「偽の共有」が発生していないかを確認しつつ、チューニングを進めるのが最も確実なアプローチです。
コメント