Xxhash: 与 crc32 的更新速度比较

问题是，
基准测试在 Core 2 Duo @3GHz 上运行。
此 CPU 不支持硬件 crc32c。

此外，crc32 和 crc32c 相似但算法不同：您不会得到相同的结果。
crc32 被广泛使用，而 crc32c 则少得多。 这种命名混淆可能会导致重要的互操作性问题。

这里的 crc32 版本是 smasher 测试套件中提供的版本。
存在更快的版本，包括矢量化版本。
它需要修改测试套件以集成它们。

如果您可以容忍您的应用程序依赖英特尔，并且可以保证您的所有客户端 CPU 都足够新（这在 2016 年是合理的），那么您可以使用硬件 crc32c，它确实非常快。

xxHash 是在不同的上下文中创建的，使用没有此功能的 cpu，其预期目标是最大的可移植性，远远超出英特尔的领域（arm、mips、power 等）。 因此，不依赖于品牌特定的功能。

@Cyan4973
作为一个非常晚的后续行动，与 crc32c 相比，您能否提供一些关于新 XXH3 的见解？

硬件crc32c本身没有竞争力。 虽然它肯定比软件 crc32 快，但它无法跟上大多数现代哈希算法使用的 ILP。

但是，并行的多个crc32c通道会更有效。 在这种情况下，确切的结果取决于实现。 可以在 Internet 上找到许多实现。 我发现了几个可以最好的XXH64速度的实现，但还没有一个可以最好的XXH3 。 也许这是搜索更多的问题。

使用英特尔的 pclmulqdq 或 ARMv8 CLMUL 指令可以非常高效地实现 CRC32 和 CRC32C。

前段时间我使用 CRC32 和 CLMUL 指令将几个 ARM 实现放在一起，它们的速度在 rk3399 上浮动在 4.1GB/s 左右。 现在我将它们与 xxh32 和 xxh64 进行比较，分别得到 3.5GB/s 和 2.5GB/s。

在ARMv8上是不是期望xxh64比xxh32慢，或者有什么问题？

预计xxh64 xxh32在 32 位二进制文​​件上比
虽然在 64 位二进制文​​件上，这不太可能，但人们仍然可以想象一种具有弱/慢 64 位乘法指令的芯片，比 32 位乘法指令慢得多，在这种情况下，这是可能的。
不幸的是，ARMv8 系列芯片非常庞大，每个芯片的性能权衡都有很大不同。 所以我会说这种情况必须发生在某个地方，但我不会把它作为规则。

为了在 ARM 上获得更快的 64 位哈希，您可能有兴趣尝试最新版本中的更新XXH3_64bit() 。

谢谢！
二进制文件是 64 位的。
XXH3_64bit肯定表现得更好。 不使用 NEON 矢量化，我得到 3.9GB/s，而 NEON 接近 4.0GB/s。 尽管如此，使用vmull_p64 CRC32 的吞吐量还是稍好一些。