AMD EPYC – STREAM, HPL, InfiniBand 및 WRF 성능 연구

---

요약

HPC 및 AI Innovation Lab에는 Mellanox EDR InfiniBand와 상호 연결된 32개의 AMD EPYC 기반 시스템이 포함된 새로운 클러스터가 있습니다. 저희는 변함없이 최신 클러스터에 대한 성능 평가를 수행하고 있으며 결과를 공유하고자 합니다. 이 블로그에서는 STREAM, HPL, InfiniBand 마이크로벤치마크 성능(레이턴시 및 대역폭)의 메모리 대역폭 결과와 벤치마크 데이터 세트의 WRF 결과를 다룹니다.

우리는 EPYC의 실제 HPC 애플리케이션 성능에 관심을 갖고 있습니다. EPYC에서 데이터 세트를 사용하시려면 Dell 어카운트 팀에 문의하여 Innovation Lab에 액세스하십시오.
 

---

AMD EPYC 아키텍처

AMD EPYC 프로세서는 8개의 메모리 채널, 소켓당 최대 16개의 DIMM(Dual In-line Memory Module), 채널당 2개의 DIMM, 소켓당 최대 32개의 코어를 지원합니다. 또한 AMD CPU가 장착된 플랫폼은 GPU 및 NVMe 드라이브와 같은 주변 기기에 대해 최대 128개의 PCI-E 레인을 제공합니다.
CPU 자체는 4개의 다이로 조립된 멀티 칩 모듈입니다. 각 다이에는 최대 8개의 Zen 코어, 2개의 DDR4 메모리 채널 및 32개의 IO 레인이 포함되어 있습니다. 다이의 Zen 코어는 코어 컴플렉스라고 하는 4개의 코어 그룹을 2개 그룹으로 배열하여 L3 캐시를 공유합니다. 소켓 내에서 4개의 다이는 모두 인피니티 패브릭이라고 하는 일관된 상호 연결을 통해 교차 연결됩니다. 그림 1과 같습니다.


그림 1 - EPYC 소켓 레이아웃 CCX는 L3 캐시를 공유하는 최대 4개의 코어로 구성된 코어 컴플렉스입니다. M*는 메모리 채널로 각 다이에서 처리하는 2개의 채널입니다. P* 및 G*는 IO 레인입니다. ∞는 인피니티 패브릭입니다.



단일 소켓 시스템에서 각 다이는 그림 1처럼 P* 및 G* IO 레인을 사용하여 최대 32개의 PCI-E 레인을 제공합니다. 그림 2와 같이 소켓에는 총 128개의 PCI-E 레인이 있습니다. CPU를 2S(Two-Socket) 구성에서 사용할 경우, 각 다이의 IO 레인 절반은 인피니티 패브릭으로 구성된 G* IO 레인을 사용하여 다른 소켓의 다이 중 하나에 연결하는 데 사용됩니다. 그러면 소켓에는 총 64개의 PCI-E 레인을 위한 P* IO 레인이 남으므로 플랫폼용 PCI-E 레인은 여전히 128개입니다. 그림 3과 같습니다.


그림 2 - EPYC 1S PCI-E 레인




그림 3 - EPYC 2S 레이아웃




그림 3 - EPYC 2S 레이아웃

 

---

STREAM 벤치마크 성능

EPYC를 평가하는 첫 번째 단계로, STREAM 벤치마크를 사용하여 플랫폼의 메모리 대역폭 용량을 측정했습니다. 이러한 테스트는 2400MT/s에서 듀얼 AMD EPYC 7601 프로세서(32c, 2.2GHz), 16*16GB DIMM을 사용하는 Dell EMC PowerEdge R7425 서버에서 Red Hat® Enterprise Linux® 7.5를 실행하여 수행되었습니다.

EPYC의 NUMA(Non-Uniform Memory Access)는 "Memory Interleaving"이라고 하는 BIOS 옵션으로 제어할 수 있으며 numactl 및 lstopo와 같은 Linux 유틸리티를 사용하여 매핑할 수 있습니다.

기본 메모리 인터리빙 옵션은 "Memory Channel Interleaving"입니다. 이 모드에서는 각 다이의 두 채널이 인터리브됩니다. 이는 소켓당 4개의 NUMA 노드와 2S 시스템의 운영 체제에 8개의 NUMA 노드가 있음을 나타냅니다.

"Memory Die Interleaving"은 소켓의 4개 다이 전체에 걸쳐 메모리(예: 8개의 메모리 채널)가 인터리브되는 옵션입니다. 이는 소켓당 1개의 NUMA 노드와 2S 시스템에 2개의 NUMA 노드가 있음을 나타냅니다.

