AMD EPYC Turin-cpu's krijgen tot 192 cores en verschijnen in tweede helft 2024

AMD's volgende generatie EPYC-serverprocessors krijgen tot 192 kernen. Dat bevestigt Ceo Lisa Su tijdens haar Computex 2024-keynote. De processors krijgen de codenaam Turin en komen in de tweede helft van 2024 beschikbaar.

AMD's komende EPYC Turin-cpu's worden gebaseerd op de nieuwe Zen 5-architectuur, die de fabrikant ook aankondigde tijdens de Computex. Deze architectuur biedt volgens AMD gemiddeld een tot 16 procent hogere ipc dan Zen 4, dat in 2022 werd geïntroduceerd.

De server-cpu's krijgen volgens Su dertien chiplets op een enkele package. De Turin-chips krijgen daarmee maximaal 192 cores en 384 threads, zo bevestigt het bedrijf. Vermoedelijk betreft dat een variant met Zen 5c-cores, die een hogere dichtheid hebben dat de reguliere Zen 5-architectuur. Volgens eerdere geruchten komen Turin-chips met 'gewone' Zen 5-cores beschikbaar met maximaal 128 kernen. De nieuwe chips gebruiken de SP5-socket, die ook werd gebruikt voor de vorige EPYC Genoa-processors. Enterprisegebruikers kunnen bestaande Genoa-systemen dan ook upgraden naar Turin.

In een demo claimt AMD dat een Turin-cpu met 128 cores tot 3,1x sneller is dan een Intel Xeon 8592+ met 64 cores in een wetenschappelijke STMV-workload. Volgens AMD is zijn chip ook aanzienlijk sneller in verschillende AI-workloads, bijvoorbeeld rondom het implementeren van Meta's Llama 2-opensourcemodel en het genereren van tokens voor verschillende AI-taken. AMD's nieuwe Turin-chips komen in de tweede helft van 2024 beschikbaar, maar de fabrikant deelt geen concrete releasedatum.

Reacties (29)

[Moobear]

Ben wel benieuwd naar benchmarks van dit monster

[uncle_sjohie]

Soms zie je deze wel voorbijkomen bij youtubers, maar die lopen er tegenaan dat veel multicore benchmarks niet schalen voorbij zeg 32 of 64. Daarna kom je in zulke specifieke benchmarks terecht, dat anders dan echte vakspecialisten, niet veel mensen er wat aan hebben. Dus dan wordt het wat nietszeggend voor zeg sites als Tweakers, en zijn er onderwerpen die meer kliks genereren in relatie tot kostbare voorpagina ruimte.

[Ellej_Harmsen]

Hoe goed je berekeningen schalen op het aantal computer cores hangt enorm af van je berekeningen (open deur). Maar wat er veel fout gaat in benchmarks op YouTube is dat alle cores tegen hetzelfde rekenprobleem aan gegooid worden. Vaak gebruik je minder cores per simulatie en voer je gewoon meer simulaties tegelijkertijd uit.

Voor wat meer achtergrond:
Ik gebruik momenteel veel clusters voor mijn wetenschappelijke berekeningen en heb hier nu best veel ervaring mee.
Ik gebruik momenteel regelmatig AMD Milan en Genoa cpu's (op Snellius, zie https://tweakers.net/revi...t-voor-de-wetenschap.html of Intel Xeon Cascade lake of Sapphire Rapids (Universteits cluster van de TU Delft https://doc.dhpc.tudelft.nl/delftblue/DHPC-hardware/). Wij zijn naast de AWS's van deze wereld natuurlijk een deel van de doelgroep.

Mijn eigen simulaties schalen ook slecht boven de 64 cores (dat geeft 60% parallel efficiency). Maar dat is helemaal niet erg, ik moet verschillende simulaties tegelijkertijd runnen. Normaal gesproken doe ik er 5 tegelijk met exact dezelfde settings omdat mijn resultaten ook random processen erin hebben en ik zo een foutmarge van mijn resultaten kan berekenen. Daarnaast moet ik ook verschillende situaties berekenen (in mijn geval materiaal voorspellingen met verschillende temperaturen en drukken). Dus ik heb al gauw 8*5 simulaties lopen van 64 cores.

