wyhash V5 draft is out about wyhash HOT 16 CLOSED

This may be relevant:

Faster 64-bit universal hashing using carry-less multiplications, Journal of Cryptographic Engineering 6(3), 2016

Source code

from wyhash.

The draft becomes a version now. As you known, I update it too quickly because I stay at home due to the flu. Test it and enjoy it but no hurry to update :-)

from wyhash.

__builtin_popcountll can not used on ms vc++(_mm_popcnt_u64)

from wyhash.

done.
In order to be fast, I also provide WYHASH_PART define, which means no avalanche finalization is performed. It breaks many quallity rules, however, it offer uncompetable performance for hash table.
hash short hashmap bulk16M
wyhash_part 281.818 53.466 23.536
wyhash 258.874 47.490 23.873

from wyhash.

add support clang compiler with marco clang

from wyhash.

I am not familar with clang, can you help me by a pull request?

from wyhash.

your can download form https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1,
use is same as gcc on no-win os. And it can be easy integrated in vs 2017/2019.

I have change some of your code https://github.com/ktprime/emhash/blob/master/thirdparty/wyhash.h
I use wyhash in my c++ flast hash map(string key), speed is the key factor.

from wyhash.

try https://travis-ci.org/ to trigger test matrix for all supported compilers after each commit

from wyhash.

in _wyhash function, the bulk processing part could be implemented via SSE/AVX instructions.

from wyhash.

really? I know that AVX has 32 X 32 => 64 function, but what I need is 64 X 64 =>128 function. would you give me more hints （instruction name)? thanks!

from wyhash.

PMULUDQ ?

from wyhash.

yes, 64bit MUL can only get low 64bit result now.

But vectorizing 32-bit version MUM could still speed up for long keys.

PS, v5 is a little slow for shot keys, although reducing one xor operation, but we could have to use cycles for loading memory from secret[6] not const _wyp*.

from wyhash.

But vectorizing 32-bit version MUM could still speed up for long keys.
the magic is 32 X 32 will fail tests, while 64 X 64 passes tests.

PS, v5 is a little slow for shot keys, although reducing one xor operation, but we could have to use cycles for loading memory from secret[6] not const _wyp*.
you can make_secret offline, write it to a include file as constant.

from wyhash.

I doubt it helps here, but my C# port uses BMI2's MULX operation, which gives both the high and parts in a single operation, providing a nice speed up.

But I would presume the C compiler would automatically use this, or an equivelant.

from wyhash.

On x64, you can always get the low and high 64-bit components in one instruction. The mulx is there mostly to help with dependencies.

from wyhash.

On x64, you can always get the low and high 64-bit components in one instruction. The mulx is there mostly to help with dependencies.

Not in .NET you don't 😖

from wyhash.