"Memory Socket Interleaving"은 2S 플랫폼에서 1개의 NUMA 노드를 제공하는 2개의 소켓에 메모리를 인터리브합니다. 이것은 NUMA 비활성화에 해당합니다.    

"Memory Channel Interleaving"의 기본 구성을 사용하는 경우, 각 소켓에 4개의 다이가 있고, 각 다이는 2개의 메모리 채널을 제공하며, BIOS는 2S 플랫폼에 8개의 NUMA 노드가 있음을 나타냅니다. 그림 4의 샘플 numactl 출력은 2S 플랫폼에 이러한 8개의 NUMA 노드가 있고, 다이당 1개의 NUMA 노드가 있음을 나타냅니다.


그림 4 - 2S EPYC의 numactl 출력


물리적으로 그림 4에 강조 표시된 것처럼, 플랫폼에서 NUMA 노드 자체까지(빨간색 거리 "10"), 동일한 다이를 공유하는 3개 노드까지(파란색 거리 "16"), 인피니티 패브릭 링크를 통해 직접 연결된 다른 소켓의 노드까지(녹색 거리 "22"), 2개 소켓 사이의 인피니티 패브릭과 내부 인피니티 패브릭 링크를 사용하는 2개의 홉을 통해 액세스하는 원격 소켓의 다른 3개 노드까지(검은색 거리 "28") 4개의 NUMA 거리가 있습니다.

일부 BIOS 구현 및 버전은 이 물리적 레이아웃을 단순화하고 운영 체제에 대한 3개의 NUMA 거리만 나타낼 수 있습니다. 이러한 단순화에는 NUMA 노드 0(예와 마찬가지)과 NUMA 노드 4, 5, 6, 7 사이의 거리 차이를 NUMA 노드 0에서 등거리로 NUMA 노드 4, 5, 6, 7를 표시하는 것이 포함됩니다. 이러한 구현은 그림 5에 나와 있습니다. NUMA 레이아웃은 PowerEdge R7425 BIOS의 다음 릴리스에서 조정 가능한 옵션이 됩니다. NUMA 노드 거리를 단순화하면 코어의 실제 물리적 레이아웃이 변경되지 않으며, 주로 OS 스케줄러의 이점을 얻을 수 있습니다. NUMA를 인식하는 HPC 및 MPI 작업의 경우 이러한 다양한 표시는 중요하지 않습니다.


그림 5 - NUMA 거리를 단순화한 2S EPYC의 numactl 출력


2소켓 플랫폼에 있는 8개의 NUMA 노드 외에 그림 4 및 그림 5에는 각 NUMA 노드와 연결된 메모리와 코어도 표시됩니다. 각 NUMA 노드에는 2개의 16GB DIMM(서버에 16개의 DIMM, 소켓당 8개, 채널당 1개의 DIMM)의 32GB 메모리가 있습니다. 각 NUMA 노드에는 로컬 다이의 8개 코어가 포함되어 있습니다. Dell EMC 플랫폼의 코어 열거는 라운드 로빈 방식으로, 먼저 모든 NUMA 노드를 거쳐 각 NUMA 노드를 채웁니다.

또한 lstopo 출력을 사용하여 코어 컴플렉스를 구성하는 4개의 코어 세트를 명확하게 표시할 수 있습니다. 이는 L3 캐시를 공유하는 다이의 4개 코어입니다. 예를 들어, 그림 6에서는 NUMA 노드 0에 8개의 코어가 있고 이 NUMA 노드에서 코어 0, 16, 32, 48이 L3 캐시를 공유하고 코어 8, 24, 40, 56이 L3 캐시를 공유하고 있는 것을 보여줍니다.


그림 6 - 2S EPYC의 lstopo 출력


그림 7 - AMD EPYC 플랫폼 메모리 대역폭

이 NUMA 레이아웃 정보를 기억한 상태에서 메모리 대역폭에 대한 STREAM Triad 벤치마크 결과가 그림 7에서 "Memory Channel Interleaving"으로 설정된 BIOS로 표시됩니다. 이 테스트 베드에서 사용된 16GB 2667MT/s 듀얼 랭크 메모리 모듈은 EPYC에서 2400MT/s로 작동합니다. 그림 7의 첫 번째 막대 집합은 코어가 모두 사용되면 2S 플랫폼의 메모리 대역폭이 244GB/s로 코어 절반이 사용되면 255.5Gb/s로 표시됩니다. 두 번째 데이터 포인트는 단일 소켓의 메모리 대역폭이며, 이는 전체 2S 플랫폼의 절반 정도로 예상됩니다. 세 번째 데이터 포인트는 개별 다이인 NUMA 노드의 메모리 대역폭을 측정합니다. 각 소켓에는 4개의 다이가 있고 다이의 대역폭은 소켓의 ¼번째 다이에 관한 것입니다. 다이에는 2개의 코어 컴플렉스가 있으며 1개의 코어 컴플렉스에서만 코어를 사용할 경우 최대 30GB/s의 용량이 제공됩니다. 다이의 두 코어 컴플렉스 모두에서 코어를 사용하면 다이의 전체 대역폭은 최대 32GB/s에 달성할 수 있습니다.

