在GNU Make流程中划分可用内核是否是一个好主意？

Question

是否有人看到过某种情况，其中每个都使用

运行n GNU Make流程

$ make -j <number of cores / n>

比使用

运行它们更快

$ make -j < number of cores>

让GNU Make照顾它。我在练习中从未见过这样的效果，在我看来，做前者是毫无意义的。也就是说，也许有可能做出会产生这种影响的特定非实际例子，但在实际情况下，没有。

我的问题是，有没有人在他们的实践中看到过这样的效果。

ADDED：当然假设不同的进程彼此独立，并且可以在逻辑上同时运行。

ADDED：问题不是：手动分区通常会更快。我知道答案，它是：不。问题是，它可以在实践中发生吗？有人见过吗？

特别是我对MadScientist的回答感兴趣：）

这个问题是关于StackOverflow的主题，因为，上面的行是在程序中，即GNU Make的包装脚本。 （是的我知道这可能不会飞，但至少我试过:)）

Answer 1

如您所述，手动分区可能会产生很大的负面影响：

• 在单独的make进程之间没有同步，他们可能会尝试同时重建相同的文件，导致不仅浪费了工作，而且由于被覆盖的垃圾输入而导致构建失败。
• 即使您设法对整个依赖关系链进行分区而没有任何重叠，在第一个分区完成后，您将拥有空闲的CPU。

我见过的唯一可以提高makefile速度的技术是：

• 在依赖项列表的前面放置“更昂贵”的目标（即具有最多链接的二进制），以防止最后的空闲CPU。
• 包含生成的包含缓存依赖项的makefile，而不是每次运行时重新计算它们，即使它们没有更改。
• 使用系统避免在源文件更改时间戳而不是内容时重建文件。我只是开始研究这里有什么可能。