[閒聊] 為什麼llvm的效能比gcc差

看板C_and_CPP作者 (一直飛)時間5年前 (2019/02/02 19:33), 5年前編輯推噓12(12推 0噓 36→)
留言48則, 10人參與, 5年前最新討論串1/1
肥宅 我翻了幾篇文章 好像都說gcc生出來的code效能比較好(也沒說為什麼 肥宅我實在不懂 這兩個是差在哪裡 llvm 的pass順序不是還可以自己調 更有彈性嗎 我唯一知道的就是 llvm的暫存器分佈是用 linear scan 而不是用理論效能較佳的 graph coloring 有人可以告訴肥宅我嗎 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.170.117.195 ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1549107208.A.0E7.html
推
02/02 21:49, 5年前 , 1F
這問題太專業，推一個
02/02 21:49, 1F
→
02/02 22:09, 5年前 , 2F
那幾篇文章是那幾篇？我也想看看，能提供嗎？
02/02 22:09, 2F
聽大大說完 仔細看看才發現都是引用 phoronix這個網站的文章 e.g https://goo.gl/c4NTuv
→
02/02 22:17, 5年前 , 3F
llvm的webassembly確實還跟gcc原生程式有一段差距
02/02 22:17, 3F
原來還有這點
→
02/02 23:29, 5年前 , 4F
可能codegen輸了一些吧，那部分還沒看完不是很肯定
02/02 23:29, 4F
推
02/03 00:42, 5年前 , 5F
ㄖㄨㄍ
02/03 00:42, 5F
→
02/03 00:42, 5年前 , 6F
如果gcc又沒彈性效能又差就沒人要用了（馬後炮XD
02/03 00:42, 6F
→
02/03 02:24, 5年前 , 7F
所以原PO如果發現改成graph coloring就能跟gcc比的
02/03 02:24, 7F
不用graph coloring 是因為編譯太慢阿
→
02/03 02:24, 5年前 , 8F
話是不是就可以生一篇 paper 了ㄋ
02/03 02:24, 8F
推
02/03 04:52, 5年前 , 9F
你貼的文章結論明明是 "LLVM Clang performance has come
02/03 04:52, 9F
→
02/03 04:53, 5年前 , 10F
a long way over the past few years and is generally
02/03 04:53, 10F
→
02/03 04:54, 5年前 , 11F
on-par with GCC these days, but as these benchmark
02/03 04:54, 11F
→
02/03 04:54, 5年前 , 12F
results show, there still are many cases where the
02/03 04:54, 12F
→
02/03 04:54, 5年前 , 13F
GNU Compiler Collection can offer a measurable
02/03 04:54, 13F
→
02/03 04:54, 5年前 , 14F
advantage over Clang for the performance of generated
02/03 04:54, 14F
→
02/03 04:54, 5年前 , 15F
binaries from C/C++." XD
02/03 04:54, 15F
可是這樣不是只是說問題出在後端嗎？ 不過這的確這樣 效能應該沒差太多了吧
推
02/03 09:44, 5年前 , 16F
據我所知 大部分情況clang編譯速度和執行效能>>>gcc
02/03 09:44, 16F
→
02/03 09:44, 5年前 , 17F
clang沒有取代gcc的原因是flag和binary沒有通用
02/03 09:44, 17F
→
02/03 09:45, 5年前 , 18F
至少我自己和學長的經驗都是這樣 能換clang絕對換
02/03 09:45, 18F
感謝分享
推
02/03 13:24, 5年前 , 19F
沒有說吧, 就是說大致在同一個等級, 不過有些 benchmark
02/03 13:24, 19F
→
02/03 13:25, 5年前 , 20F
輸. 他沒特別去分析原因或看是哪樣子類型的程式速度輸
02/03 13:25, 20F
→
02/03 13:26, 5年前 , 21F
可能性太多了, 也許是 LLVM 沒有某一個特定的最佳化演算
02/03 13:26, 21F
→
02/03 13:26, 5年前 , 22F
法, 跑的 pass 順序跟參數不同導致被最佳化的結果不同
02/03 13:26, 22F
→
02/03 13:26, 5年前 , 23F
不一定後端生機器碼的部分
02/03 13:26, 23F
好吧 這樣說可以接受 ※ 編輯: flypaper (1.170.42.236), 02/03/2019 13:41:47
推
02/03 22:03, 5年前 , 24F
可是我聽到做編譯器的人都說gcc黑科技比較多,蠻多情況是
02/03 22:03, 24F
→
02/03 22:04, 5年前 , 25F
是比clang+llvm好的吧?
02/03 22:04, 25F
推
02/04 08:45, 5年前 , 26F
c++11以前我不確定 但是GNU現在人力缺乏到跟不上標
02/04 08:45, 26F
→
02/04 08:47, 5年前 , 27F
準 可能我經驗太少吧 我還沒遇過gcc換clang變慢的
02/04 08:47, 27F
推
02/04 10:09, 5年前 , 28F
https://godbolt.org/z/pl-A9s gcc 意外的比較會算?
02/04 10:09, 28F
推
02/04 23:23, 5年前 , 29F
02/04 23:23, 29F
→
02/04 23:24, 5年前 , 30F
cpp2017這場有說clang有大量數學base的轉換
02/04 23:24, 30F
推
02/04 23:31, 5年前 , 31F
如果GCC是這兩年變強 那就是我資訊太落後 抱歉
02/04 23:31, 31F
→
02/04 23:37, 5年前 , 32F
gcc黑科技應該是指直接對cpu優化這件事吧
02/04 23:37, 32F
→
02/04 23:37, 5年前 , 33F
GNU團隊針對蠻多cpu做編譯的人工加速
02/04 23:37, 33F
→
02/04 23:38, 5年前 , 34F
之類的技巧 這個clang因為要轉llvm所以不行使用
02/04 23:38, 34F
→
02/04 23:40, 5年前 , 35F
所以實務上還是要benchmark常用系統硬體
02/04 23:40, 35F
→
02/04 23:42, 5年前 , 36F
reddit.com/r/cpp/comments/9or8s1/llvm_vs_gcc/
02/04 23:42, 36F
→
02/04 23:42, 5年前 , 37F
蠻新的討論串
02/04 23:42, 37F
推
02/05 00:01, 5年前 , 38F
這只是除法，所以有compile time evaluation 就足夠了03
02/05 00:01, 38F
→
02/05 00:01, 5年前 , 39F
0
02/05 00:01, 39F
推
02/05 22:01, 5年前 , 40F
那個討論串看起來是都要混著用了
02/05 22:01, 40F
→
02/05 22:01, 5年前 , 41F
clang-tidy/senertizer/analyer + msvc + gcc
02/05 22:01, 41F
→
02/09 04:54, 5年前 , 42F
LLVM 後端的最佳化演算法還不能共用，少了 GCC RTL 層級
02/09 04:54, 42F
→
02/09 04:55, 5年前 , 43F
的一些最佳化，包括一堆 dirty work 的 combination pass
02/09 04:55, 43F
→
02/09 04:55, 5年前 , 44F
都要各個後端自己手刻，這問題之後會改善。我轉行半年了
02/09 04:55, 44F
→
02/09 04:56, 5年前 , 45F
不知道現況，但短期內問題的根本都差不多吧。
02/09 04:56, 45F
→
02/09 04:57, 5年前 , 46F
平台無關的最佳化，LLVM 其實也因為太年輕，很多東西都
02/09 04:57, 46F
→
02/09 04:57, 5年前 , 47F
沒有實作出來，光是 loop unrolling 就有 GCC 能展開但是
02/09 04:57, 47F
→
02/09 04:57, 5年前 , 48F
LLVM 無法展開的狀況。
02/09 04:57, 48F
‣ 更多 flypaper 的文章
文章代碼(AID): #1SLO083d (C_and_CPP)