【转】Arm Cortex A78微架构评测:中核奠基之作

您所在的位置:网站首页 A78马来西亚 【转】Arm Cortex A78微架构评测:中核奠基之作

【转】Arm Cortex A78微架构评测:中核奠基之作

2024-07-15 07:08| 来源: 网络整理| 查看: 265

前言

A78的故事得从2018年讲起,彼时Arm Austin团队接过了微架构设计的接力棒,带来了影响深远的A76。A76在我眼中是Arm A系列步入现代高性能处理器领域的第一款微架构,其诸多的先进特性和良好的功耗、性能表现为时至今日的Arm微结构演进打下了良好的基础。次年的A77是一步坚实的迭代,引入了更合理的后端配置和micro op cache等部件;采用了A77的骁龙865也堪称一代传奇。在A78世代,同期的X系列接过了wider、deeper的任务向最高性能发起冲击;而A系列的定位悄然由大核变为了中核,在X1的映衬下似乎黯然失色。那么A78的表现究竟如何呢?我们来一探究尽。

基准测试

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

频率

我们使用的平台是Microsoft windows dev kit 2023;处理器为高通8cx Gen3。在多次更新后处理器已经能够稳定运行在2.4GHz,以下的测试都基于2.4GHz的频率进行,但是A78微架构本身是可以运行在更高频率的。

SPEC06

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

A78拥有这三款处理器核中最高的IPC性能;考虑到其较小的浮点后端规格,其浮点性能也十分优秀。在mcf等重访存项目上,A78丝毫不逊于Gracemont;考虑到8cx Gen3相对较小的Cache规模,A78的极限应远不止于此。Icestrom受制于E核簇较小的可访问L2 Cache容量,在诸多子项上都落后明显,绝对性能并不是其强项。

SPEC17

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

A78拥有这三款处理器核中最高的IPC性能,考虑到A78也可以运行至3GHz,与Gracemont相比拥有相当的竞争力。Icestorm以极低的能耗著称,但是在绝对性能上并不是其他两款处理器核的对手。A78最令人惊奇的是其相较A76(本图并未列出)的提升十分全面,在几乎所有子项上都有正向提升而非“取舍的艺术”。

Coremark

Coremark是一款嵌入式基准测试程序,其受下级Cache子系统、内存等的影响极小,主要考察核内流水线以及L1 Cache的性能表现。

可见A78的表现十分优秀,充分发挥了mop cache供指时6发射的前端优势;Icestorm则受制于较弱的后端执行单元规格,落后于其他两款CPU。

Verilator

以上三款测试集对处理器的前端压力较小,仿真大规模设计的verilator则恰恰相反,海量的分支与数MB的代码足迹能够轻松压垮ICache、BTB等组件,导致巨大的性能下降。

在这一项目中,尽管Icestrom频率最低但仍然胜出。采用分离式前端的A78与Gracemont受制于较小的前端规模,发生了海量的BTB miss;采用传统设计的Icestorm则将ICache视为下级BTB,因此取指效率更好。A78本身也并没有为前端bound负载优化的迹象,表现较为普通,甚至不敌较老的源于A76的N1。与Skylake相比更因为巨大的目标频率差异而被远远甩开。

前端

随着现代程序体量的膨胀,处理器面临越发巨大的前端压力;为了应对巨大的程序代码段带来的海量跳转指令,大部分高性能处理器核心的BTB容量、分支预测器容量不断扩展,分支预测算法不断演进。

BTB

对于A78这样的分离式前端设计,BTB是前端的绝对核心组件。其负责在译码之前识别指令流中的跳转指令,并提供相应的跳转目标地址。频繁的BTB miss会造成严重的性能损失。

可见,A78的L0 BTB容量为64项,疑似全相联;L1 BTB为4096项,组相联。对于现今的分离式前端设计而言,这样的BTB配置并不算大;但是考虑到A78的定位,4K项也算是诚意十足,与常青的传奇架构Skylake规模相当。但是决定BTB性能的远不止有效容量,其吞吐率、预测速度也十分重要。当分支指令数量小于64条时,平均每条分支指令的执行延迟仅有0.5 cycle;即A78支持每周期2 taken分支。现如今的其他消费级处理器中仅有Intel的新产品12代、13代酷睿(GoldenCove等)拥有与之匹敌的特性。当分支指令大于64条小于4096条时,平均每条分支指令的执行延迟仅有1-2 cycle;即此时A78每周期预测1条taken分支的代价在0-1间波动。如此低的下级BTB延迟也实属不易;作为参照,12K项的Intel GoldenCove BTB延迟为2,7K项的AMD Zen4 BTB延迟为1.5-2。总体而言A78的BTB表现十分惊艳,受制于其定位,A78在BTB容量方面有所保留,火力全开的X1则更为亮眼(容量相较A78倍增)。

