【转】华为麒麟9000s TSV new微架构评测（上）：如闪电般归来
【转】华为麒麟9000s TSV new微架构评测（上）：如闪电般归来
作者：JamesAslan
喜欢画画和摄影的硅工码农（滑稽）
传说中的胖子
等
目录
收起
前言
基准测试
前端
取指
ICache
供指带宽
BTB
RAS
BP
IJP
ITLB
后端
流水线宽度
执行单元
幕间
前言
4年前鲲鹏920携TSV110闪亮登场，麒麟990紧随其后但仍使用了Arm公版微架构。我不禁畅想，是不是有一天能在手机上看到自研CPU微架构，是不是有一天世界舞台上会多一位apple-level的玩家。然而4年可以发生太多事情，暮然回首，无论是自己还是世界都已经历了沧海桑田般的巨变。于我而言，TSV new有点像一位“老朋友”。2019年它的坊间传闻就不胫而走，2020年它的身影出现在了cpu_type.h文件的一隅，2022年的HPCA论文又似乎是它无声的呐喊。这般若即若离让我难以捉摸，没想到素未谋面的重逢竟在一个寻常的午后。一觉醒来的我不抱希望得点击Mate60pro的购买按钮，却得来全不费功夫。轻舟已过万重山，四年不见，落花时节又逢君，欢迎回来。
基准测试
这部分在先行测试中已经涵盖，可以查阅往期文章：
JamesAslan：麒麟9000s大中核规格对比、初步性能测试723 赞同 · 134 评论文章
前端
随着现代程序体量的膨胀，处理器面临越发巨大的前端压力；为了应对庞大的程序代码段带来的海量跳转指令，高性能处理器的BTB容量、分支预测器容量不断扩展，相关算法也在不断演进。
从前的评测文章中，我们并没有涉及真正意义上的取指宽度（Fetch width）。
该图中标注出的三组流水级宽度实际上都是Decode宽度的某种体现，而非真正从ICache取指的带宽。在今后的文章中，我们将尽可能测试真正的ICache取指宽度，因此相关数据无法与之前的文章直接比较，望注意。
取指
现代处理器的取指宽度往往大于后续流水级宽度，更宽的取指级有几点好处：
现代处理器的分支预测系统往往存在各种限制，如每周期只能预测不大于2条分支指令、每周期只能预测1条taken分支指令等。这就会导致分支密集指令时，每周期的取指无法达到预定数量就被迫终止，进而导致后端指令供给不足；随着处理器后端的宽度持续增长，这一问题越发严重。因此，将取指级尽可能加宽有助于我们在理想工况（分支稀疏）下积攒更多的指令，平衡非理想工况下不足的取指带宽。
以定长指令集ARM为例，一个64Byte ICache行能存储16条4Byte指令。处理器对Cache SRAM的读取往往以行为单位（对于部分处理器的ICache而言是半行为单位），因此每次读取行为ICache都会提供8-16条指令。对ICache的读取涉及ITLB、Tag、Data SRAM的开关，功耗开销较大，丢弃额外的指令较为可惜；不如引入Fetch Buffer（Instruction Queue）这一缓冲队列，将额外的指令存储下来。
当Instruction Queue满时，前端可以关闭，减少功耗。
经过测试TSV new的取指级宽度大于11，远大于后续流水级的最窄处（6），超出了我对一款6发射处理器的预期。我们暂时无从得知这一数字到底落在12-16间的哪一处，但这样的宽度无疑能轻松满足目前TSV new的需求；个人猜测为16，毕竟cache行都已经打开了，不取白不取。这也表明这款前端设计时可能考虑了后续迭代需求，以适应未来更宽的微架构。作为参考，一些更宽的微架构能够支持每周期16条指令的取指，如Apple Firestorm。
ICache
我们可以通过巧妙而细致的测试确定ICache的bank粒度。与数据侧一样，ICache也要分bank以满足取指带宽需求，因为分支跳转的目标地址在cache行内的位置是我们无法控制的。
TSV new的ICache以半行为粒度分为上下两个bank，没有采用cacheline粒度的地址interleave。从设计需求上来看，上下半行独立访问的设计已经足以应对各种正常的跨行取指场景；从乐子人的角度来看，这样的粒度还是比较粗糙，不如苹果炫酷。至此，我们也能推断出TSV new每次取指理论读取16条指令，而非12条（否则ICache的bank粒度需要更细）。
供指带宽
程序的执行始于取指，处理器前端的指令供给能力至关重要；一旦前端无法提供足够的指令，纵使后端的乱序执行能力再强也无力回天。对于TSV new这样的6发射处理器，我们期望其每周期能够向后端供给至少6条指令。
TSV new使用了64KB的ICache，大于Arm一般在Cortex A series上惯用的32KB。在整个64KB区间内TSV new的取指带宽稳定为6，因此没有明显的存在mop cache的迹象，至少mop cache没有被用于提高供指带宽。mop cache在Arm等定长指令集上存在的意义存疑，可能减配的loop buffer是个更经济的选择。Arm的mop Cache对nop指令进行了压缩优化。倘若使用nop指令测试取指，mop cache每周期能够供给近乎双倍的指令，表明mop cache中每个表项可能存储了两条nop指令；TSV new没有配备mop cache自然没有此类优化。当指令足迹溢出mop cache后A78的供指带宽下降到了4条/周期；而TSV new并没有mop cache且配备了6个译码器，因此没有此类限制。
TSV new和A78的L2 Cache取指带宽相较ICache取指带宽并未严重下滑；不过TSV new在绝对值上保持领先，达到了>5条/周期，十分优秀。作为参考，一些早期处理器上此时的取指带宽甚至会下降至2条/周期。较高的L2 Cache供指带宽对潜在的服务器用途十分重要，小小的64KB ICache是不足以应对某些code footprint巨大的服务器负载的。对于取指而言，TSV new的L2 Cache的有效容量在512KB左右；与Arm一样，海思有意限制了代码段可以占据的L2 Cache容量，指令只能使用一半左右的空间（～512KB）。
当代码段溢出到LLC后，TSV new的取指带宽下降到了～2.5条/周期，十分优秀；A78此时的带宽为正好2条/周期。与L2阶段不同的是，TSV new似乎允许指令占据超过一半的LLC空间。总体而言TSV new的取指能力十分优秀，比TSV110不知道高到哪里去了。
BTB
对于采用了分离式前端（英文表述：decoupled branch prediction更为准确）的设计而言，BTB是前端的绝对核心组件；其负责在译码前识别指令流中的跳转指令并提供相应的跳转目标地址，频繁的BTB miss会造成严重的性能损失。对于没有采用分离式前端的设计而言，BTB也要负责尽快给出跳转目标地址，减少取指流水线的空泡，保证取指带宽。
首先我们可以看到非常明显的L0 BTB和L1 BTB：
TSV new的L0 BTB容量为64项，疑似全相联；与A78项数一致；没有每周期2 taken指令的优化。
TSV new的L1 BTB容量为1024项，组相联；索引hash留下了一定的死角，在最稀疏的情况下由于hash冲突无法使用全部的L1 BTB容量。
我们换用hash友好的测法重测，此时L1 BTB的容量更为清晰：
其次，TSV new似乎采用了传统BTB设计，而非basic-block设计。在L1 BTB中每个Cache行对应的最大分支数量为8，导致分支最致密的情况下L1 BTB完全失效。
然后，TSV new的行为更符合我个人眼中的分离式前端设计，也就意味着其还有巨大的L2 BTB，估算其L2 BTB容量为～6K，可能配备了某种程度的表项压缩优化导致图像难以辨认。这样的前端配置超越了A78，接近Zen3；但是落后于当前的Zen4、RaptorCove、ARM公版一众新核心。不过相较TSV110而言这是长足的进步，也就不难解释TSV new在verilator负载中的优秀表现了。
最后，BTB方面的遗憾有二。其一是0-bubble BTB的容量偏小，一众厂商已经进入1000项时代。其二是2-taken优化缺席，当然这一点想要发挥全部功效还需要潜在的指令融合、loop buffer、后端优化等一系列配套措施。
RAS
指令流中的call、return调用是较为特殊的分支指令情况，其栈形式的特征催生了专门用于预测此类场景的RAS（Return Address Stack）。简而言之，call指令压栈，return指令弹栈；而硬件栈（RAS）结构的深度就影响了处理器在复杂函数调用场景中的性能表现。
TSV new的RAS容量为16项。
当RAS溢出时，TSV new在回滚后对栈顶做了一定程度的恢复，行为模式与Arm类似；而icestorm则在回滚后做了其他形式的修正（诸如有效的清空）。
RAS CapacityTSV new16A7616A7716A7816X116A71016Icestorm32Zen432
BP
分支预测器是当代高性能处理器前端中的又一核心组件，负责在流水线早期给出分支指令跳转与否的猜测，引导指令流的方向。在推测执行的超标量处理器中，分支预测器的准确率会极大影响处理器的性能和能效表现。
本测试考察分支预测器在不同历史pattern长度、不同分支数量（需要预测）情况下的准确性表现。
与A78相比，TSV new的BP预测器规模显著得大。尽管在追踪少量长历史分支时两者表现相近，但是随着需要追踪的分支指令数量变多，TSV new就开始占据优势。在极端情况下TSV new的历史追踪能力是A78的两倍，甚至超过了经历了BP增强的A710。
在分支预测器失效前，TSV new的分支吞吐都接近2条/周期，较为理想。虽然不能由此确定前端的最大分支吞吐，但是至少后端的2组BRU如预期工作着，并且似乎大部分情况下都能retire 2条分支指令。
TSV new的预测器有一定的cascading特征，当分支历史超过一定长度后无论分支数量是多是少，分支的吞吐量都会经历一个可见的下滑；推测此时主预测器的过多介入导致了前端空泡增多。当然，这并不能说明一定有多个BP预测器，也可能是同一预测器的使用了不同历史长度的预测表有不同的介入延迟。
由于目前无法访问性能计数器，TSV new在实际负载中的分支预测表现我们不得而知。实际负载中的分支预测表现其实更考验corner case的覆盖和修正，无法直接从规模推知；但是规格是表现的基础，TSV new的BP规格展现了很大的潜力。以X1的BP表现作为参考，TSV new的BP经过finetune后也许可以优于Goldencove，并在追踪海量分支指令时比肩Zen3。这对于一款同时会用于server和client的微架构无疑是个好消息。
IJP
IJP（Indirect Jump Predictor）作为BP（Branch Predictor）的一部分，负责预测间接跳转的地址。与预测跳转与否的BP不同的是，IJP需要在多个可能的跳转目标中选择本次的跳转目标，并引导指令流。
首先考察TSV new IJP在不同历史pattern长度（但是可能目标均只有2个）、不同间接跳转数量（需要预测）情况下的准确性表现。与之前测试的众多Arm核类似，TSV new在32和64条间接跳转指令时经历了一定程度的性能衰减；但是这种衰减可能并非IJP失效导致的，因为其并没有完全导致分支预测错误而回滚，只是增加了延迟。与之前测试的众多Arm Cortex微架构不同的是，2条间接跳转指令时TSV new IJP内部没有发生Hash冲突，因此没有Cortex A series上突兀的意料外性能衰减。从规模上来看，TSV new的IJP不及A78；无论是少分支长历史还是多分支短历史，TSV new的表现均不及A78。
接下来，考察TSV new IJP在不同可能跳转目标、不同间接跳转数量（需要预测）情况下的准确性表现。TSV new在32-64条间接跳转指令时经历了一定程度的性能衰减。其间接跳转预测器的有效容量约为1024项，该规模小于A78，更不及经历了IJP加强的A710。不过，考虑到日常应用中间接跳转指令出现的频次一般较低，采用克制的IJP规格合情合理。
ITLB
TLB是现代处理器中容易被忽视的一个部件，其负责虚拟地址至物理地址的翻译。在一般情况下TLB并不会成为瓶颈，但是随着现代程序体量的膨胀，TLB承受的压力也与日俱增。这一点在服务器负载中尤为明显，因此对于可能用于服务器用途的TSV new也十分重要。
TSV new的ITLB容量为48项，取指时可以访问的L2 TLB容量为1024项。值得注意的是，TSV new在2048项有一个较为明显的小阶跃。
ITLB CapacityL2 TLB(for instruction) CapacityTSV new481024A76321024A77321024A78321024X1481024A710481024
后端
处理器的后端负责指令的执行，当代高性能处理器普遍配备了乱序超标量机制，后端的设计也是纷繁复杂。
流水线宽度
在超标量处理器中我们着重关注前端与mid-core部分的宽度。
流水级宽度Fetch(ICache)16（12+）Fetch(mop Cache)N/ADecode6Rename6
TSV new没有配备mop cache，这一选择也是情理之中；毕竟要在Arm ISA上从mop cache中获得可观收益，条件会比X86严苛很多。既然没有mop cache，那么保障供指带宽的重任就全部压在了ICache之上；理想情况下TSV new的ICache每周期能够向Instruction Queue（anyway，各家的名称不同，或者叫Fetch Buffer balabala）填入16条指令，对于一款6发射处理器而言是绰绰有余了。
无论是出于补齐产品线还是稳扎稳打磨砺团队的目的，似乎大部分设计公司总会经历这样一条由4发射到6发射再到更高更远的路径，TSV110和TSV new就分别处于上述的两个关键节点上，TSV new的6发射设计可谓意料之中。4-6发射的甜点宽度直到如今仍然是高性能处理器市场的绝对主流，TSV new的宽度配置适中，可以预见后续会有许多基于它的迭代改进。
执行单元
执行部件数量延迟ALU41BRU2
MUL23DIV117（支持提前退出）AGU(ld+st)4
AGU(ld)2
AGU(st)2
FPU4
FADD42FMUL43FDIV1？7-8FMA44
TSV new相较TSV110在整数端增加了一组ALU和一组MUL，MUL延迟由4周期下降至3周期，但是仍然有下降空间。TSV new配备了2组BRU，在密集跳转应用中能够保证后端吞吐量，符合现代应用程序发展的趋势。乘除法单元上TSV new选择了非对称配置，由于除法指令使用较少这一选择是合理的。除法器支持提前退出，当被除数变为0时算法可以立即结束。
相较TSV110，TSV new的理论访存能力大幅提升。一方面，TSV new采用了Intel式的全分离式AGU设计，与使用了1个load/store AGU+load AGU的TSV110相比，理论峰值带宽翻倍。但是与Arm公版相比时情况就较为复杂。以A78为例，其3个AGU中2个支持load/store操作，1个只支持load操作；因此A78的峰值load能力是更强的（此处我们不考虑DCache通路宽度，仅针对能够操作地址的数量），但是在某些比例的load、store混合流中带宽又会低于TSV new，这就是取舍的艺术了。需要指出的是，分离式AGU相较共享AGU会显著增加发射队列、物理寄存器堆的设计复杂度，同时LDQ和STQ的设计也会相应更为复杂。对于一款6发射处理器而言，这样的访存单元配置较为合理，但也谈不上豪华；可以预见在不久的将来TSV new new也会拥有第三个load AGU。
TSV new的浮点侧相较TSV110有了史诗级提升，其配备了四组FPU，基本完全对称。数量翻倍的同时，各类指令的延迟终于降低至了正常水平。不过需要注意的是，不同运行中得到的FMA、FADD单元数量结果不一致，个人推测有一些可能：
浮点寄存器堆有读端口争抢和写端口争抢，且由某些简单规则定义的；某些序列会让分配算法卡入corner case导致带宽下降，这算是一种bug？
浮点寄存器堆有分block处理，由重命名阶段控制block分配，某些序列会让分配算法卡入corner case导致带宽下降，这也算是一种bug？
总体而言TSV new的后端执行单元配置较为均衡和传统，符合我们对一款现代6发射处理器的期待。
幕间
在下篇中我们将对Mid-core、访存子系统、核外系统进行逆向探究。最近事情真是好多啊23333，个人精力实在有限，能做这件事的时间无法预计（潜在的咕咕咕预告）。
分析与测试：lyz、lxy
发布于 2023-09-10 18:53・IP 属地北京
华为
麒麟9000s
中央处理器 (CPU)
