ARM还是X86?指令集并不重要

您所在的位置:网站首页 arm架构的指令集 ARM还是X86?指令集并不重要

ARM还是X86?指令集并不重要

2023-03-22 06:52| 来源: 网络整理| 查看: 265

急招:①数据中心基础架构研发专家②硅后验证工程师③GPU显存技术主管④GPU Architecture Modeling Expert⑤人工智能算法开发专家⑥GPU编译器开发专家⑦GPU C++开发专家(图形渲染生态)⑧AI基础软件设计专家(训练)

过去的十年里,ARM CPU 的制造商一直在尝试进军高性能 CPU 市场,因此我们看到了很多关于 ARM 所做的工作的文章、视频和讨论。其中许多文章都在讨论两种指令集架构(ISA)之间的差异。

本文将综合已经发表的文章、CPU 领域专家的评论以及我们自己的数据,展示为什么把重点放在 ISA 上是浪费时间(1)。为了开始我们的探索,让我们引用 Anandtech 对 Jim Keller 的采访。Jim Keller 是多个成功的 CPU (包括 AMD 的 Zen 和 Apple 的 A4/A5)的设计师,他对这个话题有着深入的见解。

[关于指令集的争论] 是一个非常令人悲伤的故事。An AnandTech Interview with Jim Keller: ‘The Laziest Person at Tesla’1 CISC VS RISC: 一场过时的争论

历史上,x86被归类为CISC(复杂指令集计算机),而ARM被归类为RISC(精简指令集计算机)。最初,CISC机器的目标是执行更少但更复杂的指令,每个指令完成更多的工作。RISC则使用更简单、更快、更易于执行指令。Jim Keller的话是:

在RISC首次问世时,x86芯片一半的面积被微码占据,如果你查看芯片的布局,就会发现有三分之一甚至是一半的面积都是ROM。而RISC的支持者可以声称RISC芯片上不需要ROM,因此RISC的性能更好。但是现在ROM已经变得非常小了,你几乎无法找到它。实际上,连加法器也已经小到几乎无法找到了。如今,限制计算机性能的主要问题是可预测性问题,其中最主要的两个问题是分支预测和数据局部性。An AnandTech Interview with Jim Keller: ‘The Laziest Person at Tesla’

简而言之,就性能而言,RISC/ARM和CISC/x86之间没有实质性的区别。重要的是保持核心的持续运转并正确供应数据,这需要关注缓存设计、分支预测、指令预取等一系列技巧,例如预测某个load操作能否在某个store执行之前执行。

在Jim Keller还未接受Anandtech采访的2013年,研究人员已经就开始在不同的x86和ARM处理器上研究ISA对性能的影响[1],发现RISC/ARM和CISC/x86在很大程度上已经趋于一致。

Blem等人的结论是,ARM和x86 CPU在功耗和性能上的差异主要是因为它们针对不同的目标进行了优化。指令集在这里并不是很重要,而实现指令集的设计才是最重要的。

我们研究的主要发现是:

尽管不同的实现之间存在着很大的性能差距,但平均IPC的差距不超过2.5倍。指令计数和指令组合在第一阶段与ISA无关。性能差异来自与ISA无关的微架构差异。功耗也与ISA无关。ISA的差异会对实现产生影响,但现代微架构技术使它们变得无关紧要;一个ISA并不从根本上更加高效。ARM和x86的实现分别为不同性能水平进行了优化。Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures

换句话说,这个非常受欢迎的Techquickie视频是具有误导性的,ARM ISA与低功耗并无必然联系。同样地,x86 ISA也并非代表高性能。我们今天熟知的基于ARM的CPU之所以功耗低,是因为ARM CPU制造商瞄准手机和平板电脑等低功耗场景,而英特尔和AMD的x86 CPU则专注于追求更高的性能,但这也带来了更高的功耗。

为了更进一步说明ISA在性能方面的作用相对较小,英特尔使用基于x86的Atom核心来制造低功耗处理器。一项由巴西联邦大学进行的研究[6]得出结论:在所有测试案例中,基于Atom核心的集群被证明是多级并行低功耗处理器的最佳选择。

