`std::hardware_destructive_interference_size` と `std::hardware_constructive_interference_size` は L1 キャッシュ ライン サイズとどのように関係し、その使用例は何ですか?

std::hardware_destructive_interference_size と std::hardware_constructive_interference_size について

はじめに:

C 17 では 2 つの定数 std が導入されました。 :hardware_destructive_interference_size および std::hardware_constructive_interference_size は、さまざまなハードウェア アーキテクチャで最適なパフォーマンスを実現するためのデータ構造の位置合わせとレイアウトを容易にします。

これらの定数は L1 キャッシュ ライン サイズとどのように関連していますか?

これらの定数は、ターゲット アーキテクチャの L1 キャッシュ ライン サイズの近似値を提供することを目的としています。

• 破壊的干渉: std::hardware_destructive_interference_size は、次の間のオフセットとして使用できる値を提供します。偽共有、つまり 2 つ以上のオブジェクトのデータが同じキャッシュ ラインに配置され、競合によるパフォーマンスの低下を引き起こす状況を回避するためのオブジェクト。
• 建設的干渉: std::hardware_constructive_interference_sizeパフォーマンスを向上させるために、異なるオブジェクトからのデータが同じキャッシュ ラインに配置される真の共有を促進するために、オブジェクトのメモリ フットプリントとベース アライメントを組み合わせた制限として使用できる値を提供します。

そのユースケースを示す良い例はありますか?

次の例を考えてみましょう:

struct CacheOptimizedStruct {
  alignas(std::hardware_constructive_interference_size) int a;
  alignas(std::hardware_constructive_interference_size) int b;
};

int main() {
  CacheOptimizedStruct data;
  // Accessing data.a and data.b in a tight loop will likely benefit from better cache locality.
}

この例では、alignas 属性は定数を使用して data.a と data が確実に一致するようにします。 .b には、真の共有のための最適なアライメントとメモリ レイアウトがあります。

両方とも静的 constexpr が定義されています。バイナリをビルドし、キャッシュ ライン サイズが異なる他のマシンで実行する場合、問題はありませんか?

はい、問題になる可能性があります。定数は、すべてのターゲット マシンに正確なキャッシュ ライン サイズを提供することを保証するものではありません。

ただし、独自の定数またはマクロを定義して、次のようなシステム固有の情報に基づいてより正確な値を提供できます。

#ifdef KNOWN_L1_CACHE_LINE_SIZE
  constexpr std::size_t cache_line_size = KNOWN_L1_CACHE_LINE_SIZE;
#else
  constexpr std::size_t cache_line_size = std::hardware_destructive_interference_size;
#endif

以上が`std::hardware_destructive_interference_size` と `std::hardware_constructive_interference_size` は L1 キャッシュ ライン サイズとどのように関係し、その使用例は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。