64位程序是否比32位版本更大，更快？

我想我专注于x86，但是我通常对从32位到64位的转换感兴趣。

从逻辑上讲，我可以看到常量和指针在某些情况下会更大，因此程序可能会更大。为了提高效率而在单词边界上分配内存的愿望将意味着分配之间会有更多的空白。

我还听说x86的32位模式在上下文切换时由于可能重叠的4G地址空间而必须刷新其缓存。

那么，64位的真正好处是什么？

作为补充问题，128位会更好吗？

编辑：

我刚刚编写了第一个32/64位程序。它制作了16字节（32b版本）或32字节（64b版本）对象的链表/树，并在stderr上进行了大量打印-这不是一个真正有用的程序，也不是典型的程序，但这是我的第一个。

大小：81128（32b）v 83672（64b）-差异不大

速度：17s（32b）v 24s（64b）-在32位OS（OS-X 10.5.8）上运行

更新：

我注意到，正在开发一种新的混合x32 ABI（应用程序二进制接口），它是64b但使用32b指针。对于某些测试，与32b或64b相比，它导致更小的代码和更快的执行速度。

https://sites.google.com/site/x32abi/

除非您需要访问32b寻址将允许您使用的更多内存，否则好处将是很小的（如果有的话）。

在64b CPU上运行时，无论运行的是32b还是64b代码，您都将获得相同的内存接口（使用相同的缓存和相同的BUS）。

虽然x64体系结构具有更多的寄存器，可以简化优化操作，但事实通常是由于现在的指针更大而抵消了，并且使用带有指针的任何结构都会导致更大的内存流量。我估计与64b应用程序相比，与32b应用程序相比，整体内存使用量的增加约为15-30％。

通常，与x86相比，x86-64上的计算密集型代码的速度提高了30％。这很可能是由于我们拥有16 x 64位通用寄存器和16 x SSE寄存器，而不是8 x 32位通用寄存器和8 x SSE寄存器。这与x86-64 Linux上的Intel ICC编译器（11.1）一起使用-其他编译器（例如gcc）或其他操作系统（例如Windows）的结果当然可能有所不同。

不管有什么好处，我建议您始终按照系统的默认字长（32位或64位）编译程序，因为如果将库编译为32位二进制文​​件并在64位上提供系统，当默认可用64位版本时，您将强制任何想要与您的库链接的人以32位二进制文​​件的形式提供其库（以及任何其他库依赖项）。这对每个人都可能是个麻烦。如有疑问，请提供您的库的两个版本。

至于64位的实际好处...最明显的是，您可以获得更大的地址空间，因此，如果mmap一个文件，则可以一次寻址更多地址（并将更大的文件加载到内存中）。另一个好处是，假设编译器在优化方面做得很好，则您的许多算术运算都可以并行化（例如，将两个32位数字对放在两个寄存器中，并在单个加法运算中执行两个加法），并且很大数字计算将运行得更快。就是说，整个64位和32位的内容完全不会帮助您解决渐近复杂性，因此，如果您要优化代码，则可能应该考虑算法而不是像这样的常量因素。

编辑：
请忽略我关于并行化加法的声明。这不是通过普通的add语句执行的...我将其与某些向量化/ SSE指令相混淆。除了更大的地址空间外，更准确的好处是有更多的通用寄存器，这意味着与将变量放在CPU寄存器文件中相比，可以在CPU寄存器文件中维护更多的局部变量。程序堆栈（通常意味着进入L1缓存）。

除了具有更多寄存器外，默认情况下64位还具有SSE2。这意味着您确实可以并行执行一些计算。SSE扩展也具有其他优点。但是我想主要的好处是不必检查扩展的存在。如果是x64，则可以使用SSE2。...如果我的记忆正确地为我服务。

我正在编写一个名为foolsmate的象棋引擎。使用基于最小极大值的树搜索到深度9（从某个位置）进行的最佳移动提取为：

关于Win32配置：〜17.0s;

切换到x64配置后：〜10.3s;

这是41％的加速度！

只有将应用程序迁移到64位的理由才需要在具有至少100个并发用户的大型数据库或ERP应用程序等应用程序中需要更多的内存，当应用程序缓存以实现更好的性能时，很快就会超过2 GB的限制。在Windows操作系统上，尤其是在整数和long仍为32位的情况下（它们具有新的变量_int64。只有指针是64位。）实际上，WOW64在Windows x64上进行了高度优化，因此32位应用程序在64位Windows上运行时耗费很少操作系统：我在Windows x64上的经验是32位应用程序版本比64位版本运行速度快10-15％，因为在前一种情况下，至少对于专有内存数据库，您可以使用指针算术维护b树（数据库系统中处理器最密集的部分） 。需要32位至64位操作系统上的双精度值无法提供的最高精度的计算密集型应用程序。这些应用程序可以本机使用_int64而不是软件仿真。当然，仅基于大型磁盘的数据库也将显示出超过32位的改进，这仅仅是由于能够使用大型内存来缓存查询计划等。

每次读取内存时，都会在CPU和RAM之间传输更多数据（64位而不是32位），因此如果写入64位程序，则可以更快地利用它们，从而可以更快地利用它们。

在x68到x68_64的特定情况下，该64位程序的大小大约相同，即使不小一点，也要使用更多的内存，并且运行速度更快。通常，这是因为x86_64不仅具有64位寄存器，而且还具有两倍的数量。x86没有足够的寄存器来使编译后的语言尽可能高效，因此x86代码花费大量指令和内存带宽在寄存器和内存之间来回移动数据。x86_64具有更少的空间，因此占用的空间更少，运行速度更快。在x86_64中，浮点和位翻转向量指令也更加有效。

但是，总的来说，对于运行时的代码和内存使用情况，64位代码不一定会更快，并且通常更大。

任何需要CPU使用的应用程序，例如转码，显示性能和媒体渲染，无论是音频还是视觉的，都肯定会（此时）需要，并且由于CPU能够处理纯粹的能力，因此可以使用64位而不是32位向其抛出的数据量。与其说地址空间是问题，不如说是数据处理的方式。给定64位代码的64位处理器性能将更好，尤其是在数学上难以处理的事情（如转码和VoIP数据）时-实际上，使用64位CPU和操作系统都应受益于任何“数学”应用程序。证明我是错的。