解读《华为鲲鹏920 TSV110微架构评测（上）:初露锋芒，砥砺前行》 ...

媒介

比年来，纵使摩尔定律已死的论调甚嚣尘上，处置惩罚器性能还是迎来了一波发作式增长；适逢DSA的黄金期间，巨头们对于自研微架构的热情空前高涨。众多因素加持下，处置惩罚器新秀们如雨后春笋般层出不穷。华为作为天下舞台的顶级玩家之一天然不会错过这场盛宴。在海思麒麟的光芒下鲲鹏系列并不为多数人所知，但它的故事早在2016年就由鲲鹏916拉开了序幕。时至2019年，第一颗7nm数据中心ARM处置惩罚器鲲鹏920翩然而至，将鲲鹏系列带上了台前。然而让人意想不到的是，仅仅4个月后华为就遭受了来自大洋彼岸的制裁。正值一飞冲天之际的鲲鹏横遭折翼之祸，令人唏嘘不已；此后就只能从学术集会中窥见鲲鹏系列的车尘马迹。现在回望，鲲鹏920究竟多少，我们这次就来探究TSV110的微架构。
基准测试

在这一部分我们利用SPEC06、SPEC17、Coremark以及Verilator对处置惩罚器举行测试。注意，我们并不执着于fine-tune以得到某一微架构的最高分数；而是以公道、同一的编译参数带来可比的分值数据。SPEC06、SPEC17等的分值受系统环境、编译器版本、编译参数、BIOS调教、频率稳定性、详细SKU的Cache设置、详细平台的内存参数等因素影响巨大，且无法通过任何简单线性缩放举行分数推演。
频率

在UOS下鲲鹏920的稳定运行频率为2.6GHz，以下测试都基于2.6GHz的频率举行。
SPEC06

SPEC06是已经退役的SPEC测试集但是仍然被广泛利用；其负载特性与SPEC17并不相同，因此仍然具有相当的测试价值。

我们再次请出A76、A78这两款处置惩罚器作为参考对象。A76和TSV110可谓同期生，相互参照最为合适不过；而A78则是2年后的来人，用来一窥前两者与当今同定位处置惩罚器的差距。在绝对性能上TSV110落伍于A76、A78，但是细致观察子项分数我们很快发现一些异乎寻常的现象。TSV110的整数分数其实与A76并驾齐驱，但是一来到浮点侧便马失前蹄。TSV110在全部侧重内存带宽的子项上都体现欠佳，其单核的访存带宽应该是偏低的。TSV110在大部分侧重预取器体现的子项上都体现普通，甚至在SPEC06中唯逐一个rate 1激进预取负结果子项上得分反超了A76，不禁令人猜疑TSV110的硬件预取器并未fine-tuned，抑或是被人为限制了预取激进度（因为鲲鹏920主攻服务器市场，过于激进的单核预取会导致全核负载时片上系统压力过大，最终总吞吐量不升反降）。后续的测试也会部分印证这些猜想。TSV110羸弱的浮点、向量性能不仅来自于访存子系统的掣肘，延迟过大的运算器计划、相对较小的浮点乱序队列规格也难脱其责。总体而言，TSV110的SPEC06 int体现在当时的ARM阵营堪称优秀，但是fp体现与A76等相去甚远，导致最终总分不及同期生A76。
SPEC17

SPEC17是现役的SPEC测试集，被广泛用于微结构性能评估。

SPEC17测试中三款处置惩罚器相对体现的结论没有变化，整数方面TSV110紧追A76，浮点方面则被远远甩开。TSV110在520.omnetpp中超越了其他两款处置惩罚器，让人猜疑其数据预取器是否在工作（该子项容易因为预取而失分，stream预取器尤为容易造成负结果）；再结合stream结果、503.bwaves的结果、549.fotonik3d的结果，我公道猜疑TSV110根本没有配备stream预取器（L1中）。种种奇怪的现象都指向了TSV110对单核访存带宽、浮点吞吐的不重视，这究竟是出于目标负载刻意为之还是计划周期告急没能面面俱到，我们不得而知。
Coremark是一款嵌入式基准测试步伐，其受下级Cache子系统、内存等的影响极小，紧张考察核内流水线以及L1 Cache的性能体现。

