Re: x86 asm SHA1 (draft)

The series to revamp SHA1 is good but judging the merit of each
is outside my expertise, so I'd appreciate help to evaluate
these changes.  For example, I cannot choose between competing
three implementations for ppc without having access to a variety
of ppc machines, and even if I did, ppc is not what I normally
use, so incentive to try picking the best one for everybody is
relatively low on my part.

What we would want are obviously (1) no regression, (2) an easy
way for people who build git for their own machine to decide
which one suits them the best, and (3) an easy way to tell the
build mechanism to use the one that is chosen.

The only external interface for the set of SHA1 implementation
alternatives to the outside world is a well established SHA_CTX
type, and three functions SHA1_Init(), SHA1_Update() and
SHA1_Final(), and the alternative implementations are supposed
to be drop-in replaceable.

So let's do something like this:

 - When adding a new SHA1 implementation, we need to come up
   with a Makefile symbol (similar to PPC_SHA1, MOZILLA_SHA1 and
   friends) and set up the build machinery to use the one that
   is chosen;

 - We need a test program and a build rule in the Makefile that
   links with the chosen SHA1 implementation.

 - We need a test script that feeds the above program with known
   vectors to validate the SHA1 implementation (make sure the
   test covers large input to avoid the recent half-gig-limit
   problem), and bench the speed on the platform it was built.

 - If we wanted to go fancier, another script that builds all
   applicable alternatives on the building platform, run the
   bench for all of them and automatically pick the right one
   for the platform would be a plus.

We probably would want to collect the benchmark results from
popular platforms, have a summary to help people to choose a
sensible one in the toplevel INSTALL file, and include the raw
numbers in Documentation/technical/sha1-implementations.txt.

Once we go the above path, we may want to include both of the
the two new ppc implementations as separate choices as I
understand their performance depends on which ppc you are
talking about.

Any takers?

The series to revamp SHA1 is good but judging the merit of each
is outside my expertise, so I'd appreciate help to evaluate
these changes.  For example, I cannot choose between competing
three implementations for ppc without having access to a variety
of ppc machines, and even if I did, ppc is not what I normally
use, so incentive to try picking the best one for everybody is
relatively low on my part.

Well, I'm not sure it's worth this much trouble.  Both of my PPC
implementations are smaller and faster than the current one,
so that's a pretty easy decision.  The difference between them
is 2-3%, which is, I think, not enough to be worth the maintenance
burden of a run-time decision infrastructure.  Just pick either one
and call it a day.

The only external interface for the set of SHA1 implementation
alternatives to the outside world is a well established SHA_CTX
type, and three functions SHA1_Init(), SHA1_Update() and
SHA1_Final(), and the alternative implementations are supposed
to be drop-in replaceable.

I'd prefer it it was an *opaque* SHA_CTX type.  Sometimes you can achieve
some useful benefits by rearranging the fields.  For example, keeping the
64-bit length field as a native-order 64-bit number when appropriate.
And sometimes it's useful to have the full 80-word W[] array, while
other implementations don't want it.

We probably would want to collect the benchmark results from
popular platforms, have a summary to help people to choose a
sensible one in the toplevel INSTALL file, and include the raw
numbers in Documentation/technical/sha1-implementations.txt.

Not that numbers are bad, but I think that until there's a real
need for more than a single good-enough version per instruction set,
this is excessive.  Does hashing even show up on a profile?