Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx> writes:
> 5b594f457a (Threaded grep, 2010-01-25) added a hardcoded number of
> threads(8) to use in grep and 89f09dd34e (grep: add --threads=<num>
> option and grep.threads configuration, 2015-12-15) made it configurable
> through a knob as a workaround for systems where that default was not
> effective.
>
> Use instead the industry standard of 2x number of CPUs (to allow for
> IO wait) for the default.
Thanks.
While I am not bold enough to endorse the "industry standard is
twice the number of CPUs" claim, my gut feeling agrees with you that
8 threads may be too many for a 2 CPU box.
I think we cap the parallelism to the number of CPUs (not twice
that) in all the codepaths that currently call online_cpus(), and
some codepaths even cap it further to avoid creating tasks that are
too small (e.g. name-hash, index-pack).
There may not be a single one-size-fits-all scaling factor (as I/O
bound jobs tend to do better with a bit more workers than there are
cores, but adding more workers would not help when you are CPU
bound), but we'd be better off to have a mechanism to allow us to
later have a consistent way to auto-scale the number of workers?
Random ideas include (not mutually exclusive)
- accept "[grep] threads = 2xCPU", in addition to "[grep] threads =
8", to mean "this many workers per CPUs"?
- add "cpuBound.numThreads" and "ioBound.numThreads" variables to
configure the number of workers for cpu and io bound jobs, so
that the users do not have to configure them for each command?
- build an num_threads() API that is used by the current callers of
online_cpus(), including the new one this patch adds, perhaps
with a signature allows it to take configuration key (e.g. "git
grep" would pass "grep.threads") and if the task is expected to
be IO or CPU bound ("git grep" may pass "I am heavy on IO"), e.g.
int num_threads(const char *config_key,
enum { CPUBOUND, IOBOUND } task_type);
to hide the complexity of the first two items?
> Using Debian 10 amd64 in a 2 CPU VirtualBox running in macOS 10.14.6
> and that might had been representative of the original author environment
> shows an overall performance improvement by avoiding thread trashing:
The above does not parse very well, at least to me.
> diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> index 2d27969057..5d72e03b2e 100644
> --- a/Documentation/git-grep.txt
> +++ b/Documentation/git-grep.txt
> @@ -60,7 +60,7 @@ grep.extendedRegexp::
>
> grep.threads::
> Number of grep worker threads to use. If unset (or set to 0),
> - 8 threads are used by default (for now).
> + 2 threads per core are used by default.
>
> grep.fullName::
> If set to true, enable `--full-name` option by default.
> diff --git a/builtin/grep.c b/builtin/grep.c
> index 580fd38f41..0ed8da30f8 100644
> --- a/builtin/grep.c
> +++ b/builtin/grep.c
> @@ -32,7 +32,6 @@ static char const * const grep_usage[] = {
>
> static int recurse_submodules;
>
> -#define GREP_NUM_THREADS_DEFAULT 8
> static int num_threads;
>
> static pthread_t *threads;
> @@ -1068,7 +1067,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
> } else if (num_threads < 0)
> die(_("invalid number of threads specified (%d)"), num_threads);
> else if (num_threads == 0)
> - num_threads = HAVE_THREADS ? GREP_NUM_THREADS_DEFAULT : 1;
> + num_threads = HAVE_THREADS ? online_cpus() * 2 : 1;
>
> if (num_threads > 1) {
> if (!HAVE_THREADS)
