.NET 优化的 Int32
在阅读 70-536 培训套件时，它指出：
运行时优化性能 32 位整数类型 (Int32)，因此 将这些类型用于计数器和其他 经常访问的积分 变量。
这只适用于32位环境吗？ Int64 是否会在 64 位环境中取代，或者 Int32 仍然是更好的选择？
While reading through the 70-536 training kit, it states:
The runtime optimizes the performance
of 32-bit integer types (Int32), so
use those types for counters and other
frequently accessed integral
variables.
Does this only apply in a 32 bit environment? Does Int64 take over in a 64 bit environment, or is Int32 still the better choice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这是一个有趣的表达方式。 运行时间与它没有太大关系。
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 字节。 这意味着它必须掩盖部分值，因此这些变得更慢。
That's a funny way to put it. The runtime doesn't have much to do with it.
The CPU is designed for processing 32-bit integers, which is why they're the most efficient to use.
In a 64-bit environment, it again depends on the CPU. However, on x86 CPU's at least (which, to the best of my knowledge, is the only place .NET runs), 32-bit integers are still the default. The registers have simply been expanded so they can fit a 64-bit value. But 32 is still the default.
So prefer 32-bit integers, even in 64-bit mode.
Edit: "default" is probably not the right word. The CPU just supports a number of instructions, which define which data types it can process, and which it can not. There is no "default" there. However, there is generally a data size that the CPU is designed to process efficiently. And on x86, in 32 and 64-bit mode, that is 32-bit integers. 64-bit values are generally not more expensive, but they do mean longer instructions. I also believe that at least the 64-bit capable Pentium 4's were significantly slower at 64-bit ops, although on recent CPU's, that part shouldn't be an issue. (But the instruction size may still be)
Smaller than 32-bit values are somewhat more surprising. Yes, there is less data to transfer, which is good, but the CPU still grabs 32-byte at a time. Which means it has to mask out part of the value, so these become even slower.
Scott Hanselman 今天在他的博客上发布了一篇文章，讨论了 32 位和 64 位托管代码之间的差异。 总结一下，基本上只有指针改变了大小，整数仍然是 32 位。
您可以在此处找到该帖子。
Scott Hanselman posted an article that addresses differences between 32 and 64 bit managed code to his blog today. To summarize basically only pointers change size, integers are still 32 bits.
You can find the post here.
除非您计划让该值超过 20 亿，否则请使用整数值。 没有理由使用额外的空间来获得预期的性能优势。
与此线程上其他人可能说的相反，在你衡量像这样的小事情的好处之前，它只是一种感知的好处。
Unless you plan on having the value exceed 2 billion, use an integer value. There is no reason to be using extra space for a percieved performance benefit.
And contrary to what other people on this thread may say, until you measure the benefit of such a small thing as this, it is in only a percieved benefit.
http://en.wikipedia.org/wiki/64-bit 建议（您可能会找到更权威的来源，这是我发现的第一个）微软的“64位”产品使用64位指针和32位整数。
http://www.anandtech.com/guides/viewfaq.aspx?i= 112（我不知道它有多值得信赖）说，
http://en.wikipedia.org/wiki/64-bit suggests (you might find a more authoritative source, this one is the first one that I found) that Microsoft's "64 bit" offerings use 64-bit pointers with 32-bit integers.
http://www.anandtech.com/guides/viewfaq.aspx?i=112 (and I don't know how trust-worthy it is) says,
32 位 CPU 处理 32 位整数的速度更快。 64 位处理 64 位整数的速度更快； 想想看——你要么必须一直移位 32 位，要么每 32 位浪费 32 位，这本质上与使用 64 位变量没有 64 位变量的优点相同。 另一种选择是在 CPU 中内置额外的电路，这样就不需要进行移位，但显然这会增加生产成本。 这对于处理 16 位或 8 位变量的 32 位 CPU 来说是相同的。
我不确定，但如果 .NET Framework 的 64 位变体对使用 long 进行了更优化，我不会感到惊讶 - 但这只是我的猜测。
A 32-bit CPU handles 32-bit integers faster. A 64-bit one handles 64-bit integers faster; just think about it - you either have to shift bits by 32 bits all the time, or waste 32 bits for each 32 bits, which is essentially the same as using a 64-bit variable without the advantages of a 64-bit variable. An other option would building extra circuitry into the CPU so that shifting would not be necessary but obviously that would increase production costs. This is the same for 32-bit CPUs handling 16-bit or 8-bit variables.
I'm not sure but I wouldn't be surprised if the 64 bit variant of the .NET Framework was a bit more optimized to use longs - but that's just speculation on my part.