Re: [RFC PATCH 2/2] grep: make default number of threads reflect runtime

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 5, 2019, 21:28 UTC
Message-ID: <xmqqa7cnmhds.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190804211509.39229-3-carenas@gmail.com>

Carlo Marcelo Arenas Belón  <carenas@gmail.com> writes:

Show 8 quoted lines

> 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.

Show 34 quoted lines

> 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)