RAS

指令流中的call、return指令是较为特殊的分支指令,其栈形式的行为特征催生了专门用于预测此类场景的RAS(Return Address Stack)。简而言之,call指令压栈,return指令弹栈;而硬件栈(RAS)结构的深度就影响了处理器在复杂函数调用场景中的性能表现。

可见A78的RAS容量为16项,与X1相比并没有被阉割。可能对于Arm而言,16项的RAS已经足以覆盖常见场景了;但是为服务器优化的Zen3则拥有着32项的RAS。

BP

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

本测试考察分支预测器在不同历史pattern长度、不同分支数量(需要预测)情况下的准确性表现。A78在4条分支、32条分支时经历了一定程度的性能衰减。A78总体性能表现与Intel Goldencove相似,但是在追踪海量分支指令时与Zen3仍有一定差距。

IJP

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

首先考察A78 IJP在不同历史pattern长度(但是可能目标均只有2个)、不同间接跳转指令数量(需要预测)情况下的准确性表现。A78在64条间接跳转指令时经历了一定程度的性能衰减,但是这种衰减可能并非IJP失效导致的,因为其并没有导致跳转地址错误而回滚,只是增加了少量的延迟。这可能是cascading预测的特征,IJP系统内某种规模更大但是速度相对较慢的结构修正了前级预测器的结果,导致taken延迟小幅增长。另外注意到,2条间接跳转指令时,A78 IJP内部可能发生了某种Hash冲突导致性能显著降低;对于Hash算法而言,类似的corner case是难以完全避免的。与X1相比,A78的IJP规模被小幅减少了;不过考虑到间接跳转指令在一般程序指令流中占比极少,这样的取舍是完全合理的。

接下来,考察A78 IJP在不同可能跳转目标数量、不同间接跳转指令数量(需要预测)情况下的准确性表现。A78在64条间接跳转指令时经历了一定程度的性能衰减。其间接跳转预测器的容量约为2048-4096项,相较X1减少了一半(4096-8192)。在SPEC06中间接跳转较多的perlbench子项中,A78的表现尚可但也谈不上优秀,还有一定的进步空间;但是不可否认,A78已经拥有了坚实的间接跳转预测机制。

ITLB

TLB是现代处理器中容易被忽视的一个部件,其负责虚拟地址至物理地址的翻译。在一般情况下TLB并不会成为瓶颈,但是随着现代程序体量的膨胀,TLB承受的压力也与日俱增,这一点在服务器负载中尤为明显。由A系列衍生的Neoverse N系列会被用于服务器负载,因此TLB设计也不可忽视。

A78的ITLB容量为48项,取指时可以访问的L2 TLB容量为1024项。在一般用户程序中这样的TLB规模并不会成为瓶颈;但是已经显著落后于当今的其他竞品。

取指

处理器对程序的执行始于取指,前端的指令供给能力至关重要;一旦前端无法提供足够的指令,纵使后端的乱序执行能力再强也无力回天。对于A78这样的4发射处理器,我们期望其每周期能够取指至少4条指令。

由于A78配备了mop cache,我们可以看到当指令足迹在4KB-8KB时,mop cache能够提供每周期6条指令的吞吐;mop cache的有效容量在1.5K左右。当指令足迹溢出至ICache时,取指带宽下降至4条/周期;这样的带宽是完全够用的,ICache的有效容量在32KB左右。A78的L2 Cache取指带宽相较ICache取指带宽并未严重下滑,仍然保持着~3.4条/周期的良好表现,而在一些早期处理器上此时的取指带宽甚至会下降至2条/周期。对于取指而言L2 Cache的有效容量在256KB左右;A78似乎有意限制了代码段可以占据的L2 Cache容量,指令只能使用到一半左右的空间。当代码段溢出到LLC后A78的取指带宽下降到了2条/周期;同样的,指令似乎只能最多使用一半的LLC空间。考虑到A78的应用场景,这样的取指能力是可圈可点的。

