Re: CVS commit: src

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sun, Jul 08, 2012 at 10:08:15PM +0100, Mindaugas Rasiukevicius wrote:
> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> > > Log Message:
> > > Add MurmurHash2 -- a non-cryptographic hash function by Austin Appleby.
> > > The code is taken from the upstream and is in the public domain.
> > > 
> > > OK christos@
> > 
> > There are a number of issues with this. First of all, it pollutes the
> > global namespace and can't be used safely from libc the way it is done.
> 
> How do you suggest to do it?

Look at the weak symbol handling in other places.

> > Second, I don't really like adding a special purpose name of a hash
> > function which is explicitly not designed to be endian neutral. We
> > should provide a fast hash function and be able to change it without
> > breaking assumptions, which this is not doing.
> 
> Well, the added function is endian-neutral and is generic implementation.
> Idea is to provide optimised functions per architecture.  They would
> merely override the generic one, but produce the same result regardless
> of endianess.  Do you want to do it differently?

If the desired property here is fast, endian neutral adds overhead
without benefit. Depending on the architecture, other hashes can be made
more efficient, e.g. depending on availability of hardware rotation,
complex encodings for immediate constants, speed of multiplication etc.
Basically, there are a lot of reasons why *the* fast hash function
doesn't exist, even in a tight family to choose from. That's why
murmurhash or similar names is IMO a bad interface contract.

If you don't care about speed, I don't think there is a real advantage
to Jenkin's hash.

Joerg