【问题标题】:Does the Harvard architecture have the von Neumann bottleneck?哈佛架构有没有冯诺依曼瓶颈?
【发布时间】:2019-02-26 09:45:04
【问题描述】:

从命名和这个article我觉得答案是否定的,但我不明白为什么。瓶颈是从内存中获取数据的速度。您是否可以同时获取指令似乎并不重要。不是还要等到数据到来吗?假设获取数据需要 100 个 cpu 周期,执行指令需要 1 个,那么提前完成 1 个周期的能力似乎并没有很大的改进。我在这里错过了什么?

上下文:我遇到了这个article,说由于推测性执行,Spectre 错误不会被修复。我认为投机执行,例如分支预测,对哈佛架构也有意义。我对吗?我知道投机执行对冯诺依曼架构更有利,但是有多少呢?谁能给个粗略的数字?我们可以说幽灵在多大程度上会因为冯诺依曼架构而存在?

【问题讨论】:

  • 是的,冯诺依曼的瓶颈是所有计算都发生在 CPU 中,而不是与内存中的数据并行。即使在适合 I-cache 的紧密循环中执行,这仍然是一个问题,因此不会占用带宽。
  • 感谢您的回复。我的困惑来自于我的读取数据获取比指令获取慢得多,通常需要大约 100 个 cpu 周期。没有数据,一条指令仍然必须在执行阶段挂起,对吧?所以增益似乎很小(1%?)以缓解瓶颈。我想我在这里遗漏了一些东西,但不确定是什么。
  • 对不起,我错过了你的意思。其实你同意我的看法。哈佛架构仍然存在瓶颈。那么称其为冯诺依曼瓶颈是不公平的。为冯诺依曼感到难过:)

标签: cpu-architecture spectre von-neumann harvard-architecture


【解决方案1】:

“冯诺依曼瓶颈”一词不仅仅是指哈佛与冯诺依曼架构。它谈论的是约翰·冯·诺依曼发明的存储程序计算机的整个想法。

(根据上下文,有些人可能会用它来表示代码获取和数据访问之间的竞争;如果没有拆分缓存,这确实会加剧整体内存瓶颈。或者也许 混淆了我在这个答案的其余部分讨论的处理器的术语和更一般的内存瓶颈不应该被称为冯诺依曼瓶颈,尽管它是真实的。请参阅Modern Microprocessors A 90-Minute Guide! 中的 内存墙 部分)


冯诺依曼瓶颈同样适用于两种存储程序计算机。甚至对于将数据保存在 RAM 中的固定功能(非存储程序)处理器也是如此。 (没有可编程着色器的旧 GPU 基本上是固定功能的,但在访问数据时仍然存在内存瓶颈)。

通常在循环大数组或基于指针的数据结构(如链表)时最相关,因此代码适合指令缓存,并且无论如何都不必在数据访问期间获取。 (太老的甚至没有缓存的计算机只是很慢,我没有兴趣争论即使存在时间和/或空间局部性的缓慢是否是冯诺依曼瓶颈的语义。)

https://whatis.techtarget.com/definition/von-Neumann-bottleneck 指出缓存和预取是我们解决冯诺依曼瓶颈的一部分,更快/更宽的总线使瓶颈更宽。但是只有 Processor-in-Memory / https://en.wikipedia.org/wiki/Computational_RAM 这样的东西才能真正解决它,其中 ALU 直接连接到内存单元,因此计算和存储之间没有中心瓶颈,计算容量随存储大小而变化。但是 von Neumann 具有 CPU 和单独的 RAM 足以应付大多数不会很快消失的事情(考虑到大型缓存和智能硬件预取,以及乱序执行和/或 SMT 以隐藏内存延迟。)


约翰·冯·诺依曼是早期计算领域的先驱,他的名字与两个不同的概念有关也就不足为奇了。

Harvard vs. von Neumann 是关于程序内存是否在单独的地址空间(和单独的总线)中;这是存储程序计算机的实现细节。


Spectre:是的,Spectre 只是关于数据访问和分支预测,而不是将代码作为数据访问,反之亦然。如果您可以首先在哈佛架构中对程序内存进行 Spectre 攻击(例如,通过运行进行系统调用的普通程序),那么它可以像在冯诺依曼上一样运行。

我知道投机执行对冯诺依曼架构更有利,但有多少?

