这是一个创建于 4936 天前的主题，其中的信息可能已经有所发展或是发生改变。
内存？cpu？还是硬盘？......
*瓶颈* 当然是指木桶最短的那一板或飞行中队里最慢的那架飞机
*瓶颈* 当然是指木桶最短的那一板或飞行中队里最慢的那架飞机
 |
1
meecle 2011-05-05 14:15:03 +08:00
肯定是优化哦，单纯说编译速度，应该没有用，现在的编译器主要是在优化方面耗时！ 当然什么分布式编译，其实也没有解决根本的问题，到最后，还是在编译优化方面！
|
|
2
meecle 2011-05-05 14:17:38 +08:00
LLVM这个很赞哦！ 苹果支持的开源项目。主要的目的，也就是解决编译器后端复杂的优化算法！
|
 |
3
obiwong OP  1
@meecle 编译器没法换，只能用gcc，llvm不支持。
可以这样理解：编译器干的是把磁盘上一种形式的数据转换成另一种形式的工作，不仅运算量大，io吞吐量也大。这里就分别涉及到cpu的频率，cpu缓存，内存频率，内存大小，硬盘转速，硬盘缓存等等因素。我现在想要弄清楚的是哪一个环节是编译速度的瓶颈。 我记得12年前电脑爱好者有一篇关于金钻硬盘的评测，其中有一项是用vc5测试7200转较5400转对编译性能的影响，得到的结论是能明显提高编译速度。但类似的评测我现在没找着。 |
 |
4
seerhut 2011-05-05 19:13:50 +08:00
瓶颈会变的。
用ramdisk代替磁盘进行编译时c项目的加速比明显大于c++项目，因为cpp的编译更耗cpu。 对一个大项目进行开机后第一次编译时1G内存和4G内存也没有多大差别，但是在编译一次就完全不一样了。。。 打开关闭优化选项会导致时差很大。 一定要找个瓶颈的话，我认为最主要的瓶颈是cpu/core的数量 :D |
 |
5
Jet 2011-05-05 19:27:16 +08:00
大多是堆栈大小和IO，最短的那一块应该是 CPU Cache 的大小，不过这不能算是瓶颈。
代码的复杂度也是会影响gcc的编译速度的（优化选项）。 |
|
6
obiwong OP |
|
7
meecle 2011-05-06 10:42:19 +08:00
|
|
8
Jet 2011-05-06 12:43:28 +08:00
@obiwong 堆内存和栈内存。
对于 C 的变量有两种分配方式，大概是除 malloc 以外部分都分到栈内存，而这部分优化空间最高，分析也就最慢。 补充一下，关于最短一块是CPU Cache，是因为编译过程需要很大的暂存空间，有很大的调度量。其实主要还是内存分配上，需要一些编程技巧来避免编译过程中需要过大的暂存（例如函数不要写得过长过大），基本上对编译是有「加速」作用。 另外忘了说，还有库的调用（.h）本身对于磁盘IO的考验也非常大，甚至是最大的，因为调用一个头文件，头文件里面估计又会包含无数个obj。这里本身已经不是在编译一个文件而是编译无数个文件然后 link 起来 |
|
9
obiwong OP @meecle 相对于换编译器，升级硬件是相当安全的方法了。我有一朋友曾经遇到让他愁掉无数头发的因编译器升级一个小版本而导致编出来的程序运行不正常的问题。换编译器是要冒很大风险的。
ps 我想起了一个和优化有关的漫画: http://blog.xiqiao.info/2010/10/20/829 @Jet malloc和编译器没什么关系，这部分管理是由操作系统和库来完成的。函数写得短小是为了获取在运行时更高的命中率吧，而不是提高编译速度。 gcc用gch来优化预编译速度。 |
|
10
meecle 2011-05-06 18:41:26 +08:00
@obiwong 那个漫画很有意思！生产力决定一切！
下面和编译器无关了： 当然也可以反过来说：如果大家花十分之一的升级硬件的钱去资助开发，然后，大家就可以再用十分之一的钱来使用开发的技术！这何尝不是好事呢？我想这样的列子也很多吧!也许这就是需求吧！ |
|
11
meecle 2011-05-06 18:47:37 +08:00
不知道什么时候，可以再玩玩可爱的编译器哦！
|
Select Language