我知道x64架构的一些明显优点(更高可寻址的RAM地址等)……但是:
- 如果我的程序没有真正需要在本机64位模式下运行,我还应该移植它吗?
- 是否有预期的截止日期来结束32位支持?
- 作为本机x64代码,我的应用程序是否会更快/更好/更安全地运行?
我知道x64架构的一些明显优点(更高可寻址的RAM地址等)……但是:
x86-64有些特殊,对于许多体系架构(例如SPARC),将应用程序编译为64位模式并不会带来任何好处,除非它能够有效地使用超过4GB的内存。所有它所做的就是增加二进制文件的大小,这实际上可能会使代码变慢,如果它影响了缓存行为。
然而,x86-64不仅提供了64位地址空间和64位整数寄存器 - 它还加倍了通用寄存器的数量,在像x86这样缺乏寄存器的体系架构上,只需重新编译即可显著提高性能。
此外,它还允许编译器假定许多扩展功能,如SSE和SSE2已存在,这也可以显著改善代码优化。
另一个好处是x86-64添加了PC相对寻址(PC-relative addressing),这可以显著简化位置无关代码(position-independent code)。
但是,如果应用程序对性能不敏感,那么这一切都不是很重要。
可能有一个未被提及的潜在优势是它可能会发现潜在的bug。一旦将其移植到64位,就会进行许多更改。某些数据类型的大小会改变,调用约定会改变,在Windows上,异常处理机制也会改变。
所有这些都可能导致隐藏的bug浮出水面,这意味着您可以修复它们。
假设您的代码正确且无漏洞,则理论上将其移植到64位应该很简单,只需要打开编译器开关即可。如果失败了,那是因为您依赖于语言不保证的东西,因此它们是潜在的错误来源。
64位技术给你带来以下好处:
我移植了许多C++应用程序,并看到64位代码提高了大约10%的速度(相同的系统、相同的编译器,唯一的变化是32位与64位编译器模式),但其中大部分应用程序都进行了相当数量的64位数学计算。个人经验因人而异。
我不会担心32位支持会很快消失。
(编辑评论中的笔记-谢谢!)
Rico Mariani关于为什么微软没有将Visual Studio移植到64位的帖子真正总结了一切 Visual Studio: Why is there no 64 bit version? (yet)
越来越难买到不支持64位的PC。即使32位应用程序将在未来几年内以兼容模式运行,但今天或未来销售的任何新PC都可能是64位。如果我有一个闪亮的64位操作系统,我不想在兼容模式下运行“旧气味的32位应用程序”!
有些东西在兼容模式下无法正常运行——这不同于在32位硬件上运行32位操作系统。当我在兼容模式下运行时会遇到一些问题(例如跨32/64位注册表区域访问注册表、程序因为它们不在所期望的文件夹中而失败等),我总是感到紧张。我总觉得在兼容模式下运行我的代码只是“不是真正的东西”,而且经常会出现问题。
如果您编写的代码干净利落,那么很有可能只需要重新编译为64位exe,它就可以正常工作,因此没有真正的理由不尝试一下。
越早构建本机64位版本,将来添加新功能时就越容易使其在64位上正常工作。这比在另外“n”年中继续在黑暗时代开发然后试图跳出光线要好得多。
当您进行下一次工作面试时,您将能够说自己具有64位经验和32->64端口经验。
这取决于你的代码是应用程序还是可重用库。对于一个库而言,要记住该库的客户端可能有充分的理由在64位模式下运行,因此您必须确保您的情况可以正常工作。当应用程序通过插件进行扩展时,这也可能适用。
如果您现在没有任何实际需要并且将来也不太可能需要64位模式,那么您就不应该进行移植。
如果您现在没有这个需求,但未来可能会有,您应该尝试估计所需的努力程度(例如,打开所有相关编译器警告并尝试进行64位编译)。请预期一些问题并非简单易解,因此了解您可能遇到的问题和解决它们需要多长时间将很有用。
请注意,需求也可能源自依赖关系:如果您的程序是一个库(例如DLL),则可能需要将其移植到64位模式,仅因为某些主机应用程序已经移植到了该模式。
在可预见的未来,32位应用程序将继续受到支持。
struct packet {
unsigned long name_id;
unsigned short age;
};
你已经了解了x64的优势(最重要的是增加的RAM大小),并且对此不感兴趣,那么就不要移植可执行文件(exe)。通常情况下,在移植后性能会降低,主要是由于x64模块的大小增加而导致的:现在所有指针都需要双倍长度,并且这种影响会扩散到各个方面,包括代码大小(一些跳转、函数调用、虚表、虚拟调用、全局符号等等)。虽然不是很明显的降级,但通常是可以测量的(速度降低3-5%,取决于许多因素)。
DLL值得移植,因为您可以在能够使用您的DLL的x64应用程序中获得新的“受众”。