StorageReview en onze partners hebben zojuist Pi naar 105 biljoen plaatsen gebracht, een nieuw wereldrecord dat het vorige record met vijf procent overtreft.
We zijn geen vreemden in het verleggen van de grenzen van berekeningen, maar deze neemt de Pi(e). Heet in het verlengde van vorig jaar 100 biljoen-cijferige benchmark, hebben we besloten om het op te voeren en de bekende cijfers van Pi naar 105 biljoen cijfers te duwen. Dat zijn 105,000,000,000,000 nummers na de 3. We hebben een paar updates aan het platform aangebracht ten opzichte van de run van vorig jaar, hebben onderweg een paar verrassende dingen ontdekt en gaandeweg een aantal dingen geleerd, waaronder het 105 biljoenste cijfer van Pi;6!
Met een wereldrecordbrekende berekening van Pi tot 105 biljoen cijfers heeft het StorageReview-lab de ongelooflijke mogelijkheden van moderne hardware onderstreept. Deze onderneming, mogelijk gemaakt door een baanbrekend 2P 128-core AMD EPYC Bergamo-systeem uitgerust met 1.5 TB DRAM en bijna een petabyte aan Solidigm QLC SSD's, vertegenwoordigt een mijlpaal op het gebied van computer- en opslagtechnologie.
De Uitdaging
In de digitale run van 100 biljoen zijn we verschillende technologische beperkingen tegengekomen. Het serverplatform ondersteunde bijvoorbeeld slechts 16 NVMe SSD's in de voorste slots. Hoewel we voldoende CPU-kracht hadden, vereiste deze berekening enorme opslagruimte tijdens het proces en aan de achterkant toen het uiteindelijke TXT-bestand werd uitgevoerd.
Om het opslagprobleem de vorige keer op te lossen, hebben we onze toevlucht genomen tot PCIe NVME-adaptersleeën om er nog eens drie SSD's in te persen. Vervolgens hadden we voor de uitvoer een HDD-opslagserver in RAID0, let wel, met een iSCSI-share terug naar de rekenbox. Deze keer wilden we wat ondernemender zijn met deze server, dus hebben we een paar vrienden erbij gehaald om te helpen. Interessant genoeg is het niet zo eenvoudig als het lijkt om een aantal NVMe SSD's aan een server toe te voegen.
De hardware
De kern van deze monumentale taak was het AMD EPYC 9754 Bergamo-systeem met dubbele processor, elk met 128 cores. AMD's processors, bekend om hun uitzonderlijke prestaties bij zeer complexe computertaken (AI, HPC, Big Data-analyse), zorgde voor de nodige pk's. Als aanvulling hierop was er 1.5 TB DRAM, wat een snelle gegevensverwerking en overdrachtssnelheden garandeert. Tegelijkertijd bijna een petabyte aan Solidigm QLC-opslag ongekende capaciteit en betrouwbaarheid bood.
Ons basischassisplatform bleef hetzelfde als vorig jaar (een QCT-box), maar we hebben de CPU's geüpgraded naar AMD EPYC 9754 Bergamo-chips. We wilden een snelheids- en decimale verbetering nastreven en tegelijkertijd het gebruik van opslag voor de berekeningen vermijden, wat betekende dat we een beroep moesten doen op SerialCables om een JBOF te leveren. Dit bracht op zichzelf enkele uitdagingen met zich mee, die we hieronder zullen bespreken.
| Parameter | Waarde |
|---|---|
| Begin datum | di 19 dec 14:10:48 2023 |
| Einddatum | di 27 februari 09:53:16 2024 |
| Totale rekentijd | 5,363,970.541 seconden / 62.08 dagen |
| Begin-tot-eind-muurtijd | 6,032,547.913 seconden / 69.82 dagen |
Berekeningsperiode: 14 december 2023 – 27 februari 2024, verspreid over 75 dagen.
- CPU: Dubbele AMD Epyc 9754 Bergamo-processors, 256 cores met gelijktijdige multithreading (SMT) uitgeschakeld in BIOS.
- Geheugen: 1.5 TB DDR5-RAM.
- Opslag: 36x 30.72 TB Solidigm D5-P5316 SSD's.
- 24x 30.72 TB Solidigm D5-P5316 SSD's in een seriële kabel-JBOF
- 12x 30.72TB Solidigm D5-P5316 SSD's in de server, direct aangesloten.
- Besturingssysteem: Windows Server 2022 (21H2).
Het pad naar 105 biljoen
| Parameter | Waarde |
|---|---|
| constante | Pi |
| Algoritme | Tsjoednovski (1988) |
| Decimale cijfers | 105,000,000,000,000 |
| Hexadecimale cijfers | 87,200,612,490,794 |
| Inrijgmodus | Cilk Plus werkstelen -> 256 / 256 |
| Werkgeheugen | 1,492,670,259,968 (1.36 TiB) |
| totaal geheugen | 1,492,984,298,368 (1.36 TiB) |
| Logisch grootste controlepunt | 157,783,654,587,576 (144 TiB) |
| Logisch piekschijfgebruik | 534,615,969,510,896 (486 TiB) |
| Logische schijfbytes lezen | 44,823,456,487,834,568 (39.8 PiB) |
| Logische schijfbytes geschreven | 38,717,269,572,788,080 (34.4 PiB) |
Uitdagingen tegengekomen
Een nieuw onderdeel van deze run, dat nodig was om de beschikbare opslag naar de processors uit te breiden, was het toevoegen van een NVMe JBOF. Ons testplatform bood 16 NVMe-bays, terwijl de overige acht alleen bedraad waren voor SATA. Hoewel onze run van 100 biljoen gebruikmaakte van drie interne PCIe U.2-adapters om het aantal NVMe-schijven uit te breiden naar 19, was dit niet optimaal. Voor deze herhaling hebben we een Seriële kabels 24-bay U.2 JBOF, wat op twee manieren aanzienlijk hielp: meer compute swap-opslag en interne opslag van uitvoerbestanden. Geen gekke RAID0 HDD-opslagserver meer!
Dankzij de 24-bay JBOF met seriële kabels konden we het aantal schijven bijna verdubbelen ten opzichte van onze oorspronkelijke run. We hebben 30 schijven toegewezen aan de y-cruncher-swapruimte, waardoor er 6 SSD's overblijven voor een Storage Spaces RAID5-uitvoervolume. Een groot voordeel van die aanpak kwam tijdens de eindfase, waar we niet werden tegengehouden door de snelheid van een enkele 10Gb-verbinding, zoals bij de eerste 100T Pi-iteratie. Hoewel de JBOF het probleem van het totale aantal schijven aanpakte, introduceerde het wel één beperking: de prestaties van individuele schijven.
In een server met direct aangesloten U.2 SSD's zijn er vier PCIe-lanes per schijf. Als elke schijf rechtstreeks op het moederbord is aangesloten, komt dat neer op 96 PCIe-lanes voor 24 SSD's. De totale bandbreedte van de JBOF wordt beperkt door het aantal PCIe-lanes dat het kan verbinden met de host.
In dit geval hebben we twee PCIe-switchhostkaarten gebruikt, waardoor de JBOF in twee groepen van 12 SSD's is gesplitst. Elke groep van 12 SSD's deelde vervolgens 16 PCIe-lanes. Hoewel we nog steeds aanzienlijke voordelen boden bij het verbinden van de SSD's met onze host, hadden we wel scenario's waarin swap-drives die door de JBOF liepen, achter schijven raakten die rechtstreeks op de server waren aangesloten. Dit is niet de schuld van de JBOF. Het is slechts een technische beperking, of beter gezegd een beperking van het aantal PCIe-lanes waarmee de server kan werken.
Oplettende lezers vragen zich misschien af waarom we in deze serie zijn gestopt bij 36 SSD's in plaats van naar 40 te gaan. Het is een grappig verhaal. Adresseerbare PCIe-ruimte heeft op veel servers zijn grenzen. In ons geval nam de laatste SSD bij het aantal van 38 schijven het PCIe-adres van de USB-chipset over en verloren we de controle over de server. Om op safe te spelen, hebben we een back-up gemaakt van 36 SSD's, zodat we nog steeds naar het BIOS konden gaan of op de server konden inloggen. Het verleggen van grenzen leidt tot verrassende ontdekkingen.
Diagnostisch inzicht en oplossing
De eerste van de twee belangrijkste uitdagingen die we tegenkwamen, hadden betrekking op de prestaties. Wat we ontdekten was De wet van Amdahl in actie. Er ontstond een merkwaardig probleem toen de y-cruncher leek te blijven hangen op ons 256-core AMD Bergamo-systeem tijdens grote swap-modusoperaties. Deze vastloper, gekenmerkt door een gebrek aan CPU- en schijf-I/O-activiteit, daagde de conventionele verwachtingen van softwaregedrag uit. Dit leidde tot een diepe duik in de fijne kneepjes van parallelle computer- en hardware-interacties.
Uit het ontdekkingsproces bleek dat het programma niet echt vastliep, maar met een zeer beperkte capaciteit werkte en single-threaded draaide over een uitgebreide 256-core opstelling. Dit ongebruikelijke gedrag leidde tot vragen over de mogelijke impact van de wet van Amdahl, vooral omdat de betrokken bewerkingen niet rekenintensief waren en geen significante vertragingen hadden mogen veroorzaken op een systeem dat was uitgerust met 1.5 TB RAM.
Het onderzoek nam een onverwachte wending toen het probleem werd gerepliceerd op een consumentendesktop, waardoor de ernstige implicaties van de wet van Amdahl zelfs op minder uitgebreide systemen werden benadrukt. Dit leidde tot een dieper onderzoek naar de onderliggende oorzaken, waarbij een CPU-risico aan het licht kwam dat specifiek is voor de Zen4-architectuur, met betrekking tot superuitlijning en de effecten ervan op geheugentoegangspatronen.
Het probleem werd bij AMD-processors verergerd door een lus in de code die, vanwege zijn eenvoudige aard, veel sneller had moeten worden uitgevoerd dan waargenomen. De hoofdoorzaak leek een inefficiënte verwerking van geheugenaliasing door AMD's load-store-eenheid te zijn. De oplossing van dit complexe probleem vereiste zowel het beperken van het gevaar van superuitlijning door vectorisatie van de lus met behulp van AVX512 als het aanpakken van de vertraging veroorzaakt door de wet van Amdahl met verbeterd parallellisme. Deze alomvattende aanpak loste niet alleen het directe probleem op, maar leidde ook tot aanzienlijke optimalisaties in de computerprocessen van y-cruncher, waardoor een precedent werd geschapen voor het aanpakken van soortgelijke uitdagingen in krachtige computeromgevingen.
Het volgende probleem deed zich voor in de laatste stappen van de berekening, die onverwacht stopte en geen informatie opleverde over de oorzaak van de crash. Alexander Yee kreeg toegang op afstand en voor het eerst in meer dan tien jaar vereiste het voltooien van een Pi-record directe tussenkomst van de ontwikkelaar.
We zijn niet bij dit diagnostische proces betrokken geweest, maar er was een kritieke rekenfout met drijvende komma in het AVX512-codepad van het N63-vermenigvuldigingsalgoritme. Alexander kon op afstand een diagnose stellen, geef een vast binair getal op en hervat vanaf een controlepunt, culminerend in een succesvolle berekening na het implementeren van cruciale softwarereparaties.
Reflecties en vooruitgaan
Dit streven illustreert de complexiteit en onvoorspelbaarheid van high-performance computing. Het oplossen van deze uitdagingen zorgde voor een nieuw Pi-berekeningsrecord en leverde waardevolle inzichten op in softwareontwikkeling en testmethodologieën. De nieuwste release van y-cruncher, v0.8.4, bevat oplossingen voor de geïdentificeerde problemen, en belooft verbeterde stabiliteit voor toekomstige berekeningen.
Het berekenen van Pi tot 105 biljoen cijfers was geen sinecure. Het ging om een nauwgezette planning, optimalisatie en uitvoering. Door gebruik te maken van een combinatie van open source en propriëtaire software optimaliseerde het team van StorageReview het algoritmische proces om de mogelijkheden van de hardware volledig te benutten, waardoor de rekentijd werd verminderd en de efficiëntie werd verbeterd.
Met PCIe Gen4 verzadigende leesprestaties en toonaangevende capaciteiten tot 61.44 TBs leveren Solidigm QLC SSD's ongelooflijke resultaten. “Stel je voor wat deze schijven mogelijk kunnen maken in krachtige computer- of AI-intensieve applicaties”, zegt Greg Matson, VP Strategic Planning en Marketing bij Solidigm. We zijn heel blij dat de SSD's van Solidigm de tweede recordbrekende poging van Storagereview om pi te berekenen kunnen ondersteunen. Hun inspanningen bewijzen de ware mogelijkheden van de opslagschijven van Solidigm en openen een wereld van mogelijkheden voor data-intensieve AI-toepassingen.”
Conclusie
De run naar 105 biljoen cijfers van Pi was veel complexer dan we hadden verwacht. Bij nader inzien hadden we moeten verwachten dat we met nieuwe problemen te maken zouden krijgen; we zijn tenslotte bezig met een berekening die nog nooit eerder is uitgevoerd. Maar nu de berekening van 100 biljoen werd aangevuld met een veel meer ‘ducttape en kippengaas’-configuratie, dachten we dat we het voor elkaar hadden. Uiteindelijk was er een gezamenlijke inspanning nodig om dit tuig over de finish te krijgen.
Terwijl we ons samen met onze partners verheugen over deze recordbrekende run, moeten we ons afvragen: “Wat betekent dit eigenlijk?” Vijf biljoen cijfers Pi zullen waarschijnlijk geen groot verschil maken voor de wiskunde. Toch kunnen we enkele lijnen trekken tussen computationele werklasten en de behoefte aan moderne onderliggende hardware om deze te ondersteunen. In wezen weerspiegelt deze oefening dat de juiste hardware het verschil maakt, of het nu gaat om een datacentercluster van een onderneming of om een grote HPC-installatie.
Voor de Pi-berekening waren we volledig beperkt door opslag. Snellere CPU's zullen de wiskunde helpen versnellen, maar de beperkende factor voor veel nieuwe wereldrecords is de hoeveelheid lokale opslag in de doos. Voor deze run maken we opnieuw gebruik van de Solidigm D5-P5316 30.72 TB SSD's om ons te helpen iets meer dan 1.1 PB onbewerkte flash in het systeem te krijgen. Deze SSD's zijn de enige reden waarom we de eerdere records konden doorbreken en 105 biljoen Pi-cijfers konden halen.
Dit roept wel een interessante vraag op. Veel van onze volgers weten dat Solidigm dat heeft gedaan 61.44TB SSD's in de D5-P5336 en tot 30.72 TB in de D5-P5430 SSD's, verkrijgbaar in meerdere vormfactoren en capaciteiten. We hebben de schijven beoordeeld en hebben veel posts op sociale media waarin deze verbazingwekkend compacte schijven worden getoond. Nu 32 van deze SSD's de opslagcapaciteit van 2 PB naderen, kun je je afvragen hoe lang die 105 biljoen cijfers van Pi de grootste ter wereld zullen blijven. We willen graag nadenken, niet erg lang.
Grootste bekende decimale cijfers van Pi
1432360875 9463978314 2999186657 8364664840 8558373926: Cijfers tot 105,000,000,000,000
Neem contact op met StorageReview
Nieuwsbrief | YouTube | Podcast iTunes/Spotify | Instagram | Twitter | TikTok | RSS Feed
