* "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
<snipp>
| - Avoid allocating byte[] for SHA-1s, instead we convert to 5 ints,
| which can be inlined into an object allocation.
What to pepole think about doing something simmilar in C GIT?
That is, convert the current internal representation of the SHA-1 from
"unsigned char sha1[20]" to "unsigned long sha1[5]"?
Ok, I currently see 2 problems with it:
1) Will the type "unsigned long" always be unsigned 32 bit on all
platforms on all computers? do we need an "unit_32_t" thing?
2) Can we get in truble because of differences between litle- and
big-endian machines?
And, simmilar I can see or guess the following would be positive with
this change:
3) From a SHA1 library I worked with some time ago, I noticed that
it internaly used the type "unsigned long arr[5]", so it can
mabye be possible to get some shurtcuts or maybe speedups here,
if we want to do it.
4) The "static inline void hashcpy(....)" in cache.h could then
maybe be written like this:
static inline void hashcpy(unsigned long sha_dst[5], const unsigned long sha_src[5])
{
sha_dst[0] = sha_src[0];
sha_dst[1] = sha_src[1];
sha_dst[2] = sha_src[2];
sha_dst[3] = sha_src[3];
sha_dst[4] = sha_src[4];
}
And hopefully will be compiled to just 5 store/more
instructions, or at least hopefully be faster than the currently
memcpy() call. But mabye we get more compiled instructions compared
to a single call to memcpy()?
5) Simmilar as 4) for the other SHA1 realted hash functions nearby
hashcpy() in cache.h
OK, just some thought's. Sorry if this allready has been discussed
but could not find something abouth it after a simple google search.
-- kjetil
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html