從CPU角度分析IPC產(chǎn)生的原因

IPC的意義

一般來說IPC是越高越好， 這意味著單位時間執(zhí)行了更多的指令， 通過觀測IPC可以一定程度上了解軟件的執(zhí)行效率。 但是多高才算高呢？ 這并沒有標準答案， 它需要有基線進行對比， 有的代碼邏輯就決定了不可能有太高的IPC， 比如存在大量的跳轉(zhuǎn)邏輯或者隨機訪問， 當(dāng)然這可能就是需要優(yōu)化的地方。

首先來看一個簡單的測試程序：

# cat s1.c void main（） { unsigned long sum = 0， i = 0; for （i = 0; i 《 0x10000000; i += 1） { sum += i; } } $ gcc -O0 s1.c -o s1 $ perf stat 。/s1 2，145，851，708 cycles # 2.284 GHz （83.30%） 1，606，130，789 stalled-cycles-frontend # 74.85% frontend cycles idle （83.30%） 180，401，278 stalled-cycles-backend # 8.41% backend cycles idle （66.78%） 1，347，161，466 instructions # 0.63 insns per cycle

一種比較通用的優(yōu)化方法就是把for循環(huán)展開（unroll）， 再來看看效果：

$ cat s2.c void main（） { unsigned long sum = 0， a = 0， b = 0， c = 0， d = 0， i = 0; for （i = 0; i 《 0x10000000; i += 4） { a += i; b += i + 1; c += i + 2; d += i + 3; } sum = a + b + c + d; } $ perf stat 。/s2 632，338，513 cycles # 2.281 GHz （83.40%） 229，407，430 stalled-cycles-frontend # 36.28% frontend cycles idle （83.41%） 7，151，154 stalled-cycles-backend # 1.13% backend cycles idle （66.83%） 1，343，577，403 instructions # 2.12 insns per cycle

可以看到， 這個優(yōu)化效果非常好， IPC從0.63上升到了2.12， 同時CPU執(zhí)行cycles也相應(yīng)地從2，145，851，708下降到了632，338，513. 不過指令條數(shù)基本上沒有變化， 如果再看匯編代碼， 就會發(fā)現(xiàn)-O0編譯出來的代碼還有很多訪存， 那么我們現(xiàn)在稍微修改一下， 使用register來存放變量i：

$ cat s3.c void main（） { unsigned long sum = 0， a = 0， b = 0， c = 0， d = 0; register unsigned long i = 0; for （i = 0; i 《 0x10000000; i += 4） { a += i; b += i + 1; c += i + 2; d += i + 3; } sum = a + b + c + d; } $ gcc -O0 s3.c -o s3 $ perf stat 。/s3 540，912，972 cycles # 2.284 GHz （83.12%） 270，437，339 stalled-cycles-frontend # 50.00% frontend cycles idle （83.48%） 5，344，535 stalled-cycles-backend # 0.99% backend cycles idle （67.08%） 1，074，783，046 instructions # 1.99 insns per cycle

這個優(yōu)化同樣有效， CPU執(zhí)行時間從632，338，513 cycles減少到540，912，972， 不過IPC卻從2.12減少到了1.99， 性能提升主要來源于指令條數(shù)的較少。 再進一步， 所有變量都使用register：

$ cat s4.c void main（） { register unsigned long sum = 0， a = 0， b = 0， c = 0， d = 0; register unsigned long i = 0; for （i = 0; i 《 0x10000000; i += 4） { a += i; b += i + 1; c += i + 2; d += i + 3; } sum = a + b + c + d; } $ gcc -O0 s4.c -o s4 $ perf stat 。/s4 203，071，748 cycles # 2.284 GHz （83.14%） 68，298，093 stalled-cycles-frontend # 33.63% frontend cycles idle （83.15%） 1，056，363 stalled-cycles-backend # 0.52% backend cycles idle （67.05%） 598，151，024 instructions # 2.95 insns per cycle

這個優(yōu)化更加明顯， CPU執(zhí)行時間優(yōu)化了一大半， 這來源于指令條數(shù)大幅減少了40%， 同時IPC從1.99上升到了2.95. 到這里我們已經(jīng)拿到了一個相對滿意的結(jié)果， 是否還有優(yōu)化的空間我們可以一起思考。