Ik heb ook collega's die wel goed schalende simulaties hebben. Denk aan 10 Snellius nodes voor een enkele simulatie -dus 1920 cores- die nog steeds een 80% parallel efficiency halen. Bij het indienen van een rekenaanvraag bij dit soort cluster moet je vaak ook aantonen hoe jouw software (en specifieke simulatie case) schaalt op het aantal cores en nodes van het cluster. Het voordeel van dit soort hoge core count cpus van AMD is dat het flexibel is voor de workload (van node naar node communiceren is tenslotte altijd langzamer dan binnen één node blijven). Verder is het compacter in de server ruimte, heb je minder netwerkapparatuur nodig en vaak is het per core ook zuiniger dan de alternatieven van Intel.

Al met al wil ik vooral zeggen dat je je niet hoeft stuk te staren op het idee dat veel workloads niet meer schalen bij dit soort extreme core counts. De meeste mensen die er mee werken weten dit en gaan er slimmer mee om dan alle cores voor dezelfde rekentaak gebruiken, terwijl zij die het nodig hebben wel deze grote core counts kunnen gebruiken.

Extra:
Dit is ook waarom het lastig is om dit soort hardware en wetenschappelijke software te benchmarken voor een website zoals tweakers. Echte gebruikers zullen zelf de compiler setting tweaken. Wij testen onze software met verschillende OpenMPI/openMP setups, verschillende compilers (gcc, icc (intel), AOCC (AMD)) en wiskunde library's (Blas/lapack/fftw, OneMKL, AOCL) voor soms zelfs specifieke simulaties. Je kunt van tweakers (of Linus tech tips) niet verwachten dat zij medewerker(s) hebben die voor allemaal specifieke rekentaken van de cloud, financiële en wetenschappelijke wereld weten hoe ze voor dit soort hardware moeten optimaliseren voor de benchmark gedraaid wordt. Voor het runnen van Doom (of Excel) kan dit natuurlijk wel en daarom zijn consumenten hardware benchmarks zo nuttig.

(veel te lange uitleg )

[Rob Coops]

Ik denk toch dat veel mensen wel zouden willen weten welke chip nu echt sneller is maar, het is inderdaad zo dat de moderne high-end server chips aan dingen werken die we als gewone stervelingen niet meer kunnen bevatten. Een beetje zo als een super computer alleen beschreven wordt in termen als core's, ram, storage en linpack score maar er vrijwel niemand is die daar echt een conclusie uit kan trekken om te bepalen of dit model of dat model nu echt zo veel meer nodig heeft of dat een machine die maar 1MW gebruikt niet voordeliger zou zijn ondanks dat deze toch echt wat meer tijd nodig zal hebben voor de berekeningen...

Er zullen vast een aantal tweakers zijn die deze nieuwe EPYC monsters op de pijnbank mogen leggen en er ook echt nuttige dingen mee doen niet alleen benchmarks draaien maar die groep is erg klein de meeste mensen werken niet met workloads die dit soort chips nodig hebben.

Aan de andere kant het lijkt me toch wel leuk om eens te zien wat zo'n ding nu kan doen. Een van de leukste manieren om dit soort chips te testen vond ik toch wel het geen Dave Plumber deed toen hij zijn EPYC CPU zo veel mogelijk Doom instances liet draaien. Gewoon omdat Doom overal op draait en het hem toch wel leuk leek om eens te zien hoe veel sneller meer Doom je kon draaien op een EPYC CPU. En hij zich ook niet echt een betere methode kon bedenken om een redelijk begrijpelijke test uit te voeren die alle cores zou belasten. Hij deed ook wat compiler werk maar inderdaad lang niet alle cores werden aan het werk gezet en dus ondanks dat het ding wel sneller was was de snelheidswinst beperkt omdat de vorige CPU waar hij mee werkte evenveel cores had die hier voor ingezet werden en je dus alleen de kleine verbetering in de clock snelheid zag ze hadden immers beide de zelfde architectuur.

[NEO256]

Pfff, gebruik een beetje fantasie.
Draai Seti@home, PI95 of een andere PI berekening programma. Alles wat maar "onbeperkt parallel kan draaien" zolang je vervolg berekeningen, maar niet afhankelijk zijn van het resultaat van je de deel berekening. Die schalen "bijna onbeperkt".

