為什麼這篇gcc編譯鄉民發文收入到精華區：因為在gcc編譯這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者flypaper (一直飛)看板C_and_CPP標題[閒聊] 為什麼llvm的效能比gcc差時...
肥宅 我翻了幾篇文章
好像都說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
推 alan23273850: 這問題太專業，推一個 02/02 21:49
→ Lipraxde: 那幾篇文章是那幾篇？我也想看看，能提供嗎？ 02/02 22:09
聽大大說完 仔細看看才發現都是引用 phoronix這個網站的文章e.g https://goo.gl/c4NTuv
→ stupid0319: llvm的webassembly確實還跟gcc原生程式有一段差距 02/02 22:17
原來還有這點→ Lipraxde: 可能codegen輸了一些吧，那部分還沒看完不是很肯定 02/02 23:29
推 longlongint: ㄖㄨㄍ 02/03 00:42
→ longlongint: 如果gcc又沒彈性效能又差就沒人要用了（馬後炮XD 02/03 00:42
→ alan23273850: 所以原PO如果發現改成graph coloring就能跟gcc比的 02/03 02:24
不用graph coloring 是因為編譯太慢阿→ alan23273850: 話是不是就可以生一篇 paper 了ㄋ 02/03 02:24
推 suhorng: 你貼的文章結論明明是 "LLVM Clang performance has come 02/03 04:52
→ suhorng: a long way over the past few years and is generally 02/03 04:53
→ suhorng: on-par with GCC these days, but as these benchmark 02/03 04:54
→ suhorng: results show, there still are many cases where the 02/03 04:54
→ suhorng: GNU Compiler Collection can offer a measurable 02/03 04:54
→ suhorng: advantage over Clang for the performance of generated 02/03 04:54
→ suhorng: binaries from C/C++." XD 02/03 04:54
可是這樣不是只是說問題出在後端嗎？不過這的確這樣 效能應該沒差太多了吧
推 KanzakiHAria: 據我所知 大部分情況clang編譯速度和執行效能>>>gcc 02/03 09:44
→ KanzakiHAria: clang沒有取代gcc的原因是flag和binary沒有通用 02/03 09:44
→ KanzakiHAria: 至少我自己和學長的經驗都是這樣 能換clang絕對換 02/03 09:45
感謝分享推 suhorng: 沒有說吧, 就是說大致在同一個等級, 不過有些 benchmark 02/03 13:24
→ suhorng: 輸. 他沒特別去分析原因或看是哪樣子類型的程式速度輸 02/03 13:25
→ suhorng: 可能性太多了, 也許是 LLVM 沒有某一個特定的最佳化演算 02/03 13:26
→ suhorng: 法, 跑的 pass 順序跟參數不同導致被最佳化的結果不同 02/03 13:26
→ suhorng: 不一定後端生機器碼的部分 02/03 13:26
好吧 這樣說可以接受※ 編輯: flypaper (1.170.42.236), 02/03/2019 13:41:47
推 final01: 可是我聽到做編譯器的人都說gcc黑科技比較多,蠻多情況是 02/03 22:03
→ final01: 是比clang+llvm好的吧? 02/03 22:04
推 KanzakiHAria: c++11以前我不確定 但是GNU現在人力缺乏到跟不上標 02/04 08:45
→ KanzakiHAria: 準 可能我經驗太少吧 我還沒遇過gcc換clang變慢的 02/04 08:47
→ KanzakiHAria: cpp2017這場有說clang有大量數學base的轉換 02/04 23:24
推 KanzakiHAria: 如果GCC是這兩年變強 那就是我資訊太落後 抱歉 02/04 23:31
→ KanzakiHAria: gcc黑科技應該是指直接對cpu優化這件事吧 02/04 23:37
→ KanzakiHAria: GNU團隊針對蠻多cpu做編譯的人工加速 02/04 23:37
→ KanzakiHAria: 之類的技巧 這個clang因為要轉llvm所以不行使用 02/04 23:38
→ KanzakiHAria: 所以實務上還是要benchmark常用系統硬體 02/04 23:40
→ KanzakiHAria: reddit.com/r/cpp/comments/9or8s1/llvm_vs_gcc/ 02/04 23:42
→ KanzakiHAria: 蠻新的討論串 02/04 23:42
推 firejox: 這只是除法，所以有compile time evaluation 就足夠了03 02/05 00:01
→ firejox: 0 02/05 00:01
推 Sidney0503: 那個討論串看起來是都要混著用了 02/05 22:01
→ Sidney0503: clang-tidy/senertizer/analyer + msvc + gcc 02/05 22:01
→ tinlans: LLVM 後端的最佳化演算法還不能共用，少了 GCC RTL 層級 02/09 04:54
→ tinlans: 的一些最佳化，包括一堆 dirty work 的 combination pass 02/09 04:55
→ tinlans: 都要各個後端自己手刻，這問題之後會改善。我轉行半年了 02/09 04:55
→ tinlans: 不知道現況，但短期內問題的根本都差不多吧。 02/09 04:56
→ tinlans: 平台無關的最佳化，LLVM 其實也因為太年輕，很多東西都 02/09 04:57
→ tinlans: 沒有實作出來，光是 loop unrolling 就有 GCC 能展開但是 02/09 04:57
→ tinlans: LLVM 無法展開的狀況。 02/09 04:57