問題タブ [branch-prediction]

次のコードは、たとえば Intel Core i7 で分岐予測ミスのペナルティを被りますか?

count は 0、1、または 2 です。

分岐予測テーブルのサイズを大きくすると、プログラム内の2つの分岐が共通の予測子を共有する可能性が低くなります。単一の分岐命令を予測する単一の予測子は、一般に、複数の分岐命令を処理する同じ予測子よりも正確です。

分岐の実行されたアクションと実行されなかったアクションのシーケンスをリストして、状況と比較して分岐の誤予測率を低減する2ビットの予測子共有（いくつかの異なる分岐命令が予測テーブルの同じエントリにマップされる）の簡単な例を示しますここで、ブランチごとに個別の予測子エントリが使用されます。（注：2つの異なる分岐命令の結果を必ず示し、これらの結果の順序とそれらが対応する分岐を具体的に示してください）

誰かが私にこの質問が具体的に何を求めているのか説明できますか？また、「2ビット予測子共有（いくつかの異なる分岐命令が予測テーブルの同じエントリにマップされる）」および「各分岐に個別の予測子エントリが使用される」とはどういう意味ですか？私は自分のメモを読んだり読み直したりしてきましたが、それを理解できませんでした。オンラインでいくつかの分岐予測の例を見つけようとしましたが、見つかりませんでした。

上記の 2 つのケースに固有の情報を見つけるのに苦労していますが、あなたの専門家の意見を聞いています。

最初のことは、間接jmpが分岐予測を損なうことを知っています。また、間接jmpの結果が一定であっても、絶対jmpと比較して、予測メンテナンスバッファーなどが必要であることを知っています。

私の質問は、誰かが知っているかどうかです：

プロセッサの分岐予測子によってまだ間接的であると見なされているか、この場合は計算を実行します.x64には直接的な「jmp absolute 64」命令がなく、間接的な命令しかないため、そうしています。:/ ( How to execute a call instruction with a 64-bit absolute address?代わりにジャンプをターゲットに十分近づけて使用できない場合は、これを示唆していますjmp rel32。)

次に、その範囲で、jmp 0x1234 と call 0x1234 の間に実際の違いはありますか (プロセッサの最適化 (命令キャッシュ、プリフェッチャーとそのヒント、分岐予測) に関して) ? (vc2012 の「速度最適化」は呼び出し、「min_size opt」は jmp、「混合最適化」は x64 の場合は jmp、x86 の場合は呼び出し)

I have this C function:

which I am calling in a tight loop, and would like to get rid of the branch to see if it improves performance.

I cannot use this:

because it returns NaN when x == 0 (which is true about 25% of the time.)

Is there another way to implement it so that it returns 0 when x == 0, but still get rid of the branch?

(I am less concerned about negative inputs, because these are errors, whereas zeros are not.)

この質問では、Visual Studio 2012 と GCC 4.7 に焦点を当てます。

一方では、プロファイル ガイド付きコンパイルは、実行時にコードを計測し、2 回目のコンパイル中にこの情報を使用することで、分岐予測を最適化します。一方、多くのコンパイラは、どの分岐が最も可能性が高いかをコンパイラに示唆する拡張機能を提供しています: GCC が提供するもの__builtin_expectと Visual Studio が提供するもの__assumeです。

両方のコンパイラ拡張機能を使用してコードを書き直すことができるように、(どちらかのコンパイラの) プロファイル ガイド情報を抽出する方法はありますか? 目標は、独自のバージョンのバイナリを再コンパイルすることをいとわない人々のために、「最適化された」ソース コードを提供することです。

私が理解したように、Return Stack Buffer は 4 ～ 16 のエントリのみをサポートし (wiki から: http://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_function_returns )、キーと値のペアではありません (ret 命令の位置によるインデックス付けに基づく) ）。本当ですか？コンテキスト スイッチが発生すると、RSB はどうなりますか?

リターン スタック バッファ長が 16 の CPU で返されない関数が 50 個あるとします。その後はどうなりますか? すべての予測が失敗するということですか？あなたはそれを説明できますか？このシナリオは、再帰関数呼び出しでも同じですか?

分岐予測についてお聞きしたいことがあります。私はそれが何であるか、そしてそれらがどのように機能するか、またはそれらの異なるタイプを完全に知っています。私の質問はこれです：私が各予測子のパフォーマンスを使用するプロセッサはどのようになりますか？つまり、同じベンチマーク、同じ予測子、異なるプロセッサを使用した場合、同じヒット率が期待できますか？ただのモデルで、プロセッサの種類に影響されないので、そうだと思いますが、それについては確かにしたいと思います。

この投稿 (StackOverflow の回答) (最適化セクション)を読んだ後、なぜ条件付き移動が分岐予測失敗に対して脆弱ではないのか疑問に思いました。cond move here (PDF by AMD) に関する記事を見つけました。また、彼らは cond のパフォーマンス上の利点を主張しています。動きます。しかし、これはなぜですか？見えません。その ASM 命令が評価される時点では、先行する CMP 命令の結果はまだわかりません。

私は、予測可能な分岐を含むループとランダムな分岐を含むループを実行する時間を測定することにより、分岐予測を十分に理解しようとしています。

そこで、0 と 1 の大きな配列をさまざまな順序 (つまり、すべて 0、0-1 の繰り返し、すべて rand) に配置し、現在のインデックスが 0 か 1 かによって分岐する配列を反復処理するプログラムを作成しました。・仕事の無駄。

推測しにくい配列は実行に時間がかかると予想しました。これは、分岐予測子がより頻繁に間違って推測するためであり、2 セットの配列での実行間の時間差は、時間に関係なく同じままであると予想していました。仕事を無駄にする。

ただし、時間を浪費する作業の量が増えるにつれて、アレイ間の実行時間の差が大きくなりました。

(X 軸は時間を浪費する作業の量、Y 軸は実行時間)

誰もこの行動を理解していますか？次のコードで実行しているコードを確認できます。

Pastebin リンク: http://pastebin.com/F0JAu3uw