【发布时间】：2009-02-10 00:43:12
【问题描述】：
在阅读 70-536 培训套件时，它指出：
运行时优化性能 32 位整数类型 (Int32)，所以 将这些类型用于计数器和其他 经常访问的积分 变量。
这仅适用于 32 位环境吗？是 Int64 在 64 位环境中接管，还是 Int32 仍然是更好的选择？
【问题讨论】：
标签： .net optimization integer 64-bit
【发布时间】：2009-02-10 00:43:12
【问题描述】：
这是一个有趣的说法。运行时与它没有太大关系。 CPU 专为处理 32 位整数而设计，因此使用起来效率最高。
在 64 位环境中，它再次取决于 CPU。但是，至少在 x86 CPU 上（据我所知，这是 .NET 运行的唯一地方），32 位整数仍然是默认值。寄存器已简单扩展，因此它们可以容纳 64 位值。但 32 仍然是默认值。
所以更喜欢 32 位整数，即使在 64 位模式下也是如此。
编辑：“默认”可能不是正确的词。 CPU 只支持一些指令，这些指令定义了它可以处理哪些数据类型，哪些不能处理。那里没有“默认”。但是，通常有一个 CPU 旨在高效处理的数据大小。在 x86 上，在 32 位和 64 位模式下，即 32 位整数。 64 位值通常不会更昂贵，但它们确实意味着更长的指令。我还相信，至少支持 64 位的 Pentium 4 在 64 位操作时明显较慢，尽管在最近的 CPU 上，这部分不应该成为问题。 （但指令大小可能还在）
小于 32 位的值更令人惊讶。是的，要传输的数据较少，这很好，但 CPU 仍然一次抓取 32 字节。这意味着它必须屏蔽部分值，因此这些值会变得更慢。
【讨论】：
-
从 CPU 的角度来看，没有“默认”整数数据类型，“打字”受合法寄存器操作码的限制。
-
真的。默认情况下，我指的是 CPU 可以最有效地处理的数据大小。小于 32 位意味着加载/存储操作中的更多工作（因为必须屏蔽部分读/写），大于 32 位需要更长的指令（并且可能在某些 CPU 上本身也更慢）
-
有一个适用于 x64 的 .NET 发行版。
-
但是仍然可以更有效地处理 32 位值。 .NET 对此无能为力。
Scott Hanselman 今天在他的博客上发表了一篇文章，讨论了 32 位和 64 位托管代码之间的差异。总结基本上只有指针改变大小，整数仍然是 32 位。
你可以找到here的帖子。
【讨论】：
除非您计划使值超过 20 亿，否则请使用整数值。没有理由使用额外的空间来获得性能优势。
与此线程上的其他人可能会说的相反，在您衡量这样一件小事的好处之前，它只是一种感知到的好处。
【讨论】：
http://en.wikipedia.org/wiki/64-bit 建议（您可能会找到更权威的来源，这是我发现的第一个来源）Microsoft 的“64 位”产品使用 64 位指针 和 32 -位整数。
http://www.anandtech.com/guides/viewfaq.aspx?i=112（我不知道它的可信度如何）说，
为了尽量减少代码膨胀，AMD 实际上在 64 位寻址模式下将默认数据操作数大小设置为 32 位。动机是不太可能需要 64 位数据操作数，并且可能会损害性能；在需要 64 位数据操作数的情况下，可以使用新的 REX 前缀（哇哦，又一个 x86 指令前缀 :)）来激活它们。
【讨论】：
-
在 MSVC 中，long long 是一个 64 位整数。
32 位 CPU 处理 32 位整数的速度更快。 64 位处理 64 位整数的速度更快；想想看 - 你要么必须一直移动 32 位，要么每 32 位浪费 32 位，这与使用 64 位变量而没有 64 位变量的优点基本相同。另一种选择是在 CPU 中构建额外的电路，这样就不需要转换，但显然这会增加生产成本。处理 16 位或 8 位变量的 32 位 CPU 也是如此。
我不确定，但如果 .NET Framework 的 64 位变体对使用 long 进行了更优化，我不会感到惊讶 - 但这只是我的猜测。
【讨论】：
-
您声称支持 64 位的 CPU 处理 64 位整数的速度比 32 位整数快：但这不只是您的猜测吗？
-
ChrisW：你没有仔细阅读我的回答。我没有推测；我解释说，为了避免由于未对齐而导致性能下降，您必须用额外的 32 位填充 32 位整数。这不是猜测，这是众所周知的事实。