45

我知道 x64 架构的一些明显优势（更高的可寻址 RAM 地址等）......但是：

  • 如果我的程序没有真正需要在本机 64 位模式下运行怎么办。无论如何我应该移植它吗？
  • 结束 32 位支持是否有任何可预见的截止日期？
  • 我的应用程序会像原生 x64 代码一样运行得更快/更好/更安全吗？
4

19 回答 19

66

x86-64 有点特殊——对于许多架构（例如 SPARC），为 64 位模式编译应用程序不会给它带来任何好处，除非它可以有利地使用超过 4GB 的内存。它所做的只是增加二进制文件的大小，如果它影响缓存行为，这实际上会使代码变慢。

但是，x86-64 不仅为您提供了 64 位地址空间和 64 位整数寄存器 - 它还使通用寄存器的数量增加了一倍，这在 x86 等寄存器不足的架构上可以显着提高性能，只需重新编译。

它还让编译器假设存在许多扩展，例如 SSE 和 SSE2，这也可以显着改进代码优化。

另一个好处是 x86-64 增加了 PC 相对寻址，可以显着简化与位置无关的代码。

但是，如果应用程序对性能不敏感，那么这些都不重要。

于 2009-09-25T23:41:53.447 回答
28

我还没有看到提到的一个可能的好处是它可能会发现潜在的错误。一旦将其移植到 64 位，就会进行许多更改。某些数据类型的大小发生了变化，调用约定发生了变化，异常处理机制（至少在 Windows 上）发生了变化。

所有这些都可能导致隐藏的错误浮出水面，这意味着您可以修复它们。

假设您的代码是正确且没有错误的，移植到 64 位理论上应该像轻弹编译器开关一样简单。如果失败，那是因为您依赖于语言无法保证的东西，因此它们是潜在的错误来源。

于 2009-09-26T09:57:27.190 回答
18

以下是 64 位为您做的事情：

  • 64 位允许您使用比 32 位应用程序更多的内存。
  • 64 位使所有指针成为 64 位，这使您的代码占用空间更大。
  • 64 位为您提供更多整数和浮点寄存器，从而减少向内存溢出的寄存器，这应该会在一定程度上加快您的应用程序的速度。
  • 64 位可以使 64 位 ALU 操作更快（仅当您使用 64 位数据类型时才有帮助）。
  • 您不会获得任何额外的安全性（另一个答案提到了安全性，我不知道有这样的好处）。
  • 您只能在 64 位操作系统上运行。

我已经移植了许多 C++ 应用程序，并且看到使用 64 位代码（相同的系统，相同的编译器，唯一的变化是 32 位与 64 位编译器模式）大约有 10% 的加速，但这些应用程序中的大多数是做相当多的64位数学。YMMV。

我不会担心 32 位支持很快就会消失。

（编辑以包括评论中的注释 - 谢谢！）

于 2009-09-25T23:37:01.803 回答
5

尽管 32 位确实会以某种形式出现一段时间，但 Windows Server 2008 R2 仅附带 64 位 SKU。随着越来越多的软件迁移到 64 位，早在 Windows 8 中看到 WOW64 作为安装选项，我不会感到惊讶。WOW64 是安装、内存和性能开销。32 位 Windows 中的 3.5GB RAM 限制以及不断增加的 RAM 密度将鼓励这种迁移。我宁愿拥有更多的RAM而不是CPU...

拥抱 64 位！花点时间让您的 32 位代码兼容 64 位，这很简单，也很简单。对于正常应用程序，更改更准确地描述为代码更正。对于司机来说，选择是：适应或失去用户。当时机成熟时，您将准备好通过重新编译在任何平台上进行部署。

IMO 目前与缓存相关的问题没有实际意义；该领域的芯片改进和进一步的 64 位优化即将推出。

