我不确定我是否理解正确：64位操作系统是否比同一系统上的32位操作系统更快地运行/编译代码？
我们正在使用64位操作系统而且它似乎只会导致与传统和专有软件的兼容性问题。 （我们正在运行Ubuntu 9.04 Jaunty amd64）
答案 0 :(得分：18)
我将这个答案限制在x86-32（IA-32）vs x86-64（AMD64），因为我认为这是你实际要问的问题。
在处理器级别，有一些优点。首先也是最明显的是将每进程虚拟内存扩展到更宽的48位范围。 （如果内存服务，则允许在体系结构中使用64但不是必需的。）这使应用程序可以使用系统可用的更多内存，并为内存映射文件等操作开辟了大量空间未链接到实际内存的虚拟内存。它还为相关操作系统开辟了大量空间，因为它不必共享4 GB的数据限制。简而言之，应用程序和操作系统可以更好地利用机器的资源。
此外，AMD64架构解决了IA-32最大的问题之一，即完全没有寄存器。事实上，它使可用的寄存器加倍，这对某些类型的代码来说是一个巨大的胜利。 （实际上它几乎可以用于任何代码，但是有些应用程序会受到64位内存成本增加的影响，并且它会变得均匀。）
在Windows方面，MS将其视为打破一大堆历史兼容性问题的机会。这不是与旧世界的彻底决裂，但它是一个开始。我不认为Linux一开始会遇到同样的问题，而且我没有太多的观点来提供它们的64位优势。
答案 1 :(得分：11)
作为一般规则，在任何上下文中开发或使用64位操作系统将比相同的32位操作系统更慢。因为所有指针突然大两倍，所以你更有可能破坏缓存，并且可以在RAM中容纳更少的数据。这大大减慢了你的应用程序。当您的应用程序需要同时处理超过2到3 GB的数据时，您通常只会使用64位系统 - 这在科学计算和某些数据库情况下非常常见，但在其他方面非常罕见。这就是为什么Apple不提倡无条件地在64位模式下编译PowerPC应用程序，例如：由于缓存未命中和内存不足导致的成本足够高，只有当你真正可以利用64位空间。
但x86诉AMD64，这是你真正要求的（因为你正在讨论Ubuntu），是一个非常特别的野兽。 AMD64不仅将所有指针扩展到64位;它修复了x86架构中的许多不足之处，将GPR数量增加了一倍，简化了指令，使其更加适合现代CPU设计等等。因此，仅在AMD64平台上，你会经常看到64位的性能提升。
还有另外一个领域，在软件开发中，转到64位是有意义的：你需要运行大量的虚拟机。运行几个虚拟机很容易让你超过操作系统的3 GB内存屏障，使得使用它们非常痛苦。 （它将起作用，因为英特尔发明了一种称为PAE或分页寻址扩展的技术来弥合32位系统和64位系统之间的差距，但结果很慢，很难与开发人员合作，而不是在Windows上得到了很好的支持。）使用64位操作系统可以带来巨大的好处。
答案 2 :(得分：6)
（正如评论员所说，这个答案有些通用，其中一些不适用于intel / amd芯片。）
答案是：它有所不同，原因如下：
使用更大宽度的指令，您将获得更多的表现力（更多种指令或更大容量将数据直接编码到这些指令中），这可能意味着流经的指令数量减少机器，这通常是一个胜利：所以++ 64bit在这里。
但有时较大的指令可能需要更多周期来解码和执行，因为它们可能更复杂。所以可能--64位在这里。
此外，您需要将这些指令传入和传出CPU：64位指令是32位指令的两倍，这意味着进出内存和缓存的流量更多。 CPU的结构可以改善很多这样的成本，但这里只有-64位。
更多寄存器通常在更宽的指令集中可用，这导致进出堆栈和/或内存的数据流量更少。那么++ 64bit就在这里。
正如每个人毫无疑问都要提到的那样，你有能力解决更多的记忆。
（几乎忘记了这个）本机“long”或“int”大小可能会上升，具体取决于架构，这意味着基于这些的数据结构会变大。更大=移动更多内存，这意味着更多可能等待数据移动： - 64位如果你不小心。
根据您的架构，许多其他问题也可能适用。您可以放心，处理器和编译器供应商正在努力减少上面的“ - ”并增加“++”。
答案 3 :(得分：3)
我有这个需要转换的5GByte数据库。在64位系统上，我只是将所有数据放入集合中。在32位系统中，我不得不考虑加载和转换的顺序。问题不在于运行时，而在于工程时间。切换到64位可以节省数周的开发时间。
兼容性问题：这不是错误，这是一个功能。它向您展示了谁编写了干净的软件。
答案 4 :(得分：2)
使用64位操作系统也有一些安全优势。已经存在一些缓冲区溢出漏洞，它们通过暴力绕过地址空间布局随机化。在64位操作系统上，只有太多的地址才能使这种攻击成功。
答案 5 :(得分：1)
如果您的编译过程受内存限制并且您使用64位操作系统来增加系统可用的内存量，它将加快编译速度。
答案 6 :(得分：1)
我希望它稍慢，我有FC10的经验。我没有真正的理由，但绝对不是sizeof（指针）问题。 （*）
我自己的预感是，它只是一个不太优化的驱动程序或调整芯片组的问题。
同样，NTFS-3g在64位下很有趣，而它在32位下运行（同一个发行版，同一个内核相同的分区，在某些情况下它只是“挂起”）
（*）大多数编译是磁盘绑定，而不是CPU绑定。此外，x86_64架构还有其他改进可以抵消这一事实（更好的PIC，更多的注册，SSE2默认开启，默认为686 cmov）。除非您的应用程序不会随机移动小块。