En voor de echte wereld, zet er maar eens wat NVMe's onder een TB of meer aan RAM en draai er maar eens een paar petabyte aan database op waar je een paar duizend lees acties per seconden op doet, alla wat ze bij CERN doen. En ga dan eens wat lekker rapportages draaien met wat leuke correlaties zodat hij bijna elke rij en kolom door moet gaan zoeken.

Dan ga je zien hoe fijn het is om zo-veel-cores in 1 machine te hebben en nog liever op 1 package.

Disclaimer, de stukken die ik tussen aanhalingstekens zet ik er expres zo in omdat ik weet dat er nuance is, maar ik wil mijn voorbeelden wat overzichtelijk houden voor "normale stervelingen".

[Reactie gewijzigd door NEO256 op 23 juli 2024 18:27]

[Rob Coops]

Als je een instituut als CERN nodig hebt om aan te geven hoe zo'n CPU nuttig gebruikt kan worden...

Ik weet heus dat het wel nuttig kan zijn maar de hoeveelheid taken waar je dit nuttig inzet zijn vrij beperkt voor de meeste organisaties, en voor thuis gebruik is het voorlopig niet nuttig om zo'n CPU te gebruiken.

Nogmaals ik weet dat het zeker een nuttig ding kan zijn maar ik denk dat het wel echt om heel specifieke taken gaat die je in het wild niet vaak tegen zal komen.

[NEO256]

... Ik wil geen vette starten.

En elk woord dat ik na de zin hier boven type is redundant als dat mijn enige doel zou zijn.
Want... Ja, dit stuk hardware is er voor specifieke taken en prima, ik geloof dat je de toepasbaarheid in kunt schatten... Maar eerlijk gezegd vindt ik dat minder belangrijk, want ik lees en reageer altijd vanuit de gedachte dat ik het "algemene publiek probeer in te lichten waarom bepaalde uitspraken wat meer genuanceerd zijn dan ze lijken" mijn, jou of een andere gebruikers begrip over een onderwerp, moet zover als mogelijk in mijn persoonlijke beleving graag gewogen zijn tot een punt dat ik er vanuit kan gaan dat je informatie toevoegt aan het artikel die zoveel mogelijk klopt.

Andere invalshoek; is je standpunt dat deze CPU niet interessant is voor Tweakers.net, want de toepasbaarheid is te specifiek?

[Ellej_Harmsen]

Ik denk dat je zeker gegelijk hebt om te zeggen dat er tweakers zijn die dit kunnen (en doen ). Ik bedoelde het voor het test-team van de website zelf. Er zullen genoeg tweakers (lezers/forum gebruikers) kennis en ervaring hebben dit soort systemen.

Op die note, ik zou het wel geweldig vinden als we een keer een interview hebben van een ict'er die werkt voor het KNMI, of een andere instelling die bijzonder veel rekenkracht nodig hebben. Iemand van SURF die meer de ict en software kant laat zien dan de hardware zou ik ook al bijzonder leuk vinden.

PS: Dave Plumber heeft idd best leuke filmpjes. Ik heb ook genoten van zijn programming languages drag race serie.

[lasermen]

Volgens mij is dit één van de laatste interviews die hier op de website is geweest over grote systemen: review: Datavloedgolf LHC op komst - Nikhef bereidt zich voor met rappe opslag

Al is de geinterviewde persoon laatst wel bij MNOT podcast te gast geweest.

Zou wel erg leuk en interessant zijn als er meer artikelen over grote hoeveelheden rekenwerk en hoe men daarmee omgaat gemaakt worden.

[polycombGC]

Lekker veel cores, maar het L3 cache lijkt me niet zo groot voor zo veel cores. 2.6MB per core, vs 8MB per core voor bijv een consumenten 7950X3D. Dus als je geheugen intensieve berekeningen hebt, waar je threads weinig overlap hebben qua data waar ze aan werken zal de performance misschien wel een beetje tegen gaan vallen? Al die cores blijven aan het RAM trekken, en hoe meer je er hebt, hoe minder bandbreedte je hebt per core.

[_Thanatos_]

Ik denk dat als je zoveel geld aan een CPU gaat uitgeven, dat je wel heel goed nadenkt over de workload en of die erbij past. Uiteindelijk is het altijd kiezen of delen. Je kunt niet 192 van de cores van de 7950X3D op 1 package schroeven. Als je zoveel cores wil, dan moet je ergens op inleveren.

[divvid]

