NABhash 欢迎试用， 40GB/s 哈希速度

跟 xxhash 对比有啥优势吗？

40g ……有点夸张 mark 明天再看

meow hash 啊，利用硬件 aes 指令来达到这速度，挺好挺好

官网打不开

支持一下，一直在关注楼主的博客😁

@hearfish 参考了 meow hash 的思路，主要是 meow hash 在 final block 的处理上太复杂了, nab 把长度按 uint64 xor 进 state 里就行了。

@blless 快一些～

楼主你的使用场景是什么，既然是基于 AES 那就不是标准 hash，为什么我不用更快的 crc32 呢

@murmur crc32 是纠错用的，不是 hash 用的…

@reus 实际上 crc32 广泛的用来做 hash

@murmur hash 没有标准不标准。
只有是否 Crypto-Safe 和 SMhasher 测试过不过的问题。
For Fun 也是一个作用嘛~

@tempdban 那就用得有问题了。hash 只是 checksum 的子集，checksum 并不保证冲突，只是校验有没有更改。

@mengzhuo hash 又不是只能当签名用？

@mengzhuo “那就用得有问题了” 还是建议少说这种话

data size: 4350
goos: windows
goarch: amd64
pkg: gitlab.dianchu.cc/DevOpsGroup/goutils/structhash
BenchmarkSpeed/xxhash-8-12 30000000 39.2 ns/op 204.07 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-8-12 20000000 73.0 ns/op 109.54 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-16-12 30000000 40.6 ns/op 394.15 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-16-12 20000000 72.1 ns/op 221.90 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-32-12 50000000 40.2 ns/op 796.20 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-32-12 20000000 70.6 ns/op 453.30 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-64-12 30000000 42.3 ns/op 1512.89 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-64-12 20000000 62.6 ns/op 1021.62 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-128-12 30000000 47.2 ns/op 2710.10 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-128-12 20000000 62.9 ns/op 2034.49 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-256-12 30000000 55.9 ns/op 4577.90 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-256-12 20000000 64.6 ns/op 3961.26 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-512-12 20000000 73.0 ns/op 7018.40 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-512-12 20000000 67.1 ns/op 7625.44 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-1024-12 20000000 106 ns/op 9648.91 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-1024-12 20000000 73.3 ns/op 13975.12 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-2048-12 10000000 181 ns/op 11261.76 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-2048-12 20000000 89.7 ns/op 22825.68 MB/s 80 B/op 2 allocs/op
BenchmarkSpeed/xxhash-4096-12 5000000 323 ns/op 12679.08 MB/s 8 B/op 1 allocs/op
BenchmarkSpeed/nabhash-4096-12 10000000 124 ns/op 32986.55 MB/s 80 B/op 2 allocs/op

win10 i8700 go1.12 跑了下测试
我用的 https://github.com/cespare/xxhash
数据大于 512 字节开始就比 xxhash 快了

@tempdban 哦，你喜欢啦。

@tempdban

不是语气问题。
Hash 至少要满足 collision free 的，至少 CRC32 是不满足的，拿来做 Hash 就会出现重复键的数据，程序就会出错的。

https://stackoverflow.com/questions/460576/hash-code-and-checksum-whats-the-difference

@mengzhuo https://doc.dpdk.org/api/rte__hash__crc_8h.html 本来我没想和你犟这个事，你贴的网页你自己都不看的么。
“拿来做 Hash 就会出现重复键的数据”
你的 HASH 能没有冲突？

@tempdban 这个 Collision free 是指可行的范围内，不要强掰“所有 hash 都不能冲突”。
CRC32 只能生成 32 位的 hash 值，也就是最多 2^32 个数据（ 4294967296 ），也就 40 亿。
sha1，ipv6 或者我的算法都是 128 位，最多 2^128 （ 3.4028237e+38 ），比所有目前可观测的星星都多 200 倍。

p.s. 为了验证冲突率，我还特意添加了 Smhasher
https://github.com/aappleby/smhasher/wiki/SMHasher
结果所有测试都通过了，这下我更加放心了。

@bestkayle 好了，加了张图

Github page 真香哈

@mengzhuo 没完没了了，我 CRC32 几个周期，你的 hash 几个周期，可行范围内，你知道我可行范围是啥啊。
我完全没说你的算法问题，我只是告诉那个人，有很多 hash 是 CRC 做的，完全不带情绪。
第一条甚至都没 @你
你的东西好，行，高性能软件里无数的 hash 都是 CRC 做的，人也没觉得冲突大啊。
那就用得有问题了，这是你原话，这些年用的好好的凭什么到你这就有问题。
我就问你 crc32 能不能做 hash ？扯这么多干什么

@tempdban 我一开始就应该说 crypto-safe hash。AES 是 crypto-safe 的 hash，crc 不是，所以 crc 就算再快，也不能替代。

@reus 这话没毛病。
不过有的人就是实现个性能还不错的哈希表，crc32 是首选。
但是咱不能说
crc32 是纠错用的，不是 hash 用的…
老哥你当时多打两个字 我和楼主就没必要犟这么半天了