AMD Rome benchmark数据到架构特征推导

这几天,拿到了一套最新的AMD Rome主机:EPYC 7742 @1.5GHz x 2; 16根32GB DDR4-3200内存。这是AMD的顶级配置,即Rome平台目前推出的最高频率的全部128个核心(开启HT显示为256个)且全部开启最高速率内存通道。这次就从几个测试数据推导出AMD的架构特征特别是内存方面的架构特征。

老实说,这台机器是远程的主机,我没有办法直接接触到CPU本体,只能找一张网上的图片代替。随着x86平台的设计愈发的复杂,良品率成为一个巨大的挑战,而IA两家在提升良品率的方向上可谓是各显神通:I通过SKL之后引入的mesh互联技术允许成品后直接屏蔽有瑕疵的core,成为低档次的产品(俗称“阉割”);而A则采用了多个小硅片的堆叠互联,这样一旦有成品瑕疵,丢弃的只是这一小片硅片(俗称“众核”)。

从这张图上可以看出,EYPC7742共有1大8小9块硅片互联而成。8块小硅片称为core die,中每个硅片包含8个CPU core ;中间的“大”硅片称为IO die,包含了CPU的通讯和安全部分的功能。当然,作为通讯的部分,内存访问、跨核通讯都包含在IO die里。需要特别指出的是,在IO die里包含了AMD引以为傲的infinity febri(IF)技术,相比Intel的UPI/mesh多层路由打造的网状结构,该技术统一了CPU之间各种的通讯接口,形成了一格类似总线结构的拓扑。IF可以分为数个相连的Scalable Data Fabric (SDF) 和 Scalable Control Fabric (SCF) 分别负责数据和控制信号的处理和转发。

从拓扑结构上讲,这个双插槽的服务器可谓是空前的复杂。为方便更好的理解这“8乘2”的设置,可以直接使用core-2-core latency对比。我经常挂在嘴边“从CPU的纳秒视角来看,光速是很慢的(30cm/ns),而信号传输更慢”。不同的c2c时延即可直接得出各个core之间的物理距离。

EYPC 7742 core-to-core latency

上表列出了从core#16发起的,到所有127个core的时延,单位是ns纳秒。如果你的显示器对比度说得过去的话,应该可以看到大致上可以分为几组(数学意义上的聚类)实验范围:

  • < 60 ns:只有core#16发起给自己的本地,52.7ns作为比较基线。
  • < 70 ns: 即最绿的部分,4个,其实是共享L3缓存的4个core, 只有额外的7~8ns的增加。
  • < 120 ns:32个,参考上面的图片,在IO die同一侧的4个core die。
  • < 130 ns: 64个,同一个socket上所有的core。
  • < 180 ns: 所有的两个socket上所有的core。有一个有趣的现象是core#80~core#96有着最大的时延,恰恰又跟core#16所在的socker0 core 16 是对称的(core#80 = socket 1 core 16)可以理解为这个通讯走了最远的对角线。

总结下:同die 8 ns;同侧 55ns;横跨IO die 75ns;跨socket 120ns。如果你会做减法的话得出来的数值就是对应的通讯时延开销。CPU是1.5GHz,这个数值可以通过x1.5直接转换成cycles,用以计算IPC/CPI这类性能计数中损耗的那一部分。

由于实现方式不同,怎么对比都有失公允,这么说吧:同等类型的测试,Rome架构是远远差于Skylake架构的。

其实在我刚拿到那台机器的时候,惊呆于2个socket居然有8个NUMA node,进BIOS检查了一下,发觉该机器支持每个socket 0,1,2,4 共计4种设置(NPS, NUMA node per socket)。考虑到众核的特点,这种方式也可以理解。该主机为双socket,实际可见的NUMA数量要乘2。

既然有了c2c,那就来个socket-to-socket的时延吧(单位为ns,其中横向第一行为请求发起node,纵向第一列为目标node),把不同配置下8~2个NUMA node s2s贴出来。

不同的色块热度代表了不同的node亲和性。同时数据上可见,NUMA node越多,时延指数增大,可以理解为更大的哈希开销导致的。

