我可以在核心i7上获得的最大CPU使用量是多少

时间:2014-05-22 07:28:42

标签: c++ multithreading

我有一台核心i7笔记本电脑。我只知道这种架构是四核超线程,这让用户认为盒子有8个核心。

因为我不知道上述内容是什么意思:)我问:

  1. 我的多线程程序的最大CPU使用率是多少 理论上,可以上这台笔记本电脑?是400%还是800%?

  2. 当我执行make -j 6时,这意味着我正在编译 在6个核心上的6个线程上应用?但我只有4个核心!

  3. 我可以在这台机器上运行make -j 10吗?其实我做了,但操作系统 几乎被绞死

  4. 无论如何,我的应用程序在编译或运行时从未得到超过370%的cpu使用率(这是top命令所说的)

    感谢

4 个答案:

答案 0 :(得分:3)

从技术上讲,你可以得到的最多是100%: - )

但是,我假设(因为你提到top)你在linux上(你应该标记这样的问题),这会使每个CPU负载达到最大值为100%* n(对于n逻辑CPU)。

我无法准确地回忆起它如何对待超线程 - 它可能会扩展到400%或800%。它可能取决于您是否在BIOS中启用了超线程。

关于make:make -j n要求make一次最多运行6个作业。这可能是对gcc的6次调用,其他make命令,无论makefile包含什么。它不总是能够运行该数字,它取决于构造makefile以允许并行构建的程度,并且您可以编写章节。这6个工作可以在6个单独的核心,相同的核心或混合物上运行。这一切都取决于调度程序放置它们的位置,并且它们可能会通过执行来移动内核。

你没有获得工作数* 100%使用率的原因是因为构建很少受CPU限制。有很多磁盘IO。读取makefile,扫描依赖项,读取源代码和所有包含的文件,编写输出文件,编写依赖项文件等都会对构建时间产生很大影响,当进程等待这些操作时,它们将处于空闲状态。

你能运行make -j 10吗?是的,你可以选择任何号码。通常建议设置你拥有的CPU数量,我个人更喜欢运行更多的CPU,但实际上这取决于make的功能。如果机器在-10处没有响应,请不要这样做!

希望这有帮助。

答案 1 :(得分:2)

试着回答你的问题:

  1. i7处理器有2个或4个“真核”,如下所示:http://ark.intel.com/products/family/75023/4th-Generation-Intel-Core-i7-Processors/mobile#@All 如果您在该列表中查找处理器的特定模型,它具有多少“真实”核心,并假设在您的设置中启用了HT(BIOS设置或类似设置),则可以将该数字乘以2.操作系统将假设HT *核心是实际处理单元的数量,并基于此给出统计。换句话说,如果您有4个真实内核并且启用了HT,那么您应该能够实现800%的CPU使用率。 或者您可以使用cat /proc/cpuinfo |grep -c vendor_id来获取操作系统看到的实际核心数(假设Linux,但是因为您使用top,这似乎是合理的)。

  2. 它将运行6个作业=进程,而不是线程。多少线程将完全取决于您的makefile实际执行的操作。当然,这些作业将按照操作系统可用的最佳CPU资源(核心*(HT?2:1))进行分配。

  3. 理论上,当然。但是,如果您希望机器具有响应性,那么在具有4或8(内核*(HT?2:1))的机器上运行10个CPU占用工作(例如编译)将可能耗尽所有CPU资源,并且如果编译具有相当大的来源,您可能会发现编译过程使用的总内存使用的内存多于机器中可用的内存,从而导致过度交换,并且实际上并未实现更好的结果。理想的做法是让所有核心都忙,但有足够的内存可以避免交换。

  4. 如果您的编译作业达到370%,那么您要么内存不足(交换导致磁盘IO),要么源代码足够大,以至于操作系统无法快速读取文件以跟上编译器的步伐。如果它是“等待磁盘I / O”,则运行更多数量的作业可能会有所帮助。如果内存不足,运行较低的数字会更好(因为这会降低内存压力)。我们无法真正说出这两种情景中的哪一种。您可以在顶部查看“Mem”和“Swap”,看看那里发生了什么。

答案 2 :(得分:1)

我有一个家庭作业来测试make在英特尔酷睿I7-3770K @ 3.5GHz 64Bit上具有不同数量的作业的编译速度,其中HT使用SSD和16GB RAM在FreeBSD 9.1上使用gcc 4.6.1 ..结果如下: enter image description here 底部轴是作业的数量。左轴是与-j 1相比的加速。 绿线为Boost 1.54.0,蓝线为Dosbox 0.7.4。所有测量均连续进行10次。

答案 3 :(得分:1)

这是我在sparc机器上的经验(例如Oracle / Sun的Netra T5440,它有8个内核,最多128个硬件线程)。

有一件事是操作系统认为它具有的。例如,如果我运行mpstat,它会很高兴地报告:

 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0  157   0  537   193   28  424    2   30   11    0  1368    7   5   0  88
   1    9   0  250   236   79  260    2   23    6    0   647    8   2   0  90
   ...
 125    1   0   51    47   15   49    0    4    2    0   131    3   0   0  97
 126    1   0   49    47   15   49    0    4    2    0   132    3   0   0  97
 127    2   0   81    90   32   96    1    7    3    0   238    6   1   0  93

即。它有128个处理资源......操作系统将根据128个处理资源的可用性进行调度。这意味着它每秒都有128000毫秒。可用的CPU时间(有时可以表示为最大CPU使用率为12800%)

然而。这128个虚假 CPU资源内置于8个硬件核心中。这意味着有硬件资源,管道,总线...... 共享,这些都是潜在的争用点。这意味着当你用力驱动它们时,当你超过70%-80%的CPU使用率(每线程)时,实际的吞吐量会受到影响。

现在,OS中的进程可以使用一个或多个 OS线程。但这是一个与硬件线程或CPU超线程不同的概念(虽然相关)。

操作系统处理带有相关内存和一个或多个轻型进程(调度单元)或线程的繁重进程。多个OS线程共享相同的进程内存。

通常,调度意味着在任何时候,在给定的处理资源中只有一个调度单元可以是活动的。这意味着一个线程每秒最多可以使用1000毫秒的CPU时间[100%]。这同样适用于单线程进程,而多线程进程每秒最多可使用N * 1000ms的CPU时间[N * 100%]。

从前面可以清楚地看出,系统中(活动)线程的数量应该保持低于或等于CPU资源的数量。然后,您需要考虑一些必须允许的概念,以便仍然可以执行一些管理或后台任务(例如,运行shell以查看正在发生的事情或许多后台操作系统进程) ....而且你必须考虑到你的超线程多核东西因为我们上面讨论过的硬件争用而无法提供100%的每个cpu资源。

如果线程数大于可用的CPU资源,则它们将无法运行,等待调度程序授予它们CPU资源并导致切换上下文等的成本。

当你运行make -j 6时,你指示make一次最多启动6个任务(考虑到依赖性约束),每个任务都是一个操作系统进程,可能是单线程(通常是编译器)。如果我们假设所有进程都是单线程意味着你将使用最多6个核心中的6个(任何时候都有不同的核心)

当您运行make -j 10时,您指示make最多启动10个任务。根据我之前的解释,你可以弄清楚会发生什么。假设单线程进程,这意味着你有10个线程(+其余的操作进程)竞争8个CPU资源......