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 < [email protected]> wrote: > > On 6 Aug 2013, at 15:43, Stefan Bidi <[email protected]> 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.
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
