From: "René Scharfe" <l.s.r@web.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Jeff King <peff@peff.net>, Derrick Stolee <stolee@gmail.com>,
git@vger.kernel.org, Yiyuan guo <yguoaz@gmail.com>
Subject: Re: [PATCH 3/5] pack-objects: clamp negative window size to 0
Date: Wed, 5 May 2021 18:19:06 +0200 [thread overview]
Message-ID: <aa21321a-08d8-5a3a-0ccd-4f4ea4bf7a9c@web.de> (raw)
In-Reply-To: <874kfhwfwz.fsf@evledraar.gmail.com>
Am 05.05.21 um 13:53 schrieb Ævar Arnfjörð Bjarmason:
>
> On Tue, May 04 2021, René Scharfe wrote:
>
>> There's another option: Mapping -1 or all negative values to the
>> maximum:
> That seems sensible to expose, but I think should really be
> --window=max, not --window=-1. The latter feels way too much like
> assuming that a user might know about C's "set all bits" semantics.
Nitpicking: Setting all bits for -1 is done by two's complement, which
is just one of the signed number representations supported by C.
But yeah: A non-numeric value would probably be better in general. As
Peff explained it's not a particularly good idea to specify the maximum
values of --depth and --window, though, so no need to make it easier.
> The one example of such a variable I could think of is core.abbrev=no,
> which could arguably benefit from a core.abbrev=max synonym.
core.abbrev=no turns off abbreviation, i.e. you get the full hash
size (false and off work as well).
Following that logic, core.abbrev=max would ask for a maximum of
abbreviation, i.e. for the shortest unambiguous hash. That would have
a length of at least 4. This value is stored in a constant called
minimum_abbrev -- which seems backwards. The implied negation of abbrev
(the more you abbreviate, the shorter the length) is a bit confusing.
> Another one is *.threads, e.g. grep.threads, index.threads. We currently
> say that "auto" is like "max, but I can see how we'd eventually benefit
> from splitting those up. I sometimes run git on machines where that
> "auto" is 48 or whatever (I haven't benchmarked, but that's surely
> counter-productive). Having max != auto in that case (but still having a
> "max") would be nice.
Good thinking. What is the maximum number of threads? Certainly higher
than the number of CPUs. Would that be useful? Maybe -- on a
single-core VM with an SSD queue length of 32 we can probably benefit
from running more than one thread.
Are our threads CPU-bound or I/O-bound? I guess the answer is "yes". :)
How do we even find out the disk queue length in a portable way? And
how would we calculate the optimal number of threads? Are these even
the right questions to ask?
An "auto" option might help with that. I imagine it starting out with
some default value and then experimentally decreasing and and increasing
the number of threads to find out which one works best. Downside: It
would need to have comparable workloads for that. And these benchmarks
need an otherwise quiet system. Similar battery level if running on a
laptop. Same system temperature. Impractical during normal use.
Perhaps a "git benchmark" command that runs some synthetic speed tests
to tune grep.threads etc. would be possible?
René
next prev parent reply other threads:[~2021-05-05 16:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-01 14:02 [PATCH 0/5] pack-objects: better handling of negative options Jeff King
2021-05-01 14:02 ` [PATCH 1/5] t5300: modernize basic tests Jeff King
2021-05-03 5:27 ` Junio C Hamano
2021-05-03 14:53 ` Jeff King
2021-05-01 14:03 ` [PATCH 2/5] t5300: check that we produced expected number of deltas Jeff King
2021-05-01 14:03 ` [PATCH 3/5] pack-objects: clamp negative window size to 0 Jeff King
2021-05-03 12:10 ` Derrick Stolee
2021-05-03 14:55 ` Jeff King
2021-05-04 18:47 ` René Scharfe
2021-05-04 21:38 ` Jeff King
2021-05-05 11:53 ` Ævar Arnfjörð Bjarmason
2021-05-05 16:19 ` René Scharfe [this message]
2021-05-01 14:04 ` [PATCH 4/5] t5316: check behavior of pack-objects --depth=0 Jeff King
2021-05-01 14:04 ` [PATCH 5/5] pack-objects: clamp negative depth to 0 Jeff King
2021-05-03 12:11 ` Derrick Stolee
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aa21321a-08d8-5a3a-0ccd-4f4ea4bf7a9c@web.de \
--to=l.s.r@web.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=stolee@gmail.com \
--cc=yguoaz@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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).