On 29/11/2023 15:31, John Naylor wrote:
> However, I did find a couple hash functions that are much simpler to
> adapt to a bytewise interface, pass SMHasher, and are decently fast on
> short inputs:
>
> - fast-hash, MIT licensed, and apparently has some use in software [1]
> - MX3, CC0 license (looking around, seems controversial for a code
> license, so didn't go further). [2] Seems to be a for-fun project, but
> the accompanying articles are very informative on how to develop these
> things.
>
> After wacking fast-hash around, it doesn't really resemble the
> original much, and if for some reason we went as far as switching out
> the mixing/final functions, it may as well be called completely
> original work. I thought it best to start with something whose mixing
> behavior passes SMHasher, and hopefully preserve that property.
I didn't understand what you meant by the above. Did you wack around
fast-hash, or who did? Who switched mixing/final functions; compared to
what? The version you have in the patch matches the implementation in
smhasher, did you mean that the smhasher author changed it compared to
the original?
In any case, +1 on the implementation you had in the patch at a quick
glance.
Let's also replace the partial murmurhash implementations we have in
hashfn.h with this. It's a very similar algorithm, and we don't need two.
--
Heikki Linnakangas
Neon (https://neon.tech)