※ 引述《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://webptt.com/m.aspx?n=bbs/CompilerDev/M.1652670539.A.991.html