`std::hardware_destructive_interference_size` と `std::hardware_constructive_interference_size` は L1 キャッシュ ライン サイズとどのように関係しますか?また、クロスプラットフォーム コードへの影響は何ですか?

std::hardware_destructive_interference_size および std::hardware_constructive_interference_size について

これらの定数は、サイズを取得する移植可能な方法を提供するために C 17 で導入されました。 L1キャッシュラインの。ただし、キャッシュ ライン サイズとの関係はそれよりも微妙です。

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

理論的には、これらの定数は次のようになります。 L1 キャッシュ ライン サイズ以上である必要があります。これは、弱めの干渉サイズは偽の共有を避けるために異なるスレッドによってアクセスされる 2 つのオブジェクト間の最小オフセットであるのに対し、強めの干渉サイズは真の共有を促進するためにメモリ内に一緒に配置できる 2 つのオブジェクトの最大サイズであるためです。 🎜>

ただし、実際には、いくつかの理由により、これらの定数の値は L1 キャッシュ ライン サイズと正確に一致しない可能性があります。まず、コンパイラーはヒューリスティックまたは環境ヒントを使用してキャッシュ ライン サイズを推定する場合がありますが、これはすべての場合において正確であるとは限りません。次に、キャッシュ ライン サイズは、コードが実行される特定のマシンのアーキテクチャによって異なる場合があります。

その使用例を示す良い例はありますか?

2 つ以上のスレッドが同じキャッシュ ラインの異なる部分にアクセスすると、フォールス シェアリングが発生し、キャッシュ ラインが無効化され、頻繁にリロードされます。これにより、パフォーマンスが大幅に低下する可能性があります。偽の共有を回避するには、異なるスレッドによってアクセスされるオブジェクトをメモリ内で少なくとも 1 キャッシュ ライン離して配置する必要があります。

真の共有は、2 つ以上のスレッドが同じキャッシュ ラインにアクセスするときに発生し、キャッシュ ラインを一度キャッシュにロードされ、すべてのスレッドで共有されます。これにより、パフォーマンスが大幅に向上する可能性があります。真の共有を促進するには、同じスレッドによってアクセスされるオブジェクトを、単一のキャッシュ ライン内に収まるようにメモリ内にまとめて配置する必要があります。

両方とも静的 constexpr として定義されています。バイナリをビルドして、キャッシュ ライン サイズの異なる他のマシンで実行しても問題はないでしょうか?コードがどのマシンで実行されるかわからない場合、そのシナリオで誤った共有をどのように防ぐことができますか?

これらの定数の静的な constexpr の性質は、コードを実行するときに潜在的な問題を引き起こす可能性があります。異なるキャッシュ ライン サイズを持つ異なるマシン。前述したように、これらの定数の値は L1 キャッシュ ライン サイズと正確に一致しない可能性があり、これにより誤った共有が発生したり、真の共有の機会が失われる可能性があります。

この問題を軽減するには、ターゲット アーキテクチャに特定のキャッシュ ライン サイズを使用して独自の定数を定義できます。あるいは、定数 std::hardware_destructive_interference_size および std::hardware_constructive_interference_size をフォールバック値として使用し、プラットフォーム固有のメソッドを使用して実行時に実際のキャッシュ ライン サイズを確認することもできます。

以上が`std::hardware_destructive_interference_size` と `std::hardware_constructive_interference_size` は L1 キャッシュ ライン サイズとどのように関係しますか?また、クロスプラットフォーム コードへの影響は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。