問題タブ [false-sharing]

私はOpenMPプログラムのパフォーマンス、特にキャッシュとメモリのパフォーマンスを見ています。昔、Vtuneでパフォーマンスを分析する方法について、注意すべきカウンターについて言及したガイドラインを見つけました。しかし、今はマニュアルを見つけることができないようです。

私が問題にしているマニュアルを知っている場合、またはカウンター/イベントを知っている場合は、私に知らせてください。また、マルチスレッドメモリのパフォーマンスを分析するための他の手法がある場合は、可能であれば共有してください

ありがとう

小さいが頻繁に使用する関数オブジェクトがあります。各スレッドは独自のコピーを取得します。すべてが静的に割り当てられます。コピーは、グローバル データまたは静的データを共有しません。このオブジェクトを偽の共有から保護する必要がありますか?

ありがとうございました。編集: これは、Boost.Threads を使用するおもちゃのプログラムです。フィールドデータに対して偽共有が発生する可能性はありますか?

並列プログラミング.net4.0の「偽共有」の知識を教えてもらえますか？例を挙げて説明していただければ幸いです。前もって感謝します 。コードのパフォーマンスを最大にしたい。

C または C++ で記述されたアプリケーションのFalse Sharingを検出して報告するツールはありますか?

偽共有を実証するために次のタスクがあり、簡単なプログラムを作成しました。

結果を見て非常に驚きました（i5-430Mプロセッサで実行しました）。

• 偽共有の場合、1020ミリ秒でした。
• 偽共有がなければ、それは710ミリ秒で、300％ではなく30％しか高速ではありませんでした（一部のサイトでは、300〜400％より高速になると書かれていました）。
• pthreadを使用しない場合、580ミリ秒でした。

私の間違いを見せてください、またはそれが起こる理由を説明してください。

以下に示す一般的な構造のプログラムがあります。基本的に、私はオブジェクトのベクトルを持っています。各オブジェクトにはメンバー ベクトルがあり、そのうちの 1 つは、より多くのベクトルを含む構造体のベクトルです。マルチスレッド化により、オブジェクトは並行して操作され、メンバー ベクター要素へのアクセスと変更を多く含む計算が実行されます。1 つのオブジェクトは、一度に 1 つのスレッドによってのみアクセスされ、処理のためにそのスレッドのスタックにコピーされます。

問題は、プログラムが 16 コアまでスケールアップできないことです。この問題は、誤った共有および/またはキャッシュの無効化である可能性があると思われ、アドバイスを受けています。これが本当なら、原因は互いに近すぎるメモリを割り当てるベクトルにあると思われます.両方の問題は(簡単に言えば)異なるプロセッサによって同時にアクセスされる近接メモリアドレスによって引き起こされると私は理解しているからです. この推論は理にかなっていますか、これが起こる可能性はありますか? もしそうなら、.reserve() を使用してメンバー ベクトルをパディングして余分な容量を追加し、ベクトル配列間に空のメモリの大きなスペースを残すことで、この問題を解決できるようです。それで、これはすべて意味がありますか？私は完全にここで昼食をとっていますか？

OpenMP を使用して誤った共有が発生していると思います。それを特定して修正する方法はありますか？

私のコードは次のとおりです: https://github.com/wchan/libNN/blob/master/ResilientBackpropagation.hpp 36 行目。

シングル スレッドの 1 コア バージョンと比較して 4 コア CPU を使用しても、追加のパフォーマンスは 10% しか得られませんでした。NUMA 32 物理 (64 仮想) CPU システムを使用している場合、CPU 使用率は約 1.5 コアでスタックします。これは、フォールス シェアリングの直接的な症状であり、スケーリングできないと思います。

また、Intel VTune プロファイラーで実行してみましたが、ほとんどの時間が "f()" および "+=" 関数に費やされていることがわかりました。私はこれが合理的であり、なぜ私がこんなに貧弱なスケーリングを得ているのかを本当に説明していないと信じています...

アイデア/提案はありますか？

ありがとう。

編集: ST では、初心者向けに 2 つ以上のリンクを投稿することは許可されていません。参照が不足していて申し訳ありません。