更为古老的A75受制于后端执行单元规格（只有2组ALU）落伍于其他两款CPU；后端规格相近的TSV110与A76都在-O2编译时凌驾了7分。TSV110与A76的差距来自流水线前端和midcore部分，鲲鹏还需追赶（比如TSV110较为离谱的4周期延迟整数乘法器）。不过换个角度来说，自研的TSV110相较当时的上一代公版产品有了坚实的进步已经十分优秀，只是公版产品线的A76进步更为惊人而已。
Verilator

以上三款测试集对处置惩罚器的前端压力较小，仿真大规模计划的verilator则恰好相反，海量的分支与数MB的代码足迹能够轻松压垮ICache、BTB等组件，导致巨大的性能下滑。
在这一项目中TSV110的体现出奇得差，一度让我猜疑二进制出现了问题。一开始的猜疑方向是，TSV110如许的早期微结构BTB规格不敷造成了海量分支误猜测，进而影响了verilator负载的性能。但是在perf考察后我们发现其分支误猜测率仅2.4%，因此并不是和Zen3一样的BTB瓶颈问题。在考察ICache miss率后我们发现了问题的症结，即便在4线程verilator下TSV110仍然履历了8.52%的ICache miss率。这是典型的没有直达ICache的指令预取的体现；固然思量到TSV110极其保守的数据预取体现，L1的指令预取也可能存在但显然没有发挥理想的结果（甚至到L2的指令预取也可能没发挥理想的结果）。
思量到鲲鹏920的ringbus互联和4核核心簇的计划，我们还实验了更多的线程分布。我们发现将4个线程全部置于一个核心簇时反而无法得到最佳结果，这一点让人十分困惑。最佳结果出现在将4个线程中的2个分别置于相邻核心簇中，是否是因为4核同时高强度取指时单个核心簇的出口带宽不敷呢？总体而言TSV110好像不能胜任verilator如许的大前端压力使命。
前端

随着现代步伐体量的膨胀，处置惩罚器面对越发巨大的前端压力；为了应对庞大的步伐代码段带来的海量跳转指令，大部分高性能处置惩罚器核的BTB容量、分支猜测器容量不绝扩展，相关算法也在不绝演进。
BTB

对于采用了分离式前端（英文表述：decoupled branch prediction更为准确）的计划而言，BTB是前端的绝对核心组件；其负责在译码前识别指令流中的跳转指令并提供相应的跳转目标地址，频仍的BTB miss会造成严峻的性能损失。对于没有采用分离式前端的计划而言，BTB也要负责尽快给出跳转目标地址，淘汰取指流水线的空泡，包管取指带宽。

TSV110的BTB图像令人困惑。起首，我们可以清晰地辨认出64项的L1 BTB，但是L1 BTB好像不能很好得处置惩罚cache行内密集的分支，这一点与ARM A78、X1雷同。我们利用更细的粒度测试图像的前段空间：

结果好像暗示了L1 BTB的某种内部构造结构，但64项的L1 BTB完全可以用全相联CAM实现。这让人不禁猜疑L0 BTB的存在，倘若存在其容量约为8项。固然，另一种可能是TSV110的L1 BTB并非按照基本块构造，而是按照cache行构造；每个表项（1个cacheline）最多存储4条分支，因此一旦cache行内分支密度凌驾每四条指令一条分支就会造成L1 BTB有效容量急剧降落。一旦越过L1 BTB的容量，最密集的分支分布（全是分支和每两条指令一条分支）丢失了全部来自BTB的帮助。
其次，从verilator性能测试来看TSV110的分支误猜测率偏低；倘若利用了分离式前端，仅仅1024-2048项之间的BTB容量不敷以支撑如此高的准确率，因此TSV110大概率仍然采用了传统前端计划。我们利用针对传统计划的思绪来解读后半段图像：

