5 ms·

This is not a full-blown hash function, just a mixer, like in murmur. It hashes only a single word, not a buffer. Haven't yet checked how good it is, but it's d

by rurban 5y ago

This is not a full-blown hash function, just a mixer, like in murmur. It hashes only a single word, not a buffer. Haven't yet checked how good it is, but it's definitely a bit slower than fnv1, and faster than murmur. Will add it to smhasher soon, as soon as I get the unaligned part written. So far it doesn't look too good.

MuffinFlavored 5y ago
> This is not a full-blown hash function Meaning it's super easy to create collisions? How easy exactly?
- ivanbakel 5y ago
  Not the GP, but in the sense that it can't be used to hash arbitrary (word-padded) data. This "hash" can only turn words into other words. A true hash function needs to produce a hash from a multi-word buffer, and do so in a way that all the data in the buffer is equally significant to the final hash value.
- GuB-42 5y ago
  No, it means it does only half of the job. It can only take an input of fixed size and return an output of the same size. "True" hash functions take an input buffer of an arbitrary size, and return an output of a fixed size. The mixer can be a part of the complete hash function, often the key part, but it is not the entire thing.
  - deleted 5y ago
    [deleted]
aappleby 5y ago
Thanks for maintaining your SMHasher fork by the way, I've got too darn many other projects. :)
anfilt 5y ago
I will add that 32 bit version compiles quite nicely on arm. It's also what made me try something with this structure. https://godbolt.org/z/abd79sEh1 https://godbolt.org/z/abd79sEh1 As for x86/x86_64 processors compiling with a flag like -march=broadwell will remove quite few movs from the compiled code since the RORX instruction will be available which can take two register parameters, and a constant. Unlike the normal ROR instruction which is just a register and constant or the CL register for the rotation amount. Now compared to functions that use multiplication. Multiplication can mix bits quite quickly. If the hardware multiplier is fast I don't think it would be faster with than fnv1 considering how simple that function is.

by rurban 5y ago

MuffinFlavored 5y ago

> This is not a full-blown hash function Meaning it's super easy to create collisions? How easy exactly?

ivanbakel 5y ago
Not the GP, but in the sense that it can't be used to hash arbitrary (word-padded) data. This "hash" can only turn words into other words. A true hash function needs to produce a hash from a multi-word buffer, and do so in a way that all the data in the buffer is equally significant to the final hash value.
GuB-42 5y ago
No, it means it does only half of the job. It can only take an input of fixed size and return an output of the same size. "True" hash functions take an input buffer of an arbitrary size, and return an output of a fixed size. The mixer can be a part of the complete hash function, often the key part, but it is not the entire thing.
- deleted 5y ago
  [deleted]

aappleby 5y ago

Thanks for maintaining your SMHasher fork by the way, I've got too darn many other projects. :)

anfilt 5y ago

I will add that 32 bit version compiles quite nicely on arm. It's also what made me try something with this structure. https://godbolt.org/z/abd79sEh1 https://godbolt.org/z/abd79sEh1 As for x86/x86_64 processors compiling with a flag like -march=broadwell will remove quite few movs from the compiled code since the RORX instruction will be available which can take two register parameters, and a constant. Unlike the normal ROR instruction which is just a register and constant or the CL register for the rotation amount. Now compared to functions that use multiplication. Multiplication can mix bits quite quickly. If the hardware multiplier is fast I don't think it would be faster with than fnv1 considering how simple that function is.