影响Gcc编译速度的瓶颈在哪？

[obiwong]

内存？cpu？还是硬盘？......
*瓶颈* 当然是指木桶最短的那一板或飞行中队里最慢的那架飞机

[meecle]

肯定是优化哦，单纯说编译速度，应该没有用，现在的编译器主要是在优化方面耗时！ 当然什么分布式编译，其实也没有解决根本的问题，到最后，还是在编译优化方面！

[meecle]

LLVM这个很赞哦！ 苹果支持的开源项目。主要的目的，也就是解决编译器后端复杂的优化算法！

[obiwong]

@meecle 编译器没法换，只能用gcc，llvm不支持。
可以这样理解：编译器干的是把磁盘上一种形式的数据转换成另一种形式的工作，不仅运算量大，io吞吐量也大。这里就分别涉及到cpu的频率，cpu缓存，内存频率，内存大小，硬盘转速，硬盘缓存等等因素。我现在想要弄清楚的是哪一个环节是编译速度的瓶颈。

我记得12年前电脑爱好者有一篇关于金钻硬盘的评测，其中有一项是用vc5测试7200转较5400转对编译性能的影响，得到的结论是能明显提高编译速度。但类似的评测我现在没找着。

[seerhut]

瓶颈会变的。
用ramdisk代替磁盘进行编译时c项目的加速比明显大于c++项目，因为cpp的编译更耗cpu。
对一个大项目进行开机后第一次编译时1G内存和4G内存也没有多大差别，但是在编译一次就完全不一样了。。。
打开关闭优化选项会导致时差很大。

一定要找个瓶颈的话，我认为最主要的瓶颈是cpu/core的数量 :D

[Jet]

大多是堆栈大小和IO，最短的那一块应该是 CPU Cache 的大小，不过这不能算是瓶颈。
代码的复杂度也是会影响gcc的编译速度的（优化选项）。

[obiwong]

@seerhut 目前打算ramdisk。cpu/core的数量可以通过distcc解决吧，但这样瓶颈又到net io上去了。

@Jet what堆栈?

@meecle 我对llvm和gcc的优化仅仅停留在一个是面向语义另一个是面向机器（汇编）这个层面上。这两种优化是不冲突且可以叠加的，因此仅从优化方式来看我看不出llmv较gcc有什么速度上的优势。若有错误请指正。

[meecle]

@seerhut瓶颈会变，同意
@obiwong如同@Jet所说 暂时升级硬件可以让大家对编译速度暂时满意。不管怎么样，我们需求是什么？就可以决定瓶颈！
关于编译llvm和GCC的优化： 语义方面，为什么LLVM沿用了GCC，是因为对于现在的语言语义优化是个瓶颈，换句话说，GCC编译器在语义优化方面已经做得很好了。而后端优化一大堆问题，而LLVM的出现让后端优化更可控，且效果不错！

[Jet]

@obiwong 堆内存和栈内存。
对于 C 的变量有两种分配方式，大概是除 malloc 以外部分都分到栈内存，而这部分优化空间最高，分析也就最慢。
补充一下，关于最短一块是CPU Cache，是因为编译过程需要很大的暂存空间，有很大的调度量。其实主要还是内存分配上，需要一些编程技巧来避免编译过程中需要过大的暂存（例如函数不要写得过长过大），基本上对编译是有「加速」作用。
另外忘了说，还有库的调用（.h）本身对于磁盘IO的考验也非常大，甚至是最大的，因为调用一个头文件，头文件里面估计又会包含无数个obj。这里本身已经不是在编译一个文件而是编译无数个文件然后 link 起来

[obiwong]

@meecle 相对于换编译器，升级硬件是相当安全的方法了。我有一朋友曾经遇到让他愁掉无数头发的因编译器升级一个小版本而导致编出来的程序运行不正常的问题。换编译器是要冒很大风险的。
ps 我想起了一个和优化有关的漫画: http://blog.xiqiao.info/2010/10/20/829

@Jet malloc和编译器没什么关系，这部分管理是由操作系统和库来完成的。函数写得短小是为了获取在运行时更高的命中率吧，而不是提高编译速度。

gcc用gch来优化预编译速度。

[meecle]

@obiwong 那个漫画很有意思！生产力决定一切！
下面和编译器无关了：
当然也可以反过来说：如果大家花十分之一的升级硬件的钱去资助开发，然后，大家就可以再用十分之一的钱来使用开发的技术！这何尝不是好事呢？我想这样的列子也很多吧!也许这就是需求吧！

[meecle]

不知道什么时候，可以再玩玩可爱的编译器哦！