• 可能1:TSV110的取指流水级较短，则不存在L2 BTB。分支数目凌驾64后就需要从ICache中取指并预译码才能得到分支指令信息，得到分支指令信息后才能修正执行流；这带来了较大的延迟损失，也是传统非分离前端计划的弊端。但如许的计划也并非没有长处，借助较大的ICache，TSV110无需配备独立的巨大下级BTB，省下了宝贵的片上空间并淘汰了功耗。但是这好像无法表明其糟糕的高密度分支场景体现。
  
• 可能2:TSV110的取指流水级特别长，则存在一个～2048项的L2 BTB。分支数目凌驾2048后同上。
  

不过无论是可能1还是可能2，TSV110的前端即便在传统前端计划中也算不上优秀，处置惩罚密集分支时的糟糕体现十分奇怪，也许是受到了过多的面积和功耗制约。
RAS

指令流中的call、return调用是较为特殊的分支指令环境，其栈情势的特征催生了专门用于猜测此类场景的RAS（Return Address Stack）。简而言之，call指令压栈，return指令弹栈；而硬件栈（RAS）结构的深度就影响了处置惩罚器在复杂函数调用场景中的性能体现。

TSV110的RAS显现了一些独特的行为。

• 坏的方面：其好像不能很好得处置惩罚对同一函数的嵌套调用，在call return指令对中夹杂条件分支后，RAS提前耗尽了容量。
  
• 好的方面：在该场景中，RAS容量耗尽后整个分支猜测系统并没有崩溃，好像由BTB完美接替了RAS的工作。
  

虽然在RAS理应管辖的范围内TSV110的体现逊于其他处置惩罚器，但当调用深度凌驾RAS深度很多后TSV110的体现优于其他处置惩罚器，这是我们在其他处置惩罚器核上没有观察到过的现象。

将测试改为利用不同的函数，TSV110真实的RAS容量由此显现。可见其RAS容量为32项，是时至今日也绰绰有余的容量。此时我们发现TSV110的RAS溢出后并没有做栈顶的规复或有效的清空，导致一旦发生凌驾32深度的调用整个RAS就会失效（由于此处换用了不同的函数，BTB无法再有效接受全部工作了）。相对地，A76、A78在回滚后对栈顶做了规复，icestorm则在回滚后做了其他情势的修正（诸如有效的清空）。
RAS CapacityTSV11032Icestorm32A7616A7816Gracemont2？(甚至可能没有传统意义的RAS)Zen432
BP

分支猜测器是今世高性能处置惩罚器前端中的又一核心组件，负责在流水线早期给出分支指令跳转与否的猜测，引导指令流的方向。在推测执行的超标量处置惩罚器中，分支猜测器的准确率会极大影响处置惩罚器的性能和能效体现。

本测试考察分支猜测器在不同汗青pattern长度、不同分支数目（需要猜测）环境下的准确性体现。TSV110的分支猜测器体现可圈可点。

• TSV110分支猜测器的等效有效容量比肩A76。在分支较多时，TSV110能追踪更长的汗青；在pattern长度较短时，TSV1100能够追踪更多的分支。
  
• TSV110好像利用了相对较短的分支汗青，即便在分支数较少时也无法追踪超长汗青。固然，这也可能是主猜测器内部hash辩论的结果。
  

IJP

IJP（Indirect Jump Predictor）作为BP（Branch Predictor）的一部分，负责猜测间接跳转的地址。与猜测跳转与否的BP不同的是，IJP需要在多个可能的跳转目标中选择本次的跳转目标，并引导指令流。

起首考察TSV110的IJP在不同汗青pattern长度（但是可能目标均只有2个）、不同间接跳转数目（需要猜测）环境下的准确性体现。我们惊奇地发现常用的测试写法下TSV110近乎完全无法做出有效猜测。为了照顾部分早期处置惩罚器，我们默认利用的测试在间接跳转指令间插入了条件直接跳转，因为部分早期处置惩罚器的IJP与BP利用同一份分支汗青，此中没有纳入间接跳转的地址bit，倘若不插入条件直接跳转就无法有效区分间接跳转目标的变化。TSV110的环境却反了过来，换用未插入条件直接跳转的测试得到结果如下：

