問題タブ [intel-tsx]

まず、私の英語が下手なことをお詫びしなければなりません。私は現在、ハードウェア トランザクション メモリを学習しており、TBB の spin_rw_mutex.h を使用して C++ でトランザクション ブロックを実装しています。speculative_spin_rw_mutex は、spin_rw_mutex.h 内のクラスです。h は、Intel TSX の RTM インターフェイスを既に実装しているミューテックスです。

RTM のテストに使用した例は非常に単純です。Account クラスを作成し、あるアカウントから別のアカウントにランダムに送金します。すべてのアカウントはアカウント配列にあり、サイズは 100 です。ランダム関数はブーストにあります (STL にも同じランダム関数があると思います)。伝達関数は、speculative_spin_rw_mutex で保護されています。tbb::parallel_for と tbb::task_scheduler_init を使用して並行性を制御しました。すべての転送メソッドは、paraller_for のラムダで呼び出されます。合計転送回数は 100 万回です。奇妙なことに、task_scheduler_init を 2 に設定すると、プログラムが最速 (8 秒) になります。実際、私のCPUは8スレッドのi7 6700kです。8 ～ 50,000 の範囲では、プログラムのパフォーマンスはほとんど変わりません (11 ～ 12 秒)。task_scheduler_init を 100,000 に増やすと、実行時間は約 18 秒に増加します。プロファイラーを使用してプログラムを分析しようとしたところ、ホットスポット機能がミューテックスであることがわかりました。ただし、トランザクションのロールバック率はそれほど高くないと思います。プログラムが遅い理由がわかりません。

偽の共有がパフォーマンスを低下させると誰かが言うので、その結果、私は使用しようとしました

std::vector> cache_aligned_accounts(AccountsSIZE,Account(1000));

元の配列を置き換える

アカウント* accounts[AccountsSIZE];

偽の共有を避けるために。何も変わっていないようです。これが私の新しいコードです。

gcc docs: x86-transactional-memory-intrinsics.htmlにより、トランザクションが失敗/中止された場合、_xbegin()は中止ステータスを返す必要があります。ただし、時々0が返されることがあります。そしてその頻度は非常に高いです。**_xbegin()** が 0 を返すのはどのような状況ですか?

マニュアルを確認したところ、多くの状況でこの結果が生じる可能性があることがわかりました。たとえば、CPUID、SYSTEMCALL、CFLUSH.etcです。ただし、私のコードがそれらのいずれもトリガーしたとは思いません。

これが私のコードです：小さな銀行をシミュレートし、別の口座に1ドルをランダムに送金します。

サプリメント:

1. すべてのアカウントは 64 ビットに揃えられています。bank->accounts[0], bank->accounts 1のアドレスを印刷しました。0xf41080，0xf410c0。</li>
2. -O0 を使用するasm volatile("":::"memory");ため、命令の並べ替えの問題はありません。

3. アボート率は時間とともに増加します。これが結果です

   /li>

4. n_threads が 1 であっても、結果は同じです。

5. 次のようにフォールバック後に粗いロックを追加すると、結果は正しいようです。

   /li>

よく知られているように、Intel は、マイクロコードの更新により、Haswell シリーズのプロセッサで TSX を無効にする必要がありました。これは、これらの命令を使用すると誤った結果が生じる可能性がある TSX 実装のバグが原因でした。

あまり知られていないように思われるのは、新しいアーキテクチャである Skylake の TSX に影響を与えるエラッタも明らかに存在することです。具体的には、ここで言及されているエラータ「SKL-105」:

http://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html

TSX を使用すると、予期しないシステム動作が発生する可能性があることを具体的に述べています。ただし、BIOS が修正を行う可能性があることにも注意してください。ただし、問題は、この修正が何を伴うかです。Haswell マイクロコードの「修正」のように、TSX を完全に無効にしますか? 「SKL105」をグーグルで検索しても結果が出ないので、コミュニティは一般的にそれを認識していないようですか?

一部のユーザーは、TSX 機能が「着実に」無効になっていることに気付きました (ただし、上記の正誤表に気づいていないようです)。

https://www.reddit.com/r/hardware/comments/44k218/intel_disables_tsx_transactional_memory_again_in/

CPU の特定のバリアントのみが影響を受けるのは奇妙です。なぜなら、それらはすべて同じマイクロアーキテクチャを共有しているため、このバグによって等しく影響を受けると推測されるからです。

ちなみに、そのようなマイクロコードの「修正」が機能し、さらにステルスになる可能性がある別の方法: TSX の存在を公開するマイクロコードの更新を行うことは可能だと思います (機能がまだ有効にされているように見せます)。しかし、新しい TSX 命令の実装を、実際には決してロックを回避せず、基本的に昔ながらの方法でコードを実行するだけの「ダミーの実装」でオーバーライドすることで、バグを回避するだけでなく、TSX が提供できるパフォーマンスの向上も実現できません。これが発生したかどうかを判断する唯一の方法は、パフォーマンスの測定です。

Skylake での TSX のステータスについて詳しい情報を持っている人はいますか? いずれにせよ、それ以上の情報が公開されておらず、何が影響を受け、何が影響を受けていないかを推測しなければならないのは奇妙です。実際、その機能が安全に使用できるかどうか。

私は 6700K を持っていますが、その機能はまだあります。ただし、これは、BIOS の製造元がマイクロコードの更新を取り入れているかどうかにも依存します。また、実際にパフォーマンスを測定していないため、まだ無効になっている可能性があることも除外できません。前の段落。