AMD EPYC — STREAM、HPL、InfiniBand 和 WRF 性能研究

---

摘要

HPC 和 AI 创新实验室拥有一个新的群集，后者具有与 Mellanox EDR InfiniBand 互连的 32 个基于 AMD EPYC 的系统。跟往常一样，我们正在对最新的群集进行性能评估，并且想分享结果。此博客涵盖了 STREAM、HPL、InfiniBand 对延迟和带宽性能进行微基准测试所得出的内存带宽结果以及来自基准数据集的 WRF 结果。

我们对 EPYC 上的实际 HPC 应用程序性能感兴趣。如果您具有想在 EPYC 上试用的数据集，请与戴尔客户团队联系，以访问创新实验室。
 

---

AMD EPYC 体系结构

AMD EPYC 处理器支持八个内存通道，每个通道具有两个 DIMM，每个插槽最多具有 16 个双列直插式内存模块 (DIMM)，并且每个插槽最多具有 32 个核心。此外，具有 AMD CPU 的平台可为 GPU 和 NVMe 驱动器等外围设备提供多达 128 个 PCI-E 通道。
CPU 本身是由四个晶片组装而成的多芯片模块。每个晶片包含多达八个 Zen 核心、两个 DDR4 内存通道和 32 个 IO 通道。晶片上的 Zen 核心分为两组，每组四个核心，被称为核心复合体，共享 L3 高速缓存。在插槽中，所有四个晶片都通过名为“Infinity Fabric”的相干互连进行交叉连接。图 1 中显示了这方面内容。


图 1 – EPYC 插槽布局。CCX 是一个核心复合体，由多达 4 个共享 L3 高速缓存的核心组成。M* 是内存通道，每个晶片可处理两个通道。P* 和 G* 是 IO 通道。∞ 是 Infinity Fabric。



在单插槽系统上，每个晶片使用图 1 所示的 P* 和 G* IO 通道，最多可提供 32 个 PCI-E 通道。这将为插槽提供总共 128 个 PCI-E 通道，如图 2 所示。在双插槽 (2S) 配置下使用 CPU 时，通过使用配置为 Infinity Fabric 的 G* IO 通道，每个晶片的一半 IO 通道可用于连接到另一插槽上的其中一个晶片。这给插槽留下总共可提供 64 个 PCI-E 通道的 P* IO 通道，因此，平台仍有 128 个 PCI-E 通道。图 3 中显示了这方面内容


图 2 - EPYC 1S PCI-E 通道




图 3 - EPYC 2S 布局




图 3 - EPYC 2S 布局

 

---

STREAM 基准测试性能

作为评估 EPYC 的第一步，我们使用 STREAM 基准程序测量平台的内存带宽性能。这些测试在 Dell EMC PowerEdge R7425 服务器上进行。此服务器具有双 AMD EPYC 7601 处理器（32c、2.2 GHz）、16 个 16 GB DIMM（传输速率为 2400 MT/s），并运行 Red Hat® Enterprise Linux® 7.5。

EPYC 提供的非统一内存存取 (NUMA) 可以由被称为“内存交叉存取”的 BIOS 选项控制，并使用 Linux 实用程序（例如，numactl 和 lstopo）进行映射。

默认的内存交叉存取选项是“内存通道交叉存取”。在此模式下，将交叉存取每个晶片的两个通道。这在每个插槽可提供四个 NUMA 节点，因此在 2S 系统上，就可向操作系统提供八个 NUMA 节点。

“内存晶片交叉存取”是一个选项，在其中，将交叉存取插槽上所有四个晶片上的内存（即，八个内存通道）。这在每个插槽可提供一个 NUMA 节点，因此在 2S 系统上，就可提供两个 NUMA 节点。

“内存插槽交叉存取”会对两个插槽上的内存进行交叉存取，在 2S 平台上提供一个 NUMA 节点。这相当于禁用了 NUMA。    

使用“内存通道交叉存取”的默认配置时，请记住，每个插槽有四个晶片，每个晶片提供两个内存通道，BIOS 在 2S 平台上提供八个 NUMA 节点。图 4 中的 numactl 输出示例显示 2S 平台上的这八个 NUMA 节点，每个晶片一个 NUMA 节点。


图 4 - 2S EPYC 上的 numactl 输出


