64位系统的优点答案

【问题标题】：Advantages of a 64 bit system64位系统的优点
【发布时间】：2011-06-17 22:09:11
【问题描述】：

从我试图理解的开发者的角度来看，64 位系统的卖点是什么？

我知道您可以使用更多寄存器，可以为进程分配更多内存，但我不明白是什么让开发人员的生活更轻松。有什么例子吗？

从性能的角度来看，如果程序在 32 位和 64 位上运行，是否有任何提升？

干杯！

编辑：感谢您的所有回复。我看到一些关于最终用户体验的对话，尽管它可能很重要。我更多地关注你可以挤出的任何架构优势。

据我了解，优化似乎是在编译器-汇编器链上进行的，而不是程序员可以调用的功能？

【问题讨论】：

stackoverflow.com/questions/3343812/…可能重复
是的，检查了那个......但是所有的道路都会导致更多的记忆。还有什么？
相关：en.wikipedia.org/wiki/Year_2038_problem
查看我的回答，了解一些程序员可以调用的优化示例。我列出了两个，一个与拥有更大的可用地址空间有关，另一个与能够一次操作 64 位数据有关。
“更多寄存器”仅适用于 x86-64 与 x86 - 大多数 32/64 位架构没有此“功能” - 它们具有相同数量的寄存器，但寄存器通常更宽 64 -位。

标签： c++ performance architecture 64-bit cpu-architecture

【解决方案1】：

正如您所说，更多的内存可能是一个很大的优势。对于 32 位系统，您将被限制为最大 4GB 的进程（甚至 2 或 3 个，这取决于您的操作系统有多烦人）。

64 位是每条指令字节数的两倍，因此您在内部拥有更多带宽。例如：一切都更快。

另见： http://lifehacker.com/5431284/the-lifehacker-guide-to-64+bit-vs-32+bit-operating-systems

【讨论】：

通过双重含义处理多个指令？
不，仍然是一条指令（实际上，这不是真的，但现在这将是一个非常长的故事:) 但内部的一切都将使用 64 位（8 字节）块，而不是 32 位（4 字节）块。想想 8 车道对 4 车道的高速公路。
更大的指令大小 == 更多的指令缓存未命中？
@inverse: 可能是，但你的缓存可能会更大。
如果您在 32 位模式下运行处理器 istdo 64 位，缓存大小会改变吗？

【解决方案2】：

64 位系统具有 64 位内存地址而不是 32 位地址，因此可用的最大内存量是 2⁶⁴ 与 2³²。第一个数量大约是 10¹⁸ 个字节，而后一个数量可以有 10⁹ 个字节。因此，在 64 位系统中可以拥有更多内存。

【讨论】：

这并非完全正确。仅仅因为你没有那么多可用的内存并不意味着额外的地址空间没有用。它允许您将不断增长的连续数据结构分开，这样您就不太可能不得不移动它们（或者如果无法移动它们，空间就会用完）。
即使在内存很少的系统上，额外的地址空间也可能派上用场。 64 位解决的一个问题是地址空间碎片。我的一些程序在处理不同长度的大块数据时在 32 位模式下运行时会出现这些问题。我当时正在实施一个相当复杂的内存管理方案，该方案在当时已经过时，64 位系统变得司空见惯。
@Omnifarious- 你能详细说明一下吗？我不太明白你在说什么。
@templatetyedef - 比如说，你有一堆数组。您知道任何一个阵列的大小都可能增长到 800MB，但您也知道它们中的大多数将保持在 5MB 以下。使用 64 位地址空间，您可以将它们全部间隔 1G，以便它们都可能增长。但是未使用空间的页面永远不会被映射，因此您永远不会使用超过 1G 或 2G 的实际内存。
@Omnifarious- 啊，这很有道理。我没有想到虚拟内存。我会更新我的帖子以消除不准确之处。感谢您让我知道！

【解决方案3】：

当您有 64 位地址空间可供使用时，您可以采用某些设计，这些设计在地址空间较少时会非常困难。例如，一位朋友最近向我指出，线程堆栈的地址空间可能会成为 32 位系统上数千个线程的问题。但在 64 位系统上，这不再是一个问题。这是对开发人员的主要直接好处，可以影响您编写程序的方式。不管机器有多少实际内存都是如此。

我见过的大多数转换为 64 位的程序都看到了性能改进，因为有额外的寄存器可用。

