我应该提供我的应用程序的x64版本吗?

编译和调试x64版本的另一个潜在原因是,它可能会在x86版本中暴露隐藏的错误。例如,这可能会暴露32位整数和(现在)64位指针之间的不正确转换。这也将使您在将来支持x64。

但是,除非您的应用程序能够从64位整数、额外的CPU寄存器、更大的内存空间(超过3.5GB)或实现设备驱动程序中获益,否则与32位应用程序一起使用是可以的。所有主要的操作系统都支持同时运行x32和x64应用程序,因此不会有针对64位应用程序的主要推动。

基于.NET的btw.应用程序自动受益于在64位系统上执行而不更改任何代码。不 额外的 需要测试。

潜在的性能改进主要与64位整数的使用有关(在我的计算机上,X64构建的速度大约是在我的计算机上X86的4倍),而且编译器可能会假定支持X64的CPU(如SSE2和C)中普遍存在一些CPU功能;这可能会导致代码更加优化。

对于许多应用程序,尤其是小型应用程序,64位清洗并不太困难,对于大型应用程序,这是一个很大的难题,当然。通常,令人信服的理由很少。但默认情况下,有些平台不在64位版本中安装32位支持(我认为需要明确告知FreeBSD这样做,但我可能会出错)。

如果你的程序使用很多 long long s和wow当然意味着一个小的性能损失(非常小,因为CPU有这样的兼容模式)。

Windows对32位程序的支持在未来会下降(尽管速度很慢),所以我说,在接下来的一年或两年内,您可能会想知道为什么要部署32位应用程序…

此外,应用程序的64位构建实际上可以比32位构建优化得多,因为使用64位构建,可以保证有很多东西,如SSE2。

性能;x86_64比x86快一小部分(这也取决于编译器),原因已经说明。此外,支持真正巨大的数据集更容易,但当然许多应用程序不需要去那里。

当然,在Linux和OS X上,您真的应该支持x86_64;我在OS X上的64位浏览器中键入它,角落里的Linux框也是64位的,几乎是独占的。64位Windows是一个更大的问题,但现在(驱动程序)已经出现了。

这通常是基于人为因素而不是客观的技术推理。64位是最新和最大的,必须优于32位。如果顾客想要,顾客总是对的。与Windows用户交谈过,他们的目标是使其在Windows*32中查看进程列表时不会显示在任何应用程序旁边。

通常情况下,这种情况也会因为在兼容点上的混乱而加剧,因为人们有64位操作系统,只是想确保软件可以在他们的计算机上工作。期望普通人理解64位操作系统上32位进程之间的技术界限是不现实的。除非包装上明确说明,否则对于购买新软件的客户来说,这可能是一个困惑/担忧的问题。因为这个原因,您经常会看到64位被提到。通常,这实际上意味着只有64位兼容性。

现在有几个64位的应用程序(flash player和google earth在我的列表中居首位)还不够快。

原因之一是:与64位应用程序集成,比如编写shell扩展。64位进程不能直接加载32位的dll,因此您也必须将自己的dll设置为64位。

一个尚未提及的因素是: WoW64 Is Now an Optional Feature for Server Core . 当然,只有当应用程序需要在服务器系统上运行时才有问题。

同样,Windows PE、Windows RE等不包括WOW64。