如图 4 中突出显示的那样，从物理角度而言，平台上存在四个 NUMA 距离：到 NUMA 节点本身的距离（以红色表示的距离“10”）、到共享同一晶片的三个节点的距离（以蓝色表示的距离“16”）、到通过 Infinity Fabric 链接直接连接的另一个插槽上的节点的距离（以绿色表示的距离“22”）、到使用两个插槽之间的 Infinity Fabric 以及内部 Infinity Fabric 链接经由两个跃点访问的远程插槽上的其他三个节点的距离（以黑色表示的距离“28”）。

一些 BIOS 实现和版本可能会简化此物理布局，并且只向操作系统显示三个 NUMA 距离。这种简化涉及通过将 NUMA 节点 4、5、6、7 显示为与 NUMA 节点 0 等距，来掩盖 NUMA 节点 0（作为示例）和 NUMA 节点 4、5、6、7 之间的距离差。图 5 中显示了此类实现。NUMA 布局将是 PowerEdge R7425 BIOS 下一版本中的可调选项。简化 NUMA 节点距离并不会改变核心的实际物理布局，它主要是为了 OS 调度程序才这么做。对于具有 NUMA 意识的 HPC 和 MPI 作业，这些不同的显示应该是无关紧要的。


图 5 - 具有简化的 NUMA 距离的 2S EPYC 上的 numactl 输出


除了双插槽平台上的 8 个 NUMA 节点之外，图 4 和图 5 还显示了与每个 NUMA 节点相关联的内存和核心。每个 NUMA 节点都有来自两个 16 GB DIMM 的 32 GB 内存（服务器中有 16 个 DIMM，每个插槽有八个 DIMM，每个通道有 1 个 DIMM）。每个 NUMA 节点包含本地晶片的八个核心。Dell EMC 平台上的核心枚举采用循环方式，首先遍历所有 NUMA 节点，然后填充每个 NUMA 节点。

此外，lstopo 输出可用于清楚地显示哪一组核心（共四个）构成核心复合体。这些是晶片上共享 L3 高速缓存的四个核心。例如，图 6 显示 NUMA 节点 0 有八个核心，在这个 NUMA 节点上，核心 0、16、32、48 共享 L3 高速缓存，核心 8、24、40、56 共享 L3 高速缓存。


图 6 - 2S EPYC 上的 lstopo 输出


图 7 - AMD EPYC 平台内存带宽

牢记此 NUMA 布局信息。图 7 显示在 BIOS 设置为“内存通道交叉存取”的情况下 STREAM Triad 对内存带宽的基准测试结果。请注意，此测试台中使用的 16 GB 2667 MT/s 双列内存模块在 EPYC 上以 2400 MT/s 的速率运行。图 7 中的第一组条柱显示：当使用所有核心时，2S 平台的内存带宽为 244 GB/s；当使用一半核心时，2S 平台的内存带宽为 255.5 GB/s。第二个数据点是单插槽的内存带宽，正如预期的那样，该内存带宽大约是整个 2S 平台的一半。第三个数据点测量 NUMA 节点（单个晶片）的内存带宽。请记住，每个插槽有四个晶片，晶片的带宽大约是插槽的 ¼。晶片中存在两个核心复合物，仅使用一个核心复合物上的核心就可以提供约 30GB/s 的内存带宽。如果您使用晶片上两个核心复合体的核心，则晶片的全带宽可达到约 32GB/s。

2S 平台的内存带宽令人印象深刻，达到 240-260GB/s，是平台上每个插槽八个内存通道所实现的成果。更让人钦佩的是，单个核心可以为本地内存提供大约 24.5 GB/s 的内存带宽，对于应用程序的单线程部分来说，这真是太棒了。

查看 NUMA 布局对远程内存访问的影响，图 8 描绘了核心访问不在同一 NUMA 域的内存时的相对内存带宽。对同一插槽的内存的访问大约慢 30%，对另一个插槽的内存的访问大约慢 65%。使用 STREAM Triad，当通过一个跃点（节点 6、插槽之间的 1 个 Infinity Fabric）或两个跃点（节点 4、5、7 - 插槽之间的 1 个 Infinity fabric 跃点 + 1 个本地 Infinity Fabric 跃点）访问远程插槽上的内存时，似乎对内存带宽没有明显的影响。对于内存带宽敏感型应用程序，即使在同一个插槽中，良好的内存局部性对性能也很重要。


图 8 - 远程内存访问的影响
 

---

HPL 基准测试性能