什么?不,这里根本没有联系。当然,所有高性能现代 CPU 都是冯诺依曼。 (使用拆分 L1i / L1d 缓存,但程序和数据内存不是分开的,共享相同的地址空间和物理存储。拆分 L1 缓存通常称为“修改后的哈佛”,这在 x86 以外的 L1i 之外的 ISA 上是有意义的t 与数据缓存一致,因此您需要特殊的刷新指令才能将新存储的字节作为代码执行。x86 具有一致的指令缓存,因此它是一个非常详细的实现细节。)

一些嵌入式 CPU 是真正的哈佛,程序存储器连接到闪存,数据地址空间映射到 RAM。但通常这些 CPU 的性能非常低。流水线但有序,并且仅使用分支预测进行指令预取。

但是,如果您确实构建了具有完全独立的程序和数据存储器的高性能 CPU(因此从一个复制到另一个必须通过 CPU),基本上为零与现代高性能 CPU 不同。 L1i 缓存未命中很少见,它们是否与数据访问竞争并不是很重要。

不过,我猜你会一直拆分缓存;通常,现代 CPU 具有统一的 L2 和 L3 缓存,因此根据工作负载(代码大小与否),或多或少的 L2 和 L3 最终会保留代码。也许您仍然会使用在标记中添加一个额外位的统一缓存来区分代码地址和数据地址,从而让您的大外部缓存在两个地址空间之间竞争共享。

【讨论】:

  • 很好的答案。将存储程序计算机与冯诺依曼体系结构区分开来可以消除大多数混淆。但是我责怪别人:)像Wikipedia程序内存和数据内存之间的共享总线导致冯诺依曼瓶颈)和你的那个cited冯诺依曼来了与存储程序计算机背后的想法一样,我们的标准模型,也称为冯诺依曼架构)误导了我。非常感谢。
  • 技术上,PiM 并没有解决带宽瓶颈。片上带宽要便宜得多,但它不是免费/无限的。 PiM 设计通常具有性能较低的处理器,足以满足对 PiM 有吸引力的带宽密集型工作负载;增加更细粒度的片上带宽也会降低容量。单个 DRAM 芯片的容量限制也是一个重要的制约因素。 PnearM 以适中的带宽成本增加容量。 NUMA 的“计算能力随存储大小而变化”,带宽只是稍微低了一点☺。只是吹毛求疵。
  • @tcya:是的,维基百科的措辞听起来像是代码获取是一个重大负担,和/或简单地共享总线是问题的唯一原因。对于像 8086 这样的古老 CPU(没有缓存,指令获取是主要瓶颈之一)来说,这可能是正确的,但甚至可能不是这样:访问内存的指令花费了很多额外的周期,以至于有足够的时间进行指令预取. oocities.org/mc_introtocomputers/Instruction_Timing.PDF。与现在 agner.org/optimize 相比,其中 3 到 4 条指令/时钟是正常的。
  • @PaulA.Clayton:我没有研究 PIM 实际做了什么;我曾假设每个 DRAM 单元或单元组都有一个 ALU,但这实际上没有意义,因为许多操作都有 2 个内存输入。好挑剔,因为我只是在编造东西,而不是试图简化实际细节:P
【解决方案2】:

Harvard Architecture,分离的指令和数据存储器,是冯诺依曼瓶颈的缓解。 Backus 的原始definition of the bottleneck 解决了一个比指令或数据获取稍微更普遍的问题,并讨论了 CPU/内存接口。在the money quoteBackus 之前的段落中谈到了查看这辆公共汽车上的实际流量,

具有讽刺意味的是,很大一部分流量不是有用的数据,而仅仅是 大部分由名称和操作组成的数据名称 以及仅用于计算此类名称的数据。

在具有独立 I/D 总线的哈佛架构中,这不会改变。它仍将主要由名称组成。

所以答案是肯定的。哈佛架构缓解了冯诺依曼瓶颈,但并没有解决它。说白了,这是一个更快的冯诺依曼瓶颈。

【讨论】:

    猜你喜欢
    • 2015-01-05
    • 1970-01-01
    • 2015-08-14
    • 2017-10-10
    • 1970-01-01
    • 2010-12-20
    • 2014-08-02
    • 2015-04-03
    • 1970-01-01
    相关资源
    最近更新 更多