AMD EPYC: estudio de rendimiento en STREAM, HPL, InfiniBand y WRF

---

Resumen

El laboratorio de innovación en IA y HPC tiene un nuevo clúster con 32 sistemas basados en AMD EPYC e interconectados con Mellanox EDR InfiniBand. Como siempre, realizamos evaluaciones de rendimiento en nuestro clúster más reciente y queríamos compartir los resultados. En este blog, se abordan los resultados de ancho de banda de memoria de stream, HPL, rendimiento de microrreflector InfiniBand para latencia y ancho de banda, y los resultados de WRF de sus conjuntos de datos de referencia.

Estamos interesados en el rendimiento de las aplicaciones DE HPC en el mundo real en EPYC. Si tiene conjuntos de datos que desee probar en EPYC, comuníquese con su equipo de cuenta de Dell para acceder al Laboratorio de innovación.
 

---

Arquitectura de AMD EPYC

Los procesadores AMD EPYC admiten ocho canales de memoria, hasta 16 módulos de memoria en línea duales (DIMM) por zócalo con dos DIMM por canal y hasta 32 núcleos por zócalo. Además, una plataforma con CPU AMD proporciona hasta 128 carriles PCI-E para periféricos como GPU y unidades NVMe.
Las MISMAS CPU son módulos de múltiples chips ensamblados a partir de cuatro placas. Cada matriz incluye hasta ocho núcleos Zen, dos canales de memoria DDR4 y 32 carriles de E/S. Los núcleos Zen de una matriz se organizan en dos grupos de cuatro, en el cual cada grupo de cuatro núcleos se denomina un complejo de núcleos, el cual comparte la caché L3. Dentro de un zócalo, las cuatro matrices están conectadas de forma cruzada mediante una interconexión coherente denominada Infinity Fabric. Esto se muestra en la Figura 1.


Ilustración 1: Diseño del conector EPYC. CCX es un complejo de núcleos de hasta 4 núcleos que comparten la caché L3. M* son los canales de memoria, dos canales manejados por cada matriz. P* y G* son carriles de E/S. ∞ es infinity fabric.



En un sistema de socket único, cada matriz proporciona hasta 32 carriles PCI-E mediante los carriles de I/O P* y G*, como se muestra en la Figura 1. Esto proporciona al zócalo un total de 128 carriles PCI-E, como se muestra en la Figura 2. Cuando se utiliza una CPU en una configuración de dos zócalos (2S), se utiliza la mitad de los carriles de E/S de cada matriz para conectarse a una de las matrices en el otro zócalo mediante los carriles de E/S G* configurados como Infinity Fabric. Esto deja al zócalo con los carriles de E/S P* para un total de 64 carriles PCI-E y, por lo tanto, aún quedan 128 carriles PCI-E para la plataforma. Esto se muestra en la Figura 3


Figura 2: Carriles PCI-E EPYC 1SFigura 3: Diseño de




EPYC 2S




Figura 3: diseño de EPYC 2S

 

---

Rendimiento de prueba STREAM

Como primer paso para evaluar EPYC, medimos las funcionalidades de ancho de banda de memoria de la plataforma mediante la prueba STREAM. Estas pruebas se llevaron a cabo en un servidor Dell EMC PowerEdge R7425 con procesadores AMD EPYC 7601 dobles (32c, 2,2 GHz), 16 DIMM de 16 GB a 2400 MT/s, con Red Hat® Enterprise Linux® 7.5.

La presentación de acceso de memoria no uniforme (NUMA) de EPYC se puede controlar mediante una opción del BIOS denominada "Memory Interleaving" (Intercalado de memoria) y se puede asignar mediante utilidades de Linux, como numactl y lstopo.

La opción predeterminada memory interleaving es "Memory Channel Interleaving". En este modo, los dos canales de cada matriz se entrelazan. Esto presenta cuatro nodos NUMA por conector y ocho nodos NUMA al sistema operativo en un sistema 2S

