On Tue, 11 Aug 2009, Brandon Casey wrote:
> Nicolas Pitre wrote:
> > On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >
> >> On Tue, 11 Aug 2009, Linus Torvalds wrote:
> >>
> >>> On Tue, 11 Aug 2009, Nicolas Pitre wrote:
> >>>> #define SHA_SRC(t) \
> >>>> ({ unsigned char *__d = (unsigned char *)&data[t]; \
> >>>> (__d[0] << 24) | (__d[1] << 16) | (__d[2] << 8) | (__d[3] << 0); })
> >>>>
> >>>> And this provides the exact same performance as the ntohl() based
> >>>> version (4.980s) except that this now cope with unaligned buffers too.
> >>> The actual object SHA1 calculations are likely not aligned (we do that
> >>> object header thing), and if you can't do the htonl() any better way I
> >>> guess the byte-based thing is the way to go..
> >
> > OK, even better: 4.400s.
> >
> > This is with this instead of the above:
> >
> > #define SHA_SRC(t) \
> > ({ unsigned char *__d = (unsigned char *)data; \
> > (__d[(t)*4 + 0] << 24) | (__d[(t)*4 + 1] << 16) | \
> > (__d[(t)*4 + 2] << 8) | (__d[(t)*4 + 3] << 0); })
> >
> > The previous version would allocate a new register for __d and then
> > index it with an offset of 0, 1, 2 or 3. This version always uses the
> > register containing the data pointer with absolute offsets. The binary
> > is a bit smaller too.
>
> In that case, why not change the interface of blk_SHA1Block() so that its
> second argument is const unsigned char* and get rid of __d and the { } ?
Because not all architectures care to access the data bytewise. Please
see the original SHA_SRC definition.
Nicolas
--
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