另一个点是要注意这里的4NPS揭示了另一个重要信息——单socket包含4个内存控制器(考虑到NUMA的实现方式,最大NUMA node数量和内存控制器数量是一一对应的,况且Rome架构中内存控制器就被命名为unified memory controller)!换算一下,每个socket最大8个内存通道,4个控制器意味着每8个core分享一个双通道DDR-3200内存控制器,数值换算为~42GB/s 。话说后来通过其他测试我发觉这个42GB/s带宽事实上主导了整个IF的设计实现,这里先划个重点。实话说,尽管3200是最高频的DDR4,单如此的分配总有点捉襟见肘的意思。

那就做个简单的内存带宽压力测试好了。分别在全局1,2,4,8,16个core(图中用thread计)上施加内存压力,测量在不同NUMA配置下所能达到的最大内存带宽,后来为8个core的case,有意识的调整了一下core的分布设计了8+case,绘图如下:

由以上数据可见:

  1. 所有的1 core case始终无法超过20GB/s的内存带宽。且随着NUMA node数量减少,需要依赖IF传输的数据量不断增加,导致了2,1 NUMA node时可见带宽下降趋势。
  2. 相比单核心而言,2核心可见带宽明显提升,但继续增加到4或8核心时,提升速度明显下降,此时带宽接近42GB/s。
  3. 对于8 core即8node配置下一个NUMA node中所有的core都参与了内存加压,内存带宽始终无法突破42GB/s。
  4. 8core 和8+core连个case唯一的区别在于对于8NUMA node的模式(蓝色)8+强行指定了内核心分布,压测工具特性决定了跨NUMA访问的带宽将会直接体现为最大内存带宽。而事实上采集到的数据略高于42GB/s,其实是符合本人预期的。另外, 由于case8+的核心分布更优, 在除8NUMA node模式以外,可以更好的利用2个以上的memory controller,就是为什么从整体上来说case 8+的内存性能要明显好于case 8。
  5. 8+与16这两个case的所有读数异常相似,意味着在类似本测试的极端使用情况下,共享同一个memory controller 的16个core中只要有4个core同时发起内存访问就足以使内存带宽饱和。4 core case 和8 core case的情况一致也可以作为一个侧面反映。
  6. 另有几个没有体现在图上的数据,当所有127个core都发起请求时,测得2NUMA nodes模式下最大内存带宽为286GB/s,但相比理论上的380GB/s还有一定距离。而1NUMA node模式下,同等测试只得到144GB/s,而这个值事实上是包含了耗损的4个42GB/s。

    (除此以外,以上的部分数据似乎可以直接拿来计算IF/SDF协议的payload rate 哦!)

尽管Rome拥有纸面上的单核8通道DDR4-3200,但事实上内存控制器的零散化导致了对于大多数情况下的内存带宽并不能直接受益于更多内存通道,甚至导致了单核心内存性能远低于台式机水平。但零散化的优势是更好的资源隔离性,多种灵活的NUMA分割方式最大化了这个优势。

从个人观点上说,Rome这一代的CPU架构的优缺点都体现了云计算时代对服务器CPU的要求!更零散的设计在降低了成本的同时也很好的提升了硅片表面积以便于散热;7nm的工艺更是大幅减低了功耗和发热,这是提升机房计算密度的必由之路。零散的内存控制器,过少的单核内存带宽和同样零散低效的L3 cache(本文中未展开),确实极大的拖累了整体的性能表现,使其在大规模计算和科学计算方面失分不少。但这种特殊的设计思路恰恰极大地满足了云计算所重视的“可合可分”的痛点,完全可以扳回一城。退一步说,事实上当下业界共识是使用各种加速卡、GPU、FPGA/ASIC替代传统上CPU进行的大规模计算,低耦合分布式也成为CPU侧计算的主导思维。Rome确实做了一个主动迎合主流市场需求的妥协。

推荐阅读:
一个测试性能不稳定的问题

经常会通过一些通用的测试工具测

Linux的用户内存上限

首先,提个问题:64bit x

离奇的CPU利用率

接到一个黑盒的case:一套双

DCDC’19-NUMA的优势和陷阱

去年的DCDC,我主要介绍了基

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据