这是我的一个非常基本的疑问。我不是 IT 或 CS 人，所以请尽量用简单的语言解释。现在我问这个问题的原因是因为我们可以在 64 位和 32 位操作系统中运行 32 位应用程序。AFAIK 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 位的，这意味着“一半的操作”的速度提高了 2 倍]。
如果您需要应用程序的性能，则必须进行基准测试（在多个平台上）。在某些情况下，例如，更大的指针意味着缓存更快地被填满，而代码最终运行得更慢，因为“只有一半的链表条目适合缓存”。
简而言之：在大多数情况下，64 位应用程序比 32 位应用程序做同样的事情要快。
最重要的用例是当您真的想为您的进程消耗超过 2 GB 的内存时。
接下来是 32 位支持将慢慢下降，就像您现在不会看到很多 16 位应用程序一样。虽然这是一个缓慢的过程。目前有一个版本的 Windows Server 2008 默认不支持 32 位。
最后，有时您只需要 64 位 - 那就是您构建加载到 64 位消费者进程中的任何类型的扩展时。由于 64 位进程无法加载 32 位代码，因此您必须为它们提供 64 位扩展或制作互操作解决方案以将您的代码放在单独的进程中 - 后者并不总是可行的，有时效率非常低。
32 位系统架构只能直接寻址 4 GB 地址空间。运行 64 位版本的 Windows Server 的 64 位系统体系结构可以支持高达 1,024 GB 的物理内存和可寻址内存。
使用 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)或用于 x64/x86 接口的 WoW64。通过各种缓存案例，x86 应用程序在 WoW 上的运行速度实际上可能比原生 x64 应用程序更快。