Turin da AMD: lançamento da 5ª geração do EPYC

 (chipsandcheese.com)
3 pontos por GN⁺ 2024-10-13 | 1 comentários | Compartilhar no WhatsApp
  • A medição real do AMD EPYC 9575F mostra as diferenças práticas do Turin com foco nas mudanças no subsistema de memória para servidores, em vez de repetir explicações sobre os núcleos Zen 5
  • A largura de banda single-thread fica em cerca de 52GB/s para leitura, 48GB/s para escrita e 95GB/s em add; a leitura do soquete inteiro chega a quase 99% dos 576GB/s teóricos
  • O Turin para servidores usa GMI3-W, com 2 links GMI entre o CCD e o die de I/O, e a largura do link de escrita também aumenta para 32B por link, resultando em maior largura de banda do CCD do que no Zen 5 para desktops
  • A latência de memória sem carga é semelhante à do Genoa, mas a latência entre núcleos subiu em relação ao Genoa: cerca de 45ns intra-CCD, 150ns inter-CCD e 260ns entre soquetes
  • O 9575F tem 64 núcleos que chegam a até 5GHz em single-thread e mantém cerca de 4,3GHz no Cinebench 2024 com 128 threads, evidenciando seu perfil de SKU empresarial de alta frequência e contagem de núcleos relativamente menor

As mudanças do Turin vistas pelo EPYC 9575F

  • A análise do Turin se concentra nos dados medidos do AMD EPYC 9575F
    • Foi possível testar essa CPU por meio de Jordan, da StorageReview
    • Como os núcleos Zen 5 já foram abordados em comparações entre mobile, desktop e variantes, o foco desta vez é o subsistema de memória
  • Os slides de lançamento do Turin da AMD podem ser vistos no Serve the Home; aqui, os dados medidos internamente têm maior peso

Configuração GMI que aumenta a largura de banda do CCD

  • Nos resultados 1T, a largura de banda de memória single-thread do EPYC 9575F fica nos seguintes níveis
    • Leitura: cerca de 52GB/s
    • Escrita: cerca de 48GB/s
    • add, ou Read-Modify-Write: cerca de 95GB/s
  • Mesmo um único núcleo consegue usar uma parte significativa da largura de banda de memória de todo o CCD
    • A leitura fica um pouco abaixo da metade da largura de banda total de leitura do CCD
    • A escrita é de cerca de 55% da largura de banda total de escrita do CCD
    • O add supera dois terços da largura de banda total de add do CCD
  • Essa diferença vem da configuração GMI3-W do Turin para servidores
    • O EPYC 9575F tem 2 links GMI conectados ao die de I/O
    • O Ryzen 9950X usa um único link GMI
    • O link de escrita GMI para servidores é de 32B por link, maior que os 16B por link do Zen 5 para desktops

Memória de 12 canais e desempenho do soquete inteiro

  • O Turin oferece suporte a memória de 12 canais e pode chegar a DDR5-6400MT/s
    • DDR5-6400MT/s só é suportado em determinados sistemas validados
    • Essa velocidade só é possível em configuração com 1 DIMM por canal
  • O sistema de teste opera em DDR5-6000MT/s
    • A maioria dos sistemas suporta DDR5-6000MT/s em configuração com 1 DIMM por canal
    • Com 2 DIMMs por canal, a velocidade da memória cai para 4400MT/s
    • Em uma placa-mãe com 2 slots DIMM por canal, ao usar apenas 1 DIMM por canal, pode-se esperar 5200MT/s
  • A largura de banda de leitura do soquete inteiro do 9575F chega a quase 99% dos 576GB/s teóricos
    • Escrita: 435GB/s
    • add: 453GB/s
  • Na AMD Volcano Platform, também foi medida a largura de banda entre soquetes entre dois 9575F
    • Essa plataforma tem apenas 3 links GMI entre as duas CPUs
    • O resultado foi muito parecido com o teste do Bergamo, e o sistema Bergamo também tinha a mesma configuração com 3 links GMI

Latência sob carga e latência entre núcleos

  • A latência de memória sem carga do Turin é muito semelhante à do Genoa
  • No Hot Chips 2024, a Ampere Computing divulgou um gráfico de latência de memória sob carga do chip AmpereOne e de uma CPU AMD Genoa; com isso como referência, foi criado um teste de latência sob carga semelhante
  • O teste preenche o link IOD-CCD ou todo o sistema de memória com um benchmark de largura de banda de memória e, depois, mede a latência de memória com o núcleo ou CCD restante
    • No teste de um único CCD, o benchmark de largura de banda de memória é executado em 7 núcleos de um CCD, e a latência é medida no 8º núcleo
    • No teste do sistema inteiro, o benchmark de largura de banda de memória é executado em 7 CCDs do 9575F, e a latência é medida no 8º CCD
  • Sob carga, o aumento de latência de memória do 9575F fica em níveis semelhantes dependendo da condição
    • Com carga em um único CCD, aumenta cerca de 39ns em relação ao estado sem carga
    • Com carga no sistema inteiro, aumenta cerca de 31ns em relação ao estado sem carga
  • A latência entre núcleos ficou maior que no Genoa, com destaque para o aumento dentro do CCD
    • Latência intra-CCD: cerca de 45ns
    • Latência inter-CCD: cerca de 150ns
    • Latência socket to socket: cerca de 260ns

