Re: Hash computation and TFB

[Stefan Bidi]

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).

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

On 6 Aug 2013, at 14:39, Richard Frith-Macdonald <address@hidden> wrote:

>
> On 6 Aug 2013, at 14:30, Stefan Bidi <address@hidden> wrote:
>
>> I copied the hash algorithm straight out of -base, so they should match.  I remember a few months ago Richard was playing around with hash functions and this might be causing some issues, now.
>
> It wouldn't on a normal setup ... the experimental hash code is used only if you explicitly build it.

Incidentally, the new hash looks to give a really good distribution, but is significantly slower.  That would make it poor for listeral strings.

But ... I recall David mentioning the possibility of changing the layout of literal objects produced by the compiler.

Perhaps it would not be unreasonable to add a flag to clang to get it to use MurmurHash3 (which is public domain) to generate the literal string hash at compile time ... so that we could use it directly from gnustep-base (and corebase).  That would give us a great hash distribution and zero computation time for literal strings.