A78的mop Cache对于nop指令进行了压缩优化;倘若使用nop指令测试取指,mop cache每周期能够供给超过10条指令。

后端

处理器的后端负责指令的执行,当代高性能处理器普遍配备了乱序超标量机制,后端的设计也是纷繁复杂。

流水线宽度

在超标量处理器中我们着重关注前端与mid-core部分的宽度。

流水级宽度Fetch(ICache)4Fetch(mop Cache)6Decode4Rename6

当指令流能够被mop Cache容纳时,A78能够提供其最大吞吐:6条指令/周期;此时处理器bypass了译码级以及以前的部分,因此只要重命名级拥有足够的宽度即可。较少的decoder有利于降低功耗,缓解流水线宽度增加时前端的膨胀。但是A78的mop Cache放在当代是显著偏小的,面对不算很大的代码段时也会退化至4发射,这对同源的Neoverse N系列是很不利的(虽然A78并没有对应的产品)。

执行单元执行部件数量延迟ALU41BRU2MUL22DIV119(支持提前退出)AGU(ld+st)3AGU(ld)34AGU(st)2FPU2FADD22FMUL23FDIV211FMA24

A76首代只配备了3组ALU,在随后的A77中补齐为4组,A78延续了A77的设计。简单ALU并不占据过多的面积,难度来自于物理寄存器堆读写端口的设计,这在更宽的处理器上会更加棘手。A78配备了2组BRU,在密集跳转应用中能够保证吞吐量,符合现代应用程序发展的趋势。乘除法单元上A78选择了非对称配置,由于除法指令使用较少,这一选择是合理的。其乘法器延迟符合预期但是除法器算法则显得较为普通;除法器支持提前退出,当被除数变为0时算法可以立即结束。

A78拥有3个AGU(访存地址生成单元),但是AGU load与AGU store并非分离式设计;3个AGU中2个支持load/store操作,1个只支持load操作。对于一款4发射处理器而言,这样的访存单元配置不可谓不豪华;在memory wall越发明显的趋势下,重访存也是我个人十分欣赏的设计哲学。但是我个人更喜欢Intel式的AGU load与AGU store分离的设计,但是这也会显著增加发射队列、物理寄存器堆设计的复杂度,也许这样的设计蕴藏着Arm自己的取舍哲学。

由于A78的定位其只配备了两组浮点流水线,但是在基准跑分中其浮点成绩十分优秀,这也是重访存设计的优势。其FMADD延迟表现优异仅需4周期,FADD延迟表现优异仅需2周期,但是A78本身的目标频率也较低,因此在这方面Intel似乎更胜一筹。Arm的特点便是提供足额的FMA单元,且FMA单元均支持较快的独立FADD操作。Arm在浮点寄存器堆的设计上也有所取舍,并没有提供足额的读端口;这一点在浮点执行单元较少的A78上并无大碍,但是会限制更宽的设计(如X1)在某些场景下的吞吐量。

总体而言A78的后端执行单元配置较为均衡,偏重访存和分支,弱浮点向量。当然,其相对较多的访存、分支单元也是为了兼顾mop Cache供指模式下6发射的吞吐量。

幕间

在下篇中我们将对Mid-core、访存子系统、核外系统进行逆向探究。

分析与测试:lyz、lxy

编辑于 2023-02-08 10:26

幕间

在上篇中我们主要探究了A78微架构的取指前端和后端执行单元配置,下篇我们继续探究Mid Core、访存子系统、核外系统。

JamesAslan:Arm Cortex A78微架构评测(上):中核奠基之作94 赞同 · 18 评论文章

Mid Core重命名消除

在实际应用程序中许多指令并不需要进入处理器后端被真正执行(如move指令);现代处理器普遍配备了各式各样的重命名消除机制,以减少处理器后端压力并加速程序执行。

Elimination typeThroughputmove imm zero6move imm one4move chain1.3move single4move self4move bounce1.3sub self1xor self1

A78配备了最简单的重命名消除机制,但是与当今竞品相比仍极为落后。A78的重命名甚至不能在同一周期内处理相关链;虽然这样的场景在实际应用中并不多见,但是残缺的机制在我个人眼中终究是不优雅的。抛开个人情感,这样的取舍可以理解:一方面是这样的场景较少;另一方面是A78流水线相对较短,支持相关链重命名会给重命名级带来巨大的时序压力。

