64位环境中32位整数的性能（C ++）

Question

我们已经开始编译某些应用程序的32位和64位版本。我项目中的一个人鼓励我们将所有32位整数切换为64位等值，即使这些值保证适合32位空间。例如，我有一个保证永远不会超过10,000的值，我将其存储在unsigned int中。他的建议是将其切换为size_t，以便在64位环境中扩展到64位，即使我们永远不需要额外的空间。他说，无论每个变量中存储的值如何，使用64位变量都会加速应用程序。他是对的吗？事实证明这是很多工作，如果实际上没有任何影响，我并不急于付出努力。

我们正在使用Microsoft Visual C ++ 2008.我有点希望能提供一个更通用，独立于平台的答案。

那你觉得怎么样？出于性能原因而不是范围原因，我们是否有权花时间更改数据类型？

Answer 1

我认为你有一个巨大的预成熟优化案例，盯着你。在分析器明确告诉您它是重大性能问题的根源之前，切勿在您的应用程序中进行这样的微更改。

否则您将花费​​大量时间修复非问题。

Answer 2

如果32位操作发生在64位寄存器中，则需要发出一些额外的指令来处理诸如设置进位/溢出标志等的事情。如果你意识到任何明显的性能，我会感到惊讶但改善了。我几乎可以保证你的计划中存在更糟糕的瓶颈。

Answer 3

首先，在64位环境中使用64位整数而不是32位整数通常不会加速任何事情。根据上下文和编译器功能，这实际上可能会减慢速度。通常，您应该更喜欢使用int / unsigned int类型在程序中存储整数值，仅在真正需要时切换到其他类型。最后，问题的最终答案只能通过实际的实验来获得，因为它取决于太多的变量。

其次，任何建议将size_t用于此目的（作为通用无符号类型）的人都应立即拒绝访问代码，并在允许再次触摸代码之前发送一些C / C ++类。

Answer 4

不要这样做。它只是意味着cpu将无法在缓存中保存尽可能多的数据，并且进入主内存的代价远远高于大多数其他内容。

Answer 5

使用64位整数与32位整数将加快速度的想法是一个神话。代码中更重要的是使用适当的类型。例如，在引用数组或数据结构的大小时，请使用size_t，因为这是size_t应该表示的内容。如果您要存储某些数据，请使用int而不是size_t，因为这是int要描述的内容。

不要只将所有内容更改为size_t，因为它会“自动变为64位”，这可能会导致任何改进。它将导致更大的内存开销，这可能会导致应用程序由于缓存未命中而因为更大的内存空间而减速。它也很可能会导致意外的错误。

Answer 6

我猜（并且只是一个猜测）你可能看不到性能没有任何改善，如果内存增加量导致一些内存访问丢失了引用的局部性并且推迟了缓存比以前更频繁。

作为JaredPar says，如果没有事实理由这样做，或者除非你需要更大范围的更大的整数，这可能是浪费时间。