IPC的意義

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

首先來看一個(gè)簡單的測(cè)試程序：

# 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

可以看到， 這個(gè)優(yōu)化效果非常好， IPC從0.63上升到了2.12， 同時(shí)CPU執(zhí)行cycles也相應(yīng)地從2，145，851，708下降到了632，338，513. 不過指令條數(shù)基本上沒有變化， 如果再看匯編代碼， 就會(huì)發(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

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

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

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

沒必要的事情不做

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

指令并發(fā)

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

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

飛得更高

既然IPC可以接近3， 那么還能不能再高點(diǎn)？ 我們看2個(gè)測(cè)試， alu.c 和 nop.c， 測(cè)試運(yùn)行在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個(gè)nop操作 “nop”）; } } $gcc nop.c -o nop 8，577，428，850 instructions # 3.66 insns per cycle

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

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

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

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

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

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

這里使用了一個(gè)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ū)別， 因?yàn)橹挥挟?dāng)一個(gè)cycle中沒有issue/execute任何一條指令的時(shí)候才計(jì)算， 對(duì)于這個(gè)測(cè)試用例是很少發(fā)生的。 測(cè)試發(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不能夠及時(shí)把指令發(fā)給RAT （Resource Allocation Table）， 這個(gè)通過stalled-cycle-front end是不一定能看出的。 那么一個(gè)無條件jmp指令怎么就能影響到front end， 并且還跟每個(gè)循環(huán)的指令數(shù)相關(guān)？ 按理說所有的micro ops都已經(jīng)在IDQ （Instruction Decode Queue）中， 并且LSD （Loop Stream Detector）應(yīng)該完全能夠cover住這幾條指令。 具體原因暫時(shí)還不清楚， 如果知道這個(gè)了， 也許就有了另外一個(gè)問題的答案， 為什么是3.84而不是3.75或者別的呢？

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

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

CPU架構(gòu)

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

CPU是流水線工作的， 前半部分可以稱為front end， 功能主要包括取指， 譯碼等， 在這個(gè)圖中IDQ及其前面的部分就是front end. 譯碼其實(shí)是個(gè)很費(fèi)時(shí)間的步驟， 因?yàn)閤86是外表是CISC架構(gòu)， 支持變長的指令， 內(nèi)部其實(shí)更像RISC架構(gòu)， 所以需要把這些宏指令（也就是匯編指令）轉(zhuǎn)化為微指令（micro ops/uops）。 對(duì)于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個(gè)， 其中4個(gè)p0156能執(zhí)行ALU操作， 注意能執(zhí)行branch的只有2個(gè)p06. scheduler最多可以調(diào)度8 uops/cycle.

micro/macro fusion

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

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

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

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

第二條指令是conditional branch

天空在哪

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

來自agner.org的一個(gè)例子：

#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)化手冊(cè)的方法

本文目的

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

責(zé)任編輯：YYX