TSV110的IJP体现规复正常：

• TSV110的IJP追踪汗青的能力略逊于A76。
  
• TSV110的IJP与BP一样，都没有显着的Cascading特征。
  
• 由于测试代码PC是2的幂次对齐，TSV110的IJP在某些排布下好像出现了hash辩论，有很多细碎的性能波动。
  

接下来考察TSV110 IJP在不同可能跳转目标、不同间接跳转数目（需要猜测）环境下的准确性体现。在这一场景中TSV110的行为与之前的测试完全相反。

• 如果利用没有插入条件直接跳转的测试，那么TSV110的体现与Icestorm相像，都很糟糕。一旦可能目标增多，IJP就无法精确猜测跳转目标。结合分支数目变多后IJP立即失效的现象看，IJP自身的表项容量好像被设置得极少，不过思量到一样平常指令流中心接跳转并不多见，如许的取舍也可以理解。
  
• 如果利用插入了条件直接跳转的测试，那么TSV110的体现会大幅好转，但是绝对性能上仍然落伍A76甚远。难道TSV110 IJP利用的汗青也没有混入间接跳转目标地址？
  

在IJP的两项测试中TSV110体现出了相互抵牾的特性，让人费解。不过可以肯定的是，TSV110的IJP能力不强。
ITLB

TLB是现代处置惩罚器中容易被忽视的一个部件，其负责虚拟地址至物理地址的翻译。在一样平常环境下TLB并不会成为瓶颈，但是随着现代步伐体量的膨胀TLB承受的压力也与日俱增，这一点在服务器负载中尤为显着。

TSV110的ITLB容量为～48项，取指时可以访问的L2 TLB容量为1024项。TSV110的取指侧TLB规模与A76、A78相当，大于Icestorm。不过需要注意的是，访问延迟的上涨点较为靠前，也许预示着某种特殊的更换算法或低级的TLB预取。
ITLB CapacityL2 TLB(for instruction) CapacityTSV110481024Icestorm32256A78481024A76481024
取指

处置惩罚器对步伐的执行始于取指，前端的指令供给能力至关紧张。一旦前端无法提供足够的指令，纵使后端的乱序执行能力再强也无力回天。对于TSV110如许的四发射处置惩罚器，我们渴望其每周期能够取指至少4条指令。

TSV110没有配备mop cache。我们可以看到指令足迹在64KB以内时由ICache供指，取指带宽为4条/周期；如许的带宽在分支较少时是完全够用的，但无法与配备了mop cache的处置惩罚器比肩（例如A78的mop cache供指带宽为6条/周期）。当执行流来到L2 Cache以后取指带宽骤然降落至1.75条/周期，可能预示着ICache较小的Refill通路位宽。与A78和Icestorm不同的是，TSV110并没有限制代码段可以占据的L2 Cache容量，指令可以利用近乎全部的L2空间。当指令流进入LLC与内存段后取指带宽彻底雪崩，仅剩0.25条/周期或更低。如许的取指能力在现现在是偏低的，面对大指令足迹的步伐会非常捉襟见肘（如verilator）。

A78的mop Cache对于nop指令举行了压缩优化；倘若利用nop指令测试取指，mop cache每周期能够供给凌驾10条指令；TSV110没有配备mop cache，天然也没有此类优化。
后端

处置惩罚器的后端负责指令的执行，今世高性能处置惩罚器普遍配备了乱序超标量机制，后端的计划也是纷繁复杂。
流水线宽度

在超标量处置惩罚器中我们偏重关注前端与mid-core部分的宽度。
流水级宽度Fetch(ICache)4Fetch(mop Cache)no mop CacheDecode4Rename4
TSV110能够提供的最大取指带宽为4条指令/周期，后续的重命名级与译码级和取指宽度同等，因此TSV110是最大吞吐为4条指令/周期的典型4发射处置惩罚器核。
执行单元

