指令中的x86/x64的ASM重新排序 - 與最新的CPU性能優化

Question

多少的性能提升，如果有的話，可以從一個最近高端的Intel CPU重新排序的x64（x86-64的）指令得到。在極度危急的情況下值得一提嗎？

我也想知道關於通過改變寄存器的使用取得的成果的可能性/使用附加寄存器（如果免費），以允許在某些情況下，奇較長距離的代碼移動？

Answer 1

指令調度通常不是什麼大不了的事在短距離內，因爲亂序執行通常工作。對於像一些ARM內核這樣的有序CPU來說，它更重要，在這些內核中，調度加載遠遠超過使用結果的指令，這很重要。

它可以幫助一些甚至高端的X86，不過，這取決於什麼樣的瓶頸制約着你的執行吞吐量。參見http://blog.stuffedcow.net/2013/05/measuring-rob-capacity/關於ROB大小與物理寄存器數量有關的一些有趣的內容是無序執行中的限制因素。 Software-pipelining可能有助於長期依賴鏈，無序執行很難隱藏。關鍵路徑依賴鏈

把指令早可以幫助，因爲OOO調度通常試圖執行最古老準備先。 （見How are x86 uops scheduled, exactly?）。

現代的CPU是複雜的野獸，有時重新排序的東西可以讓你的時候就不能指望它重要的差異。有時候無法準確猜測它爲什麼會產生變化。不同的排序可能會影響解碼器甚至uop緩存中的前端帶寬，因爲關於解碼uops如何打包到uop緩存（在Intel CPU上）的up-to-6-uop行有很多規則。例如，Branch alignment for loops involving micro-coded instructions on Intel SnB-family CPUs

有時候的解釋是非常模糊。例如，在英特爾的優化手冊Example 3-25. Re-ordering Sequence to Improve Effectiveness of Zero-Latency MOV Instructions中，他們討論了立即覆蓋zero-latency-movzx結果以更快地釋放內部資源。 （我嘗試了Haswell和Skylake上的例子，發現mov-elimination事實上在這麼做的時候確實有更多的工作時間，但實際上它在總週期中實際上稍慢，而不是更快。 IvyBridge帶來的好處，這可能會對其3個ALU端口造成瓶頸，但HSW/SKL僅是dep鏈中資源衝突的瓶頸，似乎並不需要ALU端口來處理更多的movzx指令。）

也許這也適用於eliminated mov instructions，不只是movzx，但它可能不會。

IDK如果如果我在真正的優化情況（對於IvyBridge）遇到如果英特爾的手冊沒有使用它作爲例子，我會想到這一點。發佈與執行的uops的性能計數器（融合域與非融合域）顯示消除了多少個mov uops，但如果沒有優化手冊說明原因，幾乎不可能找出發生這種情況的原因。重新排序附近的獨立指令只是爲了嘗試一下，可以幫助我們作爲調整的最後一步，但在那一點上，它是巫術/黑魔法/猜測。

---

正如瑪格麗特所指出的那樣，除了簡單的調度之外，還有其他原因需要重新排序。請參閱Agner Fog's optimization and microarchitecture guides以及x86標記wiki中的其他資源以瞭解更多信息。

例如，由於宏融合，將cmp/jcc和test/jcc分組在一起總是一個好主意。你的編譯器會在你編譯-march=haswell之類的時候爲你做這個，因爲那樣可以啓用-mtune=haswell。

它也可以打開其他優化機會，如果它可以讓你避免一些mov指令或溢出/重新加載，但不僅僅是調度指令。