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

Posted 2023-02-16

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

【英文标题】：Running 32bit .NET application in 64bit OS, is it really bad?

【发布时间】：2009-04-06 20:18:28

【问题描述】：

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

但是，在 64 位操作系统上报告了一个错误*，我的应用程序给出了错误以及解决方案，我需要以 x86 为目标。

现在我的问题是：即使您的代码将在 x64 中运行，以 x86 为目标真的很糟糕吗？我们在谈论什么样的表现？ （我的应用程序是 CPU 密集型的，但真的很难想出）

毕竟 .NET Framework 将以 32 位运行，这对我来说听起来很糟糕，而不是充分利用 x64 CPU** 的寻址能力。

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

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

【参考方案1】：

不，还不错；事实上，对于我正在开发的应用程序，我必须以 x86 为目标（因为它引入了供应商不支持 x64 的 COM 对象）

【讨论】：

您可以从 64 位进程运行 32 位 COM，前提是您在进程外运行它。见***.com/questions/611651/…

就我而言，它是处理互操作的框架，位于 WIC 的深处。曾考虑过编写一个 out of proc 代理，但只针对 x86 会少很多麻烦...

【参考方案2】：

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

【讨论】：

当主要处理 Int64 而不是 Int32 时，这一点很明显。这里也有因子 4 的差异，不过对于 C。

用 Any CPU 编译会发生什么？ AFAIK 它应该像在 x64 系统中编译为 x64 一样工作。

@dr.如果您直接在 x64 机器上运行 Any CPU .exe，它将以 64 位模式运行。但是，如果 32 位主机正在加载它，它将以 32 位模式运行。

【参考方案3】：

不，需要在 x64 系统上以 x86 为目标并没有那么糟糕。您将错过额外的 x64 优势并最终在 32 位仿真层中运行。但这总比完全崩溃要好，而且大多数应用程序仍然是 32 位的。

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

【参考方案4】：

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

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

【参考方案5】：

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

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

此外，如果您的进程不需要超过 2GB 的限制，您不需要需要 64 位的寻址功能，操作系统会使用称为 @ 的特殊 CPU 模式为您处理这些问题987654321@ - 兼容性子模式。 （CPU其实是在64位模式下运行的，但是使用32位寻址，为了兼容性）

【参考方案6】：

您必须记住的是，要让 32 位进程在 64 位环境中运行，系统必须对其所做的一切进行内存地址转换。不好吗？这取决于场景。它肯定没有它应有的效率。在 x-64 服务器上运行 32 位版本的 IIS 与它可能的速度相比非常缓慢。这完全取决于您对应用程序的需求。

【讨论】：

我认为现代操作系统中具有虚拟地址空间的每个进程在使用时都应该转换为物理地址。

不，x64 有一些优点，比如更多更大的寄存器，但也有缺点，比如由于双指针大小导致的更大应用程序，这会降低缓存和内存带宽的效率。无论如何，假设使用合理的编译器，速度应该大致相同。

在 .Net 的情况下，区别在于 64 位上更先进的 Jit 引擎（或者我应该说 32 位 jit 编译器不太先进，尤其是在使用 64 位结构时，比如 long double，32bi C++编译器没有的问题。）

同意 Pop Catalin。 64 位 .NET Framework 的 JIT 似乎比 32 位对应的 JIT 工作得更好。

【参考方案7】：

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

【参考方案8】：

我想说的是确定是否测量的最佳方法，但显然如果它不能正常运行，那么它就很难测量。

首先看看是否存在性能问题。如果这似乎是一个问题，那么看看您是否可以查明应用程序中不符合 x64 的确切内容。大多数 .NET 代码应该是独立于平台的，因此最可能的罪魁祸首是任何本机互操作或 3rd 方库。

【参考方案9】：

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

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

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

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

【讨论】：

我使用的是 WEBbrowser 控件，但我认为它与 x64 兼容。我认为问题是 MS Access 2007 访问。不过不记得了。