AArch64原子操作对性能的影响

419→→→POSTER：AArch64 Atomics：他们会影响你的表现吗？摘要里卡多·赫苏斯EPCC英国rjj@ed.ac.uk爱丁堡爱丁堡大学米歇尔·韦兰EPCC英 国 爱 丁 堡 爱 丁 堡 大 学m.weiland@ epcc.ed.ac.uk1引言原子操作是保证作为一个整体执行的最重要和最广泛使用的原子操作之一在最近的Arm架构上，CAS操作可以直接经由CAS指令或经由加载链接/存储条件（LL-SC）指令对来实现在这项工作中，我们探索了CAS和LL-SC方法的性能，以在最近的 高 性 能 AArch 64 CPU 上 实 现 CAS 操 作 ， 即 A64FX，Thun-derX 2（TX 2）和Graviton 3。我们观察到，这些指令可以导致根本不同的性能剖面。例如，在A64 FX上，较新的CAS指令（编译器通常优先使用较旧的LL-SC对）可以导致每次成功CAS操作的平均时间随着线程数量的增加而呈二次方增长，而较旧的LL-SC对则显示预期的线性增长。 对于高线程数，这意味着LL-SC 比CAS快20多。在TX 2和Graviton 3上，LL-SC可以带来更保守（但仍然显着）的2 ���-3加速。我们分析了每种方法在每个CPU上提供更好性能CCS概念：·计算机系统组织多核架构;·通用和参考 性能;评估;·软件及其工程并发控制;多线程。关键词：A64FX，Graviton3，ThunderX2，原子，基准测试，比较和交换，性能分析允许制作部分或全部本作品的数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用。本作品的第三方组件的版权必须得到尊重。对于所有其他用途，请联系所有者/作者。PPoPP©2023版权归所有者/作者所有。ACM ISBN979-8-4007-0015-6/23/02。https://doi.org/10.1145/3572848.3579838在并发编程的上下文中，原子操作是保证在不受其他线程干扰的情况下运行完成的不可分割的操作。 这些操作对于多线程程序中线程的同步和协作是必不可少的[1]。最常见和通用的原子操作之一是“比较和交换”（CAS），它允许线程以原子方式将存储在内存中的值与另一个值进行比较，如果值匹配，则用新值覆盖内存。CAS操作的适用范围从低级同步原语（如锁和信号量）到高级代码（如并发数据结构[7，8，11]和内存数据库[9]）。在最近的Arm架构上，CAS操作可以通过显式CAS指令或通过加载链接/存储条件（LL-SC）指令对来实现。 在这项工作中，我们探索了这些方法在最近的高性能 AArch64 CPU 上 的 性 能 ， 即 A64FX ， ThunderX2 和Graviton3。我们总结了我们工作的主要贡献如下：1. 我们证明了新的CAS指令对并行代码的负面影响（这些指令是编译器默认选择的2. 我 们 详 细 研 究 了 CAS 和 LL-SC 指 令 在 最 先 进 的AArch 64 CPU上的性能;3. 我们分析了每种方法（CAS或LL-SC）提供更好性能的条件包括2相关工作CAS和其他原子操作的性能在过去已被广泛考虑用于x86目标[5，6，12，16，17]。在这里，我们重点介绍AArch64 CPU，相比之下，它受到的关注要少得多。 在[14]中， 作 者 使用LockHam- mer [2]和Splash-3 [15]研究了Graviton 2和Kunpeng 920处理器上CAS和LL-SC指令的性能。至关重要的是，他们没有识别也没有发现我们在A64FX和TX 2上观察到的根本不同的缩放趋势，他们没有研究Graviton 2/3如何响应不同持续时间的循环，因此没有实现LL-SC指令的加速4203x3x2x1.2x8x16x 22x3x3x∼∼PPoPP10001001010.10.010.001uint64_t内核; A64 FX，TX 21 2 4 8 16 3264号线程双核（16x 22x8xTX2（CAS）A64FX（CAS）TX2（LL-SC）A64FX（LL-SC）1 2 4 8 16 3264号线程uint64_t内核; Graviton 3（1,00010,000100,0001,000,000CAS3x3x1 2 4 8 16 32 64号线程图1.CAS与LL-SC战略。（a-b）整数（a）和双（b）内核在A64 FX和TX 2 CPU上的结果（c）不同迭代次数的Graviton3结果在（c）中，LL-SC运行以彩色绘制，而CAS运行以黑色绘制（所有CAS线彼此重叠）;此外，仅显示整数核的结果，因为双核的结果相同。注释显示加速（最慢/最快）。可以引入短CAS循环。在[13]中，作者发现LL-SC指令在单线程场景中优于鲲鹏920 CPU上的HMCS锁的CAS [ 3，10 ]。最后，在[4]中，作者利用原子计数器研究了LL-SC和ldadd指令的性能。 我们的基准（如下所述）与他们的类似。3基准说明为了评估CAS和LL-SC指令的性能，我们开发了一组微基准测试，其中线程并发地增加共享计数器，利用CAS操作（用CAS或LL-SC指令实现）以线程安全的方式执行递增。使用浮点计数器和浮点（双）计数器来演示CAS操作的延迟，即. 加载和相关CAS/存储条件指令之间的时间会影响性能（例如，在A64 FX上，整数计数器意味着6个周期的CAS延迟，而双计数器意味着38-41个周期的延迟 内核是用as-socket编写的，以避免编译器可能引入的差异。 除非另有说明，每个内核每个线程运行100，000次增量，我们报告每个线程执行增量所花费的平均时间。4实验结果图 1（a-b）我们比较了CAS和LL-SC策略在TX 2和A64FX CPU上的性能。如图所示，在TX2上，每个线程执行增量所花费的平均时间随着线程数的增加而近似二次方地增加，直到32个线程，然后由于NUMA域的交叉而略微下降（所使用的系统具有两个32核TX2处理器，每个处理器对应于一个NUMA域）。这种二次减速也出现在A64FX上，CAS指令用于高延迟CAS操作，如双内核所向二次型的过渡当加载和相关CAS指令之间的时间超过39个时钟周期时，A64FX会发生减速（由于空间限制，此处未显示这些结果）。此外，图表还显示，对于任何计数器类型，LL-SC在TX2上比CAS快2-3，并且对于双计数器，可以在A64FX上带来超过20的加速比。这是因为，与CAS不同，LL-SC不会对高延迟CAS操作表现出二次减速。图1（c）我们比较了CAS和LL-SC在Graviton 3上的性能该图显示，当在Graviton 3上使用LL-SC时，每次成功操作的平均时间随着操作次数的增加而增加。实际上，这意味着在64个线程的情况下，执行1，000，000个操作时的平均每个操作 时间比执行1，000个操作时的平均时间高出近10。 这种效果在A64FX或TX2上不会出现，在Graviton3上的CAS指令也不会出现。然而，对于低操作计数（低于100，000），LL-SC可以比Graviton 3上的CAS快得多例如，在1，000次迭代时，LL-SC在所有线程计数上都比CAS快大约1.3 倍。因此，在不期望线程在长时间段内重复争用相同的存储器位置的情况下，LL-SC应该是优选的（在已经达到多次失败的LL-SC尝试之后，可能回退到 CAS指令致谢这项工作使用了由GW 4和英国气象局运营并由EPSRC（EP/P020224/1）资助的Isambard UK National Tier-2HPC 服 务 （ http ： //gw4.ac.uk/isambard/ ） ， 以 及 作 为Catalyst UK计划的一部分提供给爱丁堡大学超级计算中心EPCC的HPE Apollo 70系统Fulhame，该计划与HPE、Arm和SUSE合作，旨在加速英国采用基于Arm的超级计算机。（3x2x3x1.2xTX2（CAS）A64FX（CAS）TX2（LL-SC）A64FX（LL-SC）μsec /线程/增量421AArch64 Atomics：它们可能会损害你的表现吗？PPoPP引用[1] 维克多·亚历山德罗尼2016年。并发访问共享数据。 共享内存应用程序设计。摩根·考夫曼波士顿101https://doi.org/10.1016/B978-0-12-803761-4.00005-8[2] Arm Limited.2022年同步基准。htt ps ：//github .com/ARM-software/synchronization-benchmarks[3] Milind Chabbi ， Michael Fagan ， and John Mellor-Crummey.2015年。适用于多级NUMA系统的高性能锁。第20届ACM SIGPLANSymposium on Principles and Practice of Parallel Programming（ ACM SIGPLAN 并 行 编 程 原 理 与 实 践 研 讨 会 ） ACM ， SanFrancisco CA USA，215https：//doi.org/10.1145/2688500.2688503[4] 吉姆·考尼2021. AArch64中的原子https://cpufun.substack.com/p/atomics-in-aarch64[5] 都铎·大卫、拉希德·格拉维和瓦西里奥斯·特里戈纳基斯。2013年。 你一直想知道但又不敢问的关于同步的每一件事。第24届ACM操作系统原 理 研 讨 会 论 文 集 。 ACM ， 宾 夕 法 尼 亚 州 法 明 顿 ，33https://doi.org/10.1145/2517349.2522714[6] 大卫·戴斯丹尼·亨德勒和伊利亚·米尔斯基2013年。 轻量级竞争管理，用于高效的比较和交换操作。在Euro-Par 2013并行处理中，David Hutchison，Takeo Kanade，Josef Kittler，Jon M. 放大图片作者：John C.放大图片作者：Michael，C.潘杜·兰根，伯恩哈德·斯特芬，马杜·苏丹，德米特里·特佐普洛斯，道格·泰格，摩西·Y。Vardi，Gerhard Weikum，Felix Wolf，Bernd Mohr，and Dieteran Mey.第8097卷。Springer Berlin Heidelberg，柏林，海德堡，595-606. https://doi.org/10.1007/978-3-642-40047-6_60[7] Maurice Herlihy，Nir Saught，Victor Luchangco，and MichaelSpear.2021. 多 处 理 器 编 程 的 艺 术 （ 第 二 版 ） 。 MorganKaufmann，Cambridge，MA.[8] 迈克尔·克莱姆和吉姆·考尼。2021. 6互斥和原子性。高性能并行运 行 时 ： 设 计 与 实 现 。 De Gruyter Oldenbourg ， Berlin ，Boston，146https：//doi.org/10.1515/9783110632729-006[9] 达科·马克雷尚斯基，贾斯汀·莱万多斯基，瑞安·斯图茨曼.2015年。锁定，交换或删除：硬件transmitted内存和无锁索引的相互作用VLDB捐赠基金的会议记录8，11（2015年7月），1298-1309。https://doi.org/10.14778/2809974.2809990[10] John M.作者声明：Michael L.Scott. 一九九一年共享内存多处理器上的可扩展同步算法 ACMTransactions on Computer Systems 9，1（2010年2月）1991），21https：//doi. 103727.103729[11] 马吉德·M迈克尔和迈克尔L.Scott. 一九九六年。简单、快速、实用的非阻塞和阻塞并发排队算法。第十五届ACM分布式计算原理研讨会论文集 ACM出版社，费城，宾夕法尼亚州，美国，267-275。https://doi.org/10.1145/248052.248106[12] 亚当·莫里森和耶胡达·阿菲克2013年。适用于X86处理器的快速并发处理器 第18届ACM SIGPLAN Symposiumon Principles and Practiceof Parallel Programming（PPoPP）ACM出版社，深圳，中国，103.https://doi.org/10.1145/2442516.2442527[13] JonasOberhauser 、 Lilith Oberhauser 、 Antonio Paolillo 、 DiogoBehrens、Ming Fu和Viktor Vafeiadis。2021年为Arm服务器优化HMCS锁 在Networked Systems ，Karima Echiffel和Roland Meyer（编辑）。卷12754 施普林格国际出版社，查姆，240-260。 https://doi.org/10.1007/978-3-030-91014-3_17[14] 维克多·索里亚·帕多斯2022年基于ARM架构的原子存储器操作的表征和建模。硕士加泰罗尼亚理 工 大 学 。 https ： //upcommons.upc.edu/handle/2117/363728[15] Christians Sakalis ， Carl Leonardsson ， Stefanos Kaxiras ， andAlberto Ros. 2016. Splash-3：一个正确同步的当代研究基准套件。2016年系统和软件性能分析（ISPASS）。IEEE，乌普萨拉，瑞典，101-111。https://doi.org/10.1109/ISPASS.2016.7482078[16] Hermann Schweizer ， Maciej Besta ， and Torsten Hoefler.2015年。 评估现代体系结构上原子操作的成本。2015年并行架构与编译国际会议（PACT）。IEEE，San Francisco，CA，USA，445-456。https：//doi.org/10.1109/PACT.2015.24[17] 吴汉成和Michela Becchi。2020年。评估英特尔至强融核上的线程粗化和低成本同步在2020年IEEE国际并行和分布式处理研讨会（ IPDPS ） 。 IEEE ， New Orleans ， LA ， USA ， 1018-1029 。https://doi.org/10.1109/IPDP 47924.2020.00108