2S 플랫폼 메모리 대역폭은 240-260GB/s에 불과하며 그 결과 플랫폼의 소켓당 메모리 채널은 8개입니다. 더 나아가 단일 코어는 애플리케이션의 단일 스레드 부분에 적합한 로컬 메모리에 최대 24.5GB/s의 메모리 대역폭을 제공할 수 있습니다.

NUMA 레이아웃이 원격 메모리 액세스에 미치는 영향을 살펴보면 그림 8은 코어 액세스 메모리가 동일한 NUMA 도메인에 있지 않을 경우 상대적 메모리 대역폭을 플로팅합니다. 동일한 소켓의 메모리에 액세스하는 속도는 30% 이하, 다른 소켓의 메모리에 액세스하는 속도는 65% 이하입니다. STREAM Triad를 사용하면 한 번의 홉(노드 6, 소켓 간 인피니티 패브릭 1개) 또는 두 번의 홉(노드 4, 5, 7 - 소켓 간 인피니티 패브릭 홉 1개 + 로컬 인피니티 패브릭 홉 1개)에 대한 원격 소켓의 메모리에 액세스할 때 메모리 대역폭에 측정 가능한 영향이 없는 것으로 보입니다. 메모리 대역폭에 민감한 애플리케이션의 경우, 동일한 소켓 내에서도 성능 면에서 우수한 메모리 위치가 중요합니다.


그림 8 - 원격 메모리 액세스의 영향
 

---

HPL 벤치마크 성능

다음으로, HPL 벤치마크를 기준으로 EPYC의 연산 능력을 측정했습니다. EPYC는 AVX 지침 및 성능 8FLOP/사이클을 지원할 수 있습니다. 플랫폼에서는 Open MPI와 BLIS Linear Algebra 라이브러리를 사용하여 HPL을 실행했습니다.

테스트 시스템의 이론적 성능(이중 EPYC 7601 프로세서)은 64코어 * 8FLOP/사이클 * 2.2GHz 클록 주파수로 1126GFLOP을 제공합니다. 1133 GLOPS를 측정했으며 효율성은 100.6%입니다.

또한 EPYC 7551(32c, 2.0GHz), EPYC 7351(16c, 2.4GHz) 및 EPYC 7351P(1S, 16c, 2.4GHz)에서 HPL을 실행했습니다. 이 테스트에서 측정된 HPL 성능은 이론적인 성능의 102-106%였습니다.

EPYC는 HPL 테스트 기간 동안 기본 주파수를 터보 주파수 이상으로 유지할 수 있기 때문에 효율성이 100% 이상입니다.
 

---

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

HCA에 가장 가까운 NUMA 노드에 MPI 프로세스를 고정하는 데 주의를 기울였습니다. 이 정보는 lstopo 출력에서 제공되며, 우리의 경우는 NUMA 노드 6이었습니다. 레이턴시 테스트는 OpenMPI와 HPC-X를 모두 사용하여 수행되었습니다. OpenMPI 및 MXM 가속을 사용하여 1.17µs의 레이턴시를 측정했고 OpenMPI 및 UCX를 사용하여 1.10µs의 레이턴시를 측정했습니다. HPC-X로 얻은 레이턴시 결과는 여기에 나와 있습니다.

그림 9에서 C-상태가 활성화된 상태에서 EPYC 프로세서의 레이턴시는 1.07µs이며 C-상태가 비활성화된 경우와 비교했을 때 C-상태가 활성화된 상태에서 모든 메시지 크기에 대한 레이턴시는 ~2~9% 더 우수합니다. C-상태가 활성화된 경우 활성 코어에서 더 높은 터보 주파수가 허용되는 더 깊은 C-상태에 유휴 코어가 있게 되므로 레이턴시가 줄어듭니다.

대역폭 결과는 그림 10에 나와 있습니다. 우리는 12.4GB/s 단방향 대역폭 및 24.7GB/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

 

Table 2 - osu_mbw_mr 결과 – 단일 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 노드에 있는 8개 코어를 모두 사용하여 개별 NUMA 노드 간에 달성한 대역폭과 메시지 속도를 파악하는 것입니다. 이 테스트의 결과는 표 2에 나와 있습니다. 테스트 구성에서 성능 프로필을 사용했습니다(C-상태 비활성화 및 터보 활성화).