グローバル状態の変更の検出がパフォーマンスに関連する C アプリケーションでロックのオーバーヘッドを削減しようとしています。最近、このトピックについてかなり多くのことを読んでいますが (たとえば、H. Sutter などから多くのことを読んでいます)、自分の実装について確信が持てません。複数のスレッド間で共有されるデータからスレッド ローカル データを更新するために、 CASのような操作とDCLを組み合わせてCache-Line Alignedグローバル変数をチェックし、偽共有を回避したいと考えています。自信がないのは主に

1. Type-Attributesに関する GNU ドキュメントの解釈に失敗しました
2. STまたは1でのキャッシュラインへの整列およびキャッシュラインサイズの認識など、Cに簡単に変換できる文献や例を見つけることができないようです（1は答えているようですが）私の質問は、実装に自信がありません）
3. 私のCの経験は限られています

私の質問:

1. タイプ属性のドキュメントには次のように記載されています。

   この属性は、指定された型の変数の最小アラインメント (バイト単位) を指定します。たとえば、宣言は次のとおりです。

   (宣言については、型属性のドキュメントを参照してください)

   struct S コンパイラーに、型が割り当てられている、または割り当てられる予定の各変数がmore_aligned_int、少なくとも8-byte境界で割り当てられ、整列されることを (できる限り) 保証するように強制します。SPARC では、型のすべての変数struct Sを境界に整列させる8-byteことで、コンパイラは型 struct S の変数を別の変数にコピーするときに ldd および std (ダブルワードのロードとストア) 命令を使用できるようになり、実行時の効率が向上します。

   struct Sそれは、またはの始まりが常に境界more_aligned_intに揃えられるということですか? 8-byte正確に 64 バイトを使用するためにデータがパディングされるという意味ではありませんよね?

2. struct cache_line_aligned1. のすべてのインスタンス(以下のコード例 1を参照) が境界上に位置合わせされ、正確に 1 つのキャッシュ ラインを使用することが true であると仮定します64-byte(キャッシュ ラインが64 bytes長さであると仮定します) 。

3. 型宣言に使用typedefしても、のセマンティクスは変更されません__attribute__ ((aligned (64)))(以下のコード例 2を参照)。

4. aligned_malloc構造体がで宣言されている場合、構造体をインスタンス化するときに使用する必要はありません__attribute__ ...

最後に、キャッシュラインにアラインされたアプローチを使用して、グローバル状態が他のスレッドによって変更されたかどうかを効率的にチェックする関数のスケッチを示します。

長い投稿で申し訳ありません。

ありがとうございました！

「偽共有」によって導入されたパフォーマンスの低下を再現するために、Java で次のテスト クラスを作成しました。

基本的に、配列の「サイズ」を 4 からはるかに大きな値 (たとえば 10000) に微調整して、「偽共有現象」をオンまたはオフにすることができます。具体的には、サイズ = 4 の場合、異なるスレッドが同じキャッシュ ライン内の値を更新する可能性が高くなり、キャッシュ ミスがより頻繁に発生します。理論的には、テスト プログラムは、サイズ = 4 よりもサイズ = 10000 の方がはるかに高速に実行されるはずです。

2 つの異なるマシンで同じテストを複数回実行しました。

マシン A: Intel® Core™ i5-3210M プロセッサー (2 コア、4 スレッド) Windows 7 64 ビット搭載の Lenovo X230 ラップトップ

サイズ = 4 => 5.5 秒

サイズ = 10000 => 5.4 秒

マシン B: Dell OptiPlex 780、Intel® Core™2 Duo プロセッサ E8400 (2 コア) Windows XP 32 ビット搭載

サイズ = 4 => 14.5 秒

サイズ = 10000 => 7.2 秒

後で他のいくつかのマシンでテストを実行しましたが、明らかに偽共有は特定のマシンでのみ顕著になり、そのような違いを生む決定的な要因を理解できませんでした.

誰か親切にこの問題を見て、このテスト クラスで導入された偽共有が特定のマシンでのみ顕著になった理由を説明できますか?

}