GNU make:作业的数量是否应该等于系统中CPU核心的数量？

Question

关于GNU make中的作业数量是否应该等于内核数量，或者是否可以通过添加一个额外的作业来优化构建时间，当其他作业“工作”时，似乎存在一些争议。

在四核系统上使用-j4和-j5哪个更好？

你见过(或做过)任何支持其中之一的基准测试吗？

Answer 1

我会说，最好的做法是根据您的特定环境和工作负载对其进行基准测试。似乎有太多的变量(源文件的大小/数量，可用内存，磁盘缓存，源目录和系统头文件是否位于不同的磁盘上，等等)一刀切的答案。

我的个人经验(在双核MacBook专业版上)是-j2比-j1快很多，但超过了-j3，-j4等。没有可测量的加速比。因此，对于我的环境来说，"jobs == number of cores“似乎是一个很好的答案。(YMMV)

Answer 2

我已经在我的4核超线程笔记本电脑上运行了我的家庭项目，并记录了结果。这是一个相当繁重的编译器项目，但它在最后包含了一个17.7秒的单元测试。编译的IO密集度不是很高；有非常多的内存可用，如果没有，其余的都在一个快速的SSD上。

1 job        real   2m27.929s    user   2m11.352s    sys    0m11.964s    
2 jobs       real   1m22.901s    user   2m13.800s    sys    0m9.532s
3 jobs       real   1m6.434s     user   2m29.024s    sys    0m10.532s
4 jobs       real   0m59.847s    user   2m50.336s    sys    0m12.656s
5 jobs       real   0m58.657s    user   3m24.384s    sys    0m14.112s
6 jobs       real   0m57.100s    user   3m51.776s    sys    0m16.128s
7 jobs       real   0m56.304s    user   4m15.500s    sys    0m16.992s
8 jobs       real   0m53.513s    user   4m38.456s    sys    0m17.724s
9 jobs       real   0m53.371s    user   4m37.344s    sys    0m17.676s
10 jobs      real   0m53.350s    user   4m37.384s    sys    0m17.752s
11 jobs      real   0m53.834s    user   4m43.644s    sys    0m18.568s
12 jobs      real   0m52.187s    user   4m32.400s    sys    0m17.476s
13 jobs      real   0m53.834s    user   4m40.900s    sys    0m17.660s
14 jobs      real   0m53.901s    user   4m37.076s    sys    0m17.408s
15 jobs      real   0m55.975s    user   4m43.588s    sys    0m18.504s
16 jobs      real   0m53.764s    user   4m40.856s    sys    0m18.244s
inf jobs     real   0m51.812s    user   4m21.200s    sys    0m16.812s

基本结果：

将

• 扩展到核心计数几乎线性地提高了性能。实时时间从2.5分钟下降到1.0分钟(快2.5倍)，但编译时间从2.11分钟上升到2.50分钟。系统几乎没有注意到这一点上的任何额外负载。
• 从核心计数扩展到线程计数极大地增加了用户负载，从2.50分钟增加到4.38分钟。这种接近翻倍的情况很可能是因为其他编译器实例希望同时使用相同的CPU资源。系统的请求和任务切换负载增加了一点，导致它使用了17.7秒的时间。在53.5秒的编译时间上，优势大约是6.5秒，使得从线程计数到双线程计数的12%的speedup.
• Scaling没有显著的加速。12和15的时间很可能是您可以忽略的统计异常。所用的总时间会稍微增加，系统时间也是如此。这两种情况都很可能是因为任务切换增加了。这样做没有任何好处。

我现在的猜测是:如果您在计算机上执行其他操作，请使用核心计数。如果不这样做，请使用线程数。超过它不会带来任何好处。在某种程度上，它们会变得内存有限，并因此而崩溃，使编译变得慢得多。"inf“行是在很晚的时候添加的，这让我怀疑对8+作业有一些热限制。这确实表明，对于此项目大小，没有有效的内存或吞吐量限制。不过，这是一个小项目，需要8 8GB的内存才能进行编译。

Answer 3

我个人使用make -j n，其中n是“核数”+ 1。

然而，我不能给出一个科学的解释:我已经看到很多人使用相同的设置，到目前为止，他们给了我相当好的结果。

无论如何，您必须小心，因为一些make-chain与--jobs选项不兼容，并可能导致意外的结果。如果你遇到奇怪的依赖错误，试着在没有--jobs的情况下使用make。