Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1540681
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2] siphash: add cryptographically secure hashtable function |
| Date | 2016-12-12 22:40 +0100 |
| Message-ID | <sNGue-113-7@gated-at.bofh.it> (permalink) |
| References | <sNjeh-3HG-1@gated-at.bofh.it> <sNpMJ-7EK-3@gated-at.bofh.it> <sNq65-80d-3@gated-at.bofh.it> <sNrER-pq-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sun, Dec 11, 2016 at 9:48 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> I modified the test to hash data of size 0 through 7 repeatedly
> 100000000 times, and benchmarked that a few times on a Skylake laptop.
> The `load_unaligned_zeropad & bytemask_from_count` version was
> consistently 7% slower.
>
> I then modified it again to simply hash a 4 byte constant repeatedly
> 1000000000 times. The `load_unaligned_zeropad & bytemask_from_count`
> version was around 6% faster. I tried again with a 7 byte constant and
> got more or less a similar result.
>
> Then I tried with a 1 byte constant, and found that the
> `load_unaligned_zeropad & bytemask_from_count` version was slower.
>
> So, it would seem that between the `if (left)` and the `switch
> (left)`, there's the same number of branches.
Interesting.
For the dcache code (which is where that trick comes from), we used to
have a loop (rather than the duff's device thing), and it performed
badly due to the consistently badly predicted branch of the loop. But
I never compared it against the duff's device version.
I guess you could try to just remove the "if (left)" test entirely, if
it is at least partly the mispredict. It should do the right thing
even with a zero count, and it might schedule the code better. Code
size _should_ be better with the byte mask model (which won't matter
in the hot loop example, since it will all be cached, possibly even in
the uop cache for really tight benchmark loops).
Linus
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [kernel-hardening] [PATCH] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-11 16:40 +0100
Re: [kernel-hardening] [PATCH] siphash: add cryptographically secure hashtable function Greg KH <gregkh@linuxfoundation.org> - 2016-12-11 21:50 +0100
[PATCH v2] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-12 04:50 +0100
Re: [PATCH v2] siphash: add cryptographically secure hashtable function Linus Torvalds <torvalds@linux-foundation.org> - 2016-12-12 05:10 +0100
Re: [PATCH v2] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-12 06:50 +0100
Re: [PATCH v2] siphash: add cryptographically secure hashtable function Linus Torvalds <torvalds@linux-foundation.org> - 2016-12-12 22:40 +0100
[PATCH v3] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-12 23:30 +0100
Re: [PATCH v3] siphash: add cryptographically secure hashtable function Andi Kleen <ak@linux.intel.com> - 2016-12-13 00:10 +0100
Re: [PATCH v3] siphash: add cryptographically secure hashtable function Eric Biggers <ebiggers3@gmail.com> - 2016-12-13 09:50 +0100
Re: [PATCH v3] siphash: add cryptographically secure hashtable function Linus Torvalds <torvalds@linux-foundation.org> - 2016-12-13 20:30 +0100
Re: [PATCH v3] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-13 23:50 +0100
[PATCH v4] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-13 23:50 +0100
Re: [PATCH v2] siphash: add cryptographically secure hashtable function Eric Biggers <ebiggers3@gmail.com> - 2016-12-12 06:50 +0100
Re: [PATCH v2] siphash: add cryptographically secure hashtable function "Jason A. Donenfeld" <Jason@zx2c4.com> - 2016-12-12 22:20 +0100
csiph-web