From: Jonathan Nieder <jrnieder@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "Paul Smith" <paul@mad-scientist.net>,
git@vger.kernel.org, "Derrick Stolee" <stolee@gmail.com>,
"Duy Nguyen" <pclouds@gmail.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [ANNOUNCE] Git v2.19.0-rc0
Date: Wed, 22 Aug 2018 22:10:27 -0700 [thread overview]
Message-ID: <20180823051027.GA160081@aiede.svl.corp.google.com> (raw)
In-Reply-To: <20180823050224.GA318@sigill.intra.peff.net>
Jeff King wrote:
> Here's the patch. For some reason my numbers aren't quite as large as
> they were yesterday (I was very careful to keep the system unloaded
> today, whereas yesterday I was doing a few other things, so perhaps that
> is the difference).
>
> -- >8 --
> Subject: [PATCH] hashcmp: assert constant hash size
>
> Prior to 509f6f62a4 (cache: update object ID functions for
> the_hash_algo, 2018-07-16), hashcmp() called memcmp() with a
> constant size of 20 bytes. Some compilers were able to turn
> that into a few quad-word comparisons, which is faster than
> actually calling memcmp().
>
> In 509f6f62a4, we started using the_hash_algo->rawsz
> instead. Even though this will always be 20, the compiler
> doesn't know that while inlining hashcmp() and ends up just
> generating a call to memcmp().
>
> Eventually we'll have to deal with multiple hash sizes, but
> for the upcoming v2.19, we can restore some of the original
> performance by asserting on the size. That gives the
> compiler enough information to know that the memcmp will
> always be called with a length of 20, and it performs the
> same optimization.
>
> Here are numbers for p0001.2 run against linux.git on a few
> versions. This is using -O2 with gcc 8.2.0.
>
> Test v2.18.0 v2.19.0-rc0 HEAD
> ------------------------------------------------------------------------------
> 0001.2: 34.24(33.81+0.43) 34.83(34.42+0.40) +1.7% 33.90(33.47+0.42) -1.0%
>
> You can see that v2.19 is a little slower than v2.18. This
> commit ended up slightly faster than v2.18, but there's a
> fair bit of run-to-run noise (the generated code in the two
> cases is basically the same). This patch does seem to be
> consistently 1-2% faster than v2.19.
>
> I tried changing hashcpy(), which was also touched by
> 509f6f62a4, in the same way, but couldn't measure any
> speedup. Which makes sense, at least for this workload. A
> traversal of the whole commit graph requires looking up
> every entry of every tree via lookup_object(). That's many
> multiples of the numbers of objects in the repository (most
> of the lookups just return "yes, we already saw that
> object").
>
> Reported-by: Derrick Stolee <stolee@gmail.com>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> cache.h | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Verified using "make object.s" that the memcmp call goes away. Thank
you.
next prev parent reply other threads:[~2018-08-23 5:10 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 22:13 [ANNOUNCE] Git v2.19.0-rc0 Junio C Hamano
2018-08-20 22:41 ` Stefan Beller
2018-08-20 23:39 ` Jonathan Nieder
2018-08-21 0:27 ` Jonathan Nieder
2018-08-21 0:46 ` Stefan Beller
2018-08-21 20:41 ` Derrick Stolee
2018-08-21 21:29 ` Jeff King
2018-08-22 0:48 ` brian m. carlson
2018-08-22 3:03 ` Jeff King
2018-08-22 3:36 ` Jeff King
2018-08-22 11:11 ` Derrick Stolee
2018-08-22 5:36 ` brian m. carlson
2018-08-22 6:07 ` Jeff King
2018-08-22 7:39 ` Ævar Arnfjörð Bjarmason
2018-08-22 11:14 ` Derrick Stolee
2018-08-22 15:17 ` Jeff King
2018-08-22 16:08 ` Duy Nguyen
2018-08-22 16:14 ` Duy Nguyen
2018-08-22 16:26 ` Jeff King
2018-08-22 16:49 ` Derrick Stolee
2018-08-22 16:58 ` Duy Nguyen
2018-08-22 17:04 ` Derrick Stolee
2018-08-22 16:59 ` Jeff King
2018-08-22 17:02 ` Junio C Hamano
2018-08-22 15:14 ` Jeff King
2018-08-22 14:28 ` Derrick Stolee
2018-08-22 15:24 ` Jeff King
2018-08-22 12:42 ` Paul Smith
2018-08-22 15:23 ` Jeff King
2018-08-23 1:23 ` Jonathan Nieder
2018-08-23 2:16 ` Jeff King
2018-08-23 2:27 ` Jonathan Nieder
2018-08-23 5:02 ` Jeff King
2018-08-23 5:09 ` brian m. carlson
2018-08-23 5:10 ` Jonathan Nieder [this message]
2018-08-23 13:20 ` Junio C Hamano
2018-08-23 16:31 ` wide t/perf output, was " Jeff King
2018-08-23 3:47 ` brian m. carlson
2018-08-23 5:04 ` Jeff King
2018-08-23 10:26 ` Derrick Stolee
2018-08-23 13:16 ` Junio C Hamano
2018-08-23 16:14 ` Jeff King
2018-08-23 23:30 ` Jacob Keller
2018-08-23 23:40 ` Jeff King
2018-08-24 0:06 ` Jeff King
2018-08-24 0:16 ` Jeff King
2018-08-24 2:48 ` Jacob Keller
2018-08-24 2:59 ` Jeff King
2018-08-24 6:45 ` Jeff King
2018-08-24 11:04 ` Derrick Stolee
2018-08-27 19:36 ` Junio C Hamano
2018-08-23 18:53 ` Jeff King
2018-08-23 20:59 ` Derrick Stolee
2018-08-24 6:56 ` Jeff King
2018-08-24 7:57 ` Ævar Arnfjörð Bjarmason
2018-08-24 16:45 ` Derrick Stolee
2018-08-25 8:26 ` Jeff King
2018-09-02 18:53 ` Kaartic Sivaraam
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=20180823051027.GA160081@aiede.svl.corp.google.com \
--to=jrnieder@gmail.com \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=paul@mad-scientist.net \
--cc=pclouds@gmail.com \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
--cc=stolee@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).