Inicio Empreendimento 105 trilhões de dígitos Pi: a jornada para um novo recorde de cálculo de Pi

105 trilhões de dígitos Pi: a jornada para um novo recorde de cálculo de Pi

by Jordan Ranous

A StorageReview e nossos parceiros acabaram de resolver o Pi em 105 trilhões de lugares, um novo recorde mundial que supera o recorde anterior em XNUMX%.

Não somos estranhos em ultrapassar os limites da computação, mas este leva o Pi(e). Seguindo os passos do ano passado 100 benchmark de trilhões de dígitos, decidimos aumentá-lo e empurrar os dígitos conhecidos do Pi para 105 trilhões de dígitos. São 105,000,000,000,000 de números após o 3. Fizemos algumas atualizações na plataforma desde a execução do ano passado, encontramos algumas coisas surpreendentes ao longo do caminho e aprendemos algumas coisas ao longo do caminho - incluindo o 105 trilionésimo dígito de Pi;6!

105 trilhões de pi - servidor e JBOF

Alcançando um cálculo recorde mundial de Pi com 105 trilhões de dígitos, o laboratório StorageReview destacou as incríveis capacidades do hardware moderno. Este empreendimento, alimentado por um sistema AMD EPYC Bergamo 2P de 128 núcleos de última geração equipado com 1.5 TB de DRAM e quase um petabyte de SSDs Solidigm QLC, representa uma conquista marcante em tecnologia computacional e de armazenamento.

O Desafio

Na corrida digital de 100 trilhões, encontramos diversas limitações tecnológicas. A plataforma do servidor, por exemplo, suportava apenas 16 SSDs NVMe nos slots frontais. Embora tivéssemos bastante poder de CPU, esse cálculo exigia armazenamento massivo durante o processo e no back-end quando o arquivo TXT final era gerado.

Para resolver o problema de armazenamento da última vez, recorremos a sleds adaptadores PCIe NVME para inserir mais três SSDs. Então, para a saída, tivemos um servidor de armazenamento HDD em RAID0, lembre-se, com um compartilhamento iSCSI de volta à caixa de computação. Desta vez, queríamos ser um pouco mais “empreendedores” com este servidor, por isso trouxemos alguns amigos para ajudar. Curiosamente, não é tão fácil quanto parece adicionar vários SSDs NVMe a um servidor.

O Hardware

O coração desta tarefa monumental foi o sistema AMD EPYC 9754 Bergamo de processador duplo, oferecendo 128 núcleos cada. Processadores AMD, conhecidos por seu desempenho excepcional em tarefas computacionais de alta complexidade (IA, HPC, análise de Big Data), forneceu a potência necessária. Complementando isso, havia 1.5 TB de DRAM, garantindo rápidas velocidades de processamento e transferência de dados. Ao mesmo tempo, quase um petabyte de Armazenamento Solidigm QLC ofereceu capacidade e confiabilidade sem precedentes.

105 trilhões de unidades de armazenamento pi

Nossa plataforma de chassi base permaneceu a mesma do ano passado (uma caixa QCT), mas atualizamos as CPUs para chips AMD EPYC 9754 Bergamo. Queríamos buscar uma melhoria na velocidade e no decimal, evitando o uso de armazenamento para a computação, o que significava que precisávamos recorrer à SerialCables para fornecer um JBOF. Isso apresentou alguns desafios por si só, que detalharemos a seguir.

Parâmetro Valor
Data de início Terça-feira, 19 de dezembro 14:10:48 2023
Data final Ter, 27 de fevereiro 09:53:16 2024
Tempo total de computação 5,363,970.541 segundos / 62.08 dias
Tempo de parede do início ao fim 6,032,547.913 segundos / 69.82 dias

Período de cálculo: 14 de dezembro de 2023 – 27 de fevereiro de 2024, abrangendo 75 dias.

  • CPU: Processadores duplos AMD Epyc 9754 Bergamo, 256 núcleos com multithreading simultâneo (SMT) desabilitado no BIOS.
  • Memória: 1.5 TB de RAM DDR5.
  • Armazenamento: 36 SSDs Solidigm D30.72-P5 de 5316 TB.
    • 24 SSDs Solidigm D30.72-P5 de 5316 TB em um JBOF SerialCables
    • 12 SSDs Solidigm D30.72-P5 de 5316 TB no servidor com conexão direta.
  • Sistema operacional: Servidor Windows 2022 (21H2).

O caminho para 105 trilhões

Parâmetro Valor
constante Pi
Algoritmo Chudnovsky (1988)
Dígitos decimais 105,000,000,000,000
Dígitos Hexadecimais 87,200,612,490,794
Modo de rosqueamento Cilk Plus Roubo de Trabalho -> 256/256
Memória de Trabalho 1,492,670,259,968 (1.36 TiB)
memória total 1,492,984,298,368 (1.36 TiB)
Maior ponto de verificação lógico 157,783,654,587,576 (144 TiB)
Uso de disco de pico lógico 534,615,969,510,896 (486 TiB)
Bytes de disco lógico lidos 44,823,456,487,834,568 (39.8 PiB)
Bytes de disco lógico gravados 38,717,269,572,788,080 (34.4 PiB)

