gcc编译（有时）导致cpu欠载 [英] gcc compilations (sometimes) result in cpu underload
问题描述
我有一个更大的C ++程序，首先读取成千上万的小文本文件到内存和存储数据在stl容器。这需要大约一分钟。周期性地，编译将展示程序的初始部分将在大约22-23％CPU负载下运行的行为。一旦该步骤结束，它会回到〜100％的CPU。它更可能发生与O2标志开启但不是始终如一。它发生甚至更少与-p标志，这使得几乎不可能配置文件。我捕获它一次，但gprof输出没有帮助 - 一切运行相同的相对速度只是在低CPU使用率。
I have a larger C++ program which starts out by reading thousands of small text files into memory and storing data in stl containers. This takes about a minute. Periodically, a compilation will exhibit behavior where that initial part of the program will run at about 22-23% CPU load. Once that step is over, it goes back to ~100% CPU. It is more likely to happen with O2 flag turned on but not consistently. It happens even less often with the -p flag which makes it almost impossible to profile. I did capture it once but the gprof output wasn't helpful - everything runs with the same relative speed just at low cpu usage.
我确定这与多核无关。我有一个四核CPU，并且大多数代码是多线程的，但我测试了这个问题运行单线程。此外，当我在多个线程中运行有问题的步骤时，每个线程只运行在〜20％的CPU。
I am quite certain that this has nothing to do with multiple cores. I do have a quad-core cpu, and most of the code is multi-threaded, but I tested this issue running a single thread. Also, when I run the problematic step in multiple threads, each thread only runs at ~20% CPU.
我提前为这个问题的模糊性道歉，但是我没有提供进一步解决问题的想法，所以任何提示可能会有帮助。
I apologize ahead of time for the vagueness of the question but I have run out of ideas as to how to troubleshoot it further, so any hints might be helpful.
更新：为了确保清楚，代码有问题的部分有时（约30-40％的编译）运行在100％的CPU，因此难以购买I / O是瓶颈的（否则合理的）参数
UPDATE: Just to make sure it's clear, the problematic part of the code does sometimes (~30-40% of the compilations) run at 100% CPU, so it's hard to buy the (otherwise reasonable) argument that I/O is the bottleneck
推荐答案
em>
我的猜测是，您看到的是 Linux 缓冲区缓存
这些成千上万的文件将需要很长时间才能从磁盘读取，CPU将主要在等待旋转和寻找延迟。报告的CPU使用时间将以百分比表示。
Those thousands of files will take a long time to read in from the disk and the CPU will mostly be waiting on rotational and seek latencies. Reported CPU-time used will be low expressed as a percentage. (But probably greater overall.)
但是一旦读取，这些小文件被完全缓存在内存中，访问每个文件（在后续运行中）变成一个纯粹的CPU绑定活动。
But once read, those small files are completely cached in memory and accessing each file (in subsequent runs) becomes a purely CPU-bound activity.
块是否保留在缓存中取决于中间活动，例如重新编译。当运行新程序和读取其他文件时，程序和文件将被缓存，旧块将被丢弃，显然，内存密集型工作负载也将清除缓冲区缓存。
Whether the blocks remain in the cache depends on intervening activity, such as recompiles. When new programs are run and other files are read, the programs and the files will be cached and old blocks will be dropped, and obviously, memory-intensive workload will also clear out the buffer cache.
这篇关于gcc编译（有时）导致cpu欠载的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
