为什么我们要为c++应用程序构建64位目标?

Why should we build 64 bit targets for C++ application?

本文关键字：构建 64位目标应用程序 c++ 我们为什么更新时间：2023-10-16

这是我最基本的疑问。我不是一个IT或CS的家伙，所以请尽量用简单的语言解释。我之所以问这个问题是因为我们可以在64位运行32位应用程序;32位操作系统。据我所知，64位的数据类型占用的内存是32位应用程序的两倍。此外，64位应用程序只能在64位操作系统上运行。那么为什么要花时间构建64位应用程序呢?也许这就是为什么Firefox只有32位版本??如果这个问题不符合SO的标准，很抱歉，但我就是忍不住不去想同样的问题。谢谢你。

更新:不知何故，似乎有一个混乱。我并不是想问为什么我们需要64位架构的机器。我知道32位机器只能使用4GB RAM。64位机器有更高的限制。我在问为什么我们需要构建64位应用程序!

除了上面给出的明显原因(主要是"使用超过2-3GB的内存")之外，编译为64位的原因是x86-64有16个寄存器，而x86-32有8个。由于其中一个寄存器是堆栈指针，并且rBP通常为"帧指针"保留，因此实际有用的寄存器数量分别为6和14。例如，额外的寄存器允许在寄存器中传递更多的参数，以及在函数的寄存器中保存更多的临时变量。这对代码的实际执行速度有积极的影响，因为每次使用内存而不是寄存器时，至少会导致更复杂的指令，并且通常必须使用额外的指令。当没有足够的寄存器时，这反过来又使代码变大。

一般来说，64位x86代码在不修改实际算法的情况下运行速度要快5-15%，而且通常是这样。有时算法可以改变以获得更多[因为例如你可以有一个由"电话号码"索引的数组，而不是对电话号码进行哈希，然后在哈希上进行索引，或者使用64位整数值而不是32位整数值，这意味着"一半的操作"的速度提高了2x]。

如果您需要应用程序的性能，则必须(在多个平台上)进行基准测试。在某些情况下，例如，更大的指针意味着缓存更快地被填满，代码最终运行得更慢，因为"只有一半的链表项适合缓存"。

简而言之:在大多数情况下，64位应用程序比32位应用程序做同样的事情要快。

最重要的用例是当您真的想为您的进程消耗超过2gb的内存时。

下一件事是32位支持将慢慢下降，就像你现在不会看到很多16位应用程序一样。这是一个缓慢的过程。目前有一个版本的Windows Server 2008默认不支持32位。

最后，有时你必须是64位的——这是当你构建任何类型的扩展加载到64位的消费者进程时。由于64位进程不能加载32位代码，您必须为它们提供64位扩展，或者制作一个互操作解决方案，将您的代码放在单独的进程中——后者并不总是可行的，有时效率非常低。

32位系统架构只能直接寻址4gb的地址空间。运行64位版本Windows Server的64位系统架构可以支持最多1,024gb的物理内存和可寻址内存。

更好的并行处理

使用32位架构的服务器(Windows操作系统)限制为32个cpu。并行处理和总线架构的改进使64位环境能够支持多达64个处理器，并为每个额外的处理器提供几乎线性的可扩展性。

更快的总线架构

64位体系结构提供更多更宽的通用寄存器，这有助于提高整体应用程序的速度。当有更多的寄存器时，就不需要将持久数据写入内存，然后在几个指令之后再将其读回来。在64位环境中，函数调用也更快，因为一次可以在寄存器中向函数传递多达四个参数。

对于x64，数据类型的大小不会自动翻倍，但是处理器寄存器的大小会自动翻倍，就像指针大小一样。使用32位，您可以寻址4294967295字节的内存(~ 4 Gb)，这对于某些应用程序(如数据库管理系统，…)来说是不够的。

由于兼容性问题，Firefox只支持32位。您不能为x86(32位)架构编写库并从x64处理器调用它们，因为它们的指针不兼容(如上所述)。同时创建:x64 和 x86版本会增加测试开销。如果您的应用程序很少使用超过3.5 Gb的内存，那么它实际上并没有从x64架构中获益。

32位程序也不能简单地在x64架构上运行。在Windows上有一个层，称为Windows On Windows (WoW)，或WoW64用于x64/x86接口。通过各种缓存情况，也可能是x86应用程序在WoW上运行得比本地x64应用程序更快。