move imm one(mov x10, #0)吞吐为6说明重命名时对置0进行了消除,这是常用操作。

move imm one(mov x10, #1)吞吐为4说明重命名时未对其他立即数情况进行消除,由ALU真正执行。

sub与xor均未对置0情况进行特别优化,可能是ARM ISA的编译器极少进行此类操作;X86处理器普遍配备此类优化。

move single(非相关的move消除)等的吞吐仅为4而非6,说明了其基本不具备重命名消除机制(除最简单的置0),所有的move仍然由后端真正执行。

既然move single都不支持,其余操作显然不会支持。

总体而言A78在重命名机制上的进步空间无限大。

乱序资源

乱序推测执行的处理器需要海量的队列空间来跟踪指令,确保指令最终的提交顺序正确。

CapacityROB~160PRF(Fix)~160PRF(Float)~92PRF(Condition)~44

A78贯彻了中核的定位,采用了小而美的设计。160项的ROB对于消费级4发射处理器而言绰绰有余,但是倘若考虑到mop cache供指时的6发射宽度,这样的容量就较少了。A78提供了近乎足额的定点物理寄存器堆,说明了ARM对整数应用的重视,但实际上这是不必要的。由于A78并不注重浮点性能,因此只提供了约92项的浮点物理寄存器堆;考虑到即便是浮点程序,一般也会同时使用相当数量的定点指令,这样的FPRF容量也未尝不可,反倒是ROB容量可能先成为瓶颈。由于ARM ISA定义了Conditional Bits,该结构也支持重命名操作,其容量在44项左右。

ARM对Nop指令的特殊优化并不局限于前端的Mop Cache,ROB也同样进行了Nop指令的压缩。倘若使用Nop指令测试ROB容量会得到下图:

使用Nop指令测试得到的错误图像

使用精心配比的非Nop指令占满ROB时得到下图:

使用配比指令序列测试得到的图像

因此逆向测试时知道自己到底在做什么是非常重要的,否则会得到误导性的数据;诸如C&C也在队列容量上提供了错误数据,例如他们测试LDQ的方式就并不准确。人无完人难免百密一疏,如果我们的测试有遗漏和错误也欢迎讨论。

乱序推测执行的处理器最为直接的调度窗口由各级发射队列的容量决定:

CapacityIssueQ(Simple fix)~56IssueQ(Complex fix)~32IssueQ(Float)~48IssueQ(Load)~32LDQ~64STQ~48

由Arm官方公布的信息可知,A78采用了分布式发射队列,浮点、整数、访存分别共享一个发射队列。经过容量测试,我们可以得到以下信息:

整数发射队列为56项左右,相较X1小幅缩减。整数发射队列与ROB表项的比值为56/160=0.35,是相当高的;这是较为平衡的设计,可以认为代表了一般场景下较好的乱序调度能力。需要注意的是, 复杂整数指令如乘法指令并不能使用到所有的整数发射队列表项,而是只能用到56项中的32项;这可能是发射队列的内部结构划分导致的,为了实现每周期挑选4条就绪指令,该队列内部划分为了数个子队列。

浮点发射队列为48项左右,相较X1小幅缩减。对于A78这样的设计而言是富足的。

访存发射队列为32项左右,相较X1小幅缩减,三组发射队列的容量削减均为8项左右。A78的访存执行单元规格相较X1并未减少,不过访存发射队列小幅削减并不影响大局。

总体而言,A78的乱序调度窗口巨大,这样平衡的设计在超大核(Apple、X86)频出的如今并不多见。

A78的Load Queue容量为64项,Store Queue容量为48项;相较X1有相当幅度的缩减,不过这种缩减符合A78相对X1的定位。至于这样的LDQ、STQ容量是否够用,不同的视角会有不同的答案。从其它乱序资源的规模上来看(例如160项的ROB容量),A78的LDQ与STQ容量绰绰有余;从执行单元的规格上来看(3load AGU、2store AGU),A78的LDQ与STQ容量就显得不那么大了。总体而言,A78仍然是一款相当注重访存的微架构;较强的访存能力会让处理器在实际负载中获得较好的表现,而非仅仅是理论跑分战神。

访存

访存是体系结构永恒的话题与难题,访存性能直接决定了处理器性能的上限(甚至取指也受制于访存),访存子系统的表现体现了设计团队的综合实力(前端、后端)。为了缓解越发明显的缓存墙(memory wall)问题,现代处理器的访存子系统十分复杂;流水线内的LDQ、STQ,Dcache、DTLB,下级Cache、下级TLB,各级预取器等组件交织配合;尝试在延迟、带宽等多个维度提高访存性能。

load-store前递

当load指令命中STQ中还未来得及写回DCache的store指令(访问了相同的物理地址)时,配备了load-store forwarding的处理器无需等待store指令写回DCache后再执行load指令,而是可以直接将STQ中存储的相应数据发送至LSU,完成load指令的执行。

load-store forwarding

从橙色条带可见,A78配备了load-store forwarding机制,延迟倍率在5倍左右,属于相对较快的梯队。与A76相比,A78的store-load forwarding经历了小幅改进,延迟下降了。实际表现上A78与X1基本一致,相关机制并未改动;作为流水线的核心机制之一,这方面的规格没有必要(仅因为定位不同)修改。A78只能在32bit对齐的位置上进行load-store forwarding(STQ的查询和存储粒度为32bit),且load目标数据必须真包含于store指令的操作数据;当数据partial overlay时,必须等待store指令的数据写入DCache再重新执行load指令。当store和load操作地址跨行时,都会带来额外的延迟损失,但是load-store forwarding机制并未失效。

Dcache端口

load-store forwarding图还包含了更多的信息。

load、store均不跨行

load、store均不跨行时,每周期能够执行1.5组store-load指令对,符合A78只有3个AGU的设计。

load不跨行,store跨行

load不跨行store跨行时,store写入Dcache的带宽降低,引入了额外的开销;此时每周期能够执行1组store-load指令对。

load跨行,store不跨行

load跨行store不跨行时,load读取Dcache的带宽降低,引入了额外的开销;此时每周期能够执行0.78组store-load指令对,开销大于store跨行。这些现象表明:

Dcache并不能无损处理一般跨行情况,没有采用按地址interleave的分block设计。

倘若跨行采用的是多周期形式的处理,那么核内流水线LSU调度不够完善,遇到多周期情况不能最优得调度load与store;这也是混合load AGU与store AGU的潜在弊端。

倘若跨行采用的是争夺Dcache端口形式的处理,那么1.Dcache的设计令A78无法有效得穿插load与store。2.write buffer的写合并不够激进。

总体而言,A78的核侧访存子系统相较A76有小幅改善,但是Dcache设计鲜有变动;主要提升来自于核内流水线增加的一组load AGU。相似的核侧访存子系统也是A76、A77、A78(X1)一脉相承的关键特征。

Cache延迟

我们使用多种访存模式访问逐渐变大的数据集(直至内存),以探究A78的Cache层级设计、预取器效果、内存控制器效果。

A78展现出了一些不寻常的特性,其L2 Cache延迟与LLC延迟并没有很大差距,这可能是Dynam IQ crossbar系统的优势。

DCache有效容量为32KB。

L2Cache有效容量难以辨认。

LLC有效容量为6MB,与X1并不相同,可能存在QoS机制限制了中核的可用容量;抑或是替换算法的不完备性限制了空间使用。

预取器存在一定的进步空间,Linear Chain也未能做到无损预取。

存在开页预取器或类Region预取器,但是效果也较为一般。

内存延迟较大。

8cx Gen3的LLC延迟出奇得低,可能是Dynam IQ crossbar系统的优势;其不明显的L2 Cache容量则可能是优秀的动态替换算法发挥了作用。

访存序

乱序推测执行的处理器中,store指令无法被推测执行但是load指令允许被推测执行,这就造成了访存的RAW和WAR问题。为了避免错误推测执行的load指令带来频繁的回滚或流水线清空,处理器内部普遍配备了访存违例预测器,预测可能会导致回滚和流水线清空的load指令,并强制这样的load指令不再完全推测执行。

A78的访存违例预测器有32项容量,采用了较为传统的设计。现今处理器仍然广泛使用这样的传统设计而非store-set等机制,但是传统机制也有海量的设计细节,我们不在此展开。采用传统机制的设计中,Apple M1的表项容量最大(IBM除外),其余设计容量普遍在32项左右;只有Intel的大核采用了类store-set设计。

访存并行度

在该测试项目中,我们考察处理器同时面对多个访存流时的表现。每个访存流均是随机且独立的,因此可以规避大部分预取器的影响,最大限度压榨核内流水线乱序结构、各级Cache乱序结构。

可见A78在上级Cache层次中并不能很好得隔离各个访存流,预取器等结构的行为相互干扰造成了极大的不稳定性。在下级内存端,最大的有收益流数量在16-20之间,在现如今处理器中不算很多。

Pointer Chasing

Pointer chasing是现代高性能处理器中常见的访存优化,当一条load指令的结果用于下一条load指令的地址计算时,该结果会从快速通路进入AGU流水线,缩短这两条load指令的执行间隔。在配备了pointer chasing消除的处理器中,触发pointer chasing后load-to-use延迟会比正常情况减少1周期。

Load-to-use latencyPointer-chasing Case4No-pointer-chasing Case4

较为遗憾的是A78并未配备pointer chasing优化。A78的4周期的访存延迟本身较低,pointer chasing优化重要性较低;但是A78目标频率较低,pointer chasing优化的难度也较低。苹果firestorm在相近的目标频率下配备了pointer chasing优化,触发时load-to-use延迟仅3个时钟周期,Arm与之仍有较大的差距。

核外

随着摩尔定律的放缓,即便是消费级处理器也被迫向多核方向发展,核外组件发挥着重要的作用。核外系统是个纷繁复杂的世界,无论是总线结构、一致性协议、LLC设计还是内存控制器调度,每项都复杂到读完1本书都无法入门。因此,我们只关注其中较为浅显、直观的部分。

核间延迟

我们通过CAS测量Soc中两两核间的延迟,其反映了处理器的一致性协议效率、LLC设计、总线设计等多个维度特性的交叠。

8cx Gen3

8cx Gen3的核间延迟非常均匀,没有采用了ringbus或是mesh网络的特征,应该是最为简单的crossbar类。从发布代际上来看,Cortex A78与X1发布时DSU110(双ring结构)还未发布(不过仅从时间上判断是无效的,DSU110仍然有可能支持A78与X1);因此其采用的是初代Dynam IQ且其为crossbar设计。平均34秒左右的延迟是可以接受的,当然也谈不上优秀;不过对于消费级而言是绰绰有余了。附上老对手苹果M1的核间延迟表现:

此处不展开M1的核间延迟分析,但是较为明显的是其大小核簇之间并不能有效得共享信息,与Dynam IQ形成了鲜明对比。

访存带宽

我们通过Stream程序测试Soc中CPU单核的访存带宽,其反映了处理器核内的流水线设计、各级Cache设计、总线设计、内存控制器设计等多个维度特性的交叠。

FunctionBest Rate (MB/s)Copy33002Scale31302Add29228Triad29517

与使用高频DDR的桌面平台相比,8cx Gen3的内存带宽还有较大的差距。对于重内存带宽的极少数单核应用、重内存带宽的多核应用,8cx Gen3会更为力不从心;不过对于专注单核常规测试的我们而言这并不是问题。我们可以期待,今后“真正”的桌面级Arm平台在更好的内存子系统加持下会有更好的性能表现。

总结

从市场角度来看A78是一款长寿的微架构,至今还被广泛用于中端SoC中,这本身就说明了其成功。从微架构角度来看,A78是对A76、A77的坚实迭代,主要改进了处理器前端和核内流水线,不过鲜有涉及Cache子系统。从Benchmark的角度来看这些改进基本是正向的,鲜有负面效果,令人印象深刻。总体而言,A78已经拥有了现代微结构的大部分基本特征,但是细节上较为粗糙和“简陋”;这是受制于移动端应用环境还是人力资源限制我们不得而知,但也让人更加期待Arm A系列未来的发展动向。

分析与测试:lyz、lxy

测试平台

本文的测试是在Microsoft windows dev kit 2023上进行的,其使用了高通8cx Gen3(配备了4颗Cortex X1和4颗Cortex A78),环境为Win11的WSL2 Ubuntu22.04。

这台开发机经历了一段奇妙的旅程:康涅狄格 → 纽约 → 香港 → 澳门 → 湛江 → 广州 → 北京。个人对此类设备抱有极大的好奇与好感,无论是当初的zen/zen+还是后来的m1;而8cx gen3算是第一代真正可用的高通desktop soc了,自然不能错过。但是微软在国内并不对个人出售dev kit,故只能代购转运,也就有了它跋山涉水游历四方的传奇旅途。

发布于 2023-02-18 09:30



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3