c++ - gcc/C++ : If CPU load is low, 那么代码优化没什么用，对吗？

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 处发出非常简单的代码，并在 2016 年在 -O1 和 - 处进行几乎“标准”的那种优化。 O2。通常希望您将这些打开以供生产使用，否则您将浪费现代编译器功能的很大一部分。

许多人也倾向于不在发布版本中使用 -g，这样部署的二进制文件更小，更容易让您的客户处理。通过执行此操作，您可以将 45MB 的可执行文件减少到 1MB，无需零钱。

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

但是如果bug不能按需重现，或者只能在release build中重现，那你可能就有问题了。因此，在 (-O1) 上保持基本优化但同时在 (-g) 中保持调试符号似乎是合理的；优化本身不应极大地妨碍您分析客户提供的核心转储的能力，调试符号将使您能够将信息与源代码相关联。

话虽这么说，您也可以吃蛋糕:

• 使用 -O2 -g 构建您的应用程序>
• 复制生成的二进制文件
• 对其中一个拷贝执行strip，以删除调试符号；否则二进制文件将是相同的
• 永远保存它们
• 部署剥离版本
• 当您有要分析的核心转储时，针对原始的、未剥离的版本对其进行调试

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