這與此問題有關，但不一樣：x86-64匯編的性能優化 - 對齊和分支預測與我之前的問題略有關系：無符號64位到雙倍轉換：為什么這個算法來自g ++以下是一個不真實的測試用例。這種素性測試算法是不明智的。我懷疑任何真實世界的算法都不會執行如此多的小內循環（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生成以下內容，包含RCX n和包含XMM6 sqrt(num)。請參閱我之前發布的剩余代碼（在此示例中從未執行過，因為RCX永遠不會變得足夠大，不能被視為帶符號的否定）。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。我一直在進行奇怪的性能變化：從添加或刪除其他代碼。我最終將其追蹤到一個對齊問題。該命令.p2align 4,,10試圖對齊2 ** 4 = 16字節邊界，但只使用最多10個字節的填充來實現，我想在對齊和代碼大小之間取得平衡。我寫了一個Python腳本，用.p2align 4,,10手動控制的nop指令數替換。下面的散點圖顯示了20次運行中最快的15次，以秒為單位的時間，在x軸上填充的字節數：散點圖從objdump沒有填充，將發生在偏移0x402f5f的PXOR指令。在筆記本電腦上運行，Sandybridge i5-3210m，turboboost 禁用，我發現了對于0字節填充，性能較慢（0.42秒）對于1-4字節填充（偏移0x402f60到0x402f63）稍微好一點（0.41s，在圖上可見）。對于5-20個字節填充（偏移0x402f64到0x402f73）獲得快速性能（0.37s）對于21-32字節填充（偏移0x402f74到0x402f7f）緩慢性能（0.42秒）然后循環一個32字節的樣本因此，16字節對齊不能提供最佳性能 - 它使我們處于稍微好一點（或者從散點圖中稍微變化）的區域。32加4到19的對齊可以提供最佳性能。為什么我看到這種性能差異？為什么這似乎違反了將分支目標與16字節邊界對齊的規則（參見例如英特爾優化手冊）我沒有看到任何分支預測問題。這可能是一個uop緩存怪癖？通過將C ++算法更改為sqrt(num)64位整數緩存然后使循環純粹基于整數，我刪除了問題 - 對齊現在沒有任何區別。