From: Junio C Hamano <gitster@pobox.com>
To: Calvin Wan <calvinwan@google.com>
Cc: git@vger.kernel.org, emilyshaffer@google.com, avarab@gmail.com,
phillip.wood123@gmail.com
Subject: Re: [PATCH v2 0/4] submodule: parallelize diff
Date: Tue, 11 Oct 2022 22:52:42 -0700 [thread overview]
Message-ID: <xmqqczaxmvv9.fsf@gitster.g> (raw)
In-Reply-To: <20221011232604.839941-1-calvinwan@google.com> (Calvin Wan's message of "Tue, 11 Oct 2022 23:26:00 +0000")
Calvin Wan <calvinwan@google.com> writes:
> I also wanted to pose another question to list regarding defaults for
> parallel processes. For jobs that clearly scale with the number of
> processes (aka jobs that are mostly processor bound), it is obvious that
> setting the default number of processes to the number of available cores
> is the most optimal option. However, this changes when the job is mostly
> I/O bound or has a combination of I/O and processing. Looking at my use
> case for `status` on a cold cache (see below), we notice that increasing
> the number of parallel processes speeds up status, but after a certain
> number, it actually starts slowing down.
I do not offhand recall how the default parallelism is computed
there, but if I am correct to suspect that "git grep" has a similar
scaling pattern, i.e. the threads all need to compete for I/O to
read from the filesystem to find needles from the haystack, perhaps
it would give us a precedent to model the behaviour of this part of
the code, too, hopefully?
next prev parent reply other threads:[~2022-10-12 5:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <https://lore.kernel.org/git/20220922232947.631309-1-calvinwan@google.com/>
2022-10-11 23:26 ` [PATCH v2 0/4] submodule: parallelize diff Calvin Wan
2022-10-12 5:52 ` Junio C Hamano [this message]
2022-10-14 0:39 ` Calvin Wan
2022-10-11 23:26 ` [PATCH v2 1/4] run-command: add pipe_output_fn to run_processes_parallel_opts Calvin Wan
2022-10-12 7:58 ` Ævar Arnfjörð Bjarmason
2022-10-11 23:26 ` [PATCH v2 2/4] submodule: move status parsing into function Calvin Wan
2022-10-12 7:41 ` Ævar Arnfjörð Bjarmason
2022-10-12 8:27 ` Ævar Arnfjörð Bjarmason
2022-10-11 23:26 ` [PATCH v2 3/4] diff-lib: refactor match_stat_with_submodule Calvin Wan
2022-10-11 23:26 ` [PATCH v2 4/4] diff-lib: parallelize run_diff_files for submodules Calvin Wan
2022-10-12 8:31 ` Ævar Arnfjörð Bjarmason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqczaxmvv9.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=calvinwan@google.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.