105 biljoner Pi-siffror: Resan till ett nytt Pi-beräkningsrekord

StorageReview och våra partners har precis löst Pi till 105 biljoner platser, ett nytt världsrekord som överträffar det tidigare rekordet med fem procent.

Vi är inte främmande för att tänja på gränserna för beräkningar, men den här tar Pi(e). Hot i hälarna på förra årets 100 biljonsiffrigt riktmärke, bestämde vi oss för att höja det och skjuta upp de kända siffrorna i Pi till 105 biljoner siffror. Det är 105,000,000,000,000 3 105 6 XNUMX siffror efter XNUMX:an. Vi gjorde några uppdateringar av plattformen från förra årets körning, hittade några överraskande saker under resan och lärde oss några saker på vägen – inklusive den XNUMX biljonte siffran i Pi;XNUMX!

Genom att uppnå en världsrekordberäkning av Pi till 105 biljoner siffror, har StorageReview-labbet understrukit de otroliga egenskaperna hos modern hårdvara. Denna strävan, som drivs av ett banbrytande 2P 128-kärnigt AMD EPYC Bergamo-system utrustat med 1.5 TB DRAM och nästan en petabyte Solidigm QLC SSD, representerar en landmärkeprestation inom beräknings- och lagringsteknik.

Utmaningen

Under den 100 biljoner digitala körningen mötte vi flera tekniska begränsningar. Serverplattformen stödde till exempel bara 16 NVMe SSD:er i de främre platserna. Även om vi hade gott om CPU-kraft, krävde denna beräkning massiv lagring under processen och på baksidan när den slutliga TXT-filen matades ut.

För att lösa lagringsproblemet förra gången tog vi till PCIe NVME-adapterslädar för att klämma in ytterligare tre SSD:er. Sedan, för utgången, hade vi en hårddisklagringsserver i RAID0, märk väl, med en iSCSI-resurs tillbaka till beräkningsboxen. Den här gången ville vi vara lite mer "företagare" med den här servern, så vi tog in några vänner för att hjälpa till. Intressant nog är det inte så lätt som det kan verka att lägga till ett gäng NVMe SSD:er till en server.

Hårdvaran

Hjärtat i denna monumentala uppgift var AMD EPYC 9754 Bergamo-systemet med dubbla processorer, som erbjuder 128 kärnor vardera. AMD:s processorer, kända för sin exceptionella prestanda i högkomplexa beräkningsuppgifter (AI, HPC, Big Data Analytics), förutsatt de nödvändiga hästkrafterna. Som komplement till detta var 1.5 TB DRAM, vilket säkerställer snabb databehandling och överföringshastigheter. Samtidigt nästan en petabyte av Solidigm QLC-lagring erbjöd oöverträffad kapacitet och tillförlitlighet.

Vår baschassiplattform förblev densamma från förra året (en QCT-låda), men vi uppgraderade processorerna till AMD EPYC 9754 Bergamo-chips. Vi ville gå efter en hastighets- och decimalförbättring samtidigt som vi undvek att använda lagring för beräkningen, vilket innebar att vi var tvungna att anlita SerialCables för att tillhandahålla en JBOF. Detta innebar några utmaningar i sig, som vi kommer att beskriva nedan.

Beräkningsperiod: 14 december 2023 – 27 februari 2024, som sträcker sig över 75 dagar.

• CPU: Dubbla AMD Epyc 9754 Bergamo-processorer, 256 kärnor med simultan multithreading (SMT) inaktiverad i BIOS.
• Minne: 1.5 TB DDR5 RAM.
• Förvaring: 36x 30.72 TB Solidigm D5-P5316 SSD:er.
  • 24x 30.72 TB Solidigm D5-P5316 SSD:er i en JBOF med seriella kablar
  • 12x 30.72 TB Solidigm D5-P5316 SSD:er i servern direktansluten.
• Operativ system: Windows Server 2022 (21H2).

Vägen till 105 biljoner

Stött på utmaningar

En ny komponent i denna körning, som behövdes för att utöka den tillgängliga lagringen till processorerna, var att lägga till en NVMe JBOF. Vår testplattform erbjöd 16 NVMe-fack, med de återstående åtta endast kopplade för SATA. Medan vår 100 biljoner körning utnyttjade tre interna PCIe U.2-adaptrar för att utöka vårt antal NVMe-enheter till 19, var det inte optimalt. För denna omkörning lade vi till en Seriekablar 24-fack U.2 JBOF, vilket hjälpte avsevärt på två sätt: mer dataväxlingslagring och intern lagring av utdatafiler. Ingen mer galen RAID0 HDD-lagringsserver!

