AMD EPYC – estudo de desempenho de WRF, InfiniBand, HPL e STREAM

---

Resumo

O Laboratório de inovação em IA e HPC tem um novo cluster com 32 sistemas baseados em AMD EPYC, interconectados via Mellanox EDR InfiniBand. Como sempre, estamos realizando avaliações de desempenho em nosso cluster mais recente e gostaríamos de compartilhar os resultados. Este blog abrange os resultados de largura de banda de memória da microrreferência de desempenho STREAM, HPL e InfiniBand, em relação à latência e largura de banda, e os resultados de WRF do respectivo conjunto de dados de referência.

Estamos interessados no desempenho real do equipamento de HPC no EPYC. Se você tiver conjuntos de dados e quiser testá-los no EPYC, entre em contato com a equipe da sua conta Dell para ter acesso ao Laboratório de inovação.
 

---

Arquitetura AMD EPYC

Os processadores AMD EPYC permitem oito canais de memória, até 16 módulos de memória dupla em linha (DIMMs) por soquete com dois DIMMs por canal e até 32 núcleos por soquete. Além disso, uma plataforma com CPUs AMD oferece até 128 vias PCI-E para periféricos, como GPUs e unidades NVMe.
As próprias CPUs são módulos de vários chips, montados a partir de quatro matrizes. Cada matriz inclui até oito núcleos Zen, dois canais de memória DDR4 e 32 vias de E/S. Os núcleos Zen em uma matriz são organizados em dois grupos de quatro núcleos, chamados de complexo de núcleos, compartilhando o cache L3. Dentro de um soquete, todas as quatro matrizes são conectadas de forma cruzada por meio de uma interconexão coerente, chamada de Infinity Fabric. Isso é mostrado na Figura 1.


Figura 1 – Layout do soquete do EPYC. CCX é um complexo de núcleos de até 4 núcleos que compartilham o cache L3. M* são os canais de memória, dois canais manipulados por matriz. P* e G* são vias de E/S. ∞ é o Infinity Fabric.



Em um sistema de soquete único, cada matriz fornece até 32 vias PCI-E usando as vias de E/S P* e G*, mostradas na Figura 1. Isso dá ao soquete um total de 128 vias PCI-E, conforme mostrado na Figura 2. Quando uma CPU é usada na configuração de dois soquetes (2S), metade das vias de E/S de cada matriz é usada para se conectar a uma das matrizes no outro soquete por meio das vias de E/S G*, configuradas como Infinity Fabric. Isso permite que o soquete com as vias de E/S P* tenham um total de 64 vias PCI-E e, portanto, ainda 128 vias PCI-E na plataforma. Isso é mostrado na Figura 3


Figura 2 - Vias PCI-E de 1S do EPYC




Figura 3 – Layout de 2S do EPYC




Figura 3 – Layout de 2S do EPYC

 

---

Referência de desempenho STREAM

Como primeira etapa para avaliar o EPYC, medimos os recursos de largura de banda de memória da plataforma usando a referência de desempenho STREAM. Esses testes foram realizados em um servidor Dell EMC PowerEdge R7425 com dois processadores AMD EPYC 7601 (32c, 2,2 GHz), 16* DIMMs de 16 GB a 2400 MT/s, executando o Red Hat® Enterprise Linux® 7.5.

A apresentação de acesso não uniforme à memória (NUMA) do EPYC pode ser controlada por uma opção de BIOS, chamada de "Memory Interleaving", e mapeada usando utilitários do Linux, como numactl e lstopo.

A opção padrão de Memory Interleaving é "Memory Channel Interleaving". Nesse modo, os dois canais de cada matriz são intercalados. Isso apresenta quatro nós de NUMA por soquete e oito nós de NUMA para o sistema operacional, em um sistema de 2S.

"Memory Die Interleaving" é uma opção em que a memória é intercalada em todas as quatro matrizes de um soquete, ou seja, oito canais de memória. Isso apresenta um nó de NUMA por soquete e dois nós de NUMA em um sistema de 2S.

A opção "Memory Socket Interleaving" interliga a memória nos dois soquetes, proporcionando um nó de NUMA em uma plataforma de 2S. Isso seria o equivalente a um NUMA desativado.    

Usando a configuração padrão de "Memory Channel Interleaving", lembre-se de que cada soquete tem quatro matrizes, cada matriz fornece dois canais de memória, e o BIOS apresenta oito nós de NUMA em uma plataforma de 2S. A saída numactl de exemplo na Figura 4 mostra esses oito nós de NUMA em uma plataforma de 2S, um nó de NUMA por núcleo.


Figura 4 - Saída numactl no EPYC de 2S