Desafios encontrados

Um novo componente nesta execução, necessário para expandir o armazenamento disponível para os processadores, foi adicionar um JBOF NVMe. Nossa plataforma de teste ofereceu 16 baias NVMe, com as oito restantes conectadas apenas para SATA. Embora nossa execução de 100 trilhões tenha aproveitado três adaptadores PCIe U.2 internos para expandir nossa contagem de drives NVMe para 19, não foi o ideal. Para esta repetição, adicionamos um Cabos seriais 24-bay U.2 JBOF, o que ajudou significativamente de duas maneiras: mais armazenamento de troca de computação e armazenamento interno de arquivos de saída. Chega de servidores de armazenamento HDD RAID0 malucos!

O JBOF de 24 baias dos cabos seriais nos permitiu quase dobrar a contagem de unidades em relação à execução original. Alocamos 30 unidades para o espaço de troca do y-cruncher, deixando 6 SSDs para um volume de saída RAID5 de espaços de armazenamento. Uma grande vantagem dessa abordagem veio durante o estágio de saída, onde não fomos prejudicados pela velocidade de uma única conexão de 10 Gb, como a primeira iteração 100T Pi. Embora o JBOF tenha resolvido o problema da contagem total de unidades, ele introduziu uma limitação: desempenho individual das unidades.

Em um servidor com SSDs U.2 de conexão direta, há quatro pistas PCIe por unidade. Se cada unidade estiver conectada diretamente à placa-mãe, isso equivale a 96 pistas PCIe para 24 SSDs. A largura de banda total do JBOF é limitada pelo número de pistas PCIe que ele pode conectar ao host.

Neste caso, usamos duas placas host switch PCIe, dividindo o JBOF em dois grupos de 12 SSDs. Cada grupo de 12 SSDs compartilhou 16 pistas PCIe. Embora ainda ofereçamos vantagens consideráveis ​​na conexão de SSDs ao nosso host, tivemos cenários em que as unidades swap executadas por meio do JBOF ficaram atrás das unidades diretamente conectadas ao servidor. Isso não é culpa do JBOF. É apenas uma limitação técnica, ou melhor, uma limitação de quantas pistas PCIe o servidor pode trabalhar.

Leitores astutos podem se perguntar por que paramos em 36 SSDs nesta execução em vez de subirmos para 40. É uma história engraçada. O espaço PCIe endereçável tem limites em muitos servidores. No nosso caso, na contagem de 38 drives, o último SSD pegou o endereço PCIe do chipset USB e perdemos o controle do servidor. Para garantir a segurança, reduzimos para 36 SSDs para que ainda pudéssemos entrar no BIOS ou fazer login no servidor. Ultrapassar limites leva a algumas descobertas surpreendentes.

Insight e resolução de diagnóstico

O primeiro dos dois principais desafios que encontramos estava relacionado ao desempenho. O que descobrimos foi Lei de Amdahl em ação. Um problema peculiar surgiu quando o y-cruncher parecia “travar” em nosso sistema AMD Bergamo de 256 núcleos durante grandes operações no modo swap. Esse travamento, caracterizado pela falta de atividade de E/S da CPU e do disco, desafiou as expectativas convencionais de comportamento do software. Isso levou a um mergulho profundo nas complexidades da computação paralela e das interações de hardware.

O processo de descoberta revelou que o programa não estava realmente travado, mas operando em uma capacidade severamente limitada, rodando em thread único em uma configuração expansiva de 256 núcleos. Este comportamento incomum levantou questões sobre o impacto potencial da Lei de Amdahl, especialmente porque as operações envolvidas não exigiam muita computação e não deveriam ter causado atrasos significativos em um sistema equipado com 1.5 TB de RAM.

A investigação tomou um rumo inesperado quando o problema foi replicado em um desktop de consumidor, destacando as graves implicações da Lei de Amdahl mesmo em sistemas menos extensos. Isso levou a um exame mais profundo das causas subjacentes, que revelou um risco de CPU específico da arquitetura Zen4 envolvendo superalinhamento e seus efeitos nos padrões de acesso à memória.

105 trilhões de pi - servidor e JBOF traseiro

O problema foi agravado nos processadores AMD por um loop no código que, devido à sua natureza simples, deveria ter sido executado muito mais rápido do que o observado. A causa raiz parecia ser o manuseio ineficiente do alias de memória pela unidade de armazenamento de carga da AMD. A resolução deste problema complexo exigiu a mitigação do risco de superalinhamento por meio da vetorização do loop usando AVX512 e a abordagem da desaceleração causada pela Lei de Amdahl com paralelismo aprimorado. Esta abordagem abrangente não apenas resolveu o problema imediato, mas também levou a otimizações significativas nos processos computacionais do y-cruncher, estabelecendo um precedente para enfrentar desafios semelhantes em ambientes de computação de alto desempenho.