". Memory Die Interleaving" es una opción en la que la memoria de las cuatro placas en un conector, es decir, ocho canales de memoria, se intercala. Esto presenta un nodo NUMA por conector y dos nodos NUMA en un sistema 2S

". Memory Socket Interleaving" intercala la memoria en ambos zócalos, lo que proporciona un nodo NUMA en una plataforma 2S. Esto sería el equivalente de la deshabilitación de NUMA.    

Con la configuración predeterminada de "Memory Channel Interleaving", recuerde que cada zócalo tiene cuatro matrices, cada matriz proporciona dos canales de memoria y el BIOS presenta ocho nodos NUMA en una plataforma 2S. La salida numactl de muestra en la Figura 4 muestra estos ocho nodos NUMA en una plataforma 2S, un nodo NUMA por matriz.


Figura 4: Salida numactl en EPYC


2S Físicamente, hay cuatro distancias de NUMA en la plataforma, como se destaca en la Figura 4: al nodo NUMA en sí (distancia "10" en rojo), a los tres nodos que comparten la misma matriz (distancia "16" en azul), al nodo en el otro conector que está conectado directamente a través de un enlace infinity Fabric (distancia "22" en verde), a los otros tres nodos en el zócalo remoto a los que se accede a través de dos saltos mediante Infinity Fabric entre los dos zócalos más el enlace interno de Infinity Fabric (distancia "28" en negro).

Algunas implementaciones y versiones del BIOS pueden simplificar este diseño físico y presentar solo tres distancias NUMA al sistema operativo. Esta simplificación implica enmascarar la diferencia de distancia entre el nodo NUMA 0 (como ejemplo) y los nodos NUMA 4, 5, 6, 7 presentando los nodos NUMA 4, 5, 6 y 7 como si estuvieran a una distancia equidistante del nodo NUMA 0. Dicha implementación se muestra en la Figura 5. El diseño de NUMA será una opción ajustable en la próxima versión del BIOS de PowerEdge R7425. La simplificación de las distancias del nodo NUMA no cambia el diseño físico real de los núcleos; principalmente se realiza para beneficio del programador del SO. En el caso de los trabajos de HPC y MPI que reconocen NUMA, estas diferentes presentaciones deben ser irrelevantes.


Figura 5: Salida numactl en EPYC 2S con distancias de NUMA simplificadas


Además de los 8 nodos NUMA en una plataforma de dos conectores, la Figura 4 y la Figura 5 también muestran la memoria y los núcleos asociados con cada nodo NUMA. Cada nodo NUMA tiene 32 GB de memoria desde dos módulos DIMM de 16 GB (16 DIMM en el servidor, ocho por zócalo, 1 DIMM por canal). Cada nodo NUMA contiene los ocho núcleos de la matriz local. La enumeración de núcleos en la plataforma de Dell EMC es round-robin, por lo que primero se recorren todos los nodos NUMA y, a continuación, se completa cada nodo NUMA.

Además, la salida de lstopo se puede utilizar para mostrar claramente qué conjunto de cuatro núcleos componen un complejo de núcleos. Estos son los cuatro núcleos en una matriz que comparten la caché L3. Por ejemplo, la Figura 6 muestra que el nodo NUMA 0 tiene ocho núcleos y, en este nodo NUMA, los núcleos 0, 16, 32, 48 comparten la caché L3 y los núcleos 8, 24, 40 y 56 comparten la caché L3.


Figura 6: Salida lstopo en EPYC 2S Figura 7: Ancho de banda de memoria de la plataforma AMD EPYC Teniendo en cuenta esta información de diseño de NUMA, los resultados del parámetro de referencia STREAM Triad para el ancho de banda de


la

