最近我和一位同事争论在 32 位代码中使用 64 位变量是否是个好主意。我站在一边说“这可能很危险，会在某个地方减慢我们的速度”，他说“不。不会发生任何不好的事情。”那么谁是对的呢？
我们生态系统部分的位数如下：
Windows：32 位 或 64 位
编译器：仅32位（Delphi...）
处理器：现代英特尔处理器...64 位，不是吗？
假设我们有一些变量使用语言中内置的一些 64 位类型，在 Delphi 中为 Int64。使用基于这些的计算分散代码是否安全（在性能方面）？
【问题讨论】：
标签： performance 64-bit 32-bit
听起来你正在做一些过早的优化。
即使它会对性能造成非常轻微的影响，但随着软件的老化，用户的硬件更有可能使用 64 位计算机。所以这将是一个自我纠正的问题，即使它是一个问题。
如果编译器支持它们，请继续使用它们。如果您发现在进行大量计算的紧密循环中出现减速，那么也许可以考虑改变它。
【讨论】：
这很糟糕。数据占用两倍的内存，所以它就像在一个有一半缓存的处理器上运行。它还需要 2 条指令加载、2 条加法指令和 2 条指令来存储一对数字。您可以使用简单的程序（如素数筛）对此进行测试。在 32 位机器上使用较长的类型，这些通常会运行得更慢，甚至在 64 位机器上，当您获得大于缓存时。最糟糕的是，一旦你把这些东西撒在你的代码上，你就会遇到系统性的性能问题，以后很难纠正。是的，在可以使用短裤的情况下使用 32 位整数也是如此，但仅在内存性能方面 - 32 位 CPU 可以像 16 位一样快地执行 32 位数学 - 所以不用担心（或你的电子表格例如，将仅支持 65K 行）。
【讨论】：
GCC（我怀疑你的 Delphi 编译器要好得多）编译/组装它的 long long 数据数据类型，以便它使用 EAX 和 ECX 寄存器，加载它们已经比只加载其中一个需要更长的时间（如果它是实际上两倍的时间取决于缓存）。然后它会组装多条指令，您只需要一条指令即可。如果您只对单个 32 位值进行操作，则添加/SUB/IDIV。然后按照 EAX 和 ECX 的存储，这再次比仅存储其中一个需要更长的时间。
【讨论】：
在 x64 架构上，如果您只需要 32 位宽的整数，那么使用 32 位宽的整数会产生更快的代码，即使在运行 64 位代码时也是如此。
【讨论】：
这样问自己：
此变量是否需要存储大于 32 位的值，然后从以下选项中进行选择：
如果此答案为“否”，请使用无符号整数。
如果答案是“是”，请使用无符号 64 位 int。 64 位整数的内存不是很贵，加减法也很便宜（乘除法也相当便宜）。
如果答案是“是的，但仅限于 64 位系统”（例如，缓冲区的长度在 64 位上可能大于 4GB，但在 32 位上绝不会），请使用“size_t”。这在 32 位系统上定义为 32 位，在 64 位系统上定义为 64 位。
编写正确的程序，然后让优化器/性能测试帮助您快速获得它。先写快再修，比先写对后快要贵。
【讨论】：