CPU 能靠增大单核的规模去提高单核性能么？ 第1页

可以。

单核规模提升确实会提高单核性能，或者准确的说，是单核性能的提升确实需要提升规模。

但是这种提升是有限的，而且瓶颈越来越明显。比如初期提升100％规模也许提升了90％ 性能，往后提升100％规模可能只能提升10％性能，再往后提升100％规模只能提升2％ 性能等等。

随着规模的不断提升，对性能的提升会越来越困难。代价越来越大，成本越来越高。

M1就是一种不计成本提升单核性能的方案，这个方案导致了它的成本过高，无法作为通用处理器出售。

Update：昨晚上写的时候，主要考虑的是CPU设计的挑战，但是忽略了一个同样重要的问题是程序本身的特性：有的程序本身就是“不进油盐”，任由你CPU怎么scaling-up都无法获得显著性能提升。

在指令流方面，有的程序就是无法预测的：例如一个分支是if (rand(0, 1) > 0.5)，那么这个分支本身就无法预测。更难预测的是随机的间接跳转，例如Zoo = List(Animals)，你遍历Zoo：for animal in Zoo: animal.eat()，每个动物有不同的eat的实现，而且每个动物在Zoo里面是随机序，那么这个eat的实现的PC就非常难预测。对于无法预测的程序，指令窗口再大、宽度再宽，也只是“徒增功耗”。

在寄存器数据流方面，Scaling-up指令窗口大小是为了在窗口内容纳更大的数据流图、挖掘更多的ILP机会。极端情况下，如果一个程序的每一条指令都依赖于上一条指令，那么窗口100和窗口1000不会带来性能改进。嘛，我的一个研究工作就是研究怎么scaling-up窗口，发现窗口不敏感的程序也不少……

在访存数据流方面也有类似的问题，有的应用的局部性就是很差、footprint很大、难以预测，除非你的SRAM堆到4G+，否则就是放不下。例如SPECCPU里面的mcf就有一点这种意思，但是似乎最先进的商业处理器在mcf上已经捞到一点油水，也就是说mcf不属于完全“油盐不进”的。

难得遇到我读博的细分领域的问题，简略回答一下：

题主说的增大规模，我们一般称为“Scaling-up”。Scaling-up是可以提升性能的，但是有几个基础性的挑战。

可以是指：不考虑功耗、频率的前提下，增加晶体管的数量是可以提高同频性能的。

挑战是大头。

首先，有一个最常见的、最容易理解的答案。因为Dennard scaling不复存在，同频率下，粗暴地增加规模会增加功耗。当然，以多核的方法增加规模，全核跑起来功耗也吃不消，所以这不是单核特有的问题。

均衡——存乎万物之间

对CPU单核而言，一个最根本的问题是：CPU流水级从头到尾、层次结构从内到外必须达到一个均衡的状态，才能发挥各部分的性能潜力。这导致CPU无法像GPU那样通过堆流处理器来提升性能。

我打一个比方，CPU如果单纯地堆发射宽度和运算单元，就会像七龙珠里面特南克斯在超赛一阶段膨胀肌肉一样，纸面数值上去了，但是还是被沙鲁吊打，因为身体的敏捷性拉胯了。

其实香山处理器的第一代架构就存在这样的问题，雁栖湖架构的发射宽度非常夸张，但是性能一般（SPEC06 ~7/GHz）。而香山处理器的第二代南湖架构在没怎么增加发射宽度的前提下，性能获得了显著的提升。其实就是拓宽了瓶颈部分，使之与高发射宽度更加匹配了。

那么哪些部分需要平衡呢？

我习惯把CPU的功能分为三部分：指令流、寄存器数据流、访存数据流。这三部分都是需要平衡的，与此同时这些部分还存在无法暴力 Scaling-up 的因素。

首先是定义：

