gcc/C++：如果CPU负载很低，那么代码优化就没有什么用处了，是吗？

Question

我的同事喜欢使用带有'-g -O0‘的gcc来构建生产二进制文件，因为如果发生核心转储，调试很容易。他说，不需要使用编译器优化或调整代码，因为他发现生产中的进程没有高CPU负载，例如30%左右。

我问他背后的原因，他告诉我:如果CPU负载不高，瓶颈肯定不是我们的代码性能，而应该是一些IO (磁盘/网络)。因此，通过使用gcc，-O2对提高时延和吞吐量是没有用的。此外，这也表明我们在代码中没有太多需要改进的地方，因为CPU不是瓶颈。对吗？

Answer 1

关于CPU使用率~优化

我希望程序中的大多数优化问题都与高于通常的CPU负载相关，因为我们说次优的程序做的事情比理论上需要的多。但是“通常”在这里是一个复杂的词。我不认为你可以选择一个系统范围的CPU负载百分比的硬值，在这个值上优化变得有用。

如果我的程序在一个循环中重新分配char缓冲区，当它不需要这样做时，我的程序可能会比它需要的运行速度慢十倍，我的CPU使用率可能比它需要的高十倍，优化函数可能会使应用程序性能…提高十倍。但CPU使用率仍可能仅为整个系统容量的0.5%。

即使我们选择一个CPU负载阈值来开始分析和优化，在通用服务器上，我也会说30%太高了。但这取决于系统，因为如果你正在为一个只运行你的程序的嵌入式设备编程，并且因为它有足够的电力来运行你的程序而被选中和购买，那么30%在总体方案中可能是相对较低的。

此外，并不是所有的优化问题都与高于平常的CPU负载有关。也许您只是在sleep中等待的时间比实际需要的更长，这会导致消息延迟增加，但却大大减少了CPU的使用率。

tl;dr:你同事的观点过于简单化，可能在任何有用的方面都与现实不符。

关于构建优化级别

然而，与你问题的真正症结相关的是，在部署发布版本时关闭所有编译器优化是相当不寻常的。编译器被设计成在-O0上生成相当幼稚的代码，并进行-O1和-O2在2016年几乎是“标准”的那种优化。通常情况下，您需要将这些功能打开用于生产用途，否则您将浪费现代编译器的大部分功能。

许多人也倾向于在发布版本中不使用-g，这样部署的二进制文件更小，客户更容易处理。通过这样做，您可以将一个45MB的可执行文件减少到1MB，这不是小菜一碟。

这会使调试变得更加困难吗？是的，它可以。通常，如果定位到bug，您希望接收复制步骤，然后可以在应用程序的调试友好版本中重复这些步骤，并分析由此产生的堆栈跟踪。

但是，如果bug不能按需重现，或者它只能在发布版本中重现，那么您可能会有问题。因此，在(-O1)上保留基本优化，同时在(-g)中保留调试符号似乎是合理的；优化本身不应该大大阻碍您分析客户提供的核心转储的能力，调试符号将允许您将信息与源代码相关联。

也就是说，你可以既吃蛋糕又吃蛋糕：

通过在其中一个副本上生成binary

• Perform版本来构建应用程序，以删除调试符号；否则，当您有核心转储要针对原始的非剥离版本

进行分析和调试时，二进制文件将同时显示为

• strip
• 和

您还应该在应用程序中有足够的日志记录，以便能够跟踪大多数错误，而不需要任何这些。

Answer 2

在某些情况下，他可能是正确的，而在其他情况下，他可能是不正确的(而在某些情况下，他是完全正确的)。

如果您假设运行时间为1s，CPU将忙碌0.3s，并等待其他0.7s。如果你优化了代码，说得到了100%的改进，那么CPU将在0.15秒内完成0.3秒的工作，并在0.85秒内完成任务，而不是1秒(考虑到等待其他事情需要同样的时间)。

但是，如果您有多核的情况，CPU负载有时被定义为正在使用的处理能力的数量。因此，如果一个核心以100%的速度运行，而两个核心处于空闲状态，则CPU负载将变为33%，因此在这种情况下，30%的CPU负载可能是由于程序只能使用一个核心造成的。在这种情况下，如果对代码进行优化，它可以极大地提高性能。

请注意，有时被认为是优化的东西实际上是悲观的-这就是为什么测量很重要。我见过一些会降低性能的“优化”。此外，有时优化会改变行为(特别是当您“改进”源代码时)，因此您可能应该通过适当的测试来确保它不会破坏任何东西。在进行性能测量之后，您应该决定是否值得牺牲可调试性来换取速度。

Answer 3

一种可能的改进可能是使用最近的GCC用gcc -Og -g编译。-Og优化是调试器友好的。

此外，您可以使用gcc -O1 -g进行编译；您会得到许多(简单的)优化，因此性能通常是-O2的90% (当然也有一些例外，其中甚至-O3也很重要)。并且core转储通常是可调试的。

这实际上取决于软件的类型以及所需的可靠性和调试简易性。数值编码(HPC)与小数据库后处理有很大的不同。

最后，使用-g3而不是-g可能会有所帮助(例如gcc -Wall -O1 -g3)

顺便说一句，同步问题和死锁可能更可能出现在优化的代码上，而不是非优化的代码上。