On Wed, Aug 02, 2000 at 03:17:04AM +1000, Marc Espie wrote:
> Just caught up on the mailing-list, and looked up those performance issues.
> Is md4 a bottleneck now ?
>
> I know of at least one system with an independent md4 implementation which
> might just be faster (OpenBSD)... I'll need to do some performance tests,
> of course.
I had a look at the OpenSSL source too, as it has a reputation for
good performance tuning. They don't actually have an md4, only an
md5, but it does have this interesting comment:
void md5_block_data_order (MD5_CTX *c, const void *data_, int num)
{
const unsigned char *data=data_;
register unsigned long A,B,C,D,l;
/*
* In case you wonder why A-D are declared as long and not
* as MD5_LONG. Doing so results in slight performance
* boost on LP64 architectures. The catch is we don't
* really care if 32 MSBs of a 64-bit register get polluted
* with eventual overflows as we *save* only 32 LSBs in
* *either* case. Now declaring 'em long excuses the compiler
* from keeping 32 MSBs zeroed resulting in 13% performance
* improvement under SPARC Solaris7/64 and 5% under AlphaLinux.
* Well, to be honest it should say that this *prevents*
* performance degradation.
*
* <[EMAIL PROTECTED]>
*/
#ifndef MD32_XARRAY
/* See comment in crypto/sha/sha_locl.h for details. */
unsigned long XX0, XX1, XX2, XX3, XX4, XX5, XX6, XX7,
XX8, XX9,XX10,XX11,XX12,XX13,XX14,XX15;
# define X(i) XX##i
#else
MD5_LONG XX[MD5_LBLOCK];
# define X(i) XX[i]
#endif
I don't know if that would help rsync, but it's interesting...
--
Martin Pool http://linuxcare.com.au/rproxy/
rproxy accelerates HTTP by dynamic caching and differential update
PGP signature