Fisicamente, há quatro distâncias de NUMA na plataforma, conforme destacado na Figura 4: ao próprio nó de NUMA (distância "10" em vermelho), aos três nós que compartilham a mesma matriz (distância "16" em azul), ao nó no outro soquete que está conectado diretamente por meio de um link de Infinity Fabric (distância "22" em verde), aos outros três nós no soquete remoto que podem ser acessados por dois saltos usando o Infinity Fabric entre os dois soquetes, mais o link de Infinity Fabric interno (distância "28" em preto).

Algumas implementações e versões do BIOS podem simplificar esse layout físico e apresentar apenas três distâncias de NUMA ao sistema operacional. Esta simplificação envolve mascarar a diferença de distância entre o nó 0 de NUMA (por exemplo) e os nós 4, 5, 6 e 7 de NUMA ao apresentar os nós 4, 5, 6 e 7 como equidistantes do nó 0. Essa implementação é mostrada na Figura 5. O layout de NUMA será uma opção ajustável na próxima versão do BIOS do PowerEdge R7425. Simplificar as distâncias de nó de NUMA não altera o layout físico real dos núcleos. Isso é feito principalmente para o benefício do agendador do sistema operacional. Para os trabalhos de HPC e MPI que reconhecem NUMA, essas diferentes apresentações devem ser irrelevantes.


Figura 5 - Saída numactl no EPYC de 2S com distâncias de NUMA simplificadas


Além dos oito nós de NUMA em uma plataforma de dois soquetes, as Figuras 4 e 5 também mostram a memória e os núcleos associados a cada nó de NUMA. Cada nó de NUMA tem 32 GB de memória de dois DIMMs de 16 GB (16 DIMMs no servidor, oito por soquete, um DIMM por canal). Cada nó de NUMA contém os oito núcleos da matriz local. A enumeração de núcleos na plataforma Dell EMC é de rodízio, passando primeiro por todos os nós de NUMA e depois preenchendo cada nó de NUMA.

Além disso, a saída lstopo pode ser usada para mostrar claramente qual conjunto de quatro núcleos compõe um complexo de núcleos. Esses são os quatro núcleos em uma matriz que compartilham o cache L3. Por exemplo, a Figura 6 mostra que o nó 0 de NUMA tem oito núcleos e, neste nó, os núcleos 0, 16, 32 e 48 compartilham o cache L3, e os núcleos 8, 24, 40 e 56 compartilham o cache L3.


Figura 6 - Saída lstopo no EPYC de 2S


Figura 7 - Largura de banda de memória da plataforma AMD EPYC

Tendo em mente essas informações do layout de NUMA, os resultados da referência de desempenho STREAM Triad em relação à largura de banda de memória são apresentados na Figura 7, com o BIOS configurado como "Memory Channel Interleaving". Observe que os módulos de memória de classificação dupla de 16 GB a 2667 MT/s, usados neste banco de ensaio, operam a 2400 MT/s no EPYC. O primeiro conjunto de barras na Figura 7 mostra a largura de banda de memória da plataforma de 2S, com 244 GB/s quando todos os núcleos são usados, e 255,5 GB/s quando metade dos núcleos é usada. O segundo ponto de dados é a largura de banda de memória de um único soquete, que é cerca da metade da plataforma de 2S completa, conforme o esperado. O terceiro ponto de dados mede a largura de banda de memória de um nó de NUMA, uma matriz individual. Lembre-se de que cada soquete tem quatro matrizes e a largura de banda de uma matriz é cerca de ¼ a do soquete. Em uma matriz, há dois complexos de núcleos, e usar somente os núcleos em um complexo de núcleos fornece cerca de 30 GB/s. Quando os núcleos são usados nos dois complexos de núcleos de uma matriz, a largura de banda total da matriz pode chegar a cerca de 32 GB/s.

A largura de banda de memória da plataforma de 2S é impressionante, entre 240 e 260 GB/s, e é resultado dos oito canais de memória por soquete na plataforma. Além disso, um único núcleo pode fornecer aproximadamente 24,5 GB/s de largura de banda de memória para a memória local, o que é excelente para parcela de aplicativos de thread único.

Analisando o impacto do layout de NUMA no acesso remoto à memória, a Figura 8 traça a largura de banda de memória relativa quando os núcleos acessam a memória que não está no mesmo domínio de NUMA. O acesso à memória no mesmo soquete é cerca de 30% mais lento. O acesso à memória no outro soquete é aproximadamente 65% mais lento. Usando o STREAM Triad, parece não haver nenhum impacto mensurável na largura de banda da memória ao acessar a memória no soquete remoto em um salto (nó 6, um Infinity Fabric entre soquetes) ou dois saltos (nós 4, 5 e 7, um salto de Infinity Fabric entre soquetes + um salto de Infinity Fabric local). Para aplicativos sensíveis à largura de banda de memória, um bom local para a memória será importante para o desempenho, mesmo dentro do mesmo soquete.


