| commit | 7b5075fcfb069fc36ba4cfe5567234974793ab58 | |
| author | Linus Torvalds <torvalds@linux-foundation.org> | |
| Thu, 6 Aug 2009 03:49:41 +0000 (5 20:49 -0700) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Thu, 6 Aug 2009 20:56:45 +0000 (6 13:56 -0700) | ||
| tree | 2eba4fbbee102e4e80ec5377b201d5c1f56554f8 | treesnapshot (tar.gz zip) |
| parent | 139e3456ecf18fc03a75eda7a77441e8fec344b9 | commitdiff |
block-sha1: re-use the temporary array as we calculate the SHA1
The mozilla-SHA1 code did this 80-word array for the 80 iterations. But
the SHA1 state is really just 512 bits, and you can actually keep it in
a kind of "circular queue" of just 16 words instead.
This requires us to do the xor updates as we go along (rather than as a
pre-phase), but that's really what we want to do anyway.
This gets me really close to the OpenSSL performance on my Nehalem.
Look ma, all C code (ok, there's the rol/ror hack, but that one doesn't
strictly even matter on my Nehalem, it's just a local optimization).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The mozilla-SHA1 code did this 80-word array for the 80 iterations. But
the SHA1 state is really just 512 bits, and you can actually keep it in
a kind of "circular queue" of just 16 words instead.
This requires us to do the xor updates as we go along (rather than as a
pre-phase), but that's really what we want to do anyway.
This gets me really close to the OpenSSL performance on my Nehalem.
Look ma, all C code (ok, there's the rol/ror hack, but that one doesn't
strictly even matter on my Nehalem, it's just a local optimization).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| block-sha1/sha1.c | diffblobblamehistory |