【发布时间】：2013-02-23 17:13:03
【问题描述】：
我有 4 个处理器并且正在编译一个需要大量处理器的应用程序。我读到建议在 OpenCV 中使用 make 和 -j4 开关；我应该改用-j8 吗？为多个处理器制作有什么好处？
【问题讨论】：
-
Tl;博士：
make -j $(nproc)
【发布时间】：2013-02-23 17:13:03
【问题描述】：
上面的答案大部分都是正确的。但是，细节有点误导。例如，不需要为“管理线程”添加额外的作业（注意：make 实际上不是多线程的）。 make 从不将自己算作 -j 的工作，因此，正如 Huygens 上面所说，如果您说 -j5，您将运行 5 个编译工作，而不是 4 个加上 make。
大多数人使用 [核数] + [一些填充] 的原因与 make 或它需要什么无关，而是与编译器的性质有关。编译器实际上只是一个非常复杂的文本翻译工具：它以一种形式读取文本并将其转换为另一种形式的“文本”（二进制）。其中很多（尤其是当您的语言变得更加复杂时，例如 C++）需要大量 CPU。但它也需要大量的磁盘 I/O。磁盘 I/O 很慢，因此当一个编译器在等待来自磁盘的一些数据时，内核会安排其他作业运行。这就是为什么您可以同时运行多个内核编译器。
在您开始看到收益递减之前，您究竟可以获得多大的-j（您的构建实际上开始变慢，在某些时候，更多-j）完全取决于您的硬件，您正在执行的构建类型等。唯一确定的方法是实验。
但是，[核心数]+[几个] 通常是一个很好的近似值。
【讨论】：
-
如果要构建的文件非常大，[cores]+[something >0] 可能会造成瓶颈，因为一旦所有 IO 操作完成，每个线程都会非常占用。我使用 -j cores 作为最大值。
-
运行
vmstat并观察阻塞值很有用。编译器选项也可能会影响这一点。即，-O0 比 -O3 占用更少的 CPU，因此 I/O 更多是未优化构建的一个因素。我想知道依赖信息可以用来优化磁盘缓存吗？ An article 和 code；修改benchmark.sh并更改NPROC变量。代码结构是合成与真实构建，但它是试验和评估的一个很好的起点。 -
我认为值得补充的是，在任一侧进行测量并不难。一个编译足够了，尝试 cores + 2 和 cores - 2 应该很容易尝试。尝试很重要，因为 IO 子系统的速度在过去 5 年里发生了根本性的变化。
正如您所说，-j 标志告诉 make 允许生成提供的“线程”数量。理想情况下，每个线程都在其自己的核心/CPU 上执行，因此您的多核/CPU 环境可以充分利用。
make 本身不编译源文件。这是由编译器 (gcc) 完成的。 Makefile（make 的输入）包含一组目标。每个目标都有一组依赖项（在其他目标上）和如何构建目标的规则。 make 读取 Makefile 并管理所有目标、依赖项和构建规则。除了编译源文件，您还可以使用make 来执行任何可以用 shell 命令描述的任务。
如果您将允许的线程数设置得太高，则无法将每个线程调度到自己的内核上。需要额外的调度（上下文）开关来让所有线程执行。这种额外的资源使用显然会导致性能下降。
有多个经验法则，但我想将总数设置为<number of cores> + 1 是最常见的。这背后的想法是，所有内核都有自己的线程，并且还有一个额外的管理线程来处理目标并且接下来要构建。
【讨论】：
-
很好地解释了维格。非常感谢您的回答。
每个线程一个 CPU 加上一个管理器/加载器。由于从 CPU 的角度来看，执行磁盘操作的线程在技术上几乎是空闲的，因此将内核总数加一。
如果 CPU 使用超线程，您可以安全地将每个内核计为两个内核并将线程数加倍，因此四核 Intel Core i7 应该得到 -j9（八个虚拟内核加上管理器。）在四核 AMD 上使用 -j5
【讨论】：
-j 选项仅用于加速应用程序构建，它决定了make 可以为构建生成多少作业。您可以设置-j<nb core> 甚至更高的-j<nb-core * 1.5>，以便编译可以并行进行。
对编译后的代码没有影响。
对于 4 核系统，您可以尝试make -j6。如果 make 可以运行并行构建，它将启动多达 6 个同时编译过程（例如 6 个对 gcc 的调用）。
【讨论】：