Figura 8 - Impacto do acesso remoto à memória
 

---

Referência de desempenho HPL

Em seguida, determinamos a capacidade computacional de EPYC conforme medida pela referência de desempenho HPL. O EPYC é compatível com instruções AVX e 8 FLOP/ciclo de desempenho. Em nossa plataforma, usamos Open MPI e bibliotecas de álgebra linear BLIS para executar a referência HPL.

O desempenho teórico do nosso sistema de teste (processadores EPYC 7601 duplos) é de 64 núcleos * 8 FLOP/ciclo * frequência de relógio de 2,2 GHz, o que dá 1126 GFLOPS. Medimos 1133 GLOPS, que é uma eficiência de 100,6%.

Também executamos HPL no EPYC 7551 (32c, 2,0 GHz), no EPYC 7351 (16c, 2,4 GHz) e no EPYC 7351P (1S, 16c, 2,4 GHz). Nesses testes, o desempenho medido de HPL foi de 102 a 106% do desempenho teórico.

A eficiência é superior a 100% porque o EPYC é capaz de sustentar frequências turbo acima da frequência base durante o teste HPL.
 

---

Latência e largura de banda InfiniBand

Em seguida, verificamos os resultados da microrreferência de desempenho em relação à latência e à largura de banda InfiniBand entre dois servidores. A configuração usada para esses testes é descrita na Tabela 1. Os resultados de latência e largura de banda estão nas Figuras 9 e 10.


  Tabela 1 - Banco de ensaio de InfiniBand


Figura 9 – Latência de InfiniBand, com comutador

Comando de execução: 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

Houve cuidado para fixar o processo MPI ao nó de NUMA mais próximo à HCA. Essas informações estão disponíveis na saída lstopo. Em nosso caso, era o nó 6 de NUMA. Os testes de latência foram executados usando OpenMPI e HPC-X. Com a aceleração OpenMPI e MXM, medimos a latência de 1,17 µs. Com o OpenMPI e UCX, medimos a latência de 1,10 µs. Os resultados da latência obtidos com o HPC-X são apresentados aqui.

Na Figura 9, a latência nos processadores EPYC com estados C habilitados é de 1,07 µs, e a latência para todos os tamanhos de mensagem é, em média, 2 a 9% melhor com estados C habilitados, em comparação aos estados C desabilitados. Os estados C habilitados permitem que os núcleos ociosos estejam em estados C mais profundos, o que possibilita frequências turbo mais altas nos núcleos ativos, resultando em latência reduzida.

Os resultados da largura de banda são apresentados na Figura 10. Medimos a largura de banda unidirecional de 12,4 GB/s e a largura de banda bidirecional de 24,7 GB/s. Esses resultados são os esperados para EDR


Figura 10 - Largura de banda de InfiniBand

Comando de execução: 

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

 

Tabela 2 – Resultados de osu_mbw_mr, nó único de NUMA
Comando de execução: 

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

O layout de NUMA descrito nas Figuras 3 e 6 nos levou a verificar o impacto da localidade do processo na largura de banda. Para esse teste, usamos referência de desempenho osu_mbw_mr que mede a largura de banda unidirecional agregada entre vários pares de processos. O objetivo do teste é determinar a largura de banda alcançada e a taxa de mensagens entre os nós de NUMA individuais usando todos os oito núcleos que estão no nó de NUMA. Os resultados desse teste são apresentados na Tabela 2. A configuração de teste usou o perfil de desempenho (estados C desativados e Turbo ativado).

Os resultados mostram que, quando os processos são executados no nó de NUMA conectado à HCA InfiniBand (nó 6 de NUMA), a largura de banda agregada é de 12,3 GB/s. Quando os processos são executados em qualquer um dos outros três nós de NUMA que estão no mesmo soquete da HCA (soquete 1), a largura de banda agregada é praticamente a mesma, cerca de 12,1 GB/s. Quando os processos são executados nos nós de NUMA do soquete remoto para a HCA, a largura de banda agregada cai para aproximadamente 6,8 GB/s.

O próximo conjunto de resultados, exibido na Tabela 3, demonstra a largura de banda unidirecional entre soquetes individuais. No teste, todos os 32 núcleos disponíveis no soquete foram usados. Medimos 5,1 GB/s na execução no soquete local para a HCA, e 2,4 GB/s na execução no soquete remoto para a HCA. Usando todos os 64 núcleos em nossos servidores de teste, medimos 3,0 GB/s ao executar 64 processos por servidor.

