Re: [問題] 為何這兩份程式碼的效能差異如此奇特
※ 引述《shane87123 (陽光大肥宅)》之銘言：
: 由於我是在 LLVM IR 最佳化階段發現這個問題，
: 跟編譯器最佳化有關，所以我發在這個版上。
: 這個問題困擾我很久了，想和版上的大大討論一番。
: 由於 LLVM IR 比較難讀，所以我把程式逆推成 C code 來增加可讀性。
: 先附上兩份程式碼的線上 diff:
: https://www.diffchecker.com/Thbx9sDk
: 然後進行這樣編譯：
: opt -S -passes=mem2reg more.ll -o more.ll
: opt -S -passes=mem2reg less.ll -o less.ll
: llc more.ll
: llc less.ll
: ( llc 預設 O2）
: 得到兩份組合語言。線上 diff 如下：
: https://www.diffchecker.com/NV4uuopa
: （可以直接拉到左方組語 85 行 if.end 那裡）
: 其實可以發現，左邊那份程式碼（姑且稱之 less.c）先將 foo(rem % 5) 存起來，
: 只計算了 rem % 5 一次、call foo 一次；
: 右邊的程式碼（more.c） foo(rem % 5) 計算兩次，也就是說 rem % 5 兩次、call foo 兩次，
: 比左邊的程式碼多一次。
: 理論上，應該要比較慢才對，但我用 Linux Perf 跑過一萬次發現，
: 多計算 rem % 5 和 call foo 的反而比較快。
我其實比較好奇這個「比較快」是快幾趴？
因為其實通常差距低於2%我會直接認為是噪音
: perf 中，我可以得知 instruction 數量、cycles 數量等等
: instruction 數量中，less.c 比 more.c 還要少，不過這是可以預料的，
: 畢竟人家就是比他少做運算跟呼叫函數；
: 然而在 "insn per cycle" 則直接輸給了 more.c，導致實際 cycles 數量 less.c 比 more.c
: 還要多，
: 也當然執行時間比較長，但我實在是不明白原因為何。
: 目前的實驗做到以下：
: 1. llc 用 O0 最佳化 -> less.c 比 more.c 更快
: -> 表示 llc 的 O2 對 more.c 那份程式碼有更好的最佳化？
: 但很沒道理，明明多 call 了 function 也多計算了取餘數運算，怎麼會比較快？
: 2. 觀察 foo(rem % 5) 的參數 "rem % 5" 值為多少，發現都是 0
: -> 也就是說，多 call 的 function 都只是進入 function 直接回傳 1
: -> 把該參數改成非 0 則 less.c 比 more.c 更快。
: 但不管如何，還是多呼叫 function 了呀，沒道理參數影響這麼多，
: program counter 跳來跳去，一定會比較慢吧？
: 這問題雖然很實務，但真的很玄，而且困擾我很久。
: 我的老闆（現為碩士生）要我把原因找出來，但我找了一整天，實在是想不到原因。
: 希望有高手能夠幫幫我，拜託了...
我剛剛用 MCA 跑了一下 但沒有分析整個main而是只有while loop body
(如果是less的話是 line 63 ~ 97, more 的話是 line 74 ~ 105)
然後用這個command: llvm-mca -mcpu=skylake -iterations=10000 ...
（我猜你也是在 Skylake 上）
這是 less 的summary：
Iterations: 10000
Instructions: 240000
Total Cycles: 1110005
Total uOps: 920000
Dispatch Width: 6
uOps Per Cycle: 0.83
IPC: 0.22
Block RThroughput: 15.3
而這是 more 的summary:
Iterations: 10000
Instructions: 270000
Total Cycles: 1150003
Total uOps: 990000
Dispatch Width: 6
uOps Per Cycle: 0.86
IPC: 0.23
Block RThroughput: 16.5
IPC 的確比較低，但是老實講差距很小。另外cycle數上less也沒有比較高
雖然這是MCA而不是perf就對了
但我認同你說的關於data dependency所造成的 register pressure的理論
既便實務上我實在不覺得它會變成很嚴重的問題
證據之一就是 MCA 的 bottleneck analysis 也説 data dependency hazard
的比例還蠻低的：
less:
Data Dependencies: [ 0.90% ]
- Register Dependencies [ 0.90% ]
- Memory Dependencies [ 0.00% ]
more:
Data Dependencies: [ 0.87% ]
- Register Dependencies [ 0.87% ]
- Memory Dependencies [ 0.00% ]
兩者相距甚至不到 0.1%
就像前面提過的，遇到這種事情我通常會先問自己：這個問題的scale到底多大？
如果不到2%或甚至不到1%通常我會再三思考該不該把時間花在這上面
別說學術界了，在產業界如果你的performance regression不到5%甚至10%
有些老闆甚至不會同意你的效能優化計畫
話說既然這邊討論到LLVM MCA，在剛剛結束的 EuroLLVM 2022 本魯其實是第一天的
keynote speaker
(https://llvm.swoogo.com/2022eurollvm/agenda)
然後主題就是介紹一個新的、基於LLVM MCA 的工具: MCA Daemon (MCAD)
演講的錄影大概要再幾個月才會上傳 但如果有興趣的話這邊是投影片：
https://tinyurl.com/bdhtsuvk
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 169.234.228.237 (美國)
※ 文章網址: https://www.ptt.cc/bbs/CompilerDev/M.1652670539.A.991.html
推
05/27 17:19,
1年前
, 1F
05/27 17:19, 1F
推
12/06 19:33,
1年前
, 2F
12/06 19:33, 2F
推
01/14 06:15,
2年前
, 3F
01/14 06:15, 3F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 2 篇)：