处理器架构答案

【问题标题】：Processor architecture处理器架构
【发布时间】：2011-02-07 00:01:54
【问题描述】：

虽然 HDD 不断发展并以更小的空间提供越来越多的空间，但我们为什么要“坚持使用”32 位或 64 位？

为什么不能有例如：128 位处理器？

（这不是我的作业；我只是一个对他们教给我们的信息学知识感兴趣的学生）

【问题讨论】：

这应该是社区维基。

标签： processor

【解决方案1】：

很少需要这个，你什么时候处理这么大的数字？当前可供 64 位使用的可寻址内存空间远远超出了任何机器至少可以处理几年的能力……而且，它可能比任何台式机都可以容纳很长一段时间。

是的，桌面内存会继续增加，但会是现在的 40 亿倍吗？这将需要一段时间......如果在此之前没有抛弃整个当前模型，那么我们肯定会达到 128 位，我认为这同样可能。

此外，值得注意的是，在大多数情况下，从 32 位升级到 64 位会立即导致性能下降（这是 Visual Studio 2010 仅保留 32 位的主要原因）。 64 位到 128 位也会发生同样的情况。您拥有的小对象越多，指针就越多，现在 两倍大，这意味着需要传递更多数据来执行相同的操作，尤其是在您不需要那么多可寻址内存空间的情况下。

【讨论】：

你拥有的小对象越多，指针就越多，现在是两倍大参数只有在你不升级你的 1GB 内存时才真正相关'自从你第一次安装 XP 就一直在使用 :)
@slugster - 我的 Visual Studio 2k8 经常达到超过 2GB 的 RAM...并且变得非常缓慢...更多的内存使用意味着更多的内存移动、访问和处理。问题是带宽并没有变得那个好得多......当VS无缘无故地再吃几百兆时，这对性能来说是一个很大的打击。我是从在 Win7 64 上运行 16GB 的四核机器上说的 :)

【解决方案2】：

因为 32 位和 64 位之间的差异是天文数字 - 这确实是 2³²（十亿中的十位数）和 2⁶⁴（squillions 中的 20 位数字 :-)。

64 位足以满足未来几十年的需求。

【讨论】：

...反正没有人需要超过 640kbyte。
@dbemerlin：我们花了几十年的时间从 640K 增加到大约 10,000 倍。从 2^32 到 2^64 的跳跃为 4,000,000,000 倍的增长铺平了道路。好的，所以进步的变化率正在增加，但我仍然认为这将持续我们几十年。 :-)

【解决方案3】：

处理器架构的下一件大事将是量子计算。一个 qbit 的概率不是 0 或 1，而是 0 或 1。

这将导致算法性能的巨大改进（例如，破解任何 RSA 私钥/公钥将非常容易）。

查看http://en.wikipedia.org/wiki/Quantum_computer 了解更多信息，15 年后再见 ;-)

【讨论】：

【解决方案4】：

成本。另外，您认为 128 位架构会给您带来什么？内存寻址等，但为了有效地处理它，您需要更高带宽的总线，并且基本上需要一些新的指令语言来处理它。 64 位足够寻址（18446744073709551616 字节）。

硬盘驱动器仍然有一些基础可以赶上 RAM 等。我认为它们仍然会成为 IO 瓶颈。此外，较新的芯片只是支持更多内核，而不是对语言进行大规模更改。

【讨论】：

【解决方案5】：

当我们谈论 n 位架构时，我们经常将两个完全不同的东西混为一谈：

(1) n 位寻址，例如具有 32 位地址寄存器和 32 位地址总线的 CPU 可以寻址 4 GB 的物理内存

(2) CPU 内部数据路径和通用寄存器的大小，例如具有 32 位内部架构的 CPU 具有 32 位寄存器、32 位整数 ALU、32 位内部数据路径等

在许多情况下 (1) 和 (2) 是相同的，但也有很多例外情况，而且这种情况可能会越来越多，例如在可预见的未来，我们可能不需要超过 64 位的寻址，但我们可能需要 > 64 位的寄存器和数据路径（许多支持 SIMD 的 CPU 已经是这种情况）。

