[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: CRC -> MD5



Howard Chu writes:
> I had considered MD5 before (especially since we already had code for
> it) but it was slower, and we're not looking for cryptographic
> assurances or hash distribution anyway.

Yes, I was thinking mostly of killing unnecessary code and exposed
features.  After a brief test, I could see no good reason to keep CRC:
Neither speed nor quality.  On my machine, anyway.

> Basically all of these crypto hash functions are overkill, in terms of
> hash size and computation. We're only looking to detect casual misuse
> or corruption, not malicious deception.

Yes.  The main reason I see to use either CRC or MD5 is that they are
likely to be installed somewhere so non-programmers can use them.  We
could use a faster hash like MurmurHash3, but would then need to provide
a 'slaputil hash' command or something for use by shell programs.

> I didn't really spend a lot of time comparing the two functions'
> speed. But even with the memory access bottleneck, I would guess that
> on a loaded system with many threads running, the algorithm with fewer
> instructions is the better choice. Have you measured the throughput
> when multiple threads are executing?

On my 32-bit host, MD5 on a threaded test program had 90-95% of CRC's
throughput instead of 105% or whatever it was unthreaded.  OTOH crc32()
from linking -lz gave ~275%.  OTOH I'd expect MD5 to be more costly on
an older or cheaper machine where the which hasn't outpaced memory speed
as much as modern workhorses.

-- 
Hallvard