64位环境中32位整数的性能(C++)

Dar*_*ryl 12 c++ performance integer

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

我们正在使用Microsoft Visual C++ 2008.我有点希望能提供更一般,平台无关的答案.

所以你怎么看?出于性能原因而不是范围原因,我们是否有权花时间更改数据类型?

Jar*_*Par 17

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

否则你会花很多时间来解决非问题.


Car*_*rum 9

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


AnT*_*AnT 7

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

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

  • 反驳:short/int/long/etc使用起来有些风险,因为它们的行为并不能保证在所有平台上都是一样的.例如,如果存储将值存储为int,则在某些平台上,最大可存储值为(2 ^ 31)-1,而在某些平台上则为(2 ^ 63)-1.在许多情况下,行为的改变不会产生任何差别,但在某些情况下会发生变化,并且在前面并不总是很明显,哪些情况是哪种情况.因此,int32_t,int64_t等是首选,因为它们在所有情况下都明确定义了类型的行为. (2认同)