O próximo problema foi encontrado nas etapas finais do cálculo, que parava inesperadamente e não fornecia informações sobre a causa do acidente. O acesso remoto foi concedido a Alexander Yee e, pela primeira vez em mais de uma década, a conclusão de um registro Pi exigiu intervenção direta do desenvolvedor.

Não nos envolvemos neste processo de diagnóstico, mas houve um erro aritmético crítico de ponto flutuante no caminho do código AVX512 do algoritmo de multiplicação N63. Alexander foi capaz de diagnosticar remotamente, forneça um binário fixo e retome a partir de um ponto de verificação, culminando em um cálculo bem-sucedido após a implementação de correções de software cruciais.

Reflexões e Seguindo em Frente

Este esforço ilustra as complexidades e imprevisibilidades da computação de alto desempenho. A resolução desses desafios estabeleceu um novo recorde de computação Pi e forneceu informações valiosas sobre desenvolvimento de software e metodologias de teste. A versão mais recente do y-cruncher, v0.8.4, incorpora correções para os problemas identificados, prometendo maior estabilidade para cálculos futuros.

Calcular Pi para 105 trilhões de dígitos não foi pouca coisa. Envolveu planejamento, otimização e execução meticulosos. Aproveitando uma combinação de software proprietário e de código aberto, a equipe da StorageReview otimizou o processo algorítmico para explorar totalmente os recursos do hardware, reduzindo o tempo computacional e aumentando a eficiência.

Com desempenho de leitura saturante PCIe Gen4 e capacidades líderes do setor de até 61.44 TB, os SSDs Solidigm QLC oferecem resultados inacreditáveis. “Imagine o que essas unidades podem permitir em computação de alto desempenho ou aplicativos com uso intensivo de IA”, disse Greg Matson, vice-presidente de planejamento estratégico e marketing da Solidigm. Estamos entusiasmados com o fato de os SSDs da Solidigm poderem impulsionar a segunda tentativa recorde do Storagereview de calcular pi. Seus esforços comprovam as verdadeiras capacidades das unidades de armazenamento da Solidigm, abrindo um mundo de possibilidades para aplicações de IA com uso intensivo de dados.”

Conclusão

A corrida para 105 trilhões de dígitos do Pi foi muito mais complexa do que esperávamos. Após reflexão, deveríamos esperar encontrar novas questões; afinal, estamos concluindo um cálculo que nunca havia sido feito antes. Mas com o cálculo de 100 trilhões concluído com uma configuração muito mais “fita adesiva e tela de galinheiro”, pensamos que tínhamos conseguido. Em última análise, foi necessário um esforço colaborativo para levar esta plataforma até a linha de chegada.

Embora nos regozijemos com os nossos parceiros nesta corrida recorde, devemos perguntar: “O que é que isto significa?” Mais cinco trilhões de dígitos do Pi provavelmente não farão grande diferença para a matemática. Ainda assim, podemos traçar alguns limites entre as cargas de trabalho computacionais e a necessidade de hardware subjacente moderno para suportá-las. Fundamentalmente, este exercício reflete que o hardware adequado faz toda a diferença, seja um cluster de data center empresarial ou uma grande instalação de HPC.

Para o cálculo do Pi, ficamos completamente restritos ao armazenamento. CPUs mais rápidas ajudarão a acelerar a matemática, mas o fator limitante para muitos novos recordes mundiais é a quantidade de armazenamento local na caixa. Para esta execução, estamos novamente aproveitando o SSD Solidigm D5-P5316 de 30.72 TB para nos ajudar a obter um pouco mais de 1.1 PB de flash bruto no sistema. Esses SSDs são a única razão pela qual conseguimos quebrar os recordes anteriores e atingir 105 trilhões de dígitos Pi.

Isso levanta uma questão interessante, no entanto. Muitos de nossos seguidores sabem que a Solidigm tem SSDs de 61.44 TB em seu D5-P5336 e até 30.72 TB no D5-P5430 SSDs, disponíveis em vários formatos e capacidades. Analisamos as unidades e temos muitas postagens nas redes sociais mostrando essas unidades incrivelmente densas. Com 32 desses SSDs se aproximando de 2 PB de armazenamento, pode-se perguntar por quanto tempo esses 105 trilhões de dígitos de Pi permanecerão como os maiores do mundo. Gostaríamos de pensar, não por muito tempo.

Maiores dígitos decimais conhecidos de Pi

1432360875 9463978314 2999186657 8364664840 8558373926: Dígitos para 105,000,000,000,000

Envolva-se com a StorageReview

Newsletter | YouTube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | RSS feed