Seriekablar 24-bay JBOF tillät oss att nästan fördubbla antalet enheter från vår ursprungliga körning. Vi tilldelade 30 enheter till y-cruncher swap-utrymme, vilket lämnade 6 SSD:er för en Storage Spaces RAID5-utgångsvolym. En stor fördel med det tillvägagångssättet kom under slutsteget, där vi inte hölls tillbaka av hastigheten på en enda 10 Gb-anslutning, som den första 100T Pi-iterationen. Medan JBOF åtgärdade problemet med det totala antalet enheter, introducerade den en begränsning: individuell enhetsprestanda.

I en server med direktanslutna U.2 SSD:er finns det fyra PCIe-banor per enhet. Om varje enhet är direkt kopplad till moderkortet, fungerar det till 96 PCIe-banor för 24 SSD-enheter. JBOF:s totala bandbredd begränsas av antalet PCIe-banor som den kan ansluta tillbaka till värden.

I det här fallet använde vi två PCIe switch-värdkort, och delade upp JBOF i två grupper om 12 SSD:er. Varje grupp med 12 SSD-enheter delade sedan 16 PCIe-banor. Även om vi fortfarande erbjuder avsevärda fördelar med att ansluta SSD:erna till vår värd, hade vi scenarier där växlingsenheter som körs genom JBOF hamnade bakom enheter direkt kopplade till servern. Det här är inte JBOF:s fel. Det är bara en teknisk begränsning eller snarare en begränsning av hur många PCIe-banor servern kan arbeta med.

Sköna läsare kanske undrar varför vi stannade vid 36 SSD-enheter i den här körningen istället för att gå upp till 40. Det är en rolig historia. Adresserbart PCIe-utrymme har sina begränsningar på många servrar. I vårt fall, vid antalet 38 enheter, tog den sista SSD-enheten PCIe-adressen för USB-kretsuppsättningen, och vi förlorade kontrollen över servern. För att spela det säkert backade vi ner det till 36 SSD:er så att vi fortfarande kunde gå in i BIOS eller logga in på servern. Att tänja på gränser leder till några överraskande upptäckter.

Diagnostisk insikt och upplösning

Den första av de två huvudutmaningarna vi stötte på var prestationsrelaterad. Det vi upptäckte var Amdahls lag i aktion. Ett märkligt problem uppstod när y-cruncher såg ut att "hänga" på vårt 256-kärniga AMD Bergamo-system under stora växlingslägesoperationer. Detta häng, kännetecknat av brist på CPU och disk I/O-aktivitet, utmanade konventionella förväntningar på mjukvarubeteende. Detta ledde till en djupdykning i krångligheterna med parallell datoranvändning och hårdvaruinteraktioner.

Upptäcktsprocessen avslöjade att programmet inte riktigt hängde utan fungerade i en kraftigt begränsad kapacitet och körde entrådigt över en expansiv 256-kärnig installation. Detta ovanliga beteende väckte frågor om den potentiella effekten av Amdahls lag, särskilt eftersom de inblandade operationerna inte var datorintensiva och inte borde ha orsakat betydande förseningar på ett system utrustat med 1.5 TB RAM.

Undersökningen tog en oväntad vändning när problemet replikerades på en dator för konsumenter, vilket lyfte fram de allvarliga konsekvenserna av Amdahls lag även på mindre omfattande system. Detta ledde till en djupare undersökning av de bakomliggande orsakerna, som avslöjade en CPU-risk som är specifik för Zen4-arkitekturen som involverar superjustering och dess effekter på minnesåtkomstmönster.

Problemet förvärrades på AMD-processorer av en loop i koden som på grund av sin enkla natur borde ha exekverats mycket snabbare än vad som observerats. Grundorsaken verkade vara ineffektiv hantering av minnesaliasing av AMD:s load-store-enhet. Lösningen av detta komplexa problem krävde både att minska risken för superjustering genom vektorisering av slingan med AVX512 och att ta itu med den avmattning som orsakades av Amdahls lag med ökad parallellitet. Detta omfattande tillvägagångssätt löste inte bara det omedelbara problemet utan ledde också till betydande optimeringar i y-crunchers beräkningsprocesser, vilket skapade ett prejudikat för att ta itu med liknande utmaningar i högpresterande datormiljöer.