memoria se presentan en la Figura 7 con el BIOS configurado en "Intercalado de canal de memoria". Tenga en cuenta que los módulos de memoria dobles de 16 GB y 2667 MT/s que se usan en esta base de pruebas se ejecutan a 2400 MT/s en EPYC. En el primer conjunto de barras en la Figura 7, se muestra que el ancho de banda de la memoria de la plataforma 2S es de 244 GB/s cuando se utilizan todos los núcleos y de 255,5 GB/s cuando se utiliza la mitad de los núcleos. El segundo punto de datos es el ancho de banda de la memoria de un único zócalo, el cual es aproximadamente la mitad de la plataforma 2S completa, según lo esperado. El tercer punto de datos mide el ancho de banda de la memoria de un nodo NUMA en una matriz individual. Recuerde que cada zócalo tiene cuatro matrices y que el ancho de banda de una matriz es aproximadamente 1/4 del conector. Dentro de una matriz, existen dos complejos de núcleo y el uso de solo los núcleos en un complejo de núcleo proporciona aproximadamente 30 GB/s. Cuando se utilizan núcleos en ambos complejos de núcleos en una matriz, se puede lograr el ancho de banda completo de la matriz, alrededor de 32 GB/s.

El ancho de banda de memoria de la plataforma 2S es impresionante, de 240 a 260 GB/s, y es el resultado de los ocho canales de memoria por conector en la plataforma. Aún más, un solo núcleo puede proporcionar aproximadamente 24,5 GB/s de ancho de banda de memoria a la memoria local, lo que es ideal para la parte de subproceso único de las aplicaciones.

Al observar el impacto del diseño de NUMA en el acceso remoto a la memoria, la Figura 8 traza el ancho de banda de memoria relativo cuando los núcleos acceden a la memoria que no está en el mismo dominio numa. El acceso a la memoria en el mismo zócalo es aproximadamente un 30 % más lento, el acceso a la memoria en el otro zócalo es aproximadamente un 65 % más lento. Mediante STREAM Triad, parece que no hay un impacto mesurable en el ancho de banda de la memoria cuando se accede a la memoria en el zócalo remoto a través de un salto (nodo 6: 1 salto Infinity Fabric entre zócalos) o dos saltos (nodo 4, 5, 7: 1 salto Infinity Fabric entre zócalos + 1 salto Infinity Fabric local). Para las aplicaciones sensibles al ancho de banda de memoria, una buena localidad de memoria será importante para el rendimiento incluso dentro del mismo conector.


Figura 8: Impacto del acceso remoto a la memoria
 

---

Rendimiento de prueba HPL

Luego, medimos la capacidad informática de EPYC según lo medido por la prueba HPL. EPYC puede admitir instrucciones AVX y un rendimiento de 8 FLOP por ciclo. En nuestra plataforma, utilizamos Open MPI y las bibliotecas lineales de B CREATIVE para ejecutar HPL.

El rendimiento teórico de nuestro sistema de prueba (procesadores EPYC 7601 dobles) es de 64 núcleos * 8 FLOP/ciclo * frecuencia de reloj de 2,2 GHz, lo que da 1126 GFLOPS. Medimos 1133 GLOPS, que es una eficiencia del 100,6 %.

También ejecutamos HPL en EPYC 7551 (32c, 2,0 GHz), EPYC 7351 (16c, 2,4 GHz) y EPYC 7351P (1S, 16c, 2,4 GHz). En estas pruebas, el rendimiento medido de HPL fue del 102 al 106 % del rendimiento teórico.

La eficiencia es superior al 100 % debido a que EPYC es capaz de mantener frecuencias turbo por encima de la frecuencia base durante la prueba de HPL.
 

---

Latencia y ancho de banda de InfiniBand

Después, verificamos los resultados de la microprueba InfiniBand de latencia y ancho de banda entre dos servidores. La configuración utilizada para estas pruebas se describe en la Tabla 1. Los resultados de latencia y ancho de banda se muestran en la Figura 9 y la Figura 10.


  Tabla 1: Base de pruebas InfiniBand


Ilustración 9: Latencia de InfiniBand, con switch

Ejecute el comando: 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: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 Care se tomó para