Para confirmar esse último resultado, executamos um teste usando todos os oito nós de NUMA em ambos os soquetes, com cada nó de NUMA executando dois processos, dando um total de 16 processos por servidor. Com esse layout, medimos também 2,9 GB/s.

Os resultados indicam que a topologia do sistema tem um impacto no desempenho da comunicação. Isso interessante para casos em que um padrão de comunicação completo, com vários processos se comunicando entre servidores, é um fator importante. Para outros aplicativos, é possível que a largura de banda reduzida, medida ao executar processos em vários domínios de NUMA, talvez não seja um fator que influencie o desempenho no nível do aplicativo.


  Tabela 3 – Resultados de osu_mbw_br, nível de soquetes e sistema
Comando de execução: 

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 de execução:

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 de execução: 

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

---

Desempenho em nível de cluster HPL

Com o desempenho da nossa malha InfiniBand validado, o próximo teste foi executar rapidamente o HPL no cluster. Esses testes foram realizados em um sistema de 16 nós com EPYC 7601 de dois soquetes. Os resultados estão na Figura 11 e mostram a escalabilidade de HPL esperada nos 16 sistemas.


Figura 11 - HPL em 16 servidores

 

---

Desempenho em nível de cluster WRF

Finalmente, executamos o WRF, um equipamento para previsão. O banco de ensaio foi o mesmo do anterior: um sistema de 16 nós com EPYC 7601 de dois soquetes. Além disso, fizemos alguns testes em um sistema de 4 nós menor, com EPYC 7551 de dois soquetes. Todos os servidores possuíam 16 RDIMMs de 16 GB* executando a 2.400 MT/s e interconectados ao Mellanox EDR InfiniBand.


Figura 12 - Conus 12 km WRF, nó único

Usamos o WRF v3.8.1 e v3.9.1 e testamos os conjuntos de dados Conus 12 km e Conus 2,5 km. Nós compilamos o WRF e o netcdf usando compiladores Intel e fizemos a execução com o Intel MPI. Experimentamos diferentes esquemas de processo e disposição em blocos, usando as opções de configuração dmpar e dm+sm com OpenMP.

Estamos trabalhando com o AMD para determinar outras opções de ajuste do compilador para WRF.

Não houve diferença de desempenho medida entre WRF v3.8.1 e v3.9.1. Ao comparar dmpar e dm+sm, uma combinação criteriosa de processos e blocos resultou praticamente no mesmo desempenho. Isso é mostrado na Figura 12.


Figura 13 - Conus 12 km WRF, testes de cluster


Figura 14 - Conus 2,5 km WRF, testes de cluster

Os testes de nível de cluster foram realizados com o WRV versão 3.8.1 e com a configuração dmpar usando todos os núcleos e 8 blocos por execução.

Conus 12 km é um conjunto de dados menor, com desempenho estabilizado após oito nós, 512 núcleos no EPYC. Isso é mostrado na Figura 13. O EPYC 7551 e o EPYC 7601 são processadores de 32 núcleos, sendo que a frequência de relógio básica e a frequência turbo em todos os núcleos do 7601 são, respectivamente, 10% e 6% mais rápidas que as do 7551. Nos testes Conus 12 km WRF, o desempenho do sistema EPYC 7601 foi 3% mais rápido do que o do 7551 nos testes de 1, 2 e 4 nós.

O Conus 2,5 km é um conjunto maior dados de referência de desempenho. Em relação a um sistema EPYC, o desempenho é escalonado bem para até oito nós (512 núcleos) e, em seguida, começa a diminuir. Também com o Conus 2,5 km, o sistema EPYC 7601 apresenta um desempenho de 2 a 3% mais rápido do que o EPYC 7551 em testes de 1, 2 e 4 nós, conforme mostrado na Figura 14.

 

---

Conclusão e próximas etapas

O EPYC fornece boa largura de banda de memória e densidade de núcleo por soquete. Do ponto de vista de HPC, esperamos que os aplicativos que possam usar a largura de banda de memória disponível e os núcleos da CPU consigam tirar o máximo proveito da arquitetura EPYC. Atualmente, o EPYC não é compatível com o AVX512 ou o AVX2 em um único ciclo. Dessa forma, os códigos que são altamente vetorizados e podem usar o AVX2 ou o AVX512 de forma eficiente talvez não sejam ideais para o EPYC.

Os casos de uso que podem utilizar várias unidades NVMe também conseguem se beneficiar da NVMe acoplada diretamente. Isso é possível devido ao número de vias PCI-E no EPYC.

Nossas próximas etapas incluem outros testes de desempenho com aplicativos HPC adicionais.