是否有任何正在使用的编译器很少注意编译速度,而是寻求最大限度的优化,即使在一个数量级的编译时间慢下来?
在我看来,编译需要花费几个小时/天,而不是分钟/秒,一旦接近最终版本,就不会是一个大问题。(如果你有足够的测试,应该是安全的。)
编辑:我感兴趣的是编译器,它包括一些优化传递,这些程序可能需要几个小时甚至几天的时间才能在一些次要程序上运行(正常优化需要10分钟或更短的时间,例如Linux内核、apache或GCC本身)。
发布于 2010-08-20 18:28:01
实际上,是的。这并不是因为优化器速度慢,而是因为您要求优化器做的事情需要很长时间。例如,我使用LLVM来优化整个程序:已经编译的源文件以及源文件使用的所有库。一切都以中间代码的形式链接在一起,并进行了优化。这种优化比链接单独优化的对象文件要慢得多。但是我不在乎,因为两个原因: 1,优化是在整个程序中完成的,这是值得等待的(;)和2,计算机总是变得更快。
发布于 2010-08-20 18:27:20
在某种程度上,它们是“慢”的,只是计算机速度如此之快,拥有如此庞大的内存,以至于你不像以前那样注意到.
*跑去做一个g++的小实验::
选择一段我为工作而编写的稍微有点粗糙的代码(在75个c++文件中,大约有24k LOC,大量使用了根部库,但没有模板)
-O0
:8.88秒-O4
:13.60秒-Os
:11.32秒嗯.加起来不等于编译时间的很大一部分。也许它只是被文件访问时间所支配。也许我应该尝试一下mplayer
或者其他一些真正密集的东西。
https://stackoverflow.com/questions/3535974
复制