결과에 따르면 InfiniBand HCA(NUMA 노드 6)에 연결된 NUMA 노드에서 프로세스가 실행 중인 경우 총 대역폭은 12.3GB/s입니다. HCA(소켓 1)와 동일한 소켓에 있는 다른 3개의 다른 NUMA 노드 중 하나에서 프로세스가 실행 중인 경우, 총 대역폭은 약 12.1GB/s입니다. HCA에 원격으로 연결되는 소켓의 NUMA 노드에서 프로세스가 실행되는 경우 총 대역폭은 최대 6.8GB/s로 떨어집니다.

표 3에 표시된 다음 결과 집합은 개별 소켓 간의 단방향 대역폭을 보여줍니다. 이 테스트를 위해 소켓에서 사용 가능한 32개의 코어가 모두 사용되었습니다. HCA의 로컬 소켓에서 실행 시 5.1GB/s, HCA의 원격 소켓에서 실행 시 2.4GB/s가 측정되었습니다. 테스트 서버의 64개 코어를 모두 사용하여 서버당 64개의 프로세스 실행 시 3.0GB/s가 측정되었습니다.

이 마지막 결과를 다시 확인하기 위해 각 NUMA 노드에서 2개의 프로세스를 실행하는 두 소켓 모두에서 8개의 NUMA 노드를 모두 사용하여 테스트했으며, 서버당 총 16개의 프로세스를 실행했습니다. 이 레이아웃에서는 2.9GB/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노드 시스템에서도 몇 가지 테스트를 수행했습니다. 모든 서버는 2400MT/s에서 실행되는 16GB*16RDIMM을 가지고 있으며 Mellanox EDR InfiniBand와 상호 연결되었습니다.


그림 12 - WRF conus 12km, 단일 노드

WRF v3.8.1 및 v3.9.1을 사용하여 conus 12km 및 conus 2.5km 데이터 세트를 테스트했습니다. 인텔 컴파일러를 사용하여 WRF 및 netcdf를 컴파일했으며 인텔 MPI로 실행했습니다. OpenMP의 dmpar 및 dm+sm 구성 옵션을 모두 사용하여 서로 다른 프로세스 및 바둑판식 배열을 시도했습니다.

WRF에 대한 다른 컴파일러 튜닝 옵션을 결정하기 위해 AMD와 협력하고 있습니다.

WRF v3.8.1과 v3.9.1 사이에서 측정된 성능 차이는 없었습니다. dmpar 및 dm+sm과 비교할 때, 프로세스 및 바둑판식 배열을 신중하게 조합한 결과 거의 동일한 성능을 얻을 수 있었습니다. 그림 12와 같습니다.


그림 13 - WRF conus 12km, 클러스터 테스트


그림 14 - WRF conus 2.5km, 클러스터 테스트

클러스터 수준 테스트는 WRV v3.8.1 및 모든 코어 및 실행당 8개의 타일을 사용하는 dmpar 구성을 사용하여 수행되었습니다.

conus 12km는 EPYC에서 8개 노드, 512개 코어 후에 안정 상태를 유지하는 더 작은 데이터 세트 및 성능입니다. 그림 13과 같습니다. EPYC 7551과 EPYC 7601은 모두 32코어 프로세서이며, 7601 기본 클록 주파수와 모든 코어 터보 주파수는 7551보다 각각 10%, 6% 빠릅니다. WRF conus 12km 테스트에서 EPYC 7601 시스템의 성능은 1, 2 및 4노드 테스트에서 7551보다 3% 더 빨랐습니다.

conus 2.5km는 더 큰 벤치마크 데이터 세트이며, EPYC 시스템에 비해 최대 8개 노드(512개 코어)까지 성능이 크게 증가했다가 하락하기 시작합니다. conus 2.5km를 사용하면 그림 14와 같이 EPYC 7601 시스템이 1, 2, 4노드 테스트에서 EPYC 7551보다 2-3% 더 빠르게 수행됩니다.

 

---

결론 및 다음 단계

EPYC는 소켓당 우수한 메모리 대역폭과 코어 밀도를 제공합니다. HPC의 관점에서 볼 때, 사용 가능한 메모리 대역폭과 CPU 코어를 사용하여 EPYC 아키텍처의 장점을 최대한 활용할 수 있는 애플리케이션이라고 기대합니다. 현재 EPYC는 AVX512 또는 AVX2를 단일 사이클로 지원하지 않으므로 벡터화가 심하고 AVX2 또는 AVX512를 효율적으로 사용할 수 있는 코드가 EPYC에 적합하지 않을 수 있습니다.

여러 개의 NVMe 드라이브를 사용할 수 있는 사용 사례도 EPYC의 PCI-E 레인 수로 인해 직접 연결된 NVMe의 이점을 얻을 수 있습니다.

다음 단계에는 추가 HPC 애플리케이션을 사용한 추가 성능 테스트가 포함됩니다.