Re: Re: CRC

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(at)em(dot)ca> http://em.ca/~bruceg/