C ++：在范围内获取整数的最快方法

Question

我需要为大约 N=1 亿个键生成哈希键。从我的研究看来，murmur3（MurmurHash3_x86_32，参见murmur3 hash）将是最快的散列函数，具有最佳的延迟和足够小的碰撞率。我面临的问题是该函数将键返回为void *。更具体地说，模板是：

void MurmurHash3_x86_32 (const void *key, int len, uint32_t seed, void *out);

由于我的哈希表大小会小于它可以生成的最大哈希值，我需要将它放入表范围 [0, N-1] 中。最简单的解决方案似乎是使用% 运算符。但由于它的操作速度很慢，我想知道是否有更快的方法来解决这个问题。

我发现一个有趣的建议是在 StackOverflow 本身上给出的 Is there an alternative to using % (modulus) in C/C++?。它暗示“二的幂，以下作品（假设二的补码表示）”：

return i & (n-1);

我的问题是，在较新的 CPU 上，有时（或者大多数时候？），由于多路缓存行，性能会在大约 2^n，IIRC 大小时下降。 （此链接提供了有关插入的说明 Big Memory, Part 3.5: Google sparsehash!）。

目前，murmur3 的优势似乎被硬件相关问题和% 运算符的已知效率低下所抵消。由于性能是一个限制因素，我要求低延迟和更快的解决方案来满足我的要求，即使它不是 MurmurHash3_x86_32。

Answer 1

我面临的问题是该函数将键返回为void *。

它没有。它什么也不返回 (void)。哈希结果记录在您通过最后一个参数指定（指向）的缓冲区中。对于MurmurHash3_x86_32()，将其作为指向uint32_t 的指针是最有意义的。

由于我的哈希表大小会小于它可以生成的最大哈希值，我需要将它放入表范围 [0, N-1] 中。最简单的解决方案似乎是使用 % 运算符。但由于它的操作速度很慢，我想知道是否有更快的方法来解决这个问题。

% 不仅是最简单的解决方案，而且是最常用的解决方案。 “慢”是相对的——% 比 + 慢，但是比一次调用 MurmurHash3_x86_32() 快很多，很多。

我发现一个有趣的建议 [...] 建议 [使用二次方表大小，并通过 & 运算符计算模数]

请注意，与 SO 答案中的断言相反，实际上这完全不依赖于二进制补码表示。

我的问题是，在较新的 CPU 上，有时（或者大多数时候？），由于多路缓存行，性能会在大约 2^n，IIRC 大小时下降。 （此链接提供了有关插入大内存的说明，第 3.5 部分：Google sparsehash！）。

您链接的报告中描述的性能下降归因于重新散列，这似乎很合理。这与您要询问的操作无关。可以想象，缓存（缺乏）关联性可能会影响大型哈希表的性能，但可能不会比拥有大型哈希表的影响更大。使用哈希表所固有的内存访问模式自然会产生较差的缓存局部性。这实际上是要点。

目前，murmur3 的优势似乎被硬件相关问题和 % 运算符的已知低效率所抵消。由于性能是一个限制因素，我要求为我的要求提供低延迟和更快的解决方案，即使它不是 MurmurHash3_x86_32。

你想太多了。无法有效使用 CPU 缓存只是您为使用大型哈希表所付出的代价。它与散列函数无关（只要散列函数做得好）。单个算术运算的成本，无论是 % 还是 &，与计算散列以操作 的成本相比，都不会显着，所以你使用哪一个几乎无关紧要选择。如果您希望该操作获得微小优势，请使用大小为 2 的表和 & 运算符。另一方面，这会丢弃一些您费力计算的哈希位。考虑改为选择 prime 哈希表大小和 % 运算符 - 然后所有哈希位将有助于桶选择，这可能会改善您的传播。