Re: Hash computation and TFB

[Stefan Bidi]

It just dawned on me that their website says MurmurHash3 is supposed to be super fast compared to one-at-a-time.  Is this not what you saw?  I'd be curious as to why this is.  This thing does 128-bits at a time, instead of 8/16-bits.

On Tue, Aug 6, 2013 at 10:26 AM, Richard Frith-Macdonald <address@hidden> wrote:

On 6 Aug 2013, at 15:43, Stefan Bidi <address@hidden> wrote:

> Richard,
> Back when I was having a look at hash functions, I actually chose Jenkins' lookup3 as a good replacement.  It is also public domain, and has a big and little endian alternative, giving the same results.  It is still very fast (much faster than our current one-at-a-time function).
>
> The reason I shied away from MurmurHash is because it is not very efficient on big-endian machines (according to the website), and it only really optimized for x86 compatible processors.  I also prefer Jenkins' SpookyHash over MurmurHash3 (I just understand the implementation better).

When I picked what hash to try, I just did a survey of comparisons reported on the web (I'm surely not competant to judge the maths msyself).

While MurmurHash2 was supposed to be slow on big endian machines, this was not reported to be the case for MurmurHash3, and I saw one report saying that while SpookyHash was fast, it didn't produce as good a distribution as MurmurHash3 or Lookup3 (and Lookup3 was slower than MurmurHash3).  ie. I picked what appeared to be the best option 1st quarter 2013

Probably all of them are good enough.