我遇到了這張非常漂亮的資訊圖，它粗略地估計了用于某些操作的 CPU 周期。在學習時，我注意到一個條目“if 的右分支”，我認為如果滿足條件，分支“if”將采用（編輯：正如評論中指出的那樣，“右”實際上意味著“正確預測的分支” ）。這讓我想知道 if 分支與 else 分支相比是否有任何（即使是很小的）速度差異。
例如，比較以下非常簡潔的代碼：
演示
#include <cstdio>
volatile int a = 2;
int main()
{
if (a > 5) {
printf("a > 5!");
a = 2;
} else {
printf("a <= 5!");
a = 3;
}
}
在 x86 64 位中生成此程式集：
.LC0:
.string "a > 5!"
.LC1:
.string "a <= 5!"
main:
push rcx
mov eax, DWORD PTR a[rip]
cmp eax, 5
jle .L2
mov edi, OFFSET FLAT:.LC0
xor eax, eax
call printf
mov DWORD PTR a[rip], 2
jmp .L3
.L2:
mov edi, OFFSET FLAT:.LC1
xor eax, eax
call printf
mov DWORD PTR a[rip], 3
.L3:
xor eax, eax
pop rdx
ret
a:
.long 2
如您所見，呼叫 printf for "a > 5" 的正確分支更接近 cmp - 指令。因此，查看資料快取可能會出現呼叫 printf 的指令已經加載到快取行中的情況，而 else 分支必須首先從 L2 或 L3 快取中獲取。在建立分支預測模式之前，這（理論上）是否會導致“右”分支的微小加速？
uj5u.com熱心網友回復：
if不， and分支之間沒有真正的區別else，這不是您鏈接的圖形所指的“正確”分支。“正確”意味著 CPU 的分支預測在比較完成之前正確地猜到了將采用哪個分支。
現代 CPU 是流水線的。他們在完成當前指令之前就開始著手下一條指令。這可以顯著提高性能，因為這意味著 CPU 可以使其所有不同的子組件（指令解碼器、ALU 的不同部分、記憶體控制器等）一直處于忙碌狀態，而不是讓它們閑置而另一個組件CPU 的作業。即它可以同時執行加法、從記憶體中獲取運算元和解碼指令。
這種流水線取決于知道接下來將執行什么指令，而條件分支指令會在其中發揮作用。在您的示例中，CPU 不知道下一條需要執行的指令是在指令完成之后jle .L2還是在指令完成之后mov edi, OFFSET FLAT:.LC0，所以它會猜測。它開始在其中一個分支上作業，當最終完成時，它會查看它是否猜對了。如果確實如此，那太好了，它在以下說明中完成的部分作業是有效的，并且它會像往常一樣繼續進行。如果它猜錯了，它在之后的指令中所做的所有作業mov edi, OFFSET FLAT:.LC1cmpcmpjle必須扔掉，它開始在另一個分支上作業，這需要一些時間。偶爾的錯誤猜測不會產生明顯的性能差異，但如果它經常猜測錯誤，它可能會開始加起來并產生很大的不同。
另請參閱StackOverflow 上評分最高的答案。
請注意，在某些較舊的或嵌入式 CPU 上，分支預測演算法本質上只是“總是猜測第一個”，因此在此類 CPU 上，else路徑會更慢，因為默認情況下分支預測永遠不會猜測。在這些 CPU 上，GCC__builtin_expect或 C 20 的[[likely]]屬性有助于告訴編譯器哪個分支更有可能，以便它生成匯編代碼以使更有可能的路徑成為“第一個”路徑，即使它是else.
uj5u.com熱心網友回復：
簡而言之，在主流處理器上沒有，但在一些舊/嵌入式處理器上是。
現代主流處理器非常擅長預測條件（假設它們不是第一次執行或者可以提前完成測驗）。當一個分支被正確預測時，幾乎沒有成本（除了使用在某些特定埠上執行的分支單元）。處理器可以推測性地獲取并執行預測的條件塊的指令。當分支沒有被正確預測時，處理器必須執行一種非常昂貴的回滾操作（通常為 5-15 個周期）。
一些嵌入式處理器和舊處理器使用靜態預測演算法。例如，他們可以假設該分支從未被采用。在這樣的處理器上，執行if塊通常比else假設編譯器不對塊重新排序（啟用優化時這種情況非常頻繁）更快。開發人員可以提供內置提示，以幫助編譯器生成代碼，以便使用靜態磁區的處理器更有效地執行。組態檔引導優化可用于自動查找通常為真/假的條件并相應地重新排序分支以提高性能。
主流（服務器、桌面和高端移動）處理器主要使用動態預測演算法。例如，他們可以跟蹤和記憶何時采用或不采用分支，以了解將來采用該分支的概率。處理器通常跟蹤一組有限的條件分支。因此，當代碼有太多（重疊的）條件分支指令時，可以使用靜態磁區演算法作為備用方法。
值得一提的是，在某些情況下可以重置/重繪 預測資訊，例如當行程被搶占時（正如@HenriqueBucher 所指出的那樣）。這意味著當有很多背景關系切換時，預測的效果可能會低得多。請注意，推測可以由某些特定指令集部分控制，以減輕Spectre等漏洞。
由于處理器需要獲取可能不在指令高速快取中的指令，因此跳轉到遠未預測的位置可能會很昂貴。在您的情況下，在主流 x86-64 處理器上肯定無關緊要，因為最近的 x86-64 處理器預計會很快將程式的所有指令加載到快取中。例如，Skylake 處理器可以從指令快取中獲取 16 位元組/周期，而 Zen 2 處理器可以達到 32 位元組/周期。兩者都可以將 64 位元組快取行加載到指令快取中。
關于最近英特爾處理器的分支預測演算法的公開資訊并不多。AMD Zen 2 處理器的一個有據可查：它使用高效的TAGE 預測器與感知器相結合，以便根據過去的統計資料預測條件的結果。您可以在此處找到有關其行為的詳細資訊。
uj5u.com熱心網友回復：
我假設的“if 的右分支”是在滿足條件時將采用的分支“if”。
不，它是在談論正確的分支預測，而不是在表中降低“if 的錯誤分支（分支錯誤預測）”條目。else無論C 源代碼中是否存在，這都是一回事。
前端需要預測條件分支不會停止，但猜錯意味著它必須倒帶并丟棄錯誤推測的指令。無論有沒有else零件，這都適用。請參閱 Mysticial 關于為什么處理排序陣列比處理未排序陣列更快的著名答案？
只需要一個else指令塊中的一個額外的無條件分支來不運行另一個指令塊。（在您的情況下，就是jmp .L3）。另一種選擇是將一個塊放在其他地方（例如，ret在函式底部的之后），因此快速路徑上沒有采用的分支，但另一條路徑有一個被采用jcc和一個被采用jmp后重新加入另一條路徑如果/其他。
如您所見，呼叫 printf for "a > 5" 的正確分支更接近 cmp - 指令。因此，查看資料快取可能會出現呼叫 printf 的指令已經加載到快取行中的情況，而 else 分支必須首先從 L2 或 L3 快取中獲取。在建立分支預測模式之前，這（理論上）是否會導致“右”分支的微小加速？
是的，I-cache locality 的分支布局是一個東西，大部分或完全獨立于分支預測。
正如您所說，I-cache locality 是一回事，因此如果編譯器知道（或者您用or告訴它）一側，則將很少執行的塊放在函式的末尾（在 之后ret）是編譯器可以做的事情if/else 本質上是“冷的”。[[likely]][[unlikely]]
編譯器有各種啟發式方法來猜測一個if條件是否正常，因此即使沒有來自訓練運行的資料，他們仍然可以進行猜測（用于組態檔引導優化）。它可以先排版機器碼和if零件else。
此外，就前端吞吐量而言，分支的未采用直通路徑通常比采用側略便宜。這是假設正確的預測。現代 CPU 在大的連續塊中獲取機器代碼，例如一次 16 或 32 個位元組，但在一個被占用的分支上，它們可能無法使用所有這些位元組，并且必須進行另一次獲取才能看到更多指令。
一些 ISA 有機器代碼分支提示，編譯器可以使用這些提示來告訴硬體分支預測器一個分支可能會走哪條路，但除此之外，沒有組態檔引導優化或[[likely]]/[[unlikely]]或 GNU C__builtin_expect影響分支的機制預言。除了通過 CPU 上的布局進行靜態預測之外，還可以退回到靜態預測；不包括自 Sandybridge 以來的 Intel：Intel 這些年為什么要改變靜態分支預測機制？.
也可以看看：
- 是否可以告訴分支預測器跟隨分支的可能性有多大？
- GCC 的 __builtin_expect 在 if else 陳述句中的優勢是什么？
- 當 Skylake CPU 錯誤預測分支時，究竟會發生什么？- 早期分支恢復可以在錯誤預測的分支 uop 達到退休之前開始，因此它可以與在發現錯誤預測的分支之前處理獨立指令的無序 exec 并行發生。
- 這些年英特爾為什么要改變靜態分支預測機制？-靜態預測（向后采用，向前不采用）不再是現代英特爾 CPU 所做的事情，即使動態預測器恰好是冷的。IDK 如果英特爾現在可能已經改變了任何事情，因為重繪 BPU 歷史以緩解 Spectre 是一種更常見的事情，這使得冷情況更常見，因此更值得擔心和優化。
順便說一句，GCC 在這里做得并不好。 if/else和 store to的兩邊，只是具有不同的值。call printfa 而且它已經在使用 push/pop 進行堆疊對齊，因此它可以保存/恢復 RBX 以便在某個地方存盤 printf 中的比較結果。它甚至可以制作無分支代碼，cmov用于在兩個格式字串指標之間進行選擇。
hand_written_main:
push rbx # realign the stack and save RBX
mov ebx, 2
mov edi, OFFSET FLAT:.LC0 # we can set regs unconditionally, no else needed
cmp dword ptr [RIP a], 5 # splitting to mov cmp might be more efficient for macro-fusion of cmp/jcc and maybe micro-fusion
jle .L2
mov edi, OFFSET FLAT:.LC1 # or RIP-rel LEA in a PIE
mov ebx, 3
.L2:
xor eax, eax # number of XMM args in regs for variadic functions
call printf
mov DWORD PTR a[rip], ebx
pop rbx
ret
有趣的是，這對分支的一側執行了更多指令，因為mov ebx, imm32和mov edi, imm32無條件執行，然后如果沒有采用分支，我們會再次運行它們。這就像int ebx = 2;/if(a<=5) ebx=3;而不是=2in else。這是保持分支更簡單（沒有jmp任何地方）與運行額外指令的權衡。現代 x86 CPU 非常廣泛，額外的指令獨立于任何東西，因此這里有指令級并行性。
還有一種有趣的無分支方式，將字串分開 8 個位元組打包在一起，這樣我們就可以使用單一尋址模式生成其中一個或另一個的地址。
hand_written_main:
push rbx # realign the stack and save RBX
xor ebx, ebx
cmp dword ptr [RIP a], 5
setle bl # bl = (a<=5)
lea edi, [gt5msg rbx*8] # In a PIE, we'd need [rdi rbx*8] with a separate RIP-relative LEA
add bl, 2 # 2 (a<=5) = 2 or 3
xor eax, eax # number of XMM args in regs for variadic functions
call printf
mov DWORD PTR a[rip], ebx
pop rbx
ret
.section .rodata
.p2align 3
gt5msg: .asciz "a > 5!" # <= 8 bytes long, in fact 7 so there's an extra 1 byte of padding.
.p2align 3
le5msg: .asciz "a <= 5!" # starts exactly 8 bytes after the previous message
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/511330.html
標籤：Intel Collective C 表现部件x86分支预测
上一篇：在編譯時生成一系列空值，后跟一個