在阅读70-536培训套件时，其指出：
运行时会优化32位整数类型（Int32）的性能，因此将这些类型用于计数器和其他频繁访问的整数变量。
这只适用于32位环境吗？在64位环境中，是否应该使用Int64，还是Int32仍然是更好的选择？
5个回答
6
这种说法很有趣。运行时与此无关。
CPU被设计用于处理32位整数，这就是为什么它们是最有效的。
在64位环境中，这又取决于CPU。然而，至少在x86 CPU上（据我所知，这是.NET运行的唯一地方），32位整数仍然是默认值。寄存器只是扩展了，以便可以容纳64位值。但32位仍然是默认值。
所以即使在64位模式下，也要优先选择32位整数。
编辑：“默认”可能不是正确的词。CPU只支持一些指令，这些指令定义了它可以处理哪些数据类型，哪些不能处理。那里没有“默认”值。然而，通常有一个数据大小，CPU被设计为可以高效处理。在x86上，在32位和64位模式下，这是32位整数。64位值通常并不更昂贵，但它们意味着更长的指令。我还相信至少64位Pentium 4在64位操作方面明显较慢，尽管在最近的CPU上，这部分不应该是问题。（但指令大小仍可能是）
小于32位的值有点令人惊讶。是的，传输的数据较少，这很好，但CPU仍然一次抓取32个字节。这意味着它必须屏蔽部分值，因此这些变得更慢。
- jalf
4
从CPU的角度来看，没有“默认”的整数数据类型，“打字”受法律寄存器操作码的限制。 - Eduard - Gabriel Munteanu
默认情况下，我指的是CPU可以最有效地处理的数据大小。小于32位意味着在加载/存储操作中需要更多的工作（因为必须屏蔽部分读取/写入），而大于32位则需要更长的指令（并且在某些CPU上可能本身也更慢）。 - jalf
有一个适用于x64的.NET发行版。 - Cheeso
但是，32位值仍然可以更有效地处理。.NET对此无能为力。 - jalf
1
除非你打算使值超过20亿，否则使用整数值。没有理由为了一种看似的性能优势而使用额外的空间。
与这个主题上其他人所说的相反，除非你衡量了这样一个小事情的好处，否则它只是一种看似的好处。
- JaredPar
1
http://en.wikipedia.org/wiki/64-bit建议（您可能会找到更权威的来源，这是我找到的第一个）微软的“64位”产品使用64位指针和32位整数。
http://www.anandtech.com/guides/viewfaq.aspx?i=112（我不知道它有多可靠）说：
为了将代码膨胀最小化，AMD实际上将默认数据操作数大小设置为64位寻址模式下的32位。动机是64位数据操作数不太可能被需要并且可能会损害性能；在需要64位数据操作数的情况下，可以使用新的REX前缀激活它们（哇呜，又是x86指令前缀 :))。
- ChrisW
1
在MSVC中，long long是一个64位整数。 - Tamas Czinege
-2
32位CPU可以更快地处理32位整数。64位CPU可以更快地处理64位整数；想一想——你要么必须一直将位移32位，要么每32位浪费32位，这本质上与使用64位变量而没有64位变量的优势是相同的。另一个选择是在CPU中构建额外的电路，以便不需要进行位移，但显然这会增加生产成本。对于32位CPU处理16位或8位变量也是如此。
我不确定，但我不会感到惊讶，如果.NET Framework的64位版本更优化地使用长整型——但这只是我的猜测。
- DrJokepu
2
你在断言64位CPU处理64位整数比32位整数更快，但这只是你的猜测吗？ - ChrisW
ChrisW：你没有仔细阅读我的回答。我并没有猜测；我解释说，为了避免由于对齐不当而导致性能下降，您必须使用额外的32位填充您的32位整数。这不是猜测，这是一个众所周知的事实。 - Tamas Czinege
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接