这是我非常基本的疑问。我不是一个IT或CS的人，所以请尝试用简单的语言来解释。 现在为什么我问这个问题是因为我们可以在64位32位操作系统中运行32位应用程序。 AFAIK 64位数据类型比32位应用需要两倍的内存。另外64位应用程序只能在64位操作系统上运行。 那么为什么不费力地构建64位应用程序？ 也许这就是为什么Firefox只有32位可用？ 对不起，如果这个问题不符合标准的SO，但我不能控制停止思考相同。 谢谢。我们为什么要为C++应用程序构建64位目标？
更新：不知何故似乎有一个混淆。 我并不是想问为什么我们需要一个64位体系结构的机器。 我知道32位机器只能使用4GB RAM，64位机器有更高的限制。 我在质疑为什么我们需要构建64位应用程序！
除了上面给出的明显原因（主要是“使用大于2-3GB的内存”）之外，编译64位的原因是x86-64有16个寄存器，其中x86-32有8个。其中一个寄存器是堆栈指针，并且通常rBP被保留为“framepointer”，实际有用的寄存器数量分别为6和14。例如，附加寄存器允许在寄存器中传递更多数量的参数，并且在函数内的寄存器中保存更多数量的临时变量。这对代码的实际执行速度有积极影响，因为每次使用内存而不是寄存器时，至少会导致更复杂的指令，并且通常需要使用额外的指令。当没有足够的寄存器时，这又会使代码变大。
通常，64位x86代码运行速度比实际算法快5-15％，而且通常没有修改。有时候算法可以被改变以获得更多的效果[例如，因为例如你可以有一个由“电话号码”索引的数组，而不是散列电话号码，然后对散列进行索引，或者使用64位整数值的32位，这意味着“一半的操作”增加了2倍]。
如果您需要从应用程序获得性能，那么您必须进行基准测试（在多个平台上）。在某些情况下，例如较大的指针，意味着缓存变得更快，并且代码结束运行速度较慢，因为“缓存中只有一半的链接项适合”。
总之：在大多数情况下，64位应用程序比32位应用程序做同样的事情更快。
32位应用程序可以通过\ LARGEADDRESSAWARE开关在64位窗口上访问4GB：http://support.microsoft.com/default.aspx?scid=889654 – EdChum 2013-04-11 12:52:24
而且他们可以通过[AWE]访问超过4 GB（http： //msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx） – dyp 2013-04-11 12:53:09
是的，这两个都是真实的（好吧，它“仅仅低于4GB”，但对于所有人目的和目的是4GB）。 AWE不会给你一大块内存，但代码必须跳过这些内存，这不是一个好的解决方案。 – 2013-04-11 12:58:47
最重要的用例是当你真的想为你的进程消耗超过2GB的内存时。
接下来的事情是32位支持将会慢慢下降，就像你现在看不到许多16位应用程序一样。尽管这是一个缓慢的过程。目前有一个Windows Server 2008版本默认不支持32位。
最后，有时你只需要64位 - 那就是当你建立一个加载到64位消费者进程中的任何类型的扩展。由于64位进程无法加载32位代码，因此您必须为它们提供64位扩展，或者制定互操作解决方案以将代码放在单独的进程中 - 后者并非总是可行，而且有时非常低效。
谢谢你的简单回答，因为我问过。 但是我无法理解第3段。 – 2013-04-11 12:48:33
@Cool_Coder：你不明白哪件事？ – sharptooth 2013-04-11 12:49:18
32位应用程序可以通过\ LARGEADDRESSAWARE开关在64位窗口上访问4GB：http：//support.microsoft.com/default.aspx？scid = 889654 – EdChum 2013-04-11 12:51:53
32位的系统架构可以直接寻址只有4 GB的地址空间。运行64位版本Windows Server的64位系统体系结构最多可支持1,024 GB的物理和可寻址内存。
即使用32位体系结构的服务器是有限的（Windows操作系统）32个CPU。并行处理和总线体系结构的改进使64位环境能够支持多达64个处理器，并为每个额外的处理器提供几乎线性的可扩展性。
64位体系结构提供了更多的和更广泛的通用寄存器，这有助于提高整体的应用的速度。当有更多的寄存器时，不需要将持久数据写入存储器，然后只需稍后几条指令即可读回。函数调用在64位环境中也更快，因为一次最多可以将四个参数传递到函数中。
Emmm ...为什么32位服务器限于32个CPU我想知道？ – sharptooth 2013-04-11 12:33:33
我在这里找到它：http://technet.microsoft.com/en-us/library/dd630755%28v=office.12%29.aspx – duDE 2013-04-11 12:38:02
这是一些Windows特定的限制。 – sharptooth 2013-04-11 12:39:55
数据类型的大小不会自动与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应用程序的运行速度更快，同样如此。
嘿@Aschratt感谢那些信息，我不知道。 因此，Windows只有在64位操作系统上运行32位应用程序的专业？默认情况下，64位Ubuntu不运行32位应用程序。我在问，因为我不知道。 – 2013-04-11 13:06:12
我不知道Linux（或Ubuntu）是否有这样一个抽象层。基本上WoW64“模拟”x86处理器到x86进程。这不是很难，因为大多数操作码都是相同的，所需要做的就是修正指针。我认为Ubuntu有类似的东西，但我真的不知道。 – Carsten 2013-04-11 13:08:59
有没有试图在32位进程中分配150GiB的内存？ – PlasmaHH 2013-04-11 12:28:14
64位应用程序可以访问更多的内存。这对于一些应用来说很重要，对其他应用来说并不重要 – john 2013-04-11 12:28:52
@PlasmaHH什么是GiB？它与千兆字节（GB）有关吗？ – 2013-04-11 12:34:06