fijar el proceso de MPI al nodo NUMA más cercano a HCA. Esta información está disponible en el resultado de lstopo y, en nuestro caso, era el nodo NUMA 6. Las pruebas de latencia se ejecutaron con OpenMPI y HPC-X. Con la aceleración de OpenMPI y MXM, medimos la latencia de 1,17 μs, con OpenMPI y UCX medimos la latencia de 1,10 μs. Aquí se presentan los resultados de latencia obtenidos con HPC-X.

A partir de la Figura 9, la latencia en procesadores EPYC con estados C habilitados es de 1,07 μs y la latencia para todos los tamaños de mensaje es aproximadamente un 2 a 9 % mejor con estados C habilitados en comparación con los estados C deshabilitados. Los estados C habilitados permiten que los núcleos inactivos estén en estados C más profundos, lo que permite frecuencias turbo más altas en los núcleos activos, lo que da como resultado una latencia reducida.

Los resultados del ancho de banda se presentan en la Figura 10. Se midió el ancho de banda unidireccional de 12,4 GB/s y el ancho de banda bidireccional de 24,7 GB/s. Estos resultados son los esperados para EDR


Figura 10:Comando de ejecución del ancho de banda de

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

 

Tabla 2: Resultados de osu_mbw_mrs; nodo de NUMA único
Comando ejecutado: 

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=<numanode number> osu-micro-benchmarks-5.4.3/mpi/pt2pt/osu_mbw_mr

El diseño de NUMA que se describe en la Figura 3 y la Figura 6 nos solicita comprobar el impacto de la localidad de procesamiento en el ancho de banda. Para esta evaluación, usamos la prueba osu_mbw_mr, la cual mide el ancho de banda unidireccional de agregación entre varios pares de procesos. El objetivo de esta prueba es determinar el ancho de banda logrado y la tasa de mensajes entre los nodos NUMA individuales usando los ocho núcleos en el nodo NUMA. Los resultados de esta prueba se presentan en la Tabla 2. La configuración de prueba utilizó el perfil de rendimiento (los estados C están deshabilitados y Turbo activado).

Los resultados nos muestran que, cuando se ejecutan procesos en el nodo NUMA que está conectado a InfiniBand HCA (nodo NUMA 6), el ancho de banda agregado es de 12,3 GB/s. Cuando se ejecutan procesos en alguno de los otros tres nodos NUMA que se encuentran en el mismo zócalo que la HCA (zócalo 1), el ancho de banda agregado es aproximadamente el mismo: alrededor de 12,1 GB/s. Cuando se ejecutan procesos en los nodos NUMA en el conector que es remoto para HCA, el ancho de banda agregado disminuye a aproximadamente 6,8 GB/s.

El siguiente conjunto de resultados que se muestra en la Tabla 3 muestra el ancho de banda unidireccional entre zócalos individuales. Para esta prueba, se utilizaron los 32 núcleos disponibles en el zócalo. Medimos 5,1 GB/s cuando se ejecutó en el zócalo más cercano a la HCA y 2,4 GB/s cuando se ejecutó en el zócalo más alejado de la HCA. Mediante el uso de los 64 núcleos en nuestros servidores de prueba, medimos 3,0 GB/s cuando se ejecutaron 64 procesos por servidor.

Para comprobar este último resultado, se ejecutó una prueba con los 8 nodos NUMA en ambos zócalos y cada nodo NUMA ejecutó 2 procesos, lo que dio un total de 16 procesos por servidor. Con este diseño, también medimos 2,9 GB/s.

Estos resultados indican que la topología del sistema tiene un efecto en el rendimiento de la comunicación. Esto es importante en aquellos casos en los que un patrón de comunicación total con varios procesos que se comunican entre los servidores es un factor importante. Para otras aplicaciones, es posible que el ancho de banda reducido que se midió cuando se ejecutan procesos en varios dominios NUMA no sea un factor que influya en el rendimiento a nivel de aplicaciones.


  Tabla 3: Resultados de osu_mbw_br: zócalos y nivel del sistema
Comando ejecutado: 

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

 
Comando ejecutado:

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

 
Comando ejecutado: 

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

---