exact. Voor sommige workloads is minder CPU's maar meer geheugen per CPU gewoon beter. Bij andere tools juist weer andersom. Helaas zitten veel van onze workloads in "veel CPU én veel geheugen"

[kujinshi]

Ik denk dat je de workload echt in een renderfarm moet zoeken of in een server die heel veel gebruikers tegelijk aan kan. Of een indeling met veel virtuele ruimtes, dat je bijvoorbeeld 4 cores per ruimte hebt keer 48.

[SRI]

Maar nu vergelijk je het ook met de X3D varianten die riant veel L3 geheugen hebben. Dit levert bij gaming bijvoorbeeld goede resultaten. Maar heb je ook genoeg winst om een dergelijke toevoeging voor server chips te doen? En ik kan mij voorstellen dat het qua warmteontwikkeling ook een probleem kan geven.

En deze CPU's hebben wel iets meer dan de voor consument gebruikelijke 'dual channel' geheugen setup.

Ik vermoed (en AMD ook, anders zouden ze het niet maken) dat hier echt wel een markt voor is. Misschien dat voor specifieke eisen deze CPU's in een server de minder goede optie zijn en voor andere juist weer de betere. Maar dat is ook onderdeel van als je een server configureert/leased/..., je doet onderzoek naar wat je ermee wilt doen en wat daarbij het beste past. De ene wilt terabytes aan RAM om een database in memory te houden, de andere weer enorm veel opslag maar een 'trage' CPU omdat het veel al alleen 'opslaan' is. Beetje gevalletje van 'zoveel mensen, zoveel wensen'.

[NEO256]

Wat ik proef is dat veel CPU RAM cache veel oplevert door branche prediction, zie ook de eerst 1h 10m minuten van deze WAN SHOW.
YouTube: Why Do Youtubers Keep Destroying Companies - WAN Show April 19, 2024

Dit hoofdstuk precies:
YouTube: Why Do Youtubers Keep Destroying Companies - WAN Show April 19, 2024
Zie timestamps voor hoofdstukken begin/einde.

Dit is the architect van de AMD Ahtlon XP en hij heeft nog wel meer accolades onder zijn riem.
Zijn voorspelling lijkt te zijn dat ARM en RISC de toekomst gaan zijn, omdat je veel sneller kunt rekenen als je niet zo'n grote instructie sets ondersteund. Want elk van die dingen neemt een significante ruimte in op je fysieke chip ontwerp, nog niet te spreken over legacy support.

Mijn bottom line is, dat als je niet triviale berekeningen doet, dan heb je "niets" aan veel CPU cache, want het resultaat is niet te voorspellen, wellicht dat stukken van berekeningen kunnen worden opgehaald, maar hoe complexer de berekening hoe minder dat het oplevert.

[Reactie gewijzigd door NEO256 op 23 juli 2024 18:27]

[ScharlakenRood]

Vraag mij wel af, zijn de mainstream OS klaar om zoveel cores goed in te zetten. OSs zoals Solaris kunnen sinds 2010 al overweg met max 1024 cores/threads omdat dat moest. Gelukkig is er hierdoor wel veel kennis, maar wil nog niet zeggen dat dit ook kan ingezet worden voor massive workloads. Vele virtuele machines is waarschijnlijk wel een gemakkelijk haalbare kaart voor dit soort processoren in de korte termijn.

[Argantonis]

Het lijkt mij dat zij, een miljardenbedrijf met enorm inzicht in de markt, hier voldoende onderzoek naar hebben gedaan.

[SG]

Je bedoeld mijden van shared data of algoritmen en data structuren shared. Locks mutexen zijn er voor thread safe niet voor parallel compute het meer voor mijden van undefined behavior. Werkt als stoplicht.
CPU houden van data sequentieel achter mekaar STD::ARRAY STD::VECTOR
Als je dan loop compute door die vector. Bijvoorbeeld 100000 positie die met velocity geupdate worden kan je die vector compute verdelen over aantal threads.
Elke thread haalt dan cachelines 64Bytes na mekaar binnen prefetch en dus stroom aan data nauwelijk code dus icache blijft hot. Crunch er door heen.
Kan zijn dat geheugen de cache kan bijhouden en dat kan dus zijn dat je maar 512KB voldoende is ipv 2MB. Goed ontwikkelde MT software heeft geen grote caches nodig het is de juist de slechtste. Als game rond jumped dus pointers volgt naar wild groei aan data structuren verdeeld over de heap als dit 300MB is en je hebt 20MB cache dan krijg sneller cache misses. Als 100MB cache hebt dan ga kwa performance zwaar vooruit. Een runtime data pool van 40MB en je CPU heeft 40MB cache dan kan meeste in de cache zitten en presteert game goed op 10MB lowbudget cpu kan flinke hit krijgen
Sommige software problemen zijn niet paralleliseerbaar dan heeft heel veel cache veel zin.
Goed geschreven MT code heeft niet zoveel cache nodig net genoeg stream uit memory bij te kunnen houden. Dat komt bij prof software voor dan MT goed uitgevoerd is en dus x3dvcache slechter kan presteren door lagere klok.