那么IPC到底說明了什么？ 它從某一個側(cè)面說明了CPU的執(zhí)行效率， 卻也不是全部。 想要提高應(yīng)用的效率， 注意不是CPU的效率， 簡單地說無非兩點：

沒必要的事情不做

必須做的事情做得更高效， 這個是IPC可以發(fā)揮的地方

指令并發(fā)

上面已經(jīng)看到， IPC是可以大于1的。 一般的理解是CPU通過pipeline提高了throughput， 但一條流水線每個cycle還是只能完成一條指令， 這種情況下IPC是《=1的。 那么是否可以推測出一個CPU上其實有多條流水線？ 答案是肯定的。 不過多流水其實有不同的實現(xiàn)方法， 主要是VLIW （Very Long Instruction Word） 和SuperScalar， VLIW通過compiler在編譯時靜態(tài)完成多指令的調(diào)度， 而SuperScalar則是在運行時調(diào)度多指令。 目前稍微好點的CPU使用的都是SuperScalar， Intel的CPU也不例外。

具體的信息可以參考Instruction Level Parallelism

飛得更高

既然IPC可以接近3， 那么還能不能再高點？ 我們看2個測試， alu.c 和 nop.c， 測試運行在Xeon E5-2682 v4 （Broadwell架構(gòu)）。

$cat alu.c void main（） { while（1） { __asm__ （ “movq $0x0，%rax ” “movq $0xa，%rbx ” “andq $0x12345678，%rbx ” “orq $0x12345678，%rbx ” “shlq $0x2，%rbx ” “addq %rbx，%rax ” “subq $0x14，%rax ” “movq %rax，%rcx”）; } } $gcc alu.c -o alu $perf stat 。/alu 6，812，447，936 instructions # 3.84 insns per cycle $cat nop.c void main（） { while（1） { __asm__ （“nop ” 。。. // 總共128個nop操作 “nop”）; } } $gcc nop.c -o nop 8，577，428，850 instructions # 3.66 insns per cycle

通過這2個測試可以看到， IPC甚至可以接近4， 同時也產(chǎn)生了幾個疑問：

3.84應(yīng)該不是極限， 至少應(yīng)該是個整數(shù)吧？

alu比nop還高， 這似乎不符合常理？

alu中的很多指令有依賴關(guān)系， 怎么達到高并發(fā)的？

首先來看第一個問題， 為什么是3.84， 而不是4或者5呢？ 這里面第一個需要關(guān)注的地方就是while（1）， 相對于其他move/and/or/shl/sub指令， 它是一個branch指令。 CPU對branch的支持肯定會復(fù)雜一點， 碰到branch指令還會prefetch之后的指令嗎？ 如果branch taken了那之前的prefetch不就沒用了？ 另一個需要考慮的就是Broadwell的每個core里面只有4個ALU， 其中只有2個ALU能夠執(zhí)行跳轉(zhuǎn)指令， 并且每個cycle最多能夠dispatch 4個micro ops. 而alu.c中每個循環(huán)是8條指令， 加上跳轉(zhuǎn)指令本身有9條指令， 看起來不是最好的情況。 那么在循環(huán)中減少一條指令會怎么樣：

$sed /orq/d alu.c 》 alu8.c $gcc alu8.c -o alu8 $perf stat 。/alu8 10，276，581，049 instructions # 3.99 insns per cycle

可以看到IPC已經(jīng)達到3.99， 非常接近4了。 如果把每個循環(huán)的指令條數(shù)修改為12 （包括跳轉(zhuǎn)指令）， 16， 20等都可以驗證IPC在3.99左右， 反之如果是13， 14就差一點。 唯一的例外來自于7， 它同樣能達到3.99 （原因？）， 再減少到6又差點。

這里使用了一個userspace讀CPU PMU的工具likwid

