您是否通常将编译器设置为针对最大速度或最小代码大小进行优化?或者您手动配置个别优化设置?为什么呢?
我注意到大多数时候人们倾向于将编译器优化设置保留为默认状态,而使用visual c ++意味着最大速度。 我一直认为默认设置更多地与基准测试相关,基准测试往往是完全适合L2缓存的小程序,而不是整体性能最佳,因此我通常将其设置为最小尺寸。
答案 0 :(得分:6)
作为一名Gentoo用户,我在整个操作系统上尝试了很多优化,并且Gentoo forums对此进行了无休止的讨论。 GCC的一些好标志可以在wiki中找到。
简而言之,优化尺寸在有限RAM的旧Pentium3笔记本电脑上运行效果最佳,但在我的主机台式机上使用Core2Duo,-O2可以获得更好的效果。
如果您对最优化的x86(32位)特定标志感兴趣,还有一个small script。
如果您使用gcc并且确实想要优化特定应用,请尝试ACOVEA。它运行一组基准测试,然后使用编译标志的所有可能组合重新编译它们。在网站上有一个使用霍夫曼编码的例子(越低越好):
A relative graph of fitnesses:
Acovea Best-of-the-Best: ************************************** (2.55366)
Acovea Common Options: ******************************************* (2.86788)
-O1: ********************************************** (3.0752)
-O2: *********************************************** (3.12343)
-O3: *********************************************** (3.1277)
-O3 -ffast-math: ************************************************** (3.31539)
-Os: ************************************************* (3.30573)
(请注意,它发现-Os在这个Opteron系统上是最慢的。)
答案 1 :(得分:2)
我更喜欢使用最小尺寸。内存可能很便宜,缓存不是。
答案 2 :(得分:2)
除了缓存局部性很重要(正如On Freund所说),微软所做的另一件事是分析他们的应用程序并找出在启动的前几秒内执行的代码路径。之后,他们将这些数据反馈给编译器,并要求它将启动期间执行的部分放在一起。这样可以缩短启动时间。
我确实相信这种技术可以在VS中公开获得,但我并不是百分之百确定。
答案 3 :(得分:1)
对我而言,这取决于我正在使用的平台。对于某些嵌入式平台或当我使用Cell处理器时,您会遇到限制,例如非常小的缓存或为代码提供的最小空间。
我使用GCC并倾向于将其留在“-O2”,这是“最安全”的优化级别,并且有利于速度超过最小尺寸。
我认为除非您正在开发一个非常高性能的应用程序,否则它可能没有太大的区别,在这种情况下,您可能应该针对您的特定用例对各种选项进行基准测试。
答案 4 :(得分:1)
Microsoft发布了针对大小优化的所有C / C ++软件。基准测试后,他们发现它实际上提供了更好的速度(由于缓存局部性)。
答案 5 :(得分:1)
有许多类型的优化,最大速度与小代码只是一种。在这种情况下,我会选择最大速度,因为可执行文件会稍微大一些。 另一方面,您可以针对特定类型的处理器优化应用程序。在某些情况下,这是一个好主意(如果您打算仅在您的工作站上运行程序),但在这种情况下,该程序很可能无法在其他架构上运行(例如:您编译程序以在Pentium上运行) 4机器 - >它可能不适用于奔腾3)。
答案 6 :(得分:1)
构建两个,配置文件,选择哪个在特定项目和硬件上更好。
对于性能关键代码,即 - 否则选择任何代码并且不要打扰。
答案 7 :(得分:0)
我们总是使用最大化来获得最佳速度,但是,我在C ++中编写的所有代码都与生物信息学算法有某种关系,速度至关重要,而代码大小相对较小。
答案 8 :(得分:0)
现在内存很便宜:)所以除非你使用嵌入式系统,否则将编译器设置设置为最大速度会很有意义。当然答案取决于具体情况。
答案 9 :(得分:0)
这取决于您的程序的应用程序。编程应用程序以控制快速工业过程时,优化速度是有意义的。在编写仅需要对用户输入作出反应的应用程序时,优化大小可能是有意义的。也就是说,如果您担心可执行文件的大小。
答案 10 :(得分:0)
调整这样的编译器设置是一种优化。根据“过早优化是所有邪恶的根源”的原则,我不打扰它,直到程序接近其最终运输状态,并且我发现它不够快 - 即几乎从不。