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大小的一些有趣內容與物理寄存器數量是無序執行的限制因素。 軟件流水線可以幫助實現無序執行難以隱藏的長依賴鏈。

盡早將指令放在關鍵路徑依賴關系鏈上會有所幫助，因為OOO調度通常會嘗試執行最早就緒的優先級。 （請參閱如何安排x86 uops，確切地說？ ）。

現代CPU是復雜的野獸，有時重新排序的東西可能會產生影響，當你不希望它重要。 有時候無法准確猜出它為何會產生影響。 不同的排序會影響解碼器甚至uop緩存中的前端帶寬，因為有許多規則關於uop緩存（在Intel CPU上）如何將解碼的uop包裝成最多6個uop線。 例如， 涉及Intel SnB系列CPU上的微編碼指令的循環的分支對齊

有時解釋非常模糊。 例如，在英特爾的優化手冊中， 例3-25。 重新排序序列以提高零延遲MOV指令的有效性 ，他們討論立即覆蓋零延遲-movzx結果以更快地釋放內部資源。 （我嘗試了Haswell和Skylake的例子，並發現mov-elimination確實在更多的時候工作，但實際上它在整個周期中實際上稍微慢了一些，而不是更快。這個例子是為了顯示IvyBridge的好處，可能是其3個ALU端口的瓶頸，但HSW / SKL只是dep鏈中資源沖突的瓶頸，似乎不需要ALU端口來處理更多的movzx指令。）

可能這也適用於消除的mov指令 ，不僅僅是movzx ，但它可能不適用。

IDK如果我想知道如果我遇到真正的優化情況（對於IvyBridge），如果英特爾的手冊沒有用它作為一個例子。 發布與執行的uops（融合域與未融合域）的性能計數器顯示消除了多少個移動uop，但如果沒有優化手冊說明原因，幾乎不可能找出它發生的原因。 重新排序附近的獨立指令只是為了嘗試，可以作為調整的最后一步，但在那一點上它是伏都教/黑魔法/猜測。

---

正如瑪格麗特指出的那樣，除了簡單的調度之外，還有理由對指令進行重新排序。 有關詳細信息，請參閱Agner Fog的優化和微體系結構指南以及x86標記wiki中的其他資源。

例如，由於宏觀融合，將cmp/jcc和test/jcc組合在一起總是一個好主意。 當您使用-march=haswell或其他東西進行編譯時，您的編譯器將為您執行此操作，因為這樣可以啟用-mtune=haswell 。

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