性能 32 位与 64 位算术答案

【问题标题】：Performance 32 bit vs. 64 bit arithmetic性能 32 位与 64 位算术
【发布时间】：2012-02-15 11:04:50
【问题描述】：

本机64 bit 整数算术指令是否比它们的32 bit 计数器慢（在x86_64 机器上和64 bit 操作系统上）？

编辑：在当前的 CPU 上，例如 Intel Core2 Duo、i5/i7 等。

【问题讨论】：

@Cody：哦，真的吗？您声称 64 位整数除法与 32 位整数除法一样快？
你说得对。阅读下面大卫施瓦茨的解释。在 CPU 的 ALU 中执行指令是一回事。将操作数放入 CPU 并将结果从 CPU 中取出是另一回事。
相关：The advantages of using 32bit registers/instructions in x86-64

【解决方案1】：

我只是偶然发现了这个问题，但我认为这里缺少一个非常重要的方面：如果您真的使用“int”类型作为索引来查看汇编代码，可能会减慢编译器生成的代码。这是因为在许多 64 位编译器和平台（Visual Studio、GCC）上，'int' 默认为 32 位类型，并且使用指针（在 64 位操作系统上必须是 64 位）进行地址计算，而 'int' 将导致编译器发出不必要的32 位和 64 位寄存器之间的转换。我刚刚在我的代码的性能非常关键的内部循环中经历了这一点。当循环索引从“int”切换到“long long”时，我的算法运行时间提高了大约 10%，考虑到我当时已经使用的广泛的 SSE/AVX2 矢量化，这是一个相当大的收益。

【讨论】：

您能否提供对该特定示例的访问权限？我目前处于同样的困境（重度 AVX2 矢量化等），我不确定是否值得，另外，请注意循环索引的类型。

【解决方案2】：

在主要是 32 位应用程序中（意味着只使用 32 位算术，并且 32 位指针就足够了），x86-64 架构的真正好处是 AMD 对该架构进行的其他“更新”：

16 个通用寄存器，x86 中为 8 个
RIP 相对寻址模式
其他...

这在 Linux 中实现的新 x32 ABI 很明显。

【讨论】：

【解决方案3】：

这取决于确切的 CPU 和操作。例如，在 64 位 Pentium IV 上，64 位寄存器的乘法运算要慢很多。 Core 2 及更高版本的 CPU 从头开始设计用于 64 位操作。

通常，即使是为 64 位平台编写的代码也使用 32 位变量，其中值适合它们。这主要不是因为算术更快（在现代 CPU 上，通常不是），而是因为它使用更少的内存和内存带宽。

如果这些整数是 32 位的，则包含十几个整数的结构的大小将是 64 位的一半。这意味着它需要一半的字节来存储，一半的缓存空间，等等。

64 位本机寄存器和算术用于可能不适合 32 位的值。但主要的性能优势来自 x86_64 指令集中可用的额外通用寄存器。当然，还有 64 位指针带来的所有好处。

所以真正的答案是这并不重要。即使您使用 x86_64 模式，您也可以（并且通常会）仍然使用 32 位算术，并且您可以获得更大的指针和更通用的寄存器的好处。当您使用 64 位本机操作时，这是因为您需要 64 位操作，并且您知道它们比使用多个 32 位操作伪造它要快——这是您唯一的选择。因此，32 位与 64 位寄存器的相对性能永远不应成为任何实现决策的决定因素。

【讨论】：

谢谢，但我在这里只关心 CPU 周期。缓存未命中问题和类似问题绝对没问题，但那是另一回事了。
那我的第一句话就回答了你的问题。但我更大的观点是，这并不重要。在 32 位算术可以使用的地方不使用 64 位算术。因此，相对表现绝不应成为任何决定的决定性因素。
你有什么具体的例子吗？比方说Core2 Duo。还是链接？
参见instruction timing table的第47页。
我正在实现一个多线程的素筛，并使用一个位域来表示结果。我到达这个站点时想知道使用什么大小的整数作为底层存储，但没有给出有意义的答案。在这种特殊情况下，“相对性能永远不应成为任何决定的决定因素”是错误的。我选择了 32 位，以减少多线程时潜在的冲突次数，并减少内存带宽。但是，64 位最终可能会更高效，因为我还使用 popcount 和 bitscan 操作来迭代/定位结果。