我想我专注于 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-X 10.5.8) 上运行
更新：
我注意到正在开发一种新的混合 x32 ABI（应用程序二进制接口），它是 64b 但使用 32b 指针。对于某些测试，它会产生比 32b 或 64b 更小的代码和更快的执行速度。
与 x86 相比，我通常看到 x86-64 上的计算密集型代码的速度提高了 30%。这很可能是因为我们有 16 个 64 位通用寄存器和 16 个 SSE 寄存器，而不是 8 个 32 位通用寄存器和 8 个 SSE 寄存器。这是在 x86-64 Linux 上使用英特尔 ICC 编译器 (11.1) - 使用其他编译器（例如 gcc）或其他操作系统（例如 Windows）的结果当然可能会有所不同。
除非您需要访问 32b 寻址允许的更多内存，否则好处将很小（如果有的话）。
在 64b CPU 上运行时，无论您是运行 32b 还是 64b 代码（您使用相同的缓存和相同的 BUS），您都会获得相同的内存接口。
虽然 x64 架构有更多的寄存器，可以更轻松地进行优化，但这通常会被指针现在更大的事实抵消，并且使用任何带有指针的结构都会导致更高的内存流量。我估计 64b 应用程序的整体内存使用量与 32b 应用程序相比增加了 15-30% 左右。
不管有什么好处，我建议您始终按照系统的默认字长（32 位或 64 位）编译程序，因为如果您将库编译为 32 位二进制文件并在 64 位上提供它系统，当 64 位版本是默认可用时，您将强制任何想要与您的库链接的人提供他们的库（以及任何其他库依赖项）作为 32 位二进制文件。这对每个人来说都是相当麻烦的。如有疑问，请提供您的库的两个版本。
至于 64 位的实际好处……最明显的是您可以获得更大的地址空间，因此如果 mmap 一个文件，您可以一次处理更多的地址（并将更大的文件加载到内存中）。另一个好处是，假设编译器在优化方面做得很好，您的许多算术运算都可以并行化（例如，将两对 32 位数字放在两个寄存器中，并在一次加法运算中执行两次加法），并且大数字计算将运行得更快。也就是说，整个 64 位与 32 位的东西根本无法帮助您解决渐近复杂性，因此如果您正在寻找优化代码，您可能应该关注算法而不是像这样的常量因素。
编辑：
请忽略我关于并行添加的声明。这不是由普通的 add 语句执行的……我对一些向量化/SSE 指令感到困惑。除了更大的地址空间之外，更准确的好处是有更多的通用寄存器，这意味着可以在 CPU 寄存器文件中维护更多的局部变量，这比将变量放在程序栈（这通常意味着去 L1 缓存）。
I'm coding a chess engine named foolsmate. The best move extraction using a minimax-based tree search to depth 9 (from a certain position) took:
on Win32 configuration: ~17.0s;
after switching to x64 configuration: ~10.3s;
This is 41% of acceleration!
除了有更多的寄存器，64 位默认还有 SSE2。这意味着您确实可以并行执行一些计算。SSE 扩展也有其他好处。但我想主要的好处是不必检查扩展的存在。如果是 x64，它有 SSE2 可用。...如果我没有记错的话。
将应用程序迁移到 64 位的唯一理由是在大型数据库或具有至少 100 个并发用户的 ERP 应用程序等应用程序中需要更多内存，当应用程序缓存以获得更好的性能时，会很快超过 2 GB 的限制。这种情况特别适用于整数和长整数仍然是 32 位的 Windows 操作系统（它们有新的变量 _int64。只有指针是 64 位的。事实上，WOW64 在 Windows x64 上进行了高度优化，因此 32 位应用程序在 64 位 Windows 上运行时损失较低操作系统. 我在 Windows x64 上的经验是 32 位应用程序版本的运行速度比 64 位快 10-15%，因为在前一种情况下，至少对于专有内存数据库，您可以使用指针算术来维护 b-tree（数据库系统的大多数处理器密集型部分） . 在 32-64 位操作系统上需要大小数才能获得最高精度的计算密集型应用程序是 double 所不能提供的。这些应用程序可以在本地使用 _int64，而不是软件仿真。当然，基于大磁盘的数据库也将显示超过 32 位的改进，这仅仅是因为能够使用大内存来缓存查询计划等。
每次内存读取（64 位而不是 32 位）在 CPU 和 RAM 之间传输更多数据，因此 64 位程序可以更快，只要它们被写入以便它们正确利用这一点。
在 x68 到 x68_64 的特定情况下，64 位程序的大小将大致相同，如果不是稍微小一点，使用更多的内存，运行得更快。这主要是因为 x86_64 不仅有 64 位寄存器，它还有两倍的数量。x86 没有足够的寄存器来使编译语言尽可能高效，因此 x86 代码花费大量指令和内存带宽在寄存器和内存之间来回移动数据。x86_64 少得多，因此它占用的空间更少，运行速度更快。浮点和位旋转向量指令在 x86_64 中也更有效。
不过，一般来说，64 位代码不一定更快，而且通常更大，无论是运行时的代码还是内存使用。
Any applications that require CPU usage such as transcoding, display performance and media rendering, whether it be audio or visual, will certainly require (at this point) and benefit from using 64 bit versus 32 bit due to the CPU's ability to deal with the sheer amount of data being thrown at it. It's not so much a question of address space as it is the way the data is being dealt with. A 64 bit processor, given 64 bit code, is going to perform better, especially with mathematically difficult things like transcoding and VoIP data - in fact, any sort of 'math' applications should benefit by the usage of 64 bit CPUs and operating systems. Prove me wrong.