-j
在make中使用更高的工作价值有什么缺点吗?
在大多数安装自述文件中,建议使用make -j8
8 个作业来加快进程。例如,我很好奇简单地使用更多工作的缺点make -j16
。当我尝试它时,它似乎工作正常。使用更高的值有什么问题吗?为什么大多数项目都使用 -j8 作为建议值?
除非 makefile 中的先决条件语句出现错误,否则使用更高的值不会出现正确性问题。-j
但是,肯定存在性能问题。没有免费的午餐,而且您的构建不仅会继续变得更快,而且您的-j
价值越高。在某些时候,您不仅不会获得更多改进,而且实际上会增加构建时间,就像您同时在系统上运行太多程序时一样,它们都会变慢。
没有理由特别选择 8,任何暗示作为硬编码值始终是最好的值的地方都应该被视为有用的资源:他们只是在模仿从别人那里听到的东西,或者在不理解的情况下自己想出的东西这是什么意思。
运行良好的真正价值在很大程度上取决于(a)您的硬件,(b)您的操作系统,以及(c)您的配方调用的命令类型。
例如,如果您有一个单核,甚至是双核系统,那么使用-j8
可能不适合您。这意味着八个不同的编译器同时竞争有限的 CPU 资源,这意味着操作系统将不断地交换它们(这需要时间),而不是让它们在没有上下文切换的情况下运行完成。在具有 24 个内核的系统上,运行-j8
会使它们中的大多数处于空闲状态。
那么这是否意味着核心和工作之间的一对一对应是最好的?这是一个很好的起点,但还有其他事情需要考虑。首先,其他东西也可以在您的计算机上运行,所以也许 cores-1 更好?其次,编译器还必须读取和写入磁盘,并且磁盘访问非常慢(与 CPU 相比),因此当一个编译器作业正在等待磁盘 I/O 时,其他编译器作业可能正在做有用的 CPU 工作,所以也许cores+1 还是 cores+2 更好?第三,某些类型的编译非常占用 CPU,而另一些则不是:例如,使用大量模板、虚拟化类层次结构、内联和高优化级别编译 C++ 会占用大量 CPU;用它的非常直接的编译C,比较,
那么你应该使用什么?唯一可以确定的方法是进行测试:以增加的值运行构建,-j
直到时间达到稳定或开始增加。
对于具有 4 到 8 个内核的系统(现在很常见),我通常使用“cores + 2”。如果你有很多内核,你可以尝试类似“cores + 0.4*cores”之类的东西。