推 VF84: 是說 LLVM 有個東西叫 MCA,我沒用過,但看描述,感覺應該可05/04 08:42
→ VF84: 以幫到你?05/04 08:42
謝謝,我都忘記還有這個東西了。
用 llvm-mca 分析一下,並用 bottleneck-analysis 分析,發現 O3 的 data-dependency
比較重,研判可能跟 cse 有關:資料在程式碼初期計算好,並存放在 register 內,
之後的運算需要使用到它,就需要去存取這個 register 等等...
為了驗證這個部分,我把 cse 後的程式碼還原回去,再用 llvm-mca 跑一次分析,
確實 register-dependency 下降了、時間也降下來了。
我自己得到的結論是:O3 可以有效降低指令的執行數量,但有可能因此增加 data-depende
ncy,
會變差。
※ 編輯: shane87123 (1.160.189.98 臺灣), 05/04/2022 11:59:19
推 VF84: 那為什麼有 data dependency 就會跑比較慢呢?因為05/04 12:54
→ VF84: pipeline 會 stall 嗎?05/04 12:54
謝謝你抽空跟我一起討論。看過你的提問後,我在近一步分析。
我猜測 data dependency 應該是出在 C code 中的 a = a * call
(另一份的是 a = a * foo( rem % 5 )
我去做了 time-line 的分析
llvm-mca -timeline more.s
llvm-mca -timeline less.s
根據 llvm-mca 文件提到的:當指令在排班器的 ready 狀態的時間與在排班器的總時間相比越少的話,data dependency 越高,Latency也比較高
(https://llvm.org/docs/CommandGuide/llvm-mca.html#timeline-view)
所以我去看了那個乘法指令的狀態,大致上如下:
[1]: 在排班器裡面的時間
[2]: 在排班器且為 ready 的時間
[3]: 總共耗費的時間
less.s (我認為應該比較快但沒有比較快的)
[1] [2] [3]
90.4 0.5 36.2 imull %ebp, %eax
more.s
[1] [2] [3]
112.1 1.0 31.8 imull %r14d, %eax
我去算了一下比例:
less.s 的比例:0.5 / 90.4*100% = 0.56%
more.s 的比例:1 / 112.1 * 100% = 0.89%
表示 less.s 的乘法因 data dependency 而 latency 比較嚴重
至於 more.s 的乘法運算之前應該還有 callq foo 這個指令,應該會很慢才對,
但 llvm-mca 有提到,面對 call function 準確度不高,加上我原文提及,more.c 比較快
的原因是因為傳入 foo 的參數為0,會
直接 return 1,所以我覺得 call foo 實際執行時間應該很短
換成傳入2以上的話應該就會比較慢了
※ 編輯: shane87123 (49.216.29.37 臺灣), 05/04/2022 14:43:08
※ 編輯: shane87123 (49.216.29.37 臺灣), 05/04/2022 14:44:32
※ 編輯: shane87123 (49.216.29.37 臺灣), 05/04/2022 14:45:54
※ 編輯: shane87123 (49.216.29.37 臺灣), 05/04/2022 14:46:48
※ 編輯: shane87123 (49.216.29.37 臺灣), 05/04/2022 14:49:12
推 VF84: 感謝分享 05/04 17:47
推 VF84: 其實你後面那一串分析我就跟不上了XD,所以沒辦法給出更多的 05/04 23:06
→ VF84: 想法,這裡就留給更厲害的大大吧05/04 23:06
※ 編輯: shane87123 (1.160.189.98 臺灣), 05/05/2022 01:22:46
→ Lipraxde: 文章應該是說 long data dependencies 會使 ILP 變糟,05/05 06:06
→ Lipraxde: 跟你轉換過的說法有些不太一樣?05/05 06:06
謝謝你提醒我ILP,我昨天看文章沒看到這塊
所以我後來有做另一個實驗
就是我把兩份程式碼用單一核心去跑
發現less比more快了
→ Lipraxde: 「然而在 "insn per cycle" 則直接輸給了 more.c,導致05/05 06:13
→ Lipraxde: 實際 cycles 數量 less.c 比 more.c 還要多」<- 因果關05/05 06:13
→ Lipraxde: 係怪怪的,而且因為 more 有更多 cycle 短的指令去攤平05/05 06:13
→ Lipraxde: insn per cycle,比較 insn per cycle 不合適。05/05 06:13
我認為的因果關係是這樣:
1. less比more多data dependency導致ILP更差
2. ILP變差,導致在多核心運算時,less的IPC比more還低
3. 多核運算中,速度上 less 比more 慢
4. 單一核心運算中,more失去了ILP比較好的優勢,而less指令比較少的優勢還在,所以單
核運算less比more快
雖然比較IPC好像真的不合適,因為他應該是從cycles和指令數量去逆推IPC
但我想不到更好的因果關係去說明這件事情OTZ
※ 編輯: shane87123 (101.12.17.166 臺灣), 05/05/2022 12:36:56
※ 編輯: shane87123 (101.12.17.166 臺灣), 05/05/2022 12:40:10
推 xam: 專題生嗎? 05/15 05:38
→ Lipraxde: 單核跟多核比能造成影響的因素蠻多的...通常可以先考慮 05/15 16:20
→ Lipraxde: 差異的量級再針對可能的原因找 05/15 16:20
→ Lipraxde: 還有個方式是換舊舊的 CPU,比較不用考慮特殊的因素XD 05/15 16:22