forループの繰り返しは分岐と同じですか？

Question

私は通常の日にプログラミングしているとき、私はすべての支店が取られていない可能性が高いことを確認します。

int retval = do_somting(); 
if(!retval) { /* Less-than-likely event*/ } 

これは分岐の予測を最適化し、CPUの予測ビットを「取らない」ように設定します。しかし、予測子ビットはforループの後に "take"に強制されますか？

// prediction = "likely take" 
if(false) { } 

// prediction = "probably take" 
if(false) { } 

// prediction = "probably not take" 
if(false) { } 

// prediction = "likely not take" 
if(false) { } 

/* ... thousands of other if(false) that are speedy-fast */ 

for(int i = 0; i < 5; i++) { } 
// prediction = "likely take"? 

私はそれは非現実的と非常に小さい最適だけど、ちょっと、より多くのあなたが知っています。

編集： GCCは上記のコードをすべてゴミ箱に入れないとしましょう。また、amd64アーキテクチャについても話しましょう。私はこの質問がどれほど低レベルであるか分かりませんでした。

Answer 1

分岐予測は、CPUのモデルによって異なります。通常の枝にループに関連するとき

はthis paperによると、分岐予測は、いくつかの方法数え切れないほどの量で処理されます。いくつかのCPUは別個の予測ループを持っています。つまり、ifステートメントは、forステートメントの予測にはまったく影響しません。他は同じ予測を共有しています。

これに関係なく、この質問に対する真の答えは1つありません。ブランチ効率について話すとき、forループを測定することはできません。

...もちろん、CPUの単一モデルでのみプログラムを実行する場合を除きます。 （AMD64を含む）、分岐予測と

Answer 2

ほとんどのアーキテクチャは、短い下向き/フォワード/ジャンプ枝性は低いと短い後向き/上向きの枝を/可能性が高いジャンプを検討してください。これは、ほとんどのループがループを続けると予測されることを意味します。これにより、do-whileループは、初期条件のためにforループまたはwhileループよりも分数的に効率が良くなります。しかし、ほとんどの最適化コンパイラは、これらのケースを可能な限り同様のコードに最適化します。

あなたは__builtin_expect()で、条件を使用して-O3最適化レベルでGCCとのアセンブリの違いを見ることができます。可能性の低い分岐は、通常、順方向のジャンプであるが、考えられる条件は、まったく分岐しないか、逆方向にジャンプしない。これは論理を反転させることを伴い得る。注：-O3では、gccはしばしば起こりそうでないブランチにコードを複製するので、可能性のあるケースのブランチを最小限に抑えることができます。

その先頭にそれが枝場合は、キャッシュラインに収まるループがキャッシュミスを持っていないので、これは理にかなっています。同様に、プログラムは一般に関数内で線形的に前進するので、最近実行されたコードは既にキャッシュに存在する可能性が高い。ループをいくつかの点（恐らく約4つの条件文）で余分な "最適化"条件に置き換えると、キャッシュミスは可読性と保守性を犠牲にして得られる可能性のある小さな利点を無効にします。