1

背景

我在 OpenGL 渲染管道的一个阶段中使用了一个小型静态哈希表（线性探测），我必须尽可能快地检索和更新 int64_t 类型的键和一些数据。简而言之，这个阶段是关于将大 ID 转换为后续阶段使用的小本地索引（所以在这个阶段我需要处理一次 64 位密钥，并且不能使用 32 位密钥）。

我已经尝试了很长时间，以找到一个在 32 位和 64 位 arm 架构（iOS 和 Android 智能手机）上都能快速运行的哈希函数。自然，在 32 位设备上散列 64 位密钥比散列 32 位密钥慢得多（在我的测试用例中几乎是 10 次）。

我现在对我在 SO 上找到的哈希非常有信心，它在我的情况下优于 MurmurHash3 32 位终结器（有更多的碰撞，但在我的情况下并不重要）： https ://stackoverflow.com/a /12996028/1708349

现在一切都很好，但这里有一个问题：我天真地将 64 位密钥分配给 int32_t 类型，然后再对其进行散列 - 这是出于 32 位平台的性能原因。这似乎可行，大数据被包裹起来。但是问题当然是没有定义这种行为。

所以，我的问题是：将 int64_t 类型分配给 int32_t 类型的最佳（例如定义的编译器行为）是什么，所以它会环绕 - 例如不只是分配 64 位 int 的低 32 位？

这是我的实际哈希函数：

inline int32_t hash2(int64_t k) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wconversion"
    int32_t x = k;
#pragma clang diagnostic pop
    x = ((x >> 16) ^ x) * 0x45d9f3b;
    x = ((x >> 16) ^ x) * 0x45d9f3b;
    x = ((x >> 16) ^ x);

    return x;
}
4

0 回答 0