$likwid-perfctr -g UOPS_ISSUED_CORE_STALL_CYCLES:PMC0，UOPS_ISSUED_CORE_TOTAL_CYCLES:PMC1，UOPS_EXECUTED_STALL_CYCLES:PMC2，UOPS_EXECUTED_TOTAL_CYCLES:PMC3 -t 1s -O -C 1 。/alu

根據(jù)上面的結(jié)果可見， stalled cycle并無明顯區(qū)別， 因為只有當(dāng)一個cycle中沒有issue/execute任何一條指令的時候才計算， 對于這個測試用例是很少發(fā)生的。 測試發(fā)現(xiàn)event IDQ_UOPS_NOT_DELIVERED 和IPC的變化表現(xiàn)出相關(guān)性。 Intel 64 and IA-32 Architectures Optimization Reference Manual， B.4.7.1 Understanding the Micro-op Delivery Rate

也就是說front end不能夠及時把指令發(fā)給RAT （Resource Allocation Table）， 這個通過stalled-cycle-front end是不一定能看出的。 那么一個無條件jmp指令怎么就能影響到front end， 并且還跟每個循環(huán)的指令數(shù)相關(guān)？ 按理說所有的micro ops都已經(jīng)在IDQ （Instruction Decode Queue）中， 并且LSD （Loop Stream Detector）應(yīng)該完全能夠cover住這幾條指令。 具體原因暫時還不清楚， 如果知道這個了， 也許就有了另外一個問題的答案， 為什么是3.84而不是3.75或者別的呢？

現(xiàn)在來看第二個問題， 為什么alu比nop的IPC還要高呢？ 上面已經(jīng)分析過jmp指令的影響， 并且瓶頸點是在front end而不是在back end， nop和alu的指令并沒什么區(qū)別。 所以需要控制的是一個循環(huán)的指令數(shù)， 把其修改為8， 則nop一樣可以達到3.99的IPC.

第三個問題， CPU是怎么處理數(shù)據(jù)依賴的。 首先需要明確的是， 產(chǎn)生了數(shù)據(jù)依賴肯定會給并發(fā)帶來影響， 后面的指令必須等待前面指令的結(jié)果。 這里關(guān)鍵的一點是雖然在一個循環(huán)里面沒有獨立的四條指令， 但這并不影響2個甚至多個循環(huán)的并發(fā)性。 也就是說， 即使有跳轉(zhuǎn)指令， 后續(xù)的指令依然可以亂序執(zhí)行。 但兩次循環(huán)之間不還是使用相同的寄存器從而產(chǎn)生依賴嗎？ 是的， 如果它們最終使用的是相同的寄存器。 不過對于CPU來說， 匯編指令中的rax， rbx等不過是邏輯寄存器， 運行時還要進行一次rename的過程， 這個過程把一些false dependency給解決掉。 比如wiki上的例子。 而且CPU內(nèi)部物理寄存器的個數(shù)是遠遠大于可以rename的邏輯寄存器個數(shù)的， 一般來說足夠解決在流水線及亂序情況下的false dependency.

CPU架構(gòu)

再繼續(xù)探討IPC之前有必要先了解一下CPU的體系結(jié)構(gòu)， 以Haswell （和Broadwell同一個架構(gòu)， 更小的制程） 為例：

CPU是流水線工作的， 前半部分可以稱為front end， 功能主要包括取指， 譯碼等， 在這個圖中IDQ及其前面的部分就是front end. 譯碼其實是個很費時間的步驟， 因為x86是外表是CISC架構(gòu)， 支持變長的指令， 內(nèi)部其實更像RISC架構(gòu)， 所以需要把這些宏指令（也就是匯編指令）轉(zhuǎn)化為微指令（micro ops/uops）。 對于Broadwell， IDQ的最大帶寬是4 uops/cycle， Skylake的帶寬可以到6 uops/cycle. 關(guān)于譯碼的作用， 可以參考A JOURNEY IN MODERN COMPUTER ARCHITECTURES

back end自然指的就是IDQ后面的部分。 Broadwell （Skylake也一樣） 的scheduler最大輸入是4 uops/cycle. 考慮到有的指令比如nop， xor rax，rax等在rename階段就結(jié)束， 并且這類指令的IPC同樣只能到4 uops/cycle， 可以確定rename的帶寬只有4 uops/cycle， 那是不是剛好說明最大IPC是4呢？