参与该测试的两种核心分别是ARM的Cortex-A9和英特尔的Bonnell核心。有趣的是,Bonnell采用的是顺序执行引擎,而Cortex-A9则采用了乱序执行引擎,按理说,Cortex-A9在性能和能效方面都应该更优秀。然而,在这项研究的所有测试中,Bonnell在这两个方面都胜过了Cortex-A9。

2 译码器差异: 微不足道

另一个经常被提及的真理是,x86架构存在显著的“解码开销”劣势。ARM使用固定长度的指令,而x86的指令长度各不相同。因为你必须先确定一条指令的长度,才能知道下一条指令的起始位置,所以在并行解码x86指令时会更加困难,这对x86来说确实是一个劣势。然而,在高性能CPU方面,这并不重要,因为用Jim Keller的话说:

有一段时间,我们认为变长指令的解码非常困难。但是,随着时间的推移,我们不断地找到了解决方法。因此,在构建小型计算机时,固定长度指令似乎是非常优秀的选择,但如果你正在构建一个真正大型的计算机,要预测或找出所有指令的位置并不会主要整个die的设计。因此,指令长度的固定与否并不像过去一样非常重要。An AnandTech Interview with Jim Keller: ‘The Laziest Person at Tesla’

在这里,我们 Chips and Cheese 进行了很深入的调查。

通过使用未公开的MSR禁用微操作码缓存,我们发现Zen 2的取指和解码通路比微操作码缓存通路多消耗约4-10%的核心功率,或者0.5-6%的封装功率。在实际应用中,解码器将消耗更低的核心或封装功率。Zen 2的设计不是为了在关闭微操作码缓存的情况下运行,而我们所使用的基准测试工具(CPU-Z)主要针对L1缓存,这意味着它不会对内存层次结构的其他部分造成过多的压力。对于其他工作负载,来自L2和L3缓存以及内存控制器的功率会使解码器的功耗变得更加不显著。

事实上,当操作码高速缓存被禁用时,多个工作负载的功耗减少。其中,解码器的功耗被其他核心组件的功耗所淹没,尤其是当操作码高速缓存可以更好地满足这些组件的数据需求时。这与Jim Keller的评论相一致。

研究人员也持同样的观点。在2016年,由赫尔辛基物理研究所支持的一项研究[2]调查了英特尔的Haswell微架构。在那里,Hiriki等人估计Haswell的解码器消耗了3-10%的封装功率。该研究得出结论:“x86-64指令集不是生产高能效处理器架构的主要障碍。”

Hirki等人使用合成基准测试来测试开发的model,以估计单个CPU组件的功耗,并得出结论,解码器的功耗很小。测试的结果如下表。

在另一项研究中,Oboril等人[5]在Intel Ivy Bridge CPU上测量了取指和解码功耗。尽管该论文的重点是开发核心组件的准确功率模型,并没有直接得出关于x86的结论,但其数据再次表明解码器功率只占很小一部分。Oboril等人对Ivy Bridge的功耗进行了估算。相较于其他核心组件,取指和解码的功耗非常微不足道,如下图。

显然,解码器功耗是非零的,这意味着它是一个潜在的可改进领域。毕竟,在功耗受限的情况下,每瓦的功耗都很重要,即使在台式机上,多线程性能往往也会受到功耗的限制。我们已经看到了x86架构可以利用操作码缓存才提升能效,下面让我们从ARM的角度来看一下。

3 ARM解码的代价也很高

Hirki等人也得出结论,‘转换到不同的指令集只会节省少量功耗,因为在现代处理器中无法消除指令译码器(instruction decoder)。

ARM自己的设计证明了这一点。高性能的ARM芯片采用了micro-op caches来跳过指令解码,就像x86 CPU一样。2019年,Cortex-A77引入了一个1.5k条目的op cache[3]。设计这样的缓存并不容易,ARM的团队花费至少六个月的时间进行调试。表明,ARM解码难度足以证明在可能的情况下花费大量工程资源来跳过解码是有必要的。Cortex-A78、A710、X1和X2也采用了op cache,表明该方法比蛮力解码更为成功。

Samsung也在其M5芯片上引入了op cache。在详细介绍三星Exynos处理器的一篇论文中[4],作者指出降低解码功耗是引入op cache的一个重要动机。

