不可移植算法的带宽数据

以下算法在现代 x64 cpu 上运行，但要么不可移植，要么它们的性能取决于非保证指令集的存在（比如：仅SSE2在 上有保证x64）。测试环境同上，但编译标志现在是-O3 -mavx2.

x64 上的带宽，各种数据大小为 len 2^N

x86 上的带宽，各种数据大小为 len 2^N（32 位）

上面研究了 64 位性能，其中 64 位哈希具有优势，如果仅仅是因为更快地摄取数据。这种情况在 32 位系统上发生了巨大变化，因为在 32 位指令集上模拟 64 位算术会对性能造成很大影响。

下图显示了这些哈希算法在 32 位模式下的表现。他们中的大多数都显示性能的大幅下降。只有 32 位哈希保持其性能，例如XXH32. XXH3也在 32 位 CPU 上结果很好。

专注于小数据的基准测试：

在许多用例中，生成的哈希值可用于填充哈希表或布隆过滤器。在这些场景中，哈希算法经常只是更大系统（例如数据库）的一部分，并且会为许多相当小的对象调用。散列小对象时，散列属性与散列“大”输入相比可能会有很大差异。例如，一些算法可能有很长的开始或结束阶段，在小输入中占主导地位。下面的测试试图捕捉这些特征。

固定长度 N 小数据的吞吐量

吞吐量测试尝试生成尽可能多的哈希值。这通常是衡量的标准，因为它是最简单的基准测试方法。但是，它仅代表“批处理模式”场景，并且还要求所有输入具有完全相同的长度。所以它实际上根本就没有那么有代表性。

随机长度的小数据吞吐量 [1-N]

在这个更高级的场景中，输入长度不再稳定。这种情况通常更常见，因此该场景更有可能代表某些真实用例。但是，作为吞吐量测试，它仍然针对批处理模式场景，其中必须重复生成大量散列。在下图中，长度实际上是随机的，从生成的 1 和 N 之间的值系列中读取。这种情况在分支预测器上要困难得多，它可能会错过很多猜测，偶尔会触发pipeline flush。对于小输入，这种负面影响会迅速影响性能。一些算法是更好的设计来抵抗这种副作用。

固定长度 N 的小数据的延迟

延迟测试要求算法在开始下一个哈希之前完成一个哈希。这通常更能代表将散列集成到更大算法中的情况。