我知道x64架构有一些明显的好处（更高的可寻址RAM地址等）......但是：
答案 0 :(得分：65)
x86-64有点特殊情况 - 对于许多体系结构（例如SPARC），编译64位模式的应用程序并没有给它任何好处，除非它可以有利地使用超过4GB的内存。它所做的只是增加二进制文件的大小，如果它影响缓存行为，实际上可以使代码更慢。
然而，x86-64不仅提供了64位地址空间和64位整数寄存器 - 它还加倍通用寄存器的数量，这在寄存器不足的架构（如x86）上只需重新编译就可以显着提高性能。
它还允许编译器假设存在许多扩展，如SSE和SSE2，这也可以显着改善代码优化。
另一个好处是x86-64增加了PC相对寻址，可以显着简化与位置无关的代码。
但是，如果应用程序对性能不敏感，那么这一点都不重要。
答案 1 :(得分：27)
我还没有提到的一个可能的好处是，它可能会发现潜在的错误。将端口移植到64位后，会进行一些更改。某些数据类型的大小发生变化，调用约定发生变化，异常处理机制（至少在Windows上）发生变化。
所有这些都可能导致隐藏的错误浮出水面，这意味着您可以修复它们。
假设您的代码是正确且没有错误的，理论上移植到64位应该像轻弹编译器开关一样简单。如果失败了，那是因为你依赖语言不能保证的东西，因此，它们是潜在的错误来源。
答案 2 :(得分：17)
这是64位为你做的：
我已经移植了许多C ++应用程序，并看到使用64位代码加速10％（相同的系统，相同的编译器，唯一的变化是32位与64位编译器模式），但大多数那些应用程序正在进行相当数量的64位数学运算。 YMMV。
我不担心32位支持很快就会消失。
（编辑包含评论中的注释 - 谢谢！）
答案 3 :(得分：5)
虽然32位将以某种形式存在一段时间，但Windows Server 2008 R2仅附带64位SKU。早在Windows 8中，随着更多软件迁移到64位，我不会对WOW64作为安装选项感到惊讶。 WOW64是一种安装，内存和性能开销。 32位Windows中的3.5GB RAM限制以及不断增加的RAM密度将促进此迁移。我宁愿拥有比CPU更多的内存......
拥抱64位！花点时间使您的32位代码与64位兼容，这是一个简单而直截了当的问题。对于正常应用程序，更改更准确地描述为代码更正。对于司机，选择是：适应或失去用户。届时，您将准备好在任何具有重新编译的平台上进行部署。
IMO目前的缓存相关问题没有实际意义;该领域的硅片改进以及进一步的64位优化即将推出。
答案 4 :(得分：3)
Rico Mariani关于为什么微软不将Visual Studio移植到64位的帖子真的总结了Visual Studio: Why is there no 64 bit version? (yet)
答案 5 :(得分：2)
这取决于您的代码是应用程序还是可重用库。对于库，请记住该库的客户端可能有充分的理由在64位模式下运行，因此您必须确保您的方案有效。当它们可以通过插件扩展时，这也适用于应用程序。
答案 6 :(得分：2)
除非有商业理由去64位，否则没有真正“需要”支持64位。
然而，除了其他人已经提到的那些之外，有一些很好的理由在某个时候进入64位。
购买非64位的电脑越来越难了。尽管32位应用程序将在未来几年内以兼容模式运行，但今天或将来出售的任何新PC都可能是64位。如果我有一个闪亮的64位操作系统，我真的不想在兼容模式下运行“臭旧的32位应用程序”！
有些事情在兼容模式下运行不正常 - 这与在32位硬件上运行32位操作系统不同。在兼容模式下运行时，我遇到了一些问题（例如，跨32/64位注册表配置单元的注册表访问，因为它们不在他们期望的文件夹中而失败的程序等）。我总是对在兼容模式下运行我的代码感到紧张 - 它只是“不是真实的东西”，它经常显示。
如果你已经干净地编写了代码，那么你很可能只需要将它重新编译为64位exe并且它可以正常工作，所以没有理由不试一试。
越早构建本机64位版本，就越容易在添加新功能时保持64位工作。这是一个更好的计划，而不是继续在黑暗时代继续发展另一个'n'年，然后试图跳出光明。
当你去参加下一次面试时，你可以说你有64位的体验和32-> 64的移植经验。
答案 7 :(得分：2)
如果您现在没有任何实际需要，并且可能永远不会，对于64位模式，您不应该进行移植。
如果你现在没有需要，但有一天可能有这个需要，你应该尝试估计它将付出多少努力（例如，通过打开所有相应的编译器警告，并尝试64位编译）。期望有些事情不是微不足道的，所以知道你可能遇到的问题以及修复它们可能需要多长时间会很有用。
请注意，依赖项也可能需要：如果您的程序是库（例如DLL），则可能需要将其移植到64位模式，因为某些主机应用程序已被移植。
在可预见的未来，将继续支持32位应用程序。
答案 8 :(得分：1)
您已经了解x64的优点（最重要的是增加的RAM大小）并且您对任何内容都不感兴趣，然后不要移植可执行文件（exe）。通常在端口之后性能会下降，主要是因为x64模块的大小超过x86：所有指针现在都需要双倍长度，并且这在任何地方都会渗透，包括代码大小（一些跳转，函数调用，vtable，虚拟调用，全局符号）等等）。不是显着降级，但通常是可测量的（速度降低3-5％，取决于许多因素）。
DLL值得移植，因为您在x64应用程序中获得了能够使用DLL的新“受众”。
答案 9 :(得分：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。
答案 10 :(得分：1)
某些操作系统或配置无法运行32位程序。例如，安装了没有32位libc的最小Linux。另外，IIRC我通常会从内核中编译出32位支持。
如果这些操作系统或配置是您潜在用户群的一部分，那么您可以移植它。
如果你需要更快的速度，那么你也应该移植它（正如其他人所说的那样，x86-64有更多的寄存器和很酷的指令可以加速它）。
或者，当然，如果你想要mmap（）或以其他方式映射大文件或大量内存。然后64位帮助。
答案 11 :(得分：0)
请参阅我对这个问题的回答here.我关闭了该帖子，称64位计算机可以存储和检索比32位计算机更多的信息。对于大多数用户而言，这并不意味着很多，因为浏览网页，查看电子邮件和播放Solitaire等内容都能在32位寻址范围内轻松完成。 64位的好处将真正发挥作用的地方是你拥有大量数据的领域，计算机将不得不通过这种方式。数字信号处理，千兆像素摄影和高级3D游戏都是其大量数据处理在64位环境中得到巨大提升的领域。
至于你的代码运行得更快/更好，这完全取决于你的代码和强加于它的要求。
答案 12 :(得分：0)
关于截止日期。我不担心，像32bit这样的东西会在本地和在可预见的未来以其他形式出现。
答案 13 :(得分：0)
除非您需要极端安全措施或淫秽数量的RAM，否则您不太可能看到任何好处。
基本上，您很可能直观地了解您的代码是否适合64位移植。
答案 14 :(得分：0)
关于性能问题，它实际上取决于您的程序。如果您的程序是指针密集型的，移植到64位可能会导致性能降级，因为对于具有相同大小的CPU缓存，每个64位指针在缓存上占用更多空间，并且虚拟到物理映射也占用更多TLB空间。否则，如果您的程序不是指针密集型的，那么它的性能将受益于x64。
当然，性能不是移植的唯一原因，还应考虑其他问题，如移植工作，时间安排。
答案 15 :(得分：0)
我建议将它移植到64位只是为了让你运行“native”（另外，我使用的是OpenBSD。在他们的AMD64端口中，它们不提供任何32位仿真支持，一切都必须是64位）
另外，stdint.h是你最好的朋友！通过移植应用程序，您应该学习如何移植代码。当我们拥有128位处理器（希望在几十年内）时，这将使您的代码正常工作
我已经将2或3个内容移植到64位，现在为两者开发（如果你使用stdint.h这很容易），而我的第一个项目移植到64位导致出现2或3个错误，但就是这样。大多数是简单的重新编译，现在我不担心在制作新代码时32位和64位之间的差异，因为我只是自动编码。 （使用intptr_t和size_t等）
答案 16 :(得分：0)
在从64位进程调用dll的情况下，dll也必须是64位。 那么它是否值得它无关紧要，你别无选择。
答案 17 :(得分：0)
要记住的一个问题是可用的软件库。例如，我的公司开发了一个使用多个OpenGL库的应用程序，我们在OpenSuSE OS上这样做。在旧版本的操作系统中，可以在x86_64架构上下载这些库的32位版本。然而，较新的版本没有这个。它使得以64位模式编译更容易。
答案 18 :(得分：-1)