Velocidade de clock e posicionamento do produto

  • O EPYC 9575F conseguiu fazer todos os 64 núcleos chegarem a até 5GHz em testes single-thread
  • No teste de largura de banda de memória, foi possível executar todos os 8 núcleos de um CCD a 5GHz
  • No Cinebench 2024, usando todos os 128 threads, ele manteve a faixa de cerca de 4,3GHz
  • Wendell, da Level1Techs, observou cerca de 4,9GHz em all-core em cargas de trabalho de servidor web/transações TLS; essa carga é menos vetorizada
  • A linha Turin oferece SKUs com alta contagem de núcleos e também SKUs de alta frequência
    • A AMD tem SKUs de alta contagem de núcleos, como 9755 e 9965
    • Também oferece SKUs como o 9575F, com contagem de núcleos menor e frequência muito alta
    • O fato de 64 núcleos serem tratados como “baixa contagem de núcleos” por si só mostra a mudança no mercado de CPUs para servidores
  • O Turin está mais próximo de uma evolução que combina aumento de largura de banda de memória, aumento de contagem de núcleos e atualização dos núcleos, como na passagem do Milan para o Genoa, do que de uma revolução brusca como a transição do Naples para o Rome

Leituras relacionadas

1 comentários

 
GN⁺ 2024-10-13
Comentários do Hacker News

  • O AMD EPYC 9175F é o mais incomum: 16 núcleos com 512 MB de cache L3 parece algo para clientes que querem reduzir custos de licenciamento por núcleo
    Caso contrário, não faz muito sentido colocar tão poucos núcleos em um chip tão caro. Não sei se a Oracle ainda usa esse tipo de licenciamento, mas, se usa, já passou da hora de parar
    Também poderia servir para usos como HFT, em que se coloca o algoritmo inteiro no L3 para buscar a menor latência absoluta, ou pode ser o caso de querer usar apenas os melhores núcleos de cada chiplet. Ainda assim, provavelmente é por causa de licenças de software

    • Simulação de eventos discretos também é um bom exemplo. Algo como redes neurais com spikes, quando simulado com precisão, acaba serializado por meio de uma fila de spikes pendentes e, por natureza, fica próximo de single-thread
      A melhor configuração é manter todo o estado no cache local e escolher o núcleo mais rápido para executar. Se for possível rodar 16 em paralelo, dá para reduzir o espaço de busca nessa mesma proporção
      Nesse tipo de problema, quase não é preciso se preocupar com a latência entre CCDs. Mesmo rodando algo como algoritmos genéticos que periodicamente fazem cruzamentos entre núcleos físicos, a exigência de largura de banda entre núcleos é pequena
    • Há muitas aplicações single-thread, e muitas vezes é mais barato gastar alguns milhares de dólares em uma CPU ultrarrápida do que gastar dezenas de milhares com programadores para reescrever o código e paralelizá-lo
      Como foi dito, se for código de terceiros sem acesso ao código-fonte ou aos direitos, muitas vezes reescrever nem sequer é possível
    • 512 MB de cache é impressionante. Alguns anos atrás achei curioso ver que o cache de um Xeon que eu usava era tão grande quanto a RAM dos sistemas que eu usava quando era criança; e sou millennial, então não eram máquinas antigas tipo Commodore, mas PCs de verdade que até rodavam Quake
      Mas 512 MB já é bastante espaço. Fico me perguntando se daria para colocar o Puppy Linux inteiro no cache L3
    • O MATLAB Parallel Server também usa licenciamento por núcleo
      https://www.mathworks.com/products/matlab-parallel-server/li...
    • Muitos algoritmos são limitados pela largura de banda de memória. Mesmo em workstations de 16 núcleos, já rodei várias tarefas em que o melhor desempenho vinha com menos de 16 threads
      Testar um algoritmo com vários números de threads e depois usar a contagem ideal é uma prática comum. Algoritmos intensivos em memória frequentemente atingem desempenho máximo com um número relativamente pequeno de núcleos

  • A Phoronix publicou recentemente uma análise comparando o Turin Dense de 196 núcleos com o AmpereOne de 192 núcleos
    O preço sugerido do Ampere era US$ 5,5 mil, o do EPYC era US$ 15 mil, o Turin 196 tinha desempenho 1,6 vez maior, e o Ampere era 1,2 vez melhor em eficiência energética
    Pelos resultados da análise da Phoronix, em desempenho real por dólar, o Ampere de 192 núcleos é 1,7 vez melhor que o Turin Dense de 196 núcleos. Ou seja, por US$ 5,5 mil você pode comprar uma CPU AmpereOne de 192 núcleos (274 W) ou uma CPU Turin Dense de 48 núcleos (300 W)
    A Ampere deve lançar no ano que vem um produto de 256 núcleos, 3 nm e memória de 12 canais, então pode vir a competir melhor com Turin Dense e Sierra Forest em desempenho bruto. O ponto forte atual é desempenho por dólar
    Também estou muito curioso sobre o desempenho do chip de servidor da Qualcomm baseado na Nuvia. Se as melhorias nos núcleos ARM para clientes servirem de pista, também será interessante ver como chips próprios como AWS Graviton, Google Axion, Microsoft Cobalt, Nvidia Grace e Alibaba Yitian competirão com núcleos Neoverse melhores. É Nuvia contra ARM contra AmpereOne
    Provavelmente estamos vivendo agora uma era de ouro das CPUs de servidor. Há 7 anos era praticamente só Intel Xeon, e agora há muitas opções

    • A AMD também vence em desempenho/W, um resultado bastante significativo para quem acreditava que X86 jamais conseguiria acompanhar a eficiência de ARM/RISC
      Hoje, em muitos datacenters, a energia disponível e o resfriamento decorrente dela são restrições ainda maiores, então isso é um bom sinal para Turin
    • Na comparação de desempenho por dólar, estão usando o modelo Turin com o preço sugerido mais alto. Esse modelo não é o melhor em desempenho por dólar; é o que as pessoas compram para maximizar densidade ou desempenho por watt, e nesses pontos ele supera o Ampere
      Se o foco for apenas desempenho por dólar, é preciso olhar para os modelos Zen5 com menos núcleos, não Zen5c, e nessa linha o desempenho por dólar é o dobro do 9965 de 192 núcleos
      O motivo de a mesma lógica não funcionar tão bem para a Ampere é que o modelo de 192 núcleos a 3,2 GHz já está quase no topo em desempenho por dólar
    • A diferença é que dá para conseguir uma CPU EPYC, mas é difícil pôr as mãos em uma CPU Ampere
    • O preço sugerido da Ampere é bem próximo do que a maioria dos integradores de sistemas realmente paga. Já para EPYC ou Xeon, dá para presumir que a maioria dos fornecedores consegue comprar com quase 50% de desconto sobre o preço sugerido
    • É uma época realmente interessante, e a queda da Intel é muito lamentável. Ainda assim, como muita gente vinha alertando, a Intel deveria ter previsto esta situação

  • É uma escala realmente absurda. Há 20 anos, CPUs tinham 1 ou 2 núcleos por CPU, então ter 4 núcleos em um servidor dual-socket já era sorte
    Agora um único servidor pode ter quase 400 núcleos. Claro, usando núcleos ARM poderia ter ainda mais, mas pelo menos por enquanto eles não chegam a esse nível de desempenho

    • Saturar duas NICs 400GbE com mais de 700 threads em 2 chips, com 500 W por chip, dá menos de 2 W por thread. E tudo isso cabe em um pacote 2U
      Há 20 anos, isso seria equipamento suficiente para vários racks
    • Por outro lado, naquela época provavelmente se esperaria que, com 20 anos de progresso, os núcleos ficassem 1000 vezes mais rápidos; na prática, foi algo mais perto de 5 vezes
    • Fico curioso para saber que parcela dos jobs de big data que rodam em clusters hoje seria muito mais rápida em uma única máquina grande usando duckdb em vez de Spark
    • Hoje em dia, a maioria dos serviços cabe em um único servidor e ainda consegue atender milhões de usuários por dia
      Se for possível alugar um servidor dedicado poderoso por menos de US$ 1000 por mês e economizar dezenas de milhares de dólares, fico curioso sobre o impacto disso em serviços de nuvem caros demais. Com esse dinheiro daria até para contratar um administrador em tempo integral e ainda sobraria
    • Exato. Os primeiros chips de servidor dual-core apareceram por volta de 2005 com os Opteron Denmark/Italy/Egypt de 90 nm e os Xeon Paxville; pelo que sei, do lado da Intel a coisa só engrenou mesmo em 2007

  • Quando a Hetzner tiver servidores bare metal AMD Turin, quero fazer um deploy neles. A geração anterior já tinha bom custo-benefício, e esta parece ter melhorado mais um nível

  • Ainda rodo Xeons duplos em um Dell PowerEdge de 12 anos. Fico imaginando quando os servidores EPYC de 1ª geração vão aparecer como pechincha no eBay

    • EPYC de 1ª a 3ª geração pode ser encontrado bem barato, mas as placas-mãe são caras
      Se o objetivo principal não forem as lanes PCIe e a capacidade de RAM, eu não recomendaria nada abaixo da 3ª geração. CPUs atuais de consumidor comum, mesmo com metade ou um quarto dos núcleos, têm desempenho computacional melhor e consomem muito menos energia
    • Pessoalmente, acho que EPYC de 1ª geração não vale muito a pena, já que a 2ª geração existe, é mais difundida e barata o suficiente. No meu homelab, uso de fato um epyc 7302 com uma placa-mãe MZ31-AR0
      O desempenho por núcleo é baixo demais, há problemas relacionados a NUMA, e o processo de fabricação também é pior. Os dies de computação da 2ª geração são TSMC 7 nm
    • Não sei muito sobre chips EPYC, mas máquinas com Ryzen série 5 foram praticamente dadas na Amazon naquela semana
      Comprei um 9 5950X por 242 libras
    • Não vale muito. Dá para comprar um 9654 no eBay por US$ 2000 e gastar US$ 1000 numa placa-mãe. O sistema completo fica em torno de US$ 7000
      Ou então combinações como Epyc 7282 também são fáceis de encontrar e são decentes
    • Isso já aconteceu, e o desempenho não é lá essas coisas

  • ChipsAndCheese é um dos poucos veículos novos de tecnologia que realmente entende do assunto. É especialmente forte nesse tipo de benchmark aprofundado
    Com sites antigos de tecnologia como Anandtech, TechReport e HardOCP desaparecendo, é bom ver uma nova publicação capaz de acompanhar aquele estilo antigo de textos profundos

    • Curiosamente, o Slashdot começou originalmente a partir de um site chamado Chips & Dips. Fico imaginando se a inspiração é parecida
    • Acho que você queria dizer HardOCP
    • Chips and Cheese me lembra mais o extinto LostCircuits. A maioria dos sites de tecnologia foca em listas de benchmarks de aplicações, mas o C&C, assim como o LC fazia, combina textos longos sobre arquitetura com microbenchmarks de subsistemas

  • Para quem não gostou da mudança para o Substack, há https://old.chipsandcheese.com/2024/10/11/amds-turin-5th-gen...
    Pelo menos por enquanto funciona

  • Uma peça com apenas 16 núcleos, mas 512 MB de cache L3, claramente é para workloads específicos

    • A Oracle pode cobrar EE e opções por núcleo, algo entre US$ 40 mil e mais de US$ 100 mil, multiplicado por 0,5, e alguns workloads são extremamente sensíveis a cache
      Por isso, uma configuração dual-socket com uma CPU de 16 núcleos[1] com muito cache, muita largura de banda, clocks altos e grande capacidade de memória pode ser a mais eficiente frente a mais de US$ 1 milhão em custos de licença
      [1] https://www.amd.com/en/products/processors/server/epyc/9005-...
    • A topologia dessa peça é realmente peculiar. Fisicamente, é o mesmo silício de uma peça de 128 núcleos, mas com todos os núcleos desativados em cada chiplet de computação, exceto um
      Ou seja, desligaram 112 núcleos para deixar só 16, tentando manter o máximo possível de cache
      No entanto, como ele sempre terá de passar pelo barramento relativamente lento entre chiplets, a latência entre núcleos não deve ser boa
    • Fico imaginando se os chips AMD mais recentes conseguem mapear o cache L3 para usá-lo como TCM em vez de cache
      Processadores não x86 antigos davam suporte a isso, e muitas vezes inicializavam nesse modo para permitir inicializar o controlador de memória. Se ainda for possível hoje, poderia abrir usos embarcados interessantes, como sistemas grandes sem DRAM

  • Há um trecho dizendo: “O sistema ao qual tivemos acesso rodava a memória a 6000 MT/s, e DDR5-6000 MT/s é suportado pela maioria dos sistemas em configurações de 1 DIMM por canal. Usar 2 DIMMs por canal reduz a velocidade da memória para 4400 MT/s, e espere 5200 MT/s ao usar 1 DIMM por canal em uma placa-mãe de 2 DIMMs por canal”; fico imaginando se todas essas velocidades são para memória ECC

    • Sim. Servidores usam apenas RAM ECC