Como habilitar o modo de memória de canal duplo em uma placa-mãe Asus-WS-Pro-X570-ACE?

Mas quando executo o sysbench memory run no debian12, obtenho um resultado que é o mesmo que o resultado quando o executo no modo de canal único.

75375,14 MiB transferidos (7537,11 MiB/seg)

Um sistema DDR4 de 2 canais @ 3200 MT/s tem uma largura de banda de memória de pico teórica de 64b x 2 x 3,2G / 8 = 51,2 GB/s, mas seu benchmark mostra apenas 7,5 GB/s, o que é 10% do valor de pico teórico. Portanto, o benchmark em si é falho. Você não está saturando sua largura de banda de memória de sistema de pico para começar, então a falta de diferença não é surpreendente.

Um bom benchmark de memória deve ser multithread, já que um aplicativo single-thread geralmente é incapaz de saturar a largura de banda completa (a vetorização pode ajudar, mas apenas até certo ponto). Além disso, o loop interno do programa deve ser idealmente escrito em uma linguagem de baixo nível como assembly, ou FORTRAN/C com otimização do compilador, para que você possa colocar o maior estresse na CPU e seu subsistema de memória. Existem vários benchmarks de memória respeitáveis ​​e padrão da indústria disponíveis, incluindo o benchmark STREAM de John D. McCalpin e o benchmark de memória integrado incluído na ferramenta likwid-benchno LIKWID. Ambas as ferramentas são amplamente utilizadas no mundo da computação científica e de alto desempenho e foram usadas em muitos artigos de pesquisa acadêmica.

Portanto, considere usar STREAM ou likwid-benchmedir corretamente a largura de banda de memória do seu sistema.

FLUXO

STREAM é um pequeno código C/FORTRAN escrito pelo Dr. John D. McCalpin e tem sido usado em supercomputadores de referência desde a década de 1990. Hoje, continua sendo um padrão da indústria devido à sua simplicidade.

Para executar um teste STREAM, obtenha o código-fonte em https://github.com/jeffhammond/STREAM (este é um espelho não oficial).

git clone https://github.com/jeffhammond/STREAM.git

Compile o código C manualmente (não use o Makefile) com:

gcc -fopenmp -O3 -march=native -DSTREAM_ARRAY_SIZE=100000000 stream.c -o stream.100M

A macro STREAM_ARRAY_SIZEcontrola o tamanho do array alocado.

Em seguida, execute-o com:

./stream.100M

Por padrão, o OpenMP executará STREAM em todos os núcleos da CPU. Finalmente, o seguinte resultado pode ser obtido:

-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           42926.6     0.038757     0.037273     0.043436
Scale:          28796.6     0.056992     0.055562     0.060382
Add:            31537.8     0.078600     0.076099     0.086864
Triad:          31400.9     0.079844     0.076431     0.092603
-------------------------------------------------------------

Devido à falta de otimização de armazenamento não temporal no GCC, nos testes Scale, Add e Triad, a CPU executa Write-Allocate, o que cria uma sobrecarga extra no subsistema de memória que não é medida. Para interpretar corretamente esse resultado, você deve multiplicar o resultado de Scale por 1,5 e multiplicar o resultado de Add e Triad por 1,33. O motivo para fazer isso envolve uma compreensão do cache da CPU, já expliquei em outra resposta Resultados esperados de um benchmark de largura de banda de memória de fluxo aqui.

Por exemplo, neste caso:

• Cópia: 42926,6 x 1,0 = 42926,6 MB/s
• Escala: 28796,6 x 1,5 = 43194,9 MB/s
• Adicionar: 31537,8 x 1,33 = 41945,3 MB/s
• Tríade: 31400,9 x 1,33 = 41763,2 MB/s

Como você pode ver, na minha máquina, estou obtendo cerca de 40 GB/s de largura de banda de memória no benchmark STREAM em todos esses testes. Isso é esperado, pois a largura de banda de memória utilizável geralmente fica em torno de 70%-80% da largura de banda teórica da memória. Observe que a largura de banda de memória é sempre relatada em GB/s por convenção, não em GiB/s.

Executar a memória de canal único do sistema reduzirá pela metade a velocidade do STREAM. Tente fazer este experimento você mesmo: Remova um canal DIMM, os resultados do STREAM serão reduzidos em 50. Adicione o canal DIMM de volta, os resultados sobem novamente.

LÍQUIDO

STREAM é um clássico, então é útil executá-lo para comparação com benchmarks de outras pessoas. Mas ele pode ser propenso a erros. Em desktops, pode ser aceitável (desde que você entenda a eficácia dos Non-Temporal Stores). Mas em servidores, há muitas armadilhas relacionadas ao comportamento de alocação de gravação do NUMA, compilador e CPU - que não são manipuladas automaticamente e podem gerar resultados enganosos.

Então, para testar a largura de banda da memória da CPU, prefiro usar o LIKWID. O Likwid é o canivete suíço do ajuste de desempenho em aplicativos HPC. Seu uso principal é coletar estatísticas de contadores de desempenho de hardware de baixo nível para entender e otimizar as características de desempenho do seu código. Mas ele também inclui uma ferramenta micro-benchmacrk chamada likwid-bench.