于 2009-09-26T19:10:21.583 回答
3
  1. 如果您的程序不需要在 64 位下运行，您为什么要这样做？如果您不受内存限制，并且您没有庞大的数据集，那就没有意义了。新的 Miata 没有更大的轮胎，因为它不需要它们。
  2. 当您的软件不再有用时，32 位支持（即使仅通过仿真）将长期存在。我们仍然在模仿 Atari 2600，对吧？
  3. 不，很可能，您的应用程序在 64 位模式下会变慢，这仅仅是因为处理器缓存中容纳的应用程序较少。它可能更安全一些，但优秀的编码人员不需要那个拐杖:)

Rico Mariani 关于微软为什么不将 Visual Studio 移植到 64 位的帖子确实总结了Visual Studio：为什么没有 64 位版本？（然而）

于 2009-09-25T23:38:07.917 回答
2

这取决于您的代码是应用程序还是可重用库。对于库，请记住，该库的客户端可能有充分的理由在 64 位模式下运行，因此您必须确保您的方案有效。这也可能适用于可通过插件扩展的应用程序。

于 2009-09-25T23:30:28.087 回答
2

如果您现在没有任何实际需求，并且可能永远不会，那么对于 64 位模式，您不应该进行移植。

如果您现在不需要，但可能有一天会需要，您应该尝试估计需要多少工作量（例如，通过打开所有相应的编译器警告，并尝试进行 64 位编译）。期望有些事情不是微不足道的，因此了解您可能会遇到哪些问题以及解决这些问题可能需要多长时间会很有用。

请注意，依赖项也可能产生需求：如果您的程序是库（例如 DLL），则可能需要将其移植到 64 位模式，因为某些主机应用程序被移植。

在可预见的未来，将继续支持 32 位应用程序。

于 2009-09-25T23:31:13.187 回答
2

除非出于商业原因转向 64 位，否则没有真正的“需要”来支持 64 位。

但是，除了其他人已经提到的所有内容之外，在某些时候使用 64 位还有一些很好的理由。

  • 购买非 64 位的 PC 变得越来越难。尽管 32 位应用程序将在未来几年以兼容模式运行，但今天或将来销售的任何新 PC 都可能是 64 位的。如果我有一个闪亮的 64 位操作系统，我真的不想在兼容模式下运行“有异味的 32 位应用程序”！

  • 有些事情在兼容模式下无法正常运行——这与在 32 位硬件上的 32 位操作系统上运行不同。在兼容模式下运行时，我遇到了一些问题（例如，跨 32/64 位注册表配置单元的注册表访问、由于不在预期所在文件夹中而失败的程序等）。我总是对在兼容模式下运行我的代码感到紧张——它只是“不是真的”，而且它经常显示出来。

  • 如果您已经干净地编写了代码，那么您可能只需将其重新编译为 64 位 exe，它就会正常工作，因此没有真正的理由不试一试。

  • 越早构建本机 64 位版本，在添加新功能时就越容易使其在 64 位上运行。这比在黑暗时代继续发展 'n' 年然后试图跳入光明要好得多。

  • 下一次面试时，你可以说你有 64 位经验和 32->64 移植经验。

于 2009-09-26T20:13:27.887 回答
1

您已经知道 x64 的优势（最重要的是增加的 RAM 大小）并且您对任何内容都不感兴趣，那么就不要移植可执行文件 (exe)。通常在移植后性能会下降，主要是由于 x64 模块的大小比 x86 增加：所有指针现在都需要双倍长度，这会渗透到任何地方，包括代码大小（一些跳转、函数调用、vtables、虚拟调用、全局符号等等等等）。不是显着的降级，但通常是可测量的（速度降低 3-5%，取决于许多因素）。

DLL 值得移植，因为您在能够使用您的 DLL 的 x64 应用程序中获得了新的“受众”。

于 2009-09-26T00:03:02.843 回答
1

例如，如果您编写了 32 位代码 (GNU C/++)，如下编辑：格式代码

struct packet {
    unsigned long name_id;
    unsigned short age;
};

对于网络消息传递，那么您需要在 64 位系统上重新编译时进行移植，因为 htonl/ntohl 等，在网络对等体仍在使用 32 位系统的情况下通信会中断（使用与你的）；你知道 sizeof(long) 也会在你身边从 32 变为 64。

