On Fri, Dec 08, 2000 at 10:17:00PM -0500, Tom Lane wrote:
> A couple further observations while playing with this benchmark ---
>
> 1. This MD5 implementation is not too robust. On my machine it dumps
> core if given a non-word-aligned data buffer. We could probably work
> around that, but it bespeaks a little *too* much hand optimization...
The operations in the MD5 core are based on word-sized chunks.
Obviously, the implentation only does word-sized loads and stores for
that data, and you got a bus error.
> 2. It's a bad idea to ignore the startup/termination costs of the
> algorithms.
Yes. I had included the startup costs in my benchmark, but not the
termination costs, which are large for MD5 as you point out.
> Of course startup/termination is trivial for CRC, but
> it's not so trivial for MD5. I changed the code so that the md5
> update() routine also calls md5_finish_ctx(), so that each inner
> loop represents a complete MD5 calculation for a message of the
> size of the main routine's fread buffer. I then experimented with
> different buffer sizes. At a buffer size of 1K:
On my Celeron, at 1K blocks MD5 is still significantly faster than CRC,
but is slightly slower at 100 byte blocks. For comparison, I added
RIPEMD-160, but it's far slower than any of them (twice as long as CRC).
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/