接下来，我们用 HPL 基准程序测量 EPYC 的计算能力。EPYC 可以支持 AVX 指令，并且提供每个周期 8 个 FLOP 的性能。在我们的平台上，我们使用 Open MPI 和 BLIS 线性代数库来运行 HPL。

我们的测试系统（双 EPYC 7601 处理器）的理论性能是 64 个核心 * 8 个 FLOP/周期 * 2.2 GHz 时钟频率（即，能够提供 1126 GFLOPS）。我们测得 1133 GLOPS（效率为 100.6%）。

此外，我们还可以在 EPYC 7551（32c、2.0 GHz）、EPYC 7351（16c、2.4 Ghz）和 EPYC 7351P（1S、16c、2.4GHz）上运行 HPL。在这些测试中，测得的 HPL 性能为理论性能的 102-106%。

效率超过 100% 是因为 EPYC 能够在 HPL 测试期间维持高于基频的睿频。
 

---

InfiniBand 延迟和带宽

然后，我们验证了两台服务器之间的 InfiniBand 延迟和带宽微基准测试结果。表 1 描述了用于这些测试的配置。延迟和带宽结果在图 9 和图 10 中。


  表 1 - InfiniBand 测试台


图 9 – InfiniBand 延迟（在具有交换机的情况下）

运行命令：mpirun -np 2 --allow-run-as-root -host node1,node2 -mca pml ucx -x UCX_NET_DEVICES=mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1  -report-bindings --bind-to core --map-by dist:span -mca rmaps_dist_device mlx5_0 numactl –cpunodebind=6 osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_latency

注意将 MPI 进程固定到最靠近 HCA 的 NUMA 节点。这个信息在 lstopo 输出中提供。在我们的案例中，它是 NUMA 节点 6。在具有 OpenMPI 和 HPC-X 的情况下，运行延迟测试。在具有 OpenMPI 和 MXM 加速的情况下，我们测得的延迟为 1.17µs，在具有 OpenMPI 和 UCX 的情况下，我们测得的延迟为 1.10µs。此处显示在具有 HPC-X 的情况下获得的延迟结果。

从图 9 可以看出，启用 C-states 的 EPYC 处理器上的延迟为 1.07µs，与禁用 C-states 相比，在启用 C-states 的情况下，所有消息大小的延迟大约缩短 2% 至 9%。启用 C-states 将允许空闲核心处于更深的 c-states，使活动核心上的睿频更高，从而减少延迟。

图 10 中显示了带宽结果。我们测得 12.4 GB/s 的单向带宽和 24.7 GB/s 的双向带宽。这些结果与我们对 EDR 的预期一致


图 10 - InfiniBand 带宽

运行命令： 

mpirun -np 2 --allow-run-as-root -host node208,node209 -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --bind-to core -mca rmaps_dist_device mlx5_0 --report-bindings --display-map numactl --cpunodebind=6 osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_bibw

 

表 2 - osu_mbw_mr results – 单个 NUMA 节点
运行命令： 

mpirun -np 16 --allow-run-as-root –host server1,server2 -mca pml ucx -x UCX_NET_DEVICES=mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings --bind-to core -mca rmaps_dist_device mlx5_0 numactl cpunodebind= osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

图 3 和图 6 中描述的 NUMA 布局提示我们检查进程局部性对带宽的影响。对于此测试，我们使用 osu_mbw_mr 基准工具来测量多对进程之间的聚合单向带宽。此测试的目标是使用 NUMA 节点上的所有八个核心确定各个 NUMA 节点之间实现的带宽和消息速率。此测试的结果显示在表 2。测试配置使用了性能配置文件（禁用 C-states，并启用睿频）。

结果表明，当进程在连接到 InfiniBand HCA（NUMA 节点 6）的 NUMA 节点上运行时，聚合带宽为 12.3 GB/s。当进程在与 HCA（插槽 1）在同一个插槽上的其他三个 NUMA 节点中的任何一个节点上运行时，聚合带宽大约也是 12.1 GB/s。当进程在远离 HCA 的插槽中的 NUMA 节点上运行时，聚合带宽下降到大约 6.8 GB/s。

表 3 所示的下一组结果表明各个插槽之间的单向带宽。对于此测试，我们使用了插槽中的所有 32 个可用核心。在 HCA 本地的插槽上运行时，我们测量到 5.1 GB/s；在远离 HCA 的插槽上运行时，我们测量到 2.4 GB/s。当每台服务器运行 64 个进程时，使用测试服务器中的所有 64 个核心，我们测量到 3.0 GB/s。