随着从 M1 每个周期提供 4 条指令/微操作(uop)逐渐升级到 M3 每个周期提供 6 条指令/微操作(uop)(未来有望增长到每个周期 8 条指令/微操作),取指和解码功耗成为一个重要问题。M5 增加了一个微操作缓存作为替代的 uop 提供路径,主要是为了在重复的内核中节省取指和解码功耗。Evolution of the Samsung Exynos CPU Microarchitecture

与 x86 CPU 一样,ARM 核心使用micro-operation cache来降低解码成本。ARM 的“解码优势”并不足以让 ARM 避免使用微操作缓存。微操作缓存将减少解码器的使用,使得解码功耗更加微不足道。

4 ARM指令解码成微操作?

Gary Explains在题为“RISC vs CISC – Is it Still a Thing?”的视频中说,x86 CPU将指令分解为micro-ops所使用的额外功率“足以意味着它们不如相应的ARM处理器那样功耗高效”。在随后的视频中,他重申了这一说法。

Gary的观点是错误的,因为现代ARM CPU也会将ARM指令解码成多个micro-ops。实际上,正是通过“减少micro-op expansion”,使得ThunderX3的性能比ThunderX2提高了6%(Marvell的ThunderX芯片都是基于ARM架构的),这个因素的贡献是最大的。

下图是Marvell在2020年的Hot Chips会议上展示的幻灯片,红色轮廓是我们添加的强调。

我们还快速查阅了富士通 A64FX 的架构手册,这款基于 ARM 架构的 CPU 是日本富岳超级计算机的核心。A64FX 同样可以将 ARM 指令解码成多个微操作码。

这是 A64FX 架构手册中 ARMv8 基础指令部分的部分指令表。我们在能够解码为多个微操作码的指令上加了重点(红色轮廓)。

如果我们进一步深入,一些 ARM SVE 指令可以解码成几十个微操作。例如,FADDA(“严格有序的浮点规约加法,累积到标量”)可以解码成 63 个微操作。其中一些微操作码的延迟为 9 个周期。这就否定了 ARM/RISC 指令可以在单个周期内执行的说法…

另外需要指出的是,ARM不是一种纯粹的load-store体系结构。例如,LDADD指令会从内存中加载一个值,将其加上另一个值,然后将结果存回内存。A64FX会将这一指令解码为4个微操作。

5 x86和ARM:均因传统而臃肿

对他们俩来说都无所谓。

在 Anandtech 的采访中,Jim Keller 指出,随着软件需求的不断演变,x86 和 ARM 都逐步增加了新功能。虽然它们在转向 64 位时进行了一些清理,但它们仍然是经过多年迭代的旧指令集,而迭代不可避免地会导致指令集变得臃肿。

Keller有趣地指出,RISC-V由于处于“复杂性生命周期的早期”,因此没有历史遗留问题。他继续解释道:

“如果我今天想要快速构建一台高效的计算机,那么选择 RISC-V 是最为简单明了的选择。它是最简单的指令集,拥有所有必要的功能,并且针对最重要的前八个指令进行了精心设计,同时避免了过多的冗余。”An AnandTech Interview with Jim Keller: ‘The Laziest Person at Tesla’

如果历史遗留问题起到了重要作用,那么我们可能会在不久的将来看到 RISC-V 的大规模应用,但我认为这种情况不太可能发生。历史支持并不意味着历史支持必须以高速执行,它可以通过微码实现,从而最小化芯片面积的使用。与可变长度指令解码一样,这种额外开销在现代高性能 CPU 中并不重要,因为这些 CPU 的芯片面积主要被缓存、宽执行单元、大乱序调度器和大型分支预测器所占用。

6 结论:重要的是实现,而不是指令集(ISA)

我对来自 ARM 的竞争感到兴奋。高端 CPU 市场需要更多的竞争者,但由于指令集的差异,ARM 制造商并没有在与英特尔和 AMD 的竞争中占据优势。为了取得胜利,ARM 制造商需要依靠他们的设计团队的技术实力。或者,他们可以通过针对特定的功耗和性能目标进行优化,从而超越英特尔和 AMD。在这方面,AMD 尤其脆弱,因为他们使用单个核心设计来覆盖从笔记本电脑和台式机到服务器和超级计算机的所有市场。

