【问题标题】:difference between hashing on x86 or x64x86 或 x64 上的散列之间的区别
【发布时间】:2011-02-19 10:40:08
【问题描述】:

我想在我的代码中实现一个 hashmap,所以我决定坚持使用murmurhash3

我目前只交付为 x86 编译的程序,并尝试保持代码通用,因此我在 x64 上运行程序从来没有遇到过问题。

现在我查看了 murmurhash 的头文件,该库提供了以下功能:

MurmurHash3_x86_32
MurmurHash3_x86_64
MurmurHash3_x86_128

MurmurHash3_x64_32
MurmurHash3_x64_64 
MurmurHash3_x64_128 

这是否意味着我必须使用 x64 函数并提供 x64 可执行文件才能在 x64 系统上使用此哈希库?或者我可以简单地使用 x86 版本,而只是遇到性能较差的问题?

我认为 _32 _64 _128 位版本仅意味着更多位版本提供更好的分发是否正确?

【问题讨论】:

  • 为什么不直接使用boost::unordered_map
  • 真正加速关键问题。需要在有限的时间内进行数千次操作,而提升性能几乎要差 10 倍

标签: c++ hash murmurhash


【解决方案1】:

编辑:查看murmurhash3 documentation 后更改了所有内容。

首先,_x86 变体是可移植的哈希算法。 _32/_64/_128 表示散列的宽度(以位为单位)。一般 _32 应该没问题,只要你的哈希算法小于 232 个桶。

_x64 变体是完全不同的散列算法家族。所有 _x64 变体都基于 _x64_128 实现 - 一个 128 位哈希。然后他们丢弃部分哈希以获得 _32 和 _64 位大小。这可能会也可能不会比 _x86 变体更快——尽管文档声称有一些令人印象深刻的加速。但是请注意,它很可能会获得与 x86 变体不同的哈希值。

【讨论】:

    【解决方案2】:

    x86 表示该算法针对 32 位平台进行了优化。这意味着它对 32 位无符号整数进行操作。

    x64 随后针对 64 位平台进行了优化,在 64 位无符号整数上运行。

    另外,两者之间的结果不兼容。相同输入的哈希值会有所不同,具体取决于它是 MurmurHash3_x86_128 还是 MurmurHash3_x64_128

    这是否意味着我必须使用 x64 函数并提供 x64 可执行文件才能在 x64 系统上使用此哈希库?或者我可以简单地使用 x86 版本,而只是遇到性能较差的问题?

    64 位哈希函数可以为 32 位系统编译,但最终会非常慢,因为编译器将计算分成两部分。如果 32 位支持很重要,您应该使用 x86 优化函数,而不是 x64 优化函数。在 x64 系统上,32 位代码运行良好,尽管我认为这是未充分利用的。 x64 优化算法在 64 位 CPU 上效率更高。

    我认为 _32 _64 _128 位版本仅意味着更多位版本提供更好的分布是否正确?

    我想答案是是的。如果通过分发您的意思是“不太可能导致冲突”。散列中使用的每一个额外的内存位都会大大增加可能结果的数量。 4 位散列有 16 个可能的散列,而 64 提供 18 quintillion(128 然后提供 340.2 undecillion!)。 256 位提供了如此多的信息,通常足以用于加密安全目的。


    需要注意的其他事项:最近,现代哈希函数利用新的 CPU 指令集,例如 CRC32、AES、SSE2、SIMD - 其中函数利用特定的 CPU 功能/指令在支持的硬件下实现更好的性能。这可以大大加快支持这些现代功能的 CPU 上的散列速度。

    【讨论】:

    • 不理解投反对票,我回答了问题并解释了 MurmurHash3 的 x86 和 x64 实现之间的区别。
    猜你喜欢
    • 2011-11-29
    • 2014-05-07
    • 2020-05-27
    • 1970-01-01
    • 2011-10-04
    • 2010-10-20
    • 2010-09-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多