移植 32 位 C++代码转为 64 位 - 值得吗？为什么？

Question

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

• 如果我的程序不需要在本机 64 位模式下运行怎么办？我还是应该移植它吗？
• 终止 32 位支持是否有可预见的最后期限？
• 我的应用程序会像本机 x64 代码一样运行得更快/更好/更安全吗？

Answer 1

除非有商业原因需要使用 64 位，否则没有真正的“需要”支持 64 位。

然而，除了其他人已经提到的所有原因之外，在某些时候转向 64 位还有一些充分的理由。

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

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

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

• 越早构建本机 64 位版本，在添加新功能时就越容易保持其在 64 位上运行。这是一个比在黑暗时代继续开发另外 'n' 年然后试图跳入光明更好的计划。

• 当您参加下一次工作面试时，您将可以说您有 64 位经验和 32->64 移植经验。

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

有关 32/64 移植的更多说明，请访问 http://code.google.com/p /effocore/downloads/list，文档名称 EffoCoreRef.pdf。

Answer 7

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

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

Answer 8

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

Answer 9

请参阅我对此问题的回答此处。我结束了该帖子说64 位计算机可以比 32 位计算机存储和检索更多信息。对于大多数用户来说，这实际上并没有多大意义，因为浏览网页、检查电子邮件和玩纸牌等操作都可以在 32 位寻址的范围内轻松完成。 64 位的优势真正体现在计算机必须处理大量数据的领域。数字信号处理、十亿像素摄影和高级 3D 游戏等领域的海量数据处理在 64 位环境中都将得到大幅提升。

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

Answer 10

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

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

Answer 11

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

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

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

Answer 12

如果从 64 位进程调用 dll，则该 dll 也必须是 64 位。
那么是否值得并不重要，你根本没有选择。

Answer 13

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

Answer 14

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

Answer 15

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

然而，x86-64 为您提供的不仅仅是 64 位地址空间和 64 位整数寄存器 - 它还使通用寄存器的数量加倍，这在像 x86 这样的寄存器缺陷架构上可能会导致只需重新编译即可显着提高性能。

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

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

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

Answer 16

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

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

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

Answer 17

以下是 64 位为您提供的功能：

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

我移植了许多 C++ 应用程序，发现 64 位代码的速度提高了约 10%（相同的系统、相同的编译器，唯一的变化是 32 位与 64 位编译器模式），但大多数应用程序都是进行大量 64 位数学运算。 YMMV。

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

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

Answer 18

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

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

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

Answer 19

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

Rico Mariani 关于为什么 Microsoft 不 将 Visual Studio 移植到 64 位的帖子确实总结了这一点 Visual Studio：为什么没有64位版本？ （还）