在某些程序中，使用 64 位地址可以抵消这种性能改进。占用的额外空间指针意味着它们占用更多缓存，从而为其他事物留下更少的缓存空间。此外，它们在与主内存之间传输时会占用更多的内存总线带宽。

至少有一个项目建议以一种混合模式重新编译 Linux 中的大多数程序，其中使用所有额外的寄存器，但只使用 32 位指针。我对它的结果很感兴趣，因为它消除了 64 位程序的一个性能劣势。

还有一小部分（但很重要）的程序和算法可以使用 64 位寄存器。例如，大多数SHA-3 candidates 旨在利用在执行按位运算时一次操作 64 位数据的能力。

最后，由于 CPU 内部的数据路径现在是 64 位宽，这也意味着 CPU 内部有更多的带宽来移动数据。但我希望这对在 32 位模式下运行的 64 位 CPU 也有好处。

【讨论】：

我还读到了由于每个函数调用的对齐问题而导致的堆栈的额外消耗（尽管使用了寄存器，该函数仍然保留空间来保存传递给它的数据，以防寄存器需要其他东西）。

【解决方案4】：

当您运行多个进程时，例如调试会话、编译器和其他工具，如果您的系统中有大量 RAM，您会发现性能大幅提升。我的 Win7 系统中有 16GB 的 RAM，而且我永远不会回到更少的状态。这有点像当你开始使用双显示器时，之后一个就不够了。

【讨论】：

16 GB 是不是有点矫枉过正？我经常执行多项任务，拥有三台显示器，但我的 4 GB 内存 + 一个 SSD 磁盘（如果需要任何交换）从未对我造成任何减速。
目前（2011 年 1 月）对于某些系统来说，16 GB 可能有点过头了，但不会继续如此。
@monoceres：是的，640KB 对于每个人来说应该足够了。（老比尔盖茨引用，当 640KB 被认为是正常的时候（是的，KB，1 GB 是一百万倍））
这不是特别相关，但我实际上不喜欢双显示器。我用过它们，发现它们真的很烦人。但我也从来没有在常规显示器上全屏显示我的任何窗口。我宁愿有一个更大的显示器。
它会被使用，请务必！是否有用完全是另一回事。当然，数据库引擎将能够允许它们的通用缓存比以前保存更多的数据，但即使在今天，开销仍然如此之大，几乎看不到任何收益。在不久的将来，办公程序需要更多内存来执行的可能性不大。

【解决方案5】：

大多数桌面应用实际上不需要是 64 位二进制文件，图像或视频处理应用除外。相比之下，服务器应用程序通常会这样做。

在 64 位机器 a 上运行的最大优势是您的应用程序将拥有更多 RAM 空间，因此当其他应用程序需要 RAM 时，它不会被交换掉。然而 32 位应用程序在 64 位机器上运行（幸运的是）。我在一台 16GB 的 Linux 笔记本电脑上输入这个，它有 2 个 DB（Oracle 11g 和 Mysql 6.0alpha），VirtualBox 中的 Windows 和许多 Java 虚拟机，带有 Xmx=2GB 的 eclipse ......）我不能把所有这些都塞进去4GB。然而，当它们不需要大量内存空间时，我仍然更喜欢运行 32 位应用程序。

【讨论】：

【解决方案6】：

抱歉，我保留了这种位列表样式，并避免不提及增加的内存寻址以及已经提到的更多内容。

a) 您将拥有双倍数量的寄存器，实际上您可以使用的寄存器数量是三倍。 b) 通用寄存器从 32 位增加到 64 位，这意味着 64 位整数（即）的处理将更快。 c) 更有效的位置无关代码，因为现在可以相对于 RIP 寄存器引用数据。 d) No-execute bit 让系统更能容忍缓冲区溢出。

【讨论】：

【解决方案7】：

一些 Mac OS X 特定的答案（其他回复中涵盖了一般答案）：

1) 在 32 位 OSX 中，地址空间被映射 4/4（即内核获得完整的 2^32 并且每个应用程序都这样做），这需要在每个系统调用上刷新 TLB 两次。在 64 位中，有足够的空间将内核和应用程序映射到不同的地址范围。

2) Objective-C 程序在 64 位 x86 机器上使用新的 ABI/运行时。这将为您提供与 C++ 兼容的异常、非脆弱实例变量和一些加速。

【讨论】：