Rendimiento de HPL a nivel de clúster

Con nuestra red Fabric InfiniBand de rendimiento validado, en la siguiente prueba se buscaba ejecutar HPL rápidamente en todo el clúster. Estas pruebas se realizaron en un sistema de 16 nodos con dos zócalos EPYC 7601. Los resultados se encuentran en la figura 11 y muestran la escalabilidad de HPL esperada en los 16 sistemas.


Figura 11: HPL en 16 servidores

 

---

Rendimiento de WRF a nivel de clúster

Por último, ejecutamos WRF, una aplicación de pronóstico meteorológico. La base de pruebas era la misma que antes, un sistema de 16 nodos con dos zócalos EPYC 7601. Además, también hicimos algunas pruebas en un sistema más pequeño de 4 nodos con dos zócalos EPYC 7551. Todos los servidores tenían 16 GB*16 RDIMM que se ejecutaban a 2400 MT/s y estaban interconectados con Mellanox EDR InfiniBand.


Figura 12: WRF conus 12km, nodo

único Utilizamos WRF v3.8.1 y v3.9.1, y probamos los conjuntos de datos conus 12km y conus 2.5km. Hemos compilado WRF y netcdf mediante compiladores Intel y se ejecutaron con Intel MPI. Probamos diferentes esquemas de proceso y mosaico, utilizando tanto dmpar como la opción de configuración dm+sm con OpenMP.

Estamos trabajando con AMD para determinar otras opciones de ajuste de compilador para WRF.

No se midió ninguna diferencia de rendimiento entre WRF v3.8.1 y v3.9.1. La comparación de dmpar y dm+sm, una combinación sensata de procesos y mosaicos, dio como resultado casi el mismo rendimiento. Esto se muestra en la Figura 12.


Figura 13: WRF conus 12km, pruebas


de clúster Figura 14: WRF conus 2.5km, pruebas

de clúster Las pruebas a nivel de clúster se llevaron a cabo con WRV v3.8.1 y la configuración dmpar con todos los núcleos y 8 mosaicos por ejecución.

Conus 12km es un conjunto de datos más pequeño y el rendimiento se estanca después de 8 nodos, 512 núcleos en EPYC. Esto se muestra en la Figura 13. EPYC 7551 y EPYC 7601 son procesadores de 32 núcleos en los que la frecuencia de reloj base y la frecuencia de Turbo con todos los núcleos en el 7601 eran respectivamente un 10 % y un 6 % más rápido que en el 7551. En las pruebas wrf conus 12km, el rendimiento del sistema EPYC 7601 fue un 3 % más rápido que el 7551 en pruebas de 1, 2 y 4 nodos.

Conus 2.5km es un conjunto de datos de parámetro de referencia más grande, y en relación con un sistema EPYC, el rendimiento escala bien hasta 8 nodos (512 núcleos) y luego comienza a disminuir. Cuando “conus 2.5km” está en ambos sistemas, el sistema EPYC 7601 tiene un desempeño entre un 2 y un 3 % más rápido que el EPYC 7551 en las pruebas de 1, 2 y 4 nodos, como se muestra en la Figura 14.

 

---

Conclusión y próximos pasos

EPYC proporciona buenos niveles de ancho de banda de memoria y densidad de núcleo por zócalo. Desde un punto de vista de HPC, esperamos que las aplicaciones puedan utilizar el ancho de banda de memoria disponible y los núcleos de CPU puedan aprovechar al máximo la arquitectura de EPYC. EPYC actualmente no es compatible con AVX512 o AVX2 en un solo ciclo, por lo que es posible que los códigos altamente vectorizados y que puedan utilizar AVX2 o AVX512 de manera eficiente no sean ideales para EPYC.

Los casos de uso que pueden utilizar varias unidades NVMe también pueden beneficiarse del NVMe de conexión directa que es posible debido a la cantidad de canales PCI-E en EPYC.

Nuestros próximos pasos incluyen pruebas de rendimiento adicionales con aplicaciones de HPC adicionales.