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 < richardfrithmacdon...@gmail.com> wrote: > > On 6 Aug 2013, at 14:39, Richard Frith-Macdonald < > richardfrithmacdon...@gmail.com> wrote: > > > > > On 6 Aug 2013, at 14:30, Stefan Bidi <stefanb...@gmail.com> 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.
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