Nästa problem uppstod i de sista stegen av beräkningen, som skulle stanna oväntat och inte ge någon information om orsaken till kraschen. Fjärråtkomst beviljades till Alexander Yee, och för första gången på över ett decennium krävde att färdigställa en Pi-post direkt ingripande från utvecklaren.

Vi engagerade oss inte i den här diagnostiska processen, men det fanns ett kritiskt aritmetiskt flyttalsfel inom AVX512-kodvägen för N63 multiplikationsalgoritmen. Alexander kunde diagnostisera på distans, tillhandahålla en fast binär och återuppta från en kontrollpunkt, vilket kulminerar i en framgångsrik beräkning efter att ha implementerat viktiga programvarufixar.

Reflektioner och att gå framåt

Denna strävan illustrerar komplexiteten och oförutsägbarheten hos högpresterande datoranvändning. Att lösa dessa utmaningar satte ett nytt Pi-beräkningsrekord och gav värdefulla insikter om mjukvaruutveckling och testmetoder. Den senaste versionen av y-cruncher, v0.8.4, innehåller korrigeringar för de identifierade problemen, vilket lovar förbättrad stabilitet för framtida beräkningar.

Att beräkna Pi till 105 biljoner siffror var ingen liten bedrift. Det innebar noggrann planering, optimering och utförande. Med hjälp av en kombination av öppen källkod och proprietär programvara, optimerade teamet på StorageReview den algoritmiska processen för att fullt ut utnyttja hårdvarans kapacitet, minska beräkningstiden och förbättra effektiviteten.

Med PCIe Gen4 mättande läsprestanda och branschledande kapaciteter upp till 61.44 TB ger Solidigm QLC SSD:er otroliga resultat. "Föreställ dig vad dessa enheter kan möjliggöra i högpresterande datorer eller AI-intensiva applikationer", säger Greg Matson, VP för strategisk planering och marknadsföring på Solidigm. Vi är glada över att Solidigms SSD:er kunde driva Storagereviews andra rekordstora försök att beräkna pi. Deras ansträngningar bevisar de verkliga egenskaperna hos Solidigms lagringsenheter, vilket öppnar en värld av möjligheter för dataintensiva AI-applikationer.”

Slutsats

Körningen till 105 biljoner siffror av Pi var mycket mer komplex än vi förväntade oss. Vid eftertanke borde vi ha förväntat oss att möta nya frågor; trots allt slutför vi en beräkning som aldrig hade gjorts tidigare. Men med beräkningen på 100 biljoner slutförd med en mycket mer "gastejp och kycklingnät"-konfiguration, trodde vi att vi hade gjort det. I slutändan krävdes det ett samarbete för att få den här riggen över mållinjen.

Medan vi gläds med våra partners i denna rekordstora körning, måste vi fråga, "Vad betyder det här ens?" Ytterligare fem biljoner siffror av Pi kommer förmodligen inte att göra någon stor skillnad för matematik. Ändå kan vi dra några gränser mellan beräkningsmässiga arbetsbelastningar och behovet av modern underliggande hårdvara för att stödja dem. I grund och botten återspeglar denna övning att rätt hårdvara gör stor skillnad, oavsett om det är ett företagsdatacenterkluster eller en stor HPC-del.

För Pi-beräkningen var vi helt begränsade av lagring. Snabbare processorer hjälper till att påskynda matematiken, men den begränsande faktorn för många nya världsrekord är mängden lokal lagring i lådan. För den här körningen utnyttjar vi återigen Solidigm D5-P5316 30.72TB SSD för att hjälpa oss att få lite över 1.1 PB rå flash i systemet. Dessa SSD:er är den enda anledningen till att vi kunde slå igenom de tidigare rekorden och nå 105 biljoner Pi-siffror.

Detta väcker dock en intressant fråga. Många av våra följare vet att Solidigm har 61.44 TB SSD:er i sin D5-P5336 och upp till 30.72 TB i D5-P5430 SSD:er, tillgängliga i flera formfaktorer och kapaciteter. Vi har granskat enheterna och har många inlägg på sociala medier som visar upp dessa otroligt täta enheter. Med 32 av dessa SSD:er som närmar sig 2PB lagringsutrymme kan man undra hur länge de 105 biljonerna siffrorna Pi kommer att stå som världens största. Vi skulle vilja tänka, inte särskilt länge.

Största kända decimalsiffror i Pi

1432360875 9463978314 2999186657 8364664840 8558373926: Siffror till 105,000,000,000,000 XNUMX XNUMX XNUMX XNUMX

Engagera dig med StorageReview

Nyhetsbrev | Youtube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | Rssflöde