6

我不确定我是否理解正确：在同一系统上，64 位操作系统运行/编译代码是否比 32 位操作系统快？

我们使用的是 64 位操作系统，它似乎只会导致与旧版和专有软件的兼容性问题。（我们正在运行 Ubuntu 9.04 Jaunty amd64）

4

7 回答 7

17

我会将这个答案限制为 x86-32 (IA-32) 与 x86-64 (AMD64)，因为我相信这就是您实际要问的问题。

在处理器级别，有一些优势。首先也是最明显的是将每个进程的虚拟内存扩展到更广泛的 48 位范围。（架构中允许使用 64，但不是必需的，如果内存可用。）这使应用程序能够使用更多可用的系统内存，并为运行的内存映射文件之类的东西打开大量空间没有链接到真实内存的虚拟内存。它还为相关操作系统的工作开辟了很多空间，因为它不必共享其数据的 4 GB 限制。简而言之，应用程序和操作系统可以更好地利用您机器的资源。

此外，AMD64 架构解决了 IA-32 的最大问题之一，即完全没有寄存器。事实上，它使可用寄存器翻了一番，这对于某些类型的代码来说是一个巨大的胜利。（实际上，对于几乎任何代码来说，这都是一个胜利，但有些应用程序会因 64 位内存成本的增加而受到影响，而且结果会趋于平衡。）

在 Windows 方面，微软以此为契机，打破了一大堆历史上的兼容性问题。这不是与旧世界彻底决裂，但它是一个开始。我不相信 Linux 从一开始就遇到同样的问题，而且我对它们的 64 位优势没有太多看法。

于 2009-04-28T22:27:12.630 回答
11

As a general rule, developing--or using--a 64-bit operating system, in any context, will be slower than the same 32-bit operating system. Because all pointers are suddenly twice as large, you are far more likely to blow the cache, and can fit less data in RAM. That slows down your application considerably. You normally would only use 64-bit systems when your applications need to address more than 2 to 3 GB of data simultaneously--something very common in scientific computing and some database situations, but otherwise extremely rare. This is why Apple does not advocate unconditionally compiling PowerPC applications in 64-bit mode, for example: the cost due to cache-misses and lack of memory are high enough that going 64-bit only makes sense when you truly can take advantage of the 64-bit space.

But x86 v. AMD64, which is what you're really asking about (since you're discussing Ubuntu), is a very special beast. AMD64 not only extends all pointers to 64-bit; it fixes many, many deficiencies in the x86 architecture, doubling the number of GPRs, simplifying the instructions to be more friendly to modern CPU designs, and more. Because of this, on AMD64 platforms only, you will frequently see a substantial performance boost by going to 64-bit.

There is one other area where, in software development, it makes sense to go to 64-bit: you need to run lots of VMs. Running a couple of VMs can easily blow you past the 3 GB memory barrier of the operating system, making using them very painful. (It will work due to a technology called PAE, or Paged Addressing Extensions, that Intel invented to bridge the gap between 32-bit systems and 64-bit systems, but the result is slow, painful to work with as a developer, and not very well supported on Windows.) Going to a 64-bit OS can provide tremendous benefits.

于 2009-04-28T22:32:51.180 回答
6

（正如评论员所指出的，这个答案有点笼统，其中一些观点不适用于英特尔/AMD 芯片。）

答案是：它会有所不同，原因如下：

  • 使用更宽的指令，您将获得更多的表现力（更多种类的指令或将数据直接编码到这些指令中的更大容量），这可能意味着流经机器的指令数量减少，这通常是一场胜利：这里是 ++64 位。

  • 但有时较大的指令可能需要更多的周期来解码和执行，因为它们可能更复杂。所以这里可能是--64bit。

  • 此外，您需要将这些指令传入和传出 CPU：64 位指令是 32 位指令的两倍，这意味着进出内存和缓存的流量更多。CPU 的结构可以大大改善这种成本，但这里的成本略低--64 位。

  • More registers are usually available in wider instruction sets, which causes less data traffic to and from the stack and or memory. So ++64bit here.

  • And as everyone's no doubt going to mention, you have the ability to address more memory.

  • (Nearly forgot this one) the native "long" or "int" size may go up, depending on architecture, meaning data structures based on these get larger. Larger = more memory to move around, which means more possible waiting on data moving: --64bit if you're not careful.

Depending on your architecture, a lot of other concerns may apply too. You can rest assured that the processor and compiler vendors are working their butts off to reduce the "--"s above and increase the "++"s.

于 2009-04-28T22:29:49.923 回答
3

I have this 5GByte database that needs converting. On a 64-bit system, I just put all data in collections. In the 32-bit system, I had to think about the order in which to load and convert. The problem is not run-time, it is engineering time. Switching to 64 bit saves weeks of development time.

The compatability issues: that's no bug, that's a feature. It shows you who has written clean software.

于 2009-04-28T23:10:41.853 回答
2

There are also some security advantages to using 64-bit operating systems. There have been some buffer overflow exploits that circumvent address space layout randomization by brute force. On a 64-bit OS, there are simply too many addresses for this kind of attack to be successful.

于 2009-04-29T00:15:59.123 回答
1

如果您的编译过程受内存限制并且您使用 64 位操作系统来增加系统可用的内存量，它将加快编译速度。

于 2009-04-28T22:26:11.587 回答
1

I expect it to be slightly slower, I had that experience with FC10. I don't have real reasons, but it is definitely not the sizeof(pointer) issue. (*)

My own hunch is that it simply is a matter of less optimized drivers or tweaked chipsets.

Also NTFS-3g was funny under 64-bit, while it worked under 32-bit (same distro, same kernel same partition, it just "hung" in some circumstances)

(*) most compiling is disk bound, not CPU bound. Moreover there are other improvements in the x86_64 architecture that cancel out that fact (better PIC, more regs, SSE2 default on, 686 cmov default on) . Unless your app does nothing than randomly moving small blocks around.

于 2009-05-01T22:08:24.163 回答