在64位操作系统中运行32位.NET应用程序，真的很糟糕吗？

Question

据我所知，我们可以通过定位AnyCPU来编译.NET应用程序，这将导致在32位操作系统中运行32位，在64位操作系统中运行64位。

然而，在64位操作系统上有一个报告错误*，我的应用程序出错并为此提供解决方案，我需要针对x86。

现在我的问题：即使你的代码要在x64中运行，定位x86真的很糟糕吗？我们在谈论什么样的表现？ （我的应用程序非常耗费CPU，但很难想出来）

毕竟.NET Framework将以32位运行，这对我来说听起来不好，而不是取得x64 CPU的完全寻址能力**。

*我不记得这个错误，但解决方案专门针对x86，并解决了这个问题。

**我不确定它是否有用，但我的应用程序不使用任何Int64变量。

Answer 1

不，这不错;实际上，对于我正在处理的应用程序，我有来定位x86（因为它带来了COM对象，供应商不支持x64）

Answer 2

我有一个使用CPU的数字运算应用程序（暴力强制解决方案）。在64位.NET Framework上运行它（8秒）比32位（30秒）快4倍。这只是一个案例。

Answer 3

不，需要在x64系统上定位x86并不是那么糟糕。您将错过额外的x64优势，并最终在32位仿真层中运行。但这比完全破坏要好，而且大多数应用仍然是32位。

使用.Net，需要这样做的正常原因是依赖于原生的32位dll。如果从任何cpu中保留.Net目标，它将尝试以64位模式加载32位dll，从而导致崩溃。最终，您确实希望摆脱该依赖关系，以便您可以使用64位模式。但是对于一个版本它不会杀了你。

Answer 4

答案是“这取决于”。这取决于你的应用程序做什么，它是否访问内存很多。凯文是对的：处理器确实需要进行大量的地址转换，但这可能不会对应用程序的性能造成太大影响。基础硬件指令在x86和amd64之间基本相同，并且假设CLR作者知道他们在做什么（并且我确信他们这样做），那里没有太多低效率。如果你正在进行图形操作，你可能会看到很大的性能差异，但由于这只是一个.NET应用程序，我认为你不是。对于一些数字运算任务，你可能会注意到Mehrdad提到的不同，尽管如果你这样做我会感到惊讶。

总而言之，除非您拥有对性能敏感的应用程序，否则我会说不要担心性能问题。一旦您了解了应用程序的性质，就只会担心性能问题。

Answer 5

如果您使用结构分配，并且有大量的64位计算（双倍，长），那么由于32位Jit引擎与64位引擎相比不太先进，您将看到性能下降。

否则32位和64位版本的.Net在性能上有些相似。

此外，如果您的流程不需要超过2GB的限制，不需要64位的寻址功能，操作系统会使用名为{的特殊CPU模式为您解决这个问题。 {3}} - 兼容性子模式。 （CPU实际上是以64位模式运行，但为了兼容性，使用32位进行寻址）

Answer 6

您必须记住的是，要使32位进程在64位环境中运行，系统必须对其执行的所有操作进行内存地址转换。这不好吗？这取决于场景。它绝对不是那么有效。在x-64服务器上运行32位版本的IIS与可能的情况相比非常缓慢。这完全取决于您对应用程序的需求。

Answer 7

没有。它会毫无问题地运行。事实上，由于更新的操作系统内存管理器，我们经常发现我们的32位应用程序在64位Vista上运行比在32位Vista上更好。直接针对x86应该可以正常工作。但是，能够在64位本地运行将具有其他优势，例如访问更多内存的能力，更多用于CPU的寄存器等，因此，如果可能的话，值得投入和运行。

Answer 8

我打算说出最好的方法来确定是否要测量，但显然如果它不能正常运行那么它很难衡量。

首先看看是否存在性能问题。如果它似乎是一个问题，那么看看你是否可以确定它在不符合x64的应用程序中的确切含义。大多数.NET代码应该是独立于平台的，所以最可能的罪魁祸首是任何本地的inter-op或第三方库。

Answer 9

您的“错误”是否是您的.NET代码使用32位COM对象？

在使用AnyCPU设置编译的64位体系结构上运行.NET进程时，这种情况可能确实存在问题。

原因是该进程将作为64位进程执行，并且在进程中执行的任何COM组件也必须是64位版本。如果不是这种情况，您的流程将退出。

可能的解决方案是将目标平台设置为x86。