作者flypaper (一直飞)
看板C_and_CPP
标题[闲聊] 为什麽llvm的效能比gcc差
时间Sat Feb 2 19:33:23 2019
肥宅 我翻了几篇文章
好像都说gcc生出来的code效能比较好(也没说为什麽
肥宅我实在不懂
这两个是差在哪里
llvm 的pass顺序不是还可以自己调 更有弹性吗
我唯一知道的就是 llvm的暂存器分布是用 linear scan
而不是用理论效能较佳的 graph coloring
有人可以告诉肥宅我吗
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.170.117.195
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1549107208.A.0E7.html
1F：推 alan23273850: 这问题太专业，推一个 02/02 21:49
2F：→ Lipraxde: 那几篇文章是那几篇？我也想看看，能提供吗？ 02/02 22:09
听大大说完 仔细看看才发现都是引用 phoronix这个网站的文章
e.g
https://goo.gl/c4NTuv
3F：→ stupid0319: llvm的webassembly确实还跟gcc原生程式有一段差距 02/02 22:17
原来还有这点
4F：→ Lipraxde: 可能codegen输了一些吧，那部分还没看完不是很肯定 02/02 23:29
5F：推 longlongint: ㄖㄨㄍ 02/03 00:42
6F：→ longlongint: 如果gcc又没弹性效能又差就没人要用了（马後炮XD 02/03 00:42
7F：→ alan23273850: 所以原PO如果发现改成graph coloring就能跟gcc比的 02/03 02:24
不用graph coloring 是因为编译太慢阿
8F：→ alan23273850: 话是不是就可以生一篇 paper 了ㄋ 02/03 02:24
9F：推 suhorng: 你贴的文章结论明明是 "LLVM Clang performance has come 02/03 04:52
10F：→ suhorng: a long way over the past few years and is generally 02/03 04:53
11F：→ suhorng: on-par with GCC these days, but as these benchmark 02/03 04:54
12F：→ suhorng: results show, there still are many cases where the 02/03 04:54
13F：→ suhorng: GNU Compiler Collection can offer a measurable 02/03 04:54
14F：→ suhorng: advantage over Clang for the performance of generated 02/03 04:54
15F：→ suhorng: binaries from C/C++." XD 02/03 04:54
可是这样不是只是说问题出在後端吗？
不过这的确这样 效能应该没差太多了吧
16F：推 KanzakiHAria: 据我所知 大部分情况clang编译速度和执行效能>>>gcc 02/03 09:44
17F：→ KanzakiHAria: clang没有取代gcc的原因是flag和binary没有通用 02/03 09:44
18F：→ KanzakiHAria: 至少我自己和学长的经验都是这样 能换clang绝对换 02/03 09:45
感谢分享
19F：推 suhorng: 没有说吧, 就是说大致在同一个等级, 不过有些 benchmark 02/03 13:24
20F：→ suhorng: 输. 他没特别去分析原因或看是哪样子类型的程式速度输 02/03 13:25
21F：→ suhorng: 可能性太多了, 也许是 LLVM 没有某一个特定的最佳化演算 02/03 13:26
22F：→ suhorng: 法, 跑的 pass 顺序跟参数不同导致被最佳化的结果不同 02/03 13:26
23F：→ suhorng: 不一定後端生机器码的部分 02/03 13:26
好吧 这样说可以接受
※ 编辑: flypaper (1.170.42.236), 02/03/2019 13:41:47
24F：推 final01: 可是我听到做编译器的人都说gcc黑科技比较多,蛮多情况是 02/03 22:03
25F：→ final01: 是比clang+llvm好的吧? 02/03 22:04
26F：推 KanzakiHAria: c++11以前我不确定 但是GNU现在人力缺乏到跟不上标 02/04 08:45
27F：→ KanzakiHAria: 准 可能我经验太少吧 我还没遇过gcc换clang变慢的 02/04 08:47
30F：→ KanzakiHAria: cpp2017这场有说clang有大量数学base的转换 02/04 23:24
31F：推 KanzakiHAria: 如果GCC是这两年变强 那就是我资讯太落後 抱歉 02/04 23:31
32F：→ KanzakiHAria: gcc黑科技应该是指直接对cpu优化这件事吧 02/04 23:37
33F：→ KanzakiHAria: GNU团队针对蛮多cpu做编译的人工加速 02/04 23:37
34F：→ KanzakiHAria: 之类的技巧 这个clang因为要转llvm所以不行使用 02/04 23:38
35F：→ KanzakiHAria: 所以实务上还是要benchmark常用系统硬体 02/04 23:40
36F：→ KanzakiHAria: reddit.com/r/cpp/comments/9or8s1/llvm_vs_gcc/ 02/04 23:42
37F：→ KanzakiHAria: 蛮新的讨论串 02/04 23:42
38F：推 firejox: 这只是除法，所以有compile time evaluation 就足够了03 02/05 00:01
39F：→ firejox: 0 02/05 00:01
40F：推 Sidney0503: 那个讨论串看起来是都要混着用了 02/05 22:01
41F：→ Sidney0503: clang-tidy/senertizer/analyer + msvc + gcc 02/05 22:01
42F：→ tinlans: LLVM 後端的最佳化演算法还不能共用，少了 GCC RTL 层级 02/09 04:54
43F：→ tinlans: 的一些最佳化，包括一堆 dirty work 的 combination pass 02/09 04:55
44F：→ tinlans: 都要各个後端自己手刻，这问题之後会改善。我转行半年了 02/09 04:55
45F：→ tinlans: 不知道现况，但短期内问题的根本都差不多吧。 02/09 04:56
46F：→ tinlans: 平台无关的最佳化，LLVM 其实也因为太年轻，很多东西都 02/09 04:57
47F：→ tinlans: 没有实作出来，光是 loop unrolling 就有 GCC 能展开但是 02/09 04:57
48F：→ tinlans: LLVM 无法展开的状况。 02/09 04:57