c++ - gcc 编译(有时)导致 cpu 负载不足

Question

我有一个更大的 C++ 程序，它首先将数千个小文本文件读入内存并将数据存储在 STL 容器中。这大约需要一分钟。周期性地，编译将表现出程序的初始部分将以大约 22-23% 的 CPU 负载运行的行为。一旦该步骤结束，它就会回到 ~100% CPU。 O2 标志打开时更有可能发生，但并非始终如一。使用 -p 标志时，这种情况发生的频率更低，这使得几乎不可能进行概要分析。我确实捕获了一次，但 gprof 输出没有帮助——一切都以相同的相对速度运行，只是在 cpu 使用率较低的情况下。

我很确定这与多核无关。我确实有一个四核 cpu，而且大部分代码都是多线程的，但我在运行单线程时测试了这个问题。此外，当我在多个线程中运行有问题的步骤时，每个线程仅以 ~20% 的 CPU 运行。

对于这个问题的含糊不清，我提前表示歉意，但我已经想不出如何进一步解决它的问题，所以任何提示都可能有所帮助。

更新:只是为了确保清楚，代码中有问题的部分有时(约 30-40% 的编译)以 100% CPU 运行，因此很难相信我/O是瓶颈

Answer 1

这是缓冲区缓存

---

我猜您看到的是 Linux buffer cache 的结果运行中。

从磁盘读入这数千个文件需要很长时间，而且 CPU 大部分时间都在等待旋转和寻道延迟。报告的已用 CPU 时间将较低，以百分比表示。 (但总体上可能更大。)

但是一旦读取，这些小文件就会完全缓存在内存中，访问每个文件(在后续运行中)就变成了纯粹的 CPU 绑定(bind)事件。

block 是否保留在缓存中取决于干预事件，例如重新编译。当运行新程序和读取其他文件时，程序和文件将被缓存并丢弃旧 block ，显然，内存密集型工作负载也会清除缓冲区缓存。