为了再次检查此最后的结果，我们使用两个插槽上的所有 8 个 NUMA 节点运行测试，其中每个 NUMA 节点运行 2 个进程，每个服务器总共有 16 个进程。在采用此布局的情况下，我们也测量到 2.9 GB/s。

这些结果表明系统的拓扑结构对通信性能有影响。对于具有多个跨服务器通信的进程的“全部对全部”通信模式是重要因素的情况，这很有意义。对于其他应用程序，在多个 NUMA 域上运行进程时测量到的减少的带宽可能不是影响应用程序级别性能的因素。


  表 3 - osu_mbw_br 结果 – 插槽和系统级别
运行命令： 

mpirun -np 64 --allow-run-as-root –rf rankfile -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

 
运行命令：

mpirun -np 128 --allow-run-as-root –rf rankfile -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

 
运行命令： 

mpirun -np 32 --allow-run-as-root –rf rankfile -mca pml ucx -x UCX_NET_DEVICES= mlx5_0:1 -x UCX_TLS=rc_x -mca coll_fca_enable 0 -mca coll_hcoll_enable 0 -mca btl_openib_if_include mlx5_0:1 --report-bindings osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

---

HPL 群集级别性能

随着我们的 InfiniBand 构造性能得到验证，下一个测试是在群集中快速运行 HPL。这些测试在具有双插槽 EPYC 7601 的 16 节点系统上进行。结果在图 11 中，显示 16 个系统上的预期 HPL 可扩展性。


图 11 - 16 台服务器上的 HPL

 

---

WRF 群集级别性能

最后，我们运行 WRF（即，天气预报应用程序）。测试台与之前相同，仍是具有双插槽 EPYC 7601 的 16 节点系统。此外，我们还在具有双插槽 EPYC 7551 的较小的 4 节点系统上执行一些测试。所有服务器都有 16GB*16 RDIMM（以 2400 MT/s 速率运行），并与 Mellanox EDR InfiniBand 互连。


图 12 - WRF conus 12km，单节点

我们使用 WRF v3.8.1 和 v3.9.1，并测试了 conus 12km 和 conus 2.5km 数据集。我们使用 Intel 编译器编译了 WRF 和 netcdf，并与 Intel MPI 一起运行。我们尝试了不同的进程和平铺方案，并使用 dmpar 以及带有 OpenMP 的 dm+sm 配置选项。

我们正在与 AMD 合作，以便为 WRF 确定其他编译器调整选项。

WRF v3.8.1 和 v3.9.1 之间没有测量到性能差异。通过比较 dmpar 和 dm+sm，明智地将进程和平铺方案组合在一起，可以获得大致相同的性能。图 12 中显示了这方面内容。


图 13 - WRF conus 12km，群集测试


图 14 - WRF conus 2.5km，群集测试

使用 WRV v3.8.1 和 dmpar 配置执行群集级别测试，每次运行均使用全部核心和 8 个平铺方案。

Conus 12km 是较小的数据集，在 EPYC 上有 8 个节点、512 个核心后，性能稳定。图 13 中显示了这方面内容。EPYC 7551 和 EPYC 7601 都是 32 核处理器，与 7551 相比，7601 的基本时钟频率和全核睿频分别提高 10% 和 6%。在 WRF conus 12km 测试中，EPYC 7601 系统在 1、2 和 4 节点测试上的性能比 7551 的提高 3%。

Conus 2.5km 是较大的基准数据集，相对于 1 个 EPYC 系统，性能可以扩展到 8 个节点（512 个核心），然后开始下降。在同样也具有 conus 2.5km 的情况下，EPYC 7601 系统在 1、2 和 4 节点测试中的执行速度比 EPYC 7551 的快 2-3%，如图 14 所示。

 

---

结论和后续步骤

EPYC 提供良好的内存带宽和卓越的每插槽核心密度。从 HPC 的角度来看，我们希望那些可以利用可用内存带宽和 CPU 核心的应用程序能够充分利用 EPYC 体系结构。现在的 EPYC 在单个周期内并不支持 AVX512 或 AVX2，因此高度矢量化并且可以高效地使用 AVX2 或 AVX512 的代码可能不是 EPYC 的理想选择。

能够利用多个 NVMe 驱动器的用例也可受益于直接连接的 NVMe，由于 EPYC 上的 PCI-E 通道的数量，这是可能实现的目标。

我们后续的步骤包括使用其他 HPC 应用程序进行更多的性能测试。