执行部件数目延迟ALU31BRU2MUL14DIV119（支持提前退出）AGU(ld+st)2AGU(ld)24AGU(st)1FPU2FADD24FMUL25FDIV117FMA27
与Icestorm、A76雷同，同样是4发射的TSV110也只配备了3组ALU。简单ALU并不占据过多的面积，难度来自于物理寄存器堆读写端口的计划（这在更宽的处置惩罚器上会更加棘手）。TSV110的复杂整数单元单独占据了一个发射端口，这在现现在的计划中并不多见，因此TSV110可以说是3ALU+1MDU的计划（也可以说是4ALU，只是此中一个无法执行简单运算操作）。TSV110配备了2组BRU，在密集跳转应用中能够包管吞吐量，符合现代应用步伐发展的趋势；事实上，配备2组BRU已经成为当今处置惩罚器核计划的惯例。乘除法单元上方面，TSV110只配备了1组；其乘法器延迟较大，除法器算法也较为普通；除法器支持提前退出，当被除数变为0时算法可以提前竣事。
TSV110拥有2个AGU（访存地址天生单元），但AGU load与AGU store并非全分离式计划；2个AGU中1个支持load/store操作，1个只支持load操作。对于一款4发射处置惩罚器而言，如许的访存单元设置较为常见，但略微落伍于某些4发射处置惩罚器，它们会配备全分离的load、store AGU或是2组AGU load/store。在memory wall越发显着的趋势下，重访存也是我个人十分欣赏的计划哲学；但是我个人更喜好Intel式的AGU load与AGU store分离的计划，不过这也会显著增加发射队列、物理寄存器堆计划的复杂度，恐怕这也是其他计划公司都未完全分离load与store AGU的原因。
TSV110配备了两组浮点执行单元。其FMADD延迟非常高，需要7个周期；FADD延迟较高需要4个周期；思量到TSV110本身的目标频率并不算高，如许的结果较差。虽然对于浮点性能来说吞吐量至上，但是这些堪称离谱的浮点部件延迟难免要为TSV110较低的浮点性能得分负一部分责任。浮点部件的打磨磨练计划公司的综合能力，但是过高的延迟反映了TSV110在计划时没有给予浮点单元必要的尊重。
总体而言TSV110的后端执行单元设置严峻偏向整数和分支指令，浮点部分非常单薄，访存部分较为标准。
幕间

在下篇中我们将对Mid-core、访存子系统、核外系统举行逆向探究。
分析与测试：lyz、lxy

---

以下是文章的深度解读与分析，探讨该微架构的优缺点及其潜在的改进方向

1. 配景与定位

1.1 鲲鹏系列的劈头

鲲鹏系列处置惩罚器作为华为结构高性能盘算的核心产品，早在2016年由鲲鹏916初次表态。2019年，鲲鹏920发布，成为首款采用7nm工艺的ARM架构数据中心处置惩罚器。鲲鹏920的计划目标紧张集中于云盘算、大数据分析和虚拟化场景。
只管华为的自研处置惩罚器因地缘政治制裁蒙上一层阴影，但鲲鹏920及其TSV110微架构的技术价值依然不容忽视。

---

2. TSV110微架构评测

2.1 SPEC基准测试分析

2.1.1 SPEC06：整数体现优异，浮点略显不敷

SPEC06作为传统评测工具，依然具有肯定的参考价值。在测试中，TSV110体现出以下特点：

• 整数性能：与ARM Cortex-A76核心相当，体现出色。
  
• 浮点性能：落伍于A76，紧张原因在于浮点运算单元延迟较高（如FADD 4个周期，FMADD 7个周期）以及乱序队列资源较小。
  
• 访存性能：单核访存带宽不敷，且硬件预取器体现保守，对依靠带宽的使命支持有限。
  

2.1.2 SPEC17：对预取优化需求显着

