On Thu, Feb 9, 2017 at 9:02 PM, Jeff King <p...@peff.net> wrote:
>
> I think this is only half the story. A heavy-sha1 workload is faster,
> which is good. But one of the original reasons to prefer blk-sha1 (at
> least on Linux) is that resolving libcrypto.so symbols takes a
> non-trivial amount of time. I just timed it again, and it seems to be
> consistently 1ms slower to run "git rev-parse --git-dir" on my machine
> (from the top-level of a repo).
Yes. It's also a horrible plain to profile those things.
Avoiding openssl was a great thing, because it avoided a lot of crazy overhead.
I suspect that most of the openssl win comes from using the actual SHA
instructions on modern CPU's. Because last I looked, the hand-coded
assembly simply wasn't that much faster.
We could easily have some x86-specific library that just does "use SHA
instructions if you have them, use blk-sha1 otherwise".
Of course, if we end up using the collision checking SHA libraries
this is all moot anyway.
Linus