因此，简而言之，您在谈论时需要小心，例如一个“64 位 CPU”——它在不同的上下文中可能意味着不同的东西。

【讨论】：

【解决方案6】：

对 64 位处理器的主要需求是处理更多内存 - 这是切换到 64 位的驱动力。在 32 位系统上，您实际上只能处理 4Gb 的 RAM，至少每个进程是这样。 4Gb并不多。

64 位为您提供了数 PB 的地址空间。（尽管，许多当前的 64 位硬件“只能”寻址 48 位 - 但这仍然足以支持 256 TB 的内存）。

虽然增加处理器的自然整数大小并不会自动使其“更好”。有权衡。使用 128 位，您需要两倍于常见数据类型的 64 位存储空间（寄存器/内存/缓存/等） - 可能存在的所有缺点 - 需要更多内存来存储数据，更多数据要传输 = 更慢，更宽的公共汽车可能需要更多的物理空间/也许更多的电力等。

【讨论】：

【解决方案7】：

好吧，我碰巧是一名专业的计算机架构师（我的发明可能就在您正在阅读本文的计算机上），虽然我还没有得到报酬，可以在任何地址超过 64 位的处理器上工作，但我认识我的一些朋友。

几十年来，我一直在玩弄 128 位架构。

即它已经发生了。

实际上，它已经在一定程度上发生了。 HP Precision Architecture、Intel Itanium 和 IBM Power line 的更高端版本都有我所说的折叠虚拟内存。我已经在别处描述了这些，例如在 comp.arch 帖子中的一些细节，http://groups.google.com/group/comp.arch/browse_thread/thread/53a7396f56860e17/f62404dd5782f309?lnk=gst&q=folded+virtual+memory#f62404dd5782f309

我需要为这些创建一个 comp-arch.net wiki 帖子。

但您可以获取这些处理器的手册并自行阅读。

例如您可以从 64 位用户虚拟地址开始。高 8 位可用于索引区域表，该表返回与剩余 64-8=56 位连接的高 24 位以产生 80 位扩展虚拟地址。然后像往常一样由 TLB 和页表和哈希查找翻译，无论您的实际地址是什么。

为什么要从64->80？

一个原因是共享库。您可能希望共享库在所有处理器中保持相同的扩展虚拟地址，以便您可以共享 TLB 条目。但是您的语言工具可能会要求您将它们重新定位到不同的用户虚拟地址。折叠虚拟地址允许这样做。

折叠的虚拟地址不正确 >用户可以使用的 64 位虚拟地址。

就此而言，有很多关于 >64 位指针的建议：例如我研究过一个指针由 64 位地址、64 位上下限和元数据组成，总共 128 位。边界检查。但是，尽管它们具有 >64 位指针或功能，但它们并不是真正的 >64 位虚拟地址。

Linus 在http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=103574&threadid=103545&roomid=2 发布了大约 128 位虚拟地址

【讨论】：

【解决方案8】：

我还想提供一个计算机架构师对为什么 128 位目前不切实际的看法：

能源成本。请参阅 Bill Dally 的演讲，了解当今处理器中的大部分能量如何用于移动数据（消散在线路中）。但是，由于 128 位计算的最高有效位应该变化不大，它应该可以缓解这个问题。
大多数算术运算都具有非线性成本 w.r.t 操作数大小：

一个。树乘法器的空间复杂度为 n^2，w.r.t.位数。

b.分层进位超前加法器的延迟是 Log[n] w.r.t 位数（我认为）。所以 128 位加法器会比 64 位加法器慢。谁能给出一些硬数字（Log[n] 似乎很便宜）？
很少有程序使用 128 位整数或四精度浮点数，当它们使用时，有一些有效的方法可以从 32 位或 64 位运算中组合它们。

【讨论】：

您可以添加冗余形式（例如进位保存），它不会将进位发送到整个宽度。您可以将冗余形式保存在寄存器中，或绕过它 - 在后者中，使用额外管道阶段中的额外时间。但那些额外的管道不会影响大多数关键循环。 //顺便说一句，add是逻辑深度的对数，但在线长方面是线性的——至少只要位是按行排列的。（我可以想象比特的圆形排列，但是你的 rwgisters 非常受限制 - 可能适用于累加器机器。