makefile - 高工作值(value)的缺点

Question

在 make 中使用较高的作业值 -j 有什么缺点吗？

在大多数安装自述文件中，建议对 8 个作业使用 make -j8 来加快进程。我很好奇简单地使用更多作业的缺点，例如 make -j16。当我尝试时，它似乎工作得很好。使用更高的值有什么问题吗？为什么大多数项目都使用 -j8 作为建议值？

Answer 1

除非 makefile 中的先决条件语句中存在错误，否则使用较高的 -j 值不存在正确性问题。然而，肯定存在性能问题。天下没有免费的午餐，您的 -j 值越高，您的构建就不会永远变得更快。在某些时候，您不仅不会获得任何更多的改进，而且实际上会增加构建时间，就像您同时在系统上运行太多程序时一样，它们都会减慢速度.

没有理由特别选择 8，任何表明作为硬编码值始终是最好的值的地方都应该被视为有用的资源:他们只是鹦鹉学舌地模仿从别人那里听到的东西，或者自己想出的东西，不明白其含义。

有效的真正值(value)在很大程度上取决于(a)您的硬件，(b)您的操作系统，以及(c)您的配方调用的命令类型。

例如，如果您有单核甚至双核系统，那么使用 -j8 可能不太适合您。这意味着八个不同的编译器同时竞争有限的 CPU 资源，这意味着操作系统将不断地交换它们(这需要时间)，而不是让它们在没有上下文切换的情况下运行完成。在具有 24 个核心的系统上，运行 -j8 将使大部分核心闲置。

那么这是否意味着核心和作业之间的一一对应是最好的？这是一个很好的起点，但还有其他事情需要考虑。首先，其他东西也可以在你的计算机上运行，​​所以也许 cores-1 更好？其次，编译器还必须读取和写入磁盘，而磁盘访问速度非常慢(与 CPU 相比)，因此当一个编译器作业正在等待磁盘 I/O 时，其他编译器作业可能正在执行有用的 CPU 工作，所以也许核心+1 还是核心+2 更好？第三，某些类型的编译非常耗费CPU，而另一些则不是:例如，使用大量模板、虚拟化类层次结构、内联和高优化级别来编译C++会使用大量CPU；相对来说，编译 C 语言非常简单，编译模型占用的 CPU 少得多(因此 I/O 与 CPU 的比率更高，可以并行运行更多作业)。

那么你应该使用什么？确定的唯一方法是进行测试:使用不断增加的 -j 值来运行构建，直到时间达到稳定状态或开始增加。

对于具有 4 到 8 个核心的系统(目前很常见)，我通常使用“核心 + 2”。如果您有很多核心，您可以尝试诸如“核心 + 0.4*核心”之类的内容。