将32位C ++代码移植到64位 – 值得吗？ 为什么？
我知道一些显着的x64架构（更高的可寻址RAM地址等）的收益…但是：
- 如果我的程序没有真正需要在本地64位模式下运行，该怎么办？ 我应该移植它吗？
- 是否有可预见的结束32位支持的最后期限？
- 我的应用程序能够像原生x64代码一样运行得更快/更好/更安全吗？
对于许多体系结构（例如SPARC）来说，x86-64是有点特殊的情况，编译一个64位模式的应用程序不会给它带来任何好处，除非它能够使用超过4GB的内存。 它所做的只是增加二进制文件的大小，如果影响caching行为，实际上会使代码变慢 。
然而，x86-64不仅仅提供了64位地址空间和64位整数寄存器 – 它还使通用寄存器的数量增加了一倍 ，这在x86这样的寄存器不足的架构中可以导致性能显着提高重新编译。
它也让编译器假定存在许多扩展，如SSE和SSE2，这也可以显着改善代码优化。
另一个好处是x86-64增加了PC相对寻址，可以显着简化与位置无关的代码。
但是，如果应用程序不是性能敏感的，那么这也不是很重要。
我还没有提到的一个可能的好处是，它可能会发现潜在的错误。 一旦将其移植到64位，就会进行一些更改。 某些数据types的大小发生变化，调用约定发生变化，exception处理机制（至less在Windows上）发生变化。
所有这些都可能导致隐藏的bug出现，这意味着你可以修复它们。
假设你的代码是正确的，没有错误，移植到64位理论上应该像轻弹一个编译器开关一样简单。 如果失败了，那是因为你依赖的不是语言保证的东西，所以它们是潜在的错误来源。
以下是64位为你做的事情：
- 64位允许您使用比32位应用程序更多的内存。
- 64位使所有的指针64位，这使得你的代码足迹更大。
- 64位给你更多的整数和浮点寄存器，这会导致寄存器溢出到内存较less，这应该加快你的应用程序的速度。
- 64位可以使64位ALU操作更快（只有在使用64位数据types时才有用）。
- 你不会得到任何额外的安全（另一个答案提到的安全性，我不知道这样的好处）。
- 您仅限于在64位操作系统上运行。
我已经移植了许多C ++应用程序，用64位代码（相同的系统，相同的编译器，唯一的变化是32位与64位编译器模式）看到了大约10％的加速，但大多数应用程序做相当数量的64位math。 因人而异。
我不担心32位支持很快就会消失。
（编辑包括评论的笔记 – 谢谢！）
虽然32位将以某种forms存在一段时间，但Windows Server 2008 R2只附带64位SKU。 早在Windows 8上，随着更多软件迁移到64位，我将不会感到惊讶。 WOW64是一个安装，内存和性能开销。 随着RAM密度的增加，32位Windows中的3.5GB RAM限制将推动这种迁移。 我宁愿有比CPU更多的RAM …
拥抱64位！ 花点时间让你的32位代码兼容64位，它是一个没有道理和直截了当的。 对于正常的应用程序，更改会更准确地描述为代码更正。 对于司机来说，select是：适应或失去用户。 当时间到了，你将准备在任何平台上进行重新编译。
国际海事组织当前caching相关的问题是没有意义 在这个领域的硅改进和进一步的64位优化将是即将到来的。
- 如果你的程序不需要在64位下运行，为什么呢？ 如果你没有记忆力，而且你没有庞大的数据集，那就毫无意义了。 新Miata没有更大的轮胎，因为它不需要它们。
- 32位支持（即使只通过仿真）将会延长您的软件停止使用的时间。 我们仍然效仿Atari 2600s，对吧？
- 不，在所有可能的情况下，你的应用程序在64位模式下都会变慢，只是因为它的适应能力不够处理器的caching。 这可能会稍微安全些，但好的编码器不需要那个拐杖:)
Rico Mariani关于为什么微软不将Visual Studio移植到64位的真正概述Visual Studio：为什么没有64位版本？ （然而）
这取决于你的代码是一个应用程序还是一个可重用的库。 对于一个库，请记住，该库的客户端可能有很好的理由在64位模式下运行，所以您必须确保您的scheme正常工作。 这也可能适用于通过插件进行扩展的应用程序。
如果你现在没有任何真正的需求，而且可能永远不会，对于64位模式，你不应该做移植。
如果你现在没有这个需求，但有一天可能会有这个需求，那么你应该试着估计它会花多less功夫（例如打开所有的编译器警告，并尝试64位编译）。 期望有些事情不是微不足道的，因此知道你可能遇到什么问题以及可能需要多长时间来解决它们将是有用的。
请注意，依赖关系也可能会产生一个需求：如果您的程序是一个库（例如DLL），则可能需要将其移植到64位模式，只是因为某些主机应用程序被移植了。
在可预见的未来，32位应用程序将继续得到支持。
除非有64位的商业理由，否则没有真正的“需要”来支持64位。
但是，除了其他人已经提到的所有内容之外，在某些时候进入64位有一些很好的理由。
-
购买不是64位的PC越来越难了。 尽pipe32位应用程序将在未来几年以兼容模式运行，但今天或未来销售的任何新PC都可能是64位。 如果我有一个shiny的64位操作系统，我不想在兼容模式下运行“臭旧的32位应用程序”！
-
有些东西只是在兼容模式下不能正常运行 – 这与在32位硬件上运行32位操作系统不同。 在兼容模式下运行时，我遇到了一些问题（例如32/64位registryconfiguration单元的registry访问，因为它们不在预期位于的文件夹等而失败的程序）。 在兼容模式下运行我的代码时，我总是感到紧张 – 这只是“不是真实的”，而且经常performance出来。
-
如果你已经写好了你的代码，那么你很可能只需要把它重新编译成一个64位的exe文件就行了，所以没有必要试一下。
-
越早build立一个原生的64位版本，越容易保持它在64位工作，因为你添加新的function。 这是一个好得多的计划，比在黑暗时代继续发展另外n年，然后试图跳出光明。
-
当你下次面试时，你可以说你有64位的工作经验和32-64的移植经验。
你已经意识到了x64的优点（最重要的是增加了内存大小），你不感兴趣的话，不要移植一个可执行文件（exe）。 通常，端口之后性能会降低，主要是由于x64模块在x86上的大小增加：现在所有的指针都需要双倍的长度，并且这个遍历包括代码大小（一些跳转，函数调用，vtable，虚拟调用，全局符号等等）。 不是一个显着的退化，但通常是可衡量的（3-5％的速度下降，取决于许多因素）。
DLL是值得移植的，因为你在x64应用程序中获得了能够使用你的DLL的新的“受众”。
某些操作系统或configuration无法运行32位程序。 例如，没有安装32位libc的最小的Linux。 另外IIRC我通常从内核编译出32位的支持。
如果这些操作系统或configuration是潜在的用户群的一部分，那么是的，你应该移植它。
如果你需要更多的速度，那么你也应该移植它（正如其他人所说的，x86-64有更多的寄存器和更酷的指令可以加快速度）。
或者，当然，如果你想mmap（）或者映射一个大文件或大量的内存。 然后64位帮助。
例如，如果您编写了32位代码（GNU C / ++），如下所示：编辑：格式代码
struct packet { unsigned long name_id; unsigned short age; }; 对于networking消息传递，那么你需要在64位系统上重新编译时进行移植，因为htonl / ntohl等等，在networking对等体仍在使用32位系统的情况下通信被破坏（使用与你的）; 你知道sizeof（long）在你身边也会从32变成64。
有关32/64移植的更多注意事项，请访问http://code.google.com/p/effocore/downloads/list ，文档名称为EffoCoreRef.pdf。
除非您需要极端的安全措施或者猥琐的RAM，否则很难看到任何好处。
基本上，如果你的代码是64位移植的好select，你很可能直觉地了解它。
关于截止date。 我不担心，像32bit这样的东西本来会在其他forms的可预见的未来中出现。
在这里看到我对这个问题的回答。 我closures了这个post，说一个64位计算机可以存储和检索比32位计算机更多的信息。 对于大多数用户来说，这并不意味着很多，因为在32位寻址的范围内，浏览网页，查看电子邮件和玩纸牌游戏都是舒适的。 如果64位的好处真的会发生在那些你有大量数据的地方，那么计算机将不得不通过。 数字信号处理，千兆像素摄影和高级3D游戏都是大量数据处理在64位环境中大幅提升的领域。
至于你的代码运行得更快/更好，这完全取决于你的代码和强加给它的需求。
对于性能问题，实际上取决于你的程序。 如果程序的指针密集型，则移植到64位可能导致性能降级，因为对于相同大小的CPUcaching，每个64位指针在caching中占用的空间更多，而虚拟物理映射也会占用更多的TLB空间。 否则，如果你的程序不是指针密集的，它的性能将受益于x64。
当然，性能并不是移植的唯一原因，其他问题如移植工作，时间安排也应该考虑。
我build议把它移植到64位，这样你就可以运行“native”了（另外，我使用的是OpenBSD，在他们的AMD64端口上，它们不提供任何32位仿真支持，一切都必须是64位）
另外， stdint.h是你最好的朋友！ 通过移植你的应用程序，你应该学习如何移植代码。 当我们有128位处理器的时候，这也会使你的代码正常工作（希望在几十年后）
我已经移植了2到3个东西到64位，现在开发为这两个（这是很容易，如果你使用stdint.h），并在我的第一个项目移植到64位引起像2或3个错误出现，但那是它。 大部分是一个简单的重新编译，现在我不担心32位和64位之间的区别，因为我只是自动编码便携式。 （使用intptr_t和size_t等）
在从64位进程调用dll的情况下，dll也必须是64位。 那么它是否值得，不要紧，你别无select。
要牢记的一个问题是可用的软件库。 例如，我的公司开发了一个使用多个OpenGL库的应用程序，我们在OpenSuSE OS上这样做。 在旧版本的操作系统中，可以在x86_64架构上下载这些库的32位版本。 新版本，但是，没有这个。 这使得在64位模式下编译变得更容易。
当64位编译器成熟时，64位的运行速度会快很多，但是当它发生的时候我不知道