執(zhí)行單元（port）總共有8個， 其中4個p0156能執(zhí)行ALU操作， 注意能執(zhí)行branch的只有2個p06. scheduler最多可以調(diào)度8 uops/cycle.

micro/macro fusion

如果沒有fusion， 可以認為4 uops/cycle就是IPC的最大值， 并且前面的測試代碼已經(jīng)做到了。

micro fusion. 因為CPU的執(zhí)行單元是類RISC， 所以一條instruction有可能需要拆成2條或者多條uops. 比如store， 就需要2條uops， 一個store address （上圖中STA）， 一個store data （STD）。 micro fusion把這2條uops合并成一個uops， 雖然在執(zhí)行時又分成2個uops. 關(guān)于micro fusion的decoder的影響同樣可以參考Decoding x86： From P6 to Core 2 - Part 2. 利用好micro fusion能提升程序的效率， 但micro fusion不會提升最大IPC.

macro fusion. 如果相鄰的2條instruction符合某種條件， macro fusion會把它們合并成一個uops， 在執(zhí)行的時候也不會再拆成2個。 很顯然macro fusion是有可能提高max IPC的。 上面已經(jīng)了解到， 整個CPU執(zhí)行棧的瓶頸在rename階段只能處理4個uops， 既然一個uops可以包含2條指令， 不就可以處理更多的instruction了嗎？ 答案是肯定的。 macro fusion的條件主要包括：

第一條指令是CMP， TEST， ADD， SUB， AND， INC， DEC

第二條指令是conditional branch

天空在哪

上面macro fusion的討論中已知1 uops可以包含2 instructions， 那是不是可以簡單計算得到max IPC = 4 * 2？ 上面已經(jīng)說過， 8個port中只有2個是支持branch的， 而macro fusion中必須包含branch， 所以max IPC = 6. 還有一個問題是以后IPC還會不會漲， 為什么呢？

來自agner.org的一個例子：

#define ASM_TWO_MICRO_TWO_MACRO（in1， sum1， in2， sum2， max） __asm volatile （“1： ” “add （%［IN1］）， %［SUM1］ ” “cmp %［MAX］， %［SUM1］ ” “jae 2f ” “add （%［IN2］）， %［SUM2］ ” “cmp %［MAX］， %［SUM2］ ” “jb 1b ” “2：” ： ［SUM1］ “+&r” （sum1）， ［SUM2］ “+&r” （sum2） ： ［IN1］ “r” （in1）， ［IN2］ “r” （in2）， ［MAX］ “r” （max）） +----------------------------+---------+--------------+| Event | Counter | Core 1 |+----------------------------+---------+--------------+| Runtime （RDTSC） ［s］ | TSC | 4.038255e-01 || UOPS_ISSUED_ANY | PMC0 | 4000147000 || UOPS_EXECUTED_CORE | PMC1 | 6000580000 || UOPS_RETIRED_ALL | PMC2 | 6000100000 || BR_INST_RETIRED_NEAR_TAKEN | PMC3 | 1000001000 || INSTR_RETIRED_ANY | FIXC0 | 6000005000 || CPU_CLK_UNHALTED_CORE | FIXC1 | 1003127000 || CPU_CLK_UNHALTED_REF | FIXC2 | 1003129000 |+----------------------------+---------+--------------+

性能調(diào)試

指令相關(guān)的性能調(diào)試大框架可以參考Intel優(yōu)化手冊的方法

本文目的

本文通過有意構(gòu)造出來的理想代碼， 從CPU角度分析IPC產(chǎn)生的原因。 雖然這些代碼在生產(chǎn)環(huán)境中出現(xiàn)的可能性很小， 但是通過分析這些極端情況， 不只了解了CPU的極限在哪， 分析過程本身也很有意義。 那么我們是不是可以去嘗試回答這些問題： 為什么超線程這么不給力？ Xeon E5-2682相比E5-2630有哪些改進？ CPU使用率都100%了還有提高空間嗎？ IPC還會增長嗎？

責(zé)任編輯：YYX