SPEC17测试中，TSV110在整数使命中体现紧追A76，但浮点使命仍显弱势。部分子测试（如520.omnetpp）体现出数据预取器的限制，可能缺乏流式预取机制，导致在复杂浮点盘算使命中失分。

---

2.2 前端性能解析

2.2.1 分支猜测与BTB计划

TSV110的BTB（Branch Target Buffer）计划为64项，可能存在L1 BTB条目按缓存行构造的环境，影响了高密度分支使命的处置惩罚性能。此外：

• 分支猜测器容量：与A76相当，但体现出对长汗青模式支持不敷。
  
• RAS（Return Address Stack）：支持32层调用深度，但对嵌套调用的处置惩罚能力不佳。
  

2.2.2 指令缓存与取指能力

• ICache计划：取指带宽为4条指令/周期，在L1阶段能包管较高的吞吐量，但进入L2 Cache后取指带宽降落至1.75条/周期。
  
• mop Cache的缺失：TSV110未配备指令压缩缓存（mop cache），导致指令密集型使命的取指效率较低。
  

---

2.3 后端与执行单元分析

2.3.1 执行单元设置

• 整数单元：3个ALU和1个复杂整数单元，符合4发射核心的常规设置。
  
• 浮点单元：浮点运算单元数目与性能显著落伍于同代ARM核心（如A76）。
  
• 访存单元：2个AGU（地址天生单元），支持负载和存储，但未完全分离，限制了高访存使命的吞吐能力。
  

2.3.2 性能权衡

团体来看，TSV110的后端计划更倾向于优化整数使命和分支密集型场景，而对浮点性能和访存使命支持不敷。

---

3. 技术挑战与改进建议

3.1 硬件层面改进

• 优化预取器计划：
  
  
  
  • 增加流式预取器支持，提升浮点密集型使命性能。
    
  • 改善指令预取器，使大代码足迹使命（如Verilator）能够高效执行。
    
  
  
• 加强执行单元：
  
  
  
  • 提升浮点单元吞吐能力，低落延迟（如将FADD延迟优化至3周期以下）。
    
  • 增加完全分离的访存单元（load/store AGU）。
    
  
  
• 改进分支猜测机制：
  
  
  
  • 扩展分支猜测器容量，支持更长的汗青模式和复杂分支跳转。
    
  
  

3.2 软件生态优化

• 编译器优化：
  
  
  
  • 提供更高效的编译器支持，针对ARM架构举行优化。
    
  • 加强对大页（Large Pages）和NUMA架构的支持。
    
  
  
• 软件栈适配：
  
  
  
  • 针对主流数据库、大数据和虚拟化平台优化，以发挥鲲鹏920的并行处置惩罚优势。
    
  
  

---

4. 鲲鹏920的市场定位与未来展望

4.1 市场定位

鲲鹏920的计划目标在于满足云盘算和数据中心的需求。其核心优势包括：

• 高核心数：得当并行使命和多线程场景。
  
• ARM生态：推动ARM在服务器市场的扩展。
  

然而，其在浮点性能和访存使命中的体现限制了其在科学盘算和复杂虚拟化环境中的适用性。
4.2 未来展望

随着ARM生态系统的不绝成熟以及华为在微架构计划上的持续投入，未来的鲲鹏处置惩罚器有望在以下领域实现突破：

• 提升单核性能，优化浮点与访存能力。
  
• 加强软件生态适配，推动企业级应用迁徙至ARM平台。
  
• 进一步优化能效比，低落空闲功耗和多核负载下的能耗。
  

---

5. 总结

鲲鹏920的TSV110微架构在整数使命和分支处置惩罚方面体现出色，但在浮点性能、访存效率和指令前端能力上仍有显着的优化空间。这既是其计划权衡的结果，也反映了华为在ARM架构服务器处置惩罚器市场中的技术积聚与探索。
未来，通过硬件优化和软件生态的双向支持，鲲鹏系列处置惩罚器有望成为云盘算和数据中心的紧张选择，为国内自主可控的盘算生态奠定坚实基础。

---

分析与撰写：技术探索团队
发布日期：2024年11月

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。