Linux 2.6 32位+ BIGMEM与Linux 2.6 64位？

在x86处理器中，64位代码有两种方式：

• 更大的地址可让您直接访问更多内存（仅与pipe理大型数据集的进程相关）
• 更多的寄存器可能会让编译器减less紧密variables的内存访问（轻微的额外优化，除了高度优化代码的严格循环之外，这些优化是不明显的）。

并有以下缺点：

• 越来越大的寄存器意味着更多的状态来保存/恢复每个上下文切换。
• 更大的指针意味着更多的RAM使用和更大的结构，更多的数据读/写。

因此，在很多情况下，两全其美是64位操作系统和32位处理器：

• 一个64位的操作系统可以处理大量的RAM，既可以存放很多进程，也可以存放大量的caching
• 每个进程的32位应用程序被限制在2或3 GB RAM，但对于绝大多数任务来说，这已经足够了。
• 无论在32位任务的RAM所在的64位空间中，只需要32位指针就可以访问它的存储器，所以所有的指针和数据结构仍然是较小的32位。
• 32位任务（进程或线程）只需要保存/恢复32位x86中可用的less量和小型寄存器，而64位Linux调度器就可以很好地处理这种情况。

但总的来说，这个好处很less引人注意（只是猜测它远远低于5％），所以随处使用64位就可以简化了。

唯一的情况下，我一定会用32-on-64就是在做OpenVZtypes的隔离。 这样，每个分区所有者就可以充分利用他可以访问的有限RAM。

仍然，我不知道任何超过64位PAE（甚至没有小指针，因为每个PAE指针有一个32位的偏移量和一个额外的（最多32位）“开始”（记住分段内存8086？多么膨胀的负荷！）

PAE伤害performance。 唯一可能的增益是指针大小的一半，但是现在你必须处理交换周围的内存页面。

除了较less的寄存器饥饿之外，x86_64还为您提供更明智的浮点运算。 它也保证你的二进制文件得到更好的优化，因为编译器不需要发射向后兼容的操作码。 如果你正在运行任何cpu-bound，这是一个巨大的胜利。