[lasermen]

Ze zullen vast rond de Supercomputing conferentie beschikbaar zijn. Puur op basis wat AMD in het verleden vaker heeft gedaan.

De hoeveelheid cores gaat hard omhoog. Ze hebben het stroomverbruik nog redelijk in toom weten te houden.

[Luke_vda]

kijk een perfecte cpu voor mijn game pc

[uncle_sjohie]

Dat zou je nog tegenvallen. Een X3D AMD processor zal bijna zeker de betere gaming CPU zijn.

[Luke_vda]

niet te serieus nemen het is gewoon een sarcatische opmerking over het feit dat tegenwoordig de optimalisatie dikke shit is van de meeste games

[uncle_sjohie]

Doe dan even /s volgende keer.

[SRI]

Zit je gewoon maar wat te 'typen' of ben je serieus hier?

Want games schalen over algemeen nog steeds niet eindeloos over het aantal cores. Ze zijn veel meer gebaat bij enkele hele snelle cores dan tientalen 'trage'. En ook andere factoren spelen mee zoals bijvoorbeeld veel L3 geheugen zodat je minder cache misses hebt.

Ik denk dat die duizenden euro's die je bespaart door een 'normale' CPU te kopen beter gespendeerd kunnen worden aan een top notch videokaart.

[Luke_vda]

even als herhaling niet te serieus nemen het is gewoon een sarcatische opmerking over het feit dat tegenwoordig de optimalisatie dikke shit is van de meeste games

[PiHole]

een /s helpt meestal. Maar ik snap dat je per thread 1 vakje van je minesweeper wil toekennen.

[SRI]

Al zou je het optimaliseren, als ze voor zulke excessen gaan optimaliseren lijkt het mij weggegooid geld.

In geschreven taal zijn 'sarcastische tonen' nogal lastig te lezen

[Luke_vda]

dat kan ik zeker begrijpen daarom was het vervolg berichtje erop om het duidelijk te maken

[SG]

Games worden gemaakt voor mainstream CPU en G-kaarten en sysram vram.
Worden gefinancieert door publishers en die willen volume sales zien.
Game engine prioriteit gedreven doordat gamedev productie kosten met de tijd groter zijn geworden en de content complexer door de toenemende rekenkracht.
Tijd is geld dus om productie kosten en dus ook tijd meeste er uit te halen moeten game engines zwaar data driven zijn en goede efficiente content pipeline waar je art team productie efficient content kan opleveren. En dan is Performance nog steeds belangrijk maar ondergeschikt aan data driven. Ivm de mainstream vaker wel meer dan 4 cores heeft waar 8 nog niet solide mainstrean is. Hoeft engine engineer threadpool te implementeren die max tot 8 threads gaat en dat voldoende . Sommige gaan verder omdat soort game enigzins paralel loads heeft zoals RTS of massive online maar singleplayer corridor shooter niet.

Dev en publisher doet threadripper of 4090 owner niet toe. Optioneel kan er zwaardere setting voor hun zijn of ze halen insane fps. Maar Minimum en recommended is belang rijk. Dus diegene met 10th gen en 2060 is belangrijker als FPS target. MT 4 tot 8 threads is zat.
De grote Dev en publishers hebben zwaar doorontwikkelde game engine. Dus wel degelijk lange evolutie aan features en optimalisatie maar ook sterke nadruk op data driven. Zwaar MT optimalisatie brengt publisher niks. De CPU load is vaak fix load wat mainstream aankan en moderne veel core cpu ook makkelijk aankan. Maar door vaker wat lagere klok iets inlevert.