Re: [PATCH] src/main.c: Add -J to detect number of job slots based on nproc.

[Henrik Carlqvist]

> Isn't nproc or nproc+1 too much?  On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive.  Maybe nproc/2 is a better default?

There have been many other good suggestions of choices for make -j and the
choice depends upon your situation.

In your example, when you are considered about responsivness, you are probably
considering a system being used by some user interactively. For such a
situation you might want to consider a low number of parallell jobs and/or
to start make with a nice priority.

The other extreme example would be a system not being used interactively with
only a few low priority, low cpu usage, background processes. If you on such a
system want make to finish as quick as possible you want it to fully utilize
all the resources in a machine. For such situations, I usually use nproc+1,
with the idea that the machine has nproc CPU threads and 1 disk (locally or
remote) for the project. The disk will be fully utilized if 1 or more
processes are waiting for disk, the  CPU threads will be fully utilized if 1
or more processes are waiting for CPU. In either case you will have a
bottleneck. Having more than one process waiting for disk will not increase
IO performance, most likely the IO performance will instead be degraded. The
same applies for processes waiting for CPU which will get slightly less
performance from context switching of unfinished processes.

On a system with a directory like /tmp on a separate disk the performance
might benefit from nproc+2. The same applies if you are reading sources and
writing compiled binaries to different disks.

As allways, your mileage might vary. If the bottleneck during compilation
several times switches between disk and CPU you might benefit from more
processes to fully utilize the resource that currently is not the bottlneck.

Another thing that might be worth to consider is if your CPU(s) are configured
to adjust the frequencies of the cores depending on the load. On one hand, you
might want to keep the cores busy to avoid that they go up and down in
frequency. On the other hand, depending on your CPU, you might be able to
reach some higher turbo frequency on few working cores than max allowed
frequency when all cores are working.

regards Henrik