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