Do not add two to the default job count #1449
Conversation
Benchmarks show that increasing the number of make jobs past the number of CPUs decreases performance: https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/. This was conducted 5 years ago. Since then, although context switching itself has become faster, both CPU cache size and compiler memory usage have increased (the latter particularly so for C++). Moreover, compilers spend even less time on I/O now than they did then; any reasonable software package's header files will all fit into main memory. Therefore, I believe the results should be even more significant today.
|
Upon reconsideration, I think the value should be 1 for single CPU machines as well. Such machines are likely to also have low RAM, and so running more jobs than necessary is not only slower on the CPU, it may cause swapping. |
|
I think the idea behind the +2 is, that not all jobs are compiler invocations, so some are actually more IO heavy. Also keep this point from the test in mind:
If you don't do this, short IO breaks might cause the CPU to downclock and thus resulting in Windows might also act differently (process spawning takes longer there, Anti-Virus slows down IO, etc.). As an example I've just tested All in all I'm not saying that we should never touch that default, but if we do, we have to be absolute sure, that the new default is better. Currently I don't think the benefit is worth touching this known behaviour. |
|
In order to reduce the number of open PRs I'm closing this one. If you still think this should be changed, please open an issue or start a thread on the mailing list. |
|
See also: https://groups.google.com/forum/#!topic/ninja-build/E3s9gE7RiLQ , #1363 and #1399 |
Benchmarks show that increasing the number of make jobs past the number of CPUs decreases performance: https://blogs.gentoo.org/ago/2013/01/14/makeopts-jcore-1-is-not-the-best-optimization/. This was conducted 5 years ago. Since then, although context switching itself has become faster, both CPU cache size and compiler memory usage have increased (the latter particularly so for C++). Moreover, compilers spend even less time on I/O now than they did then; any reasonable software package's header files will all fit into main memory. Therefore, I believe the results should be even more significant today.