也许我在这里遗漏了 x64 平台的一个要点，但我的看法是，只有在大量内存、大指针或其他要求苛刻的情况下，x64 应用程序的性能才比 x86 版本（显然是在 x64 操作系统和硬件上）更好。涉及因素。
但是，我开始注意到一些较小的应用程序除了标准的 x86 版本之外还提供 x64 版本的安装程序。由于 x86 在使用 WoW 的 Windows x64 上运行得很好，我发布 x64 编译版本的应用程序有什么好处吗？照我看来：
优点：
缺点：
有哪些令人信服的理由让我重新考虑添加我的应用程序的 x64 编译版本？
编译和调试 x64 版本的另一个潜在原因是它可能会暴露 x86 版本中的隐藏错误。例如，这可能会暴露 32 位整数和（现在）64 位指针之间的不正确转换。这也使您在未来支持 x64。
但是，除非您的应用程序将受益于 64 位整数、额外的 cpu 寄存器、更大的内存空间（超过 3.5Gb）或实现设备驱动程序，否则使用 32 位应用程序是可以的。所有主要操作系统都支持同时运行 x32 和 x64 应用程序，因此不会大力推动仅限 64 位应用程序。
顺便提一句。基于 .NET 的应用程序自动受益于在 64 位系统上执行而无需任何代码更改。无需额外测试。
潜在的性能改进主要与 64 位整数的使用有关（在我的机器上构建 x64 的速度大约是 x86 的 4 倍）以及编译器可能假设某些 CPU 特性普遍存在于支持 x64 的 CPU 中的事实，如 SSE2 等；这可以导致更优化的代码。
对于许多应用程序，尤其是小型应用程序，64 位干净并不难，但对于较大的应用程序来说，这是一个令人头疼的问题，这是理所当然的。通常，令人信服的理由很少。但是某些平台默认情况下不会在 64 位版本中安装其 32 位支持（我认为需要明确告知 FreeBSD 这样做，但我可能会犯错）。
如果您的程序使用大量long longs 并且 WOW 确实意味着轻微的性能损失，您的程序将受益（尽管非常轻微，因为 CPU 出于这个原因具有兼容模式）...
Windows 对 32 位程序的支持将在未来下降（尽管速度很慢），所以我说再过一两年，你就会想知道为什么要部署 32 位应用程序......
此外，您的应用程序的 64 位构建实际上可以比 32 位构建更优化，因为使用 64 位，您可以保证拥有很多东西，例如 SSE2。
表现; x86_64 比 x86 快一点（这也取决于您的编译器），原因已经说明。此外，支持真正庞大的数据集更容易，但当然许多应用程序永远不需要去那里。
当然在 Linux 和 OS X 上，你真的应该支持 x86_64；我在 OS X 上的 64 位浏览器上输入这个，而我在角落里的 Linux 盒子也几乎完全是 64 位的。64 位 Windows 是一个问题，但现在即将到来（与驱动程序一起）。
这通常基于人为因素而不是客观的技术推理。64 位是最新最好的，必须比 32 位更好。如果客户想要它，客户永远是对的。曾与 Windows 用户交谈过，他们说他们的目标是让他们在 Windows 中查看他们的进程列表时 *32 不会出现在他们的任何应用程序旁边。
通常，这也是由于人们对 64 位操作系统的兼容性问题感到困惑，并且只想确保该软件可以在他们的计算机上运行。期望普通人理解 64 位操作系统上 32 位进程之间的技术分界线是不现实的。除非包装上明确说明，否则对于购买新软件的客户来说，这可能会引起混淆/担忧。由于这个原因，您经常会看到提到 64 位。通常，这实际上仅意味着 64 位兼容性。
现在有一些 64 位应用程序（flash 播放器和谷歌地球在我的列表中名列前茅）还不够快。
原因之一：与 64 位应用程序集成，例如编写 shell 扩展。64 位进程无法直接加载 32 位 DLL，因此您也必须将其设为 64 位。
一个尚未提及的因素：WoW64 现在是 Server Core 的可选功能。当然，只有当您的应用程序需要在服务器系统上运行时才会出现问题。
同样，Windows PE、Windows RE 等不包括 Wow64。