使用64位变量和32位系统时，瓶颈在哪里？

Question

一位同事和我最近在讨论在32位代码中使用64位变量是否是一个好主意。我采取了一个方面说“这可能是危险的，让我们放慢某个地方”，他说：“不。没有什么不好的事情会发生。”那么谁是对的？

我们生态系统的部分内容如下：

Windows： 32位或 64位

编译器： 32位（Delphi ...）

处理器：现代英特尔处理器...... 64位，不是吗？

假设我们有一些变量使用了语言中内置的64位类型，Delphi就是Int64。使用基于这些的计算来分散代码是否安全（性能方面）？

Answer 1

听起来你正在做一些过早的优化。

即使它会导致性能受到轻微影响，但随着软件老化，用户的硬件更有可能拥有64位计算机。如果这是一个问题，那将是一个自我纠正的问题。

如果编译器支持它们，请继续使用它们。如果你发现一个包含大量计算的紧凑循环减速，那么可以考虑改变它。

Answer 2

GCC（我怀疑你的Delphi编译器要好得多）编译/汇编它的long long数据数据类型，以便它使用EAX和ECX寄存器，加载它们所花费的时间比仅加载其中一个（如果是实际上双倍的时间取决于缓存）。然后它组装多个指令，你只需要一个例如如果您只使用一个32位值，则ADD / SUB / IDIV。然后按照EAX和ECX的商店进行操作，这比再只存储其中一个更长。

Answer 3

这很糟糕。数据占用内存的两倍，因此就像在具有一半缓存的处理器上运行一样。它还需要2个加载指令，2个要添加的指令和2个存储一对数字的指令。您可以使用素数筛等简单程序对其进行测试。在32位机器上使用较长类型时，这些通常会慢得多，甚至在大于缓存时也会在64位机器上运行。最糟糕的是，一旦你在代码中撒了这些东西，你就会遇到系统性能问题，以后很难纠正。是的，使用可以使用短路的32位整数也是如此，但仅限于内存性能 - 32位CPU可以像16位一样快速地进行32位数学运算 - 所以不用担心（或者你的电子表格）例如，只支持65K行。

Answer 4

在x64架构上，如果你只需要32位宽的整数，那么即使运行64位代码，使用32位宽的整数也会产生更快的代码。

Answer 5

问问自己：

此变量是否需要存储大于32位的值，然后从以下选项中进行选择：

如果此答案为“否”，请使用unsigned int。

如果答案为“是”，请使用无符号的64位int。 64位整数的内存不是很昂贵，加法或减法也很便宜（并且相加便宜）。

如果答案是“是，但仅限于64位系统”（例如，缓冲区的长度在64位上可能> 4GB但从不在32位上），请使用“size_t”。在32位系统上定义为32位，在64位系统上定义为64位。

编写您的程序是正确的，然后让优化器/性能测试帮助您快速获得它。你首先快速写它并稍后修复它比你先写正确并稍后快速写它更贵。