有没有真正的点将Windows应用程序编译为64位？

Question

我自信地说,我们编写的99%的应用程序不需要处理超过2Gb的内存.当然,运行64位的操作系统可以获得很多明显的好处来解决更多的内存,但是有一个特殊的原因是典型的应用程序可以编译为64位吗？

Answer 1

使用64位可能会看到性能改进.一个很好的例子是函数调用中的一些参数是通过寄存器传递的(在栈上推送的东西较少).

编辑 我查看了一些旧的笔记,当时我正在研究使用64位构建和32位构建运行产品的一些差异.我在四核64位机器上运行测试.因此,存在将苹果与橙子进行比较的问题,因为32位显然在仿真模式下运行.但是,似乎我读过的很多东西,例如,一直都说WOW64的速度并不重要.但即使该声明不正确,您的应用程序几乎肯定会在64位操作系统上运行.因此,在64位计算机上比较32位版本与64位版本具有价值.

在我执行的测试中(当然不全面),我没有发现任何32位版本更快的情况.但是,当运行64位版本时,我运行的许多SQL密集型操作(高CPU和高I/O)的速度提高了20%到50%.这些测试涉及一些相当"丑陋"的SQL语句以及一些具有高并发性的TPCC测试.当然,很大程度上取决于编译器开关,所以你需要做自己的测试.

Answer 2

现在将它们构建为64位,即使您从未发布构建,也可以帮助您查找和修复以后在您被迫构建和发布为64位时遇到的问题.

Answer 3

x64有8个通用寄存器,在运行32位代码时不可用.这是三倍的数量(如果将ESI,EDI,EBP和ESP视为通用目标,则为两倍);我不这样做.这可以在使用四个以上变量的函数中节省大量的加载和存储.

Answer 4

不要低估提供本机64位版本产品的营销价值.

此外,您可能会惊讶于有多少人处理需要尽可能多内存的应用程序.

Answer 5

我会说只有你需要2GB以上才能做到这一点.

一件事是64位编译意味着(显然)64位指针.这意味着代码和数据结构变得更大,意味着应用程序.将从缓存中受益少一点,并会更频繁地击中虚拟内存等.

所以,如果你不需要它,基本的效果就是让你的应用程序慢慢变得更加膨胀,无缘无故.

也就是说,随着时间的推移,无论如何你都会更关心64位,因为这就是为所有工具和库等编写的.即使您的应用程序可以在64K中幸福地生活,您也不太可能使用16位代码 - 这些增益并不重要(无论如何它都是一个小型的快速应用程序),并且肯定超过了所涉及的麻烦.到时候,我们会以同样的方式看到32位.

Answer 6

您可以将其视为面向未来的。这可能还有很长的路要走，但是要考虑到未来几年，到处都是64位OS和CPU（考虑一下32位接管后16位将如何消失）。如果您的应用程序是32位的，而您的所有竞争对手到那时都已升级到64位，则您的应用程序可能会被视为（或被您的竞争对手指责）过时，较慢或无法更改。也许甚至一天对32位应用程序的支持也将被删除或不完整（Windows 7是否可以正常运行16位应用程序？）。如果您现在已经在构建应用程序的64位版本，则可以避免这些问题。如果推迟到以后，您可能会在现在到移植之间编写更多的代码，那么移植会更加困难。

对于很多应用程序来说，并没有太多令人信服的技术原因，但是如果很简单，立即移植可能会节省您将来的工作。