我们希望看到讨论的重点能够转向更有趣的话题。希望这里呈现的信息可以避免陷入关于指令集的过时争论,从而使我们能够更加深入地探讨其他方面的话题。

参考文献

[1] Emily Blem, Jaikrishnan Menon, and Karthikeyan Sankaralingam, “Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures”, HPCA 2013, hpca13-isa-power-struggles.pdf (wisc.edu)

[2] Mikael Hirki and Zhonghong Ou and Kashif Nizam Khan and Jukka K. Nurminen and Tapio Niemi, “Empirical Study of the Power Consumption of the x86-64 Instruction Decoder”, USENIX Workshop on Cool Topics on Sustainable Data Centers (CoolDC 16), cooldc16-paper-hirki.pdf (usenix.org)

[3] Vaibhav Agrawal, “Formal Verification of Macro-op Cache for Arm Cortex-A77, and its Successor CPU”, DVCON 2020, https://2020.dvcon-virtual.org/sites/dvcon20/files/2020-05/01_2_P.pdf

[4] Brian Grayson, Jeff Rupley, Gerald Zuraski Jr., Eric Quinnell, Daniel A. Jimenez, Tarun Nakra, Paul Kitchin, Ryan Hensley, Edward Brekelbaum, Vikas Sinha, and Ankit Ghiya, “Evolution of the Samsung Exynos CPU Microarchitecture”, ISCA, Evolution of the Samsung Exynos CPU Microarchitecture (computer.org)

[5]Fabian Oboril, Jos Ewert and Mehdi B. Tahoori, “High-Resolution Online Power Monitoring for Modern Microprocessors”, 2015 Design, Automation & Test in Europe Conference & Exhibition (DATE), Oboril15DATE.pdf (kit.edu)

[6]Vinicius Garcia Pinto, Arthur F. Lorenzon, Antonio Carlos S. Beck, Nicolas Maillard and Philippe O. A. Navau, “Energy Efficient Evaluation of Multi-level Parallelism on Low Power Processors”, CSBC 2014, csbc2014-wperformance.pdf (ufrgs.br)

脚注

(1) 对于常见的整数负载来说,ISA扩展通常不太重要,除非工作负载能够充分利用它们的优势。但是,对于一些特定的工作负载,如矢量运算和加密操作等,ISA扩展确实非常重要,比如SSE/AVX/NEON/SVE和AES-NI等扩展。以下是一个ISA确实重要的示例:Gem5 CPU模拟器的编译时间。在这个例子中,3950X运行在Win10的WSL环境下,而Ampere则运行在在Oracle云实例上。

Zen 2(x86)和Ampere(ARM)在编译代码时大致相当,特别是考虑到Zen 2旨在达到更高的性能目标(具有更大的核心结构和更高的时钟速度)。

下图是HEVC的编码速度,以ffmpeg在编码4K Overwatch POTG片段后的报告为准。

然而,Ampere花费超过半天的时间来转码一个24秒的4K视频,而Zen 2只用了一小时多一点的时间就完成了这项工作。ARM没有使用汇编优化,因此我从最新的主分支构建了ffmpeg/libx265。使用NEON指令后,Ampere的性能提高了60%以上,将编码时间缩短到了9个多小时。但是,Ampere距离Zen 2仍有很大差距。

通过检查性能计数器,发现使用Ubuntu 20.10默认的ffmpeg时,Ampere执行的指令数量是Zen 2的13.6倍,使用最新的ffmpeg/libx265时,执行的指令数量是Zen 2的7.58倍。显然,Ampere执行的指令更简单,能够更快地完成它们,其IPC分别为3.3或3.03,而Zen 2的IPC为2.35。然而,这并不能弥补需要处理多达十倍指令的缺陷。难怪ARM指令集随着时间的推移已经被扩展,包括更多(包括复杂的)指令。

不过,这是一个另外的话题,我们可以在另一个时间进行讨论。

就现在而言,ARM和x86都拥有丰富的ISA扩展,可以涵盖大多数使用情况(不过,它们的实现和软件生态系统的支持另当别论)。



【本文地址】


今日新闻


推荐新闻


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