Hallvard B Furuseth wrote:
Howard Chu writes:
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.
Right. The fewer custom utilities involved the better.
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.
Sounds to me like we should just use zlib's crc32 code then.