這與此問題有關(guān)，但不一樣：x86-64匯編的性能優(yōu)化 - 對齊和分支預(yù)測與我之前的問題略有關(guān)系：無符號64位到雙倍轉(zhuǎn)換：為什么這個算法來自g ++以下是一個不真實的測試用例。這種素性測試算法是不明智的。我懷疑任何真實世界的算法都不會執(zhí)行如此多的小內(nèi)循環(huán)（num大概是2 ** 50的大小）。在C ++ 11中：using nt = unsigned long long;bool is_prime_float(nt num){   for (nt n=2; n<=sqrt(num); ++n) {      if ( (num%n)==0 ) { return false; }   }   return true;}然后g++ -std=c++11 -O3 -S生成以下內(nèi)容，包含RCX n和包含XMM6 sqrt(num)。請參閱我之前發(fā)布的剩余代碼（在此示例中從未執(zhí)行過，因為RCX永遠(yuǎn)不會變得足夠大，不能被視為帶符號的否定）。jmp .L20.p2align 4,,10.L37:pxor    %xmm0, %xmm0cvtsi2sdq   %rcx, %xmm0ucomisd %xmm0, %xmm6jb  .L36   // Exit the loop.L20:xorl    %edx, %edxmovq    %rbx, %raxdivq    %rcxtestq   %rdx, %rdxje  .L30   // Failed divisibility testaddq    $1, %rcxjns .L37// Further code to deal with case when ucomisd can't be used我用這個時間std::chrono::steady_clock。我一直在進(jìn)行奇怪的性能變化：從添加或刪除其他代碼。我最終將其追蹤到一個對齊問題。該命令.p2align 4,,10試圖對齊2 ** 4 = 16字節(jié)邊界，但只使用最多10個字節(jié)的填充來實現(xiàn)，我想在對齊和代碼大小之間取得平衡。我寫了一個Python腳本，用.p2align 4,,10手動控制的nop指令數(shù)替換。下面的散點圖顯示了20次運行中最快的15次，以秒為單位的時間，在x軸上填充的字節(jié)數(shù)：散點圖從objdump沒有填充，將發(fā)生在偏移0x402f5f的PXOR指令。在筆記本電腦上運行，Sandybridge i5-3210m，turboboost 禁用，我發(fā)現(xiàn)了對于0字節(jié)填充，性能較慢（0.42秒）對于1-4字節(jié)填充（偏移0x402f60到0x402f63）稍微好一點（0.41s，在圖上可見）。對于5-20個字節(jié)填充（偏移0x402f64到0x402f73）獲得快速性能（0.37s）對于21-32字節(jié)填充（偏移0x402f74到0x402f7f）緩慢性能（0.42秒）然后循環(huán)一個32字節(jié)的樣本因此，16字節(jié)對齊不能提供最佳性能 - 它使我們處于稍微好一點（或者從散點圖中稍微變化）的區(qū)域。32加4到19的對齊可以提供最佳性能。為什么我看到這種性能差異？為什么這似乎違反了將分支目標(biāo)與16字節(jié)邊界對齊的規(guī)則（參見例如英特爾優(yōu)化手冊）我沒有看到任何分支預(yù)測問題。這可能是一個uop緩存怪癖？通過將C ++算法更改為sqrt(num)64位整數(shù)緩存然后使循環(huán)純粹基于整數(shù)，我刪除了問題 - 對齊現(xiàn)在沒有任何區(qū)別。