• 指令流：从取指到重命名，包括 I-Cache
• 寄存器数据流：分发、发射、执行、写回、提交
• 访存数据流：访存推测、LSU、Cache

指令流

指令流这部分Scaling-up的需求是准确的、高带宽的、连续的指令供应。准确是指分支预测的准确率，分支预测要是不准，1024的窗口、32发射也白搭，不多说了。而且规模越大、in-flight的指令越多，对准确率要求越高。

准确性带来的挑战。TAGE和Perceptron这类分支预测器要用RAM装TAGE Table和NN的权重，一般RAM越大Hash冲突越少。但是RAM越大面积也就越大，面积大到一定程度延迟就上去了，如果你在这里打拍了就会影响指令供应的连续性。

高带宽带来的挑战。x86有个特有的问题：指令变长，后一条指令的起始位置依赖于前一条指令的类型，这导致译码是一个串行的组合逻辑。RISC基本可以并行译码，但是重命名的时候RISC和x86一样：后一条指令重命名（可能）依赖于前一条指令重命名的结果，这也是一条串行依赖路径。这些串行依赖路径的存在，导致你不能暴力Scaling-up译码宽度或者重命名宽度。

寄存器数据流

寄存器数据流是我从入学到现在都在关注的问题。根据^[1] 和^[2] 这两篇文章的结果，物理寄存器堆和发射队列的线延迟在先进工艺下会贡献主要的时延。我和工业界的前辈交流时，大家也说这些是典型的频率瓶颈。结果就是“Clock rate versus IPC”：我们如果肆无忌惮地增加物理寄存器堆和发射队列的大小或者读写口数量，即使同频性能上去了，处理器的频率也做不上去。

当然，两篇经典论文的年代非常久远，他们观察到的现象在今天是否是关键瓶颈，我也不笃定。尤其是在Apple的指令窗口做到了600+项时，我对此愈发感到怀疑：一般指令窗口和物理寄存器堆、发射队列需要一起Scaling-up才能获得较好的收益。一种猜测是Apple在架构设计或者物理设计方面发现了什么黑科技吗？另一个猜测是：M1反正只跑3GHz，不像Intel要跑5GHz，而600是在目前TSMC的工艺和Apple的物理能力下的极限？

访存数据流

首先是访存推测，它的性质和分支预测是类似的：如果经常推测错，流水线就填不满，再宽也白搭。

然后是LSQ，尤其是Store Queue，它和发射队列有类似的问题。

最头疼的是Cache，包括L2、L3。大家最熟悉的是Memory Wall问题，我就不展开了。还有一个问题就是L1的带宽问题：Scaling-up的时候，每周期的访存指令数量越来越多，L1 DCache如何在同一个周期响应更多的请求？分bank？SRAM的读写口数量跟得上吗？

要大幅提高核的规模你需要提高什么？

总结一下：

• 更高的分支预测准确率和访存推测，你的敌人是RAM的面积
• 更大的指令供应带宽，你的敌人重命名的串行时延（和译码的串行时延（x86））
• 更大的PRF、发射队列和LSQ，你的敌人是PRF和CAM的线延迟
• 更少的Cache miss，你可以暴力堆容量，也可以改进替换、预取算法
• 更大的DCache的带宽，你的敌人是DCache的时延要求

以我目前的知识，能看到的就是这些

参考

1. ^Palacharla, Subbarao, Norman P. Jouppi, and James E. Smith. "Complexity-effective superscalar processors." Proceedings of the 24th annual international symposium on Computer architecture. 1997. https://minds.wisconsin.edu/bitstream/handle/1793/11224/file_1.pdf?sequence=1
2. ^Agarwal, Vikas, et al. "Clock rate versus IPC: The end of the road for conventional microarchitectures." Proceedings of the 27th annual international symposium on Computer architecture. 2000. http://www.cs.cmu.edu/afs/cs/academic/class/15740-f02/public/doc/discussions/uniprocessors/technology/ipc.pdf