在http://code.google.com/p/effocore/downloads/list上查看有关 32/64 移植的更多说明，文档名称为 EffoCoreRef.pdf。

于 2009-10-14T14:06:04.173 回答
1

某些操作系统或配置无法运行 32 位程序。例如，没有安装 32 位libc的最小 Linux 。此外 IIRC 我通常会从内核编译出 32 位支持。

如果这些操作系统或配置是您潜在用户群的一部分，那么是的，您应该移植它。

如果您需要更高的速度，那么您也应该移植它（正如其他人所说，x86-64 有更多的寄存器和很酷的指令来加速它）。

或者，当然，如果您想要 mmap() 或以其他方式映射大文件或大量内存。然后 64 位帮助。

于 2009-10-14T14:19:28.457 回答
0

除非您需要极端的安全措施或大量的 RAM，否则您不太可能看到任何好处。

基本上，您很可能直观地知道您的代码是否适合 64 位移植。

于 2009-09-25T23:29:44.580 回答
0

关于截止日期。我不会担心，像 32 位这样的东西会在本地存在一段时间，并且在可预见的未来会以其他形式存在。

于 2009-09-25T23:30:40.520 回答
0

在这里查看我对这个问题的回答。我结束了那篇文章，说 64 位计算机可以存储和检索比 32 位计算机更多的信息。对于大多数用户来说，这实际上并不意味着太多，因为诸如浏览网页、查看电子邮件和玩纸牌游戏之类的事情都可以在 32 位寻址的范围内舒适地工作。64 位优势真正发挥作用的地方是您拥有大量计算机必须处理的数据的领域。数字信号处理、十亿像素摄影和高级 3D 游戏都是在 64 位环境中大幅提升其海量数据处理能力的领域。

至于您的代码运行得更快/更好，这完全取决于您的代码和对其施加的要求。

于 2009-09-25T23:30:41.473 回答
0

至于性能问题，实际上取决于您的程序。如果你的程序是指针密集型的，移植到 64 位可能会导致性能下降，因为对于相同大小的 CPU 缓存，每个 64 位指针在缓存上占用更多空间，虚拟到物理映射也占用更多 TLB 空间. 否则，如果您的程序不是指针密集型的，它的性能将受益于 x64。

当然，性能并不是移植的唯一原因，还应考虑移植工作量、时间安排等其他问题。

于 2010-02-18T16:16:49.647 回答
0

我建议将其移植到 64 位，以便您运行“本机”（另外，我使用 OpenBSD。在他们的 AMD64 端口中，他们不提供任何 32 位仿真支持，一切都必须是 64 位）

还有，stdint.h是你最好的朋友！通过移植您的应用程序，您应该学习如何可移植地编写代码。当我们也有 128 位处理器时，这将使您的代码正常工作（希望在几十年内）

我已经将 2 或 3 个东西移植到 64 位，现在为两者开发（如果您使用 stdint.h，这非常容易），并且在我的第一个项目移植到 64 位导致出现 2 或 3 个错误，但那是它。其中大部分是一个简单的重新编译，现在我在编写新代码时不用担心 32 位和 64 位之间的差异，因为我只是自动可移植地编写代码。（使用 intptr_t 和 size_t 等）

于 2010-02-18T16:24:30.073 回答
0

如果从 64 位进程调用 dll，则 dll 也必须是 64 位。那么值不值得也没关系，你根本别无选择。

于 2010-04-02T10:07:30.510 回答
0

要记住的一个问题是可用的软件库。例如，我的公司开发了一个使用多个 OpenGL 库的应用程序，我们在 OpenSuSE 操作系统上这样做。在旧版本的操作系统中，可以在 x86_64 架构上下载这些库的 32 位版本。然而，较新的版本没有这个。它使在 64 位模式下编译变得更容易。

于 2010-07-02T15:34:14.607 回答
-2

当 64 位编译器成熟时，64 位会运行得更快，但我不知道什么时候会发生

于 2011-01-28T23:33:05.567 回答