Primeiro, execute makee make installde acordo com o manual oficial do LIKWID. Então, uma ferramenta chamada likwid-benchse torna disponível. likwid-benchpode iniciar automaticamente várias instâncias dos programas de benchmark e fixar o processo e a memória de cada instância em seu nó NUMA correspondente. Ele também fornece muitos kernels de benchmark pré-escritos (incluindo o equivalente a um benchmark STREAM Triad) em assembly escrito à mão, permitindo resultados precisos e consistentes, como:

$ likwid-bench -a
copy - Double-precision vector copy, only scalar operations
copy_avx - Double-precision vector copy, optimized for AVX
copy_avx512 - Double-precision vector copy, optimized for AVX-
copy_mem - Double-precision vector copy, only scalar operations but with non-temporal stores
copy_mem_avx - Double-precision vector copy, uses AVX and non-temporal stores
copy_mem_avx512 - Double-precision vector copy, uses AVX-
copy_mem_sse - Double-precision vector copy, uses SSE and non-temporal stores
copy_sse - Double-precision vector copy, optimized for SSE
stream - Double-precision stream triad A(i) = B(i)*c + C(i), only scalar operations
stream_avx - Double-precision stream triad A(i) = B(i)*c + C(i), optimized for AVX
stream_avx512 - Double-precision stream triad A(i) = B(i)*c + C(i), optimized for AVX-
stream_avx512_fma - Double-precision stream triad A(i) = B(i)*c + C(i), optimized for AVX-
stream_avx_fma - Double-precision stream triad A(i) = B(i)*c + C(i), optimized for AVX FMAs
stream_mem - Double-precision stream triad A(i) = B(i)*c + C(i), uses SSE and non-temporal stores
stream_mem_avx - Double-precision stream triad A(i) = B(i)*c + C(i), uses AVX and non-temporal stores
stream_mem_avx512 - Double-precision stream triad A(i) = B(i)*c + C(i), uses AVX-
stream_mem_avx_fma - Double-precision stream triad A(i) = B(i)*c + C(i), optimized for AVX FMAs and non-temporal stores
stream_mem_sse - Double-precision stream triad A(i) = B(i)*c + C(i), uses SSE and non-temporal stores
stream_mem_sse_fma - Double-precision stream triad A(i) = B(i)*c + C(i), uses SSE FMAs and non-temporal stores

Aqui está um exemplo de uso likwid-benchpara medir a largura de banda da memória usando o benchmark STREAM Triad, usando AVX, FMA e armazenamentos não temporais, usando 4 instâncias, cada uma fixada de forma ideal a um nó NUMA.

Para comparar um único computador desktop usando o teste STREAM Triad, execute:

$ likwid-bench -t stream_mem_avx_fma -w M0:1GB

O argumento M0:1GBsignifica executar o teste no primeiro nó NUMA da máquina. Como os computadores desktop têm apenas um nó NUMA, isso é adequado. Para servidores, use tantos nós NUMA quantos a CPU tiver.

Como o código assembly já usa armazenamentos não temporais para otimização, não há necessidade de corrigir manualmente o likwid-benchresultado. O likwid-benchresultado deve ser muito similar ao resultado STREAM corrigido manualmente.

Para referência, esta é uma máquina Intel Xeon E5-2680 v4 de soquete duplo com DDR4 ECC RDIMM de 4 canais a 2400 MT/s em cada soquete, então ela deve se comportar como uma máquina de 8 canais. O modo Cluster-On-Die é habilitado no BIOS, como resultado, cada CPU é vista como dois nós NUMA - o silício da CPU é fisicamente particionado em 2 partes, cada uma com seu próprio controlador de memória de 2 canais interconectado por pontes entre dois Ring Bus separados, cada um com metade dos núcleos. A máquina inteira tem 4 nós NUMA. Para aplicativos com reconhecimento de NUMA, isso oferece a maior largura de banda de memória.

$ likwid-bench -t stream_mem_avx_fma -w M0:1GB -w M1:1GB -w M2:1GB -w M3:1GB
--------------------------------------------------------------------------------
Cycles:                 22089219858
CPU Clock:              2394502471
Cycle Clock:            2394502471
Time:                   9.224973e+00 sec
Iterations:             14336
Iterations per thread:  256
Inner loop executions:  186011
Size (Byte):            3999980544
Size per thread:        71428224
Number of Flops:        85332918272
MFlops/s:               9250.21
Data volume (Byte):     1023995019264
MByte/s:                111002.50
Cycles per update:      0.517719
Cycles per cacheline:   4.141749
Loads per update:       2
Stores per update:      1
Load bytes per element: 16
Store bytes per elem.:  8
Load/store ratio:       2.00
Instructions:           39999805457
UOPs:                   58666381312

Aumentar o número de threads em sysbench?

Não estou familiarizado com sysbench, mas ele permite que você execute o benchmark de memória com múltiplos threads. Se sim, considere refazer seu próprio teste usando tantos threads quanto núcleos de CPU ou threads SMT de hardware.