Mogelijke AMD Threadripper-cpu's met 96 cores verschijnen bij computeplatform

Er zijn mogelijke AMD Ryzen Threadripper PRO 7000-cpu's verschenen op een computeplatform. De cpu's hebben 96 cores, net als de recent uitgebrachte EPYC-cpu's op basis van Zen 4. Het is niet bekend wanneer Threadripper-modellen met Zen 4 verschijnen.

Verwijzingen naar de vermeende Threadripper-processors zijn verschenen op het distributed computing-platform Einstein@Home van de Universiteit van Wisconsin-Milwaukee, merkte Twitter-gebruiker Benchleaks op. Het zou gaan om Threadripper-chips met de codenaam Storm Peak. De bijbehorende OPN-codes zijn nog niet te vinden in de publieke lijst van AMD, wat betekent dat het processors betreffen die nog niet worden verkocht of grootschalig geproduceerd, merkt ook VideoCardz op. Dat zou betekenen dat het niet om EPYC-processors met Zen 4 gaat, aangezien AMD die recent al uitbracht.

Op Einstein@Home zijn zeker twee verschillende van deze AMD-engineeringsamples te vinden, die allebei beschikken over 96 cores en 192 threads. Dat doet vermoeden dat het om cpu's gaat met twaalf ccd's, net als de recent uitgebrachte EPYC 9004-serie serverprocessors. Een van de geteste samples heeft een baseclock van 2,0GHz, terwijl dat bij de andere sample op 2,1GHz ligt. Aangezien het engineeringsamples zijn, is het onwaarschijnlijk dat dit de definitieve kloksnelheden zijn. Verdere specificaties, zoals de boostclock en de tdp, worden niet bevestigd.

Er verschenen eerder dit jaar al geruchten over de vermeende Threadripper PRO 7000-serie. Techwebsite Wccftech kwam modellen met 64 cores tegen op hetzelfde Einstein@Home-platform, met een soortgelijke OPN-code. Gelet op het gebruikte platform en de familie- en modelnummers, zou het gaan om Threadripper-chips, schreef die website toen.

AMD bevestigde eerder dat het in de toekomst alleen nog Threadripper PRO-modellen uitbrengt voor bedrijven en professionals. Goedkopere non-PRO-modellen voor consumenten, met minder geheugenkanalen en PCIe-lanes, worden geschrapt. Het is niet bekend wanneer AMD zijn Threadripper PRO-chips met Zen 4 uitbrengt. De huidige Threadripper PRO-generatie op basis van Zen 3 verscheen in maart van dit jaar.

Reacties (56)

[Da_Teach]

Waar je hier wel rekening mee moet houden is dat software specifiek geschreven moet zijn om meer dan 64 cores aan te kunnen. Je komt anders zowel op Linux als op Windows een probleem tegen dat de oude thread-apis niet overweg kunnen met meer dan 64 cores.

In Windows ben je dan overgeleverd aan processor groepen (of meerdere instances van dezelfde software). Volgens mij is er in Linux ook zo iets maar weet ik niet helemaal hoe het dat zat.

Wij hadden ooit dual cpu servers waarbij je op 72 cores uit kwam, was drama om die allemaal te gebruiken met software die daar niet mee overweg kon.

[hooibergje]

Waar zit die beperking dan in?
Zelfs indien het aantal threads in een 8-bits int zit, komt je nog steeds op 256 uit.

[eejin]

Thread affinity APIs gebruiken een bit per core in een 64 bit integer om aan te geven op welke core een thread moet draaien

[Da_Teach]

Affinity is (als ik het zo goed uit mijn hoofd zeg) een bitwise flag. Je mag draaien op deze cores. En dat is een/was 64bit. Ofwel 64 toggles voor aan en uit.

Voor Linux weet ik zo niet welke call het was (ook al ben ik er redelijk zeker over dat Linux een soort gelijke limitatie had), voor Windows deze; https://learn.microsoft.c...ase-setthreadaffinitymask

Heel veel software ondersteunt dit gewoon niet. En dan krijg je in het algemeen sub optimale resultaten. Zelf ooit een patch geschreven voor een cpu miner die zonder thread affinity zetten dus niet alle cores gebruikte.

[Verwijderd]

Geloof dat de nieuw linux scheduler al een boel helpt, welke mee komt in kernel >= 6.0
https://www.phoronix.com/...inux-Scheduling-Warm-Core

[hooibergje]

Heel gaaf!

Je moet dan wel echt rekening gaan houden met scaling issues van je software.
Iets parallelliseren over een paar cores is meestal nog te doen zonder al te veel problemenen, maar de meerwaarde van een dergelijk aantal cores geeft maar voor een zeer beperkt aantal taken echt toegevoegde waarde.

[killercow]

Zo ongeveer elke 'cloud' of 'web' taak is hier geschikt voor, want juist al die taken bestaan al lang en breed uit duizenden kleine requests.
Ook allerlei machine learning zaken zijn eigenlijk allemaal paralelliseerbare taakjes.
Wat je hier als consument nu mee moet? Niet zo veel. Maar voor een workstation oid is het prachtig.

[hooibergje]

Voor Matrix-vectorvermenigvuligingen (zoals die in machine learning) werken ze inderdaad als een zonnetje. :-)

Rendering en raytracing zal er ook wel flink baat bij hebben.

(Ik weet geen donder van 'cloud' of 'web', dus kan daar niks over zeggen.)

[killercow]

Elke page-hit op het web kan netjes naar een losse core. dus je kunt iig 96 losse requests tegelijk afhandelen. (zelfs als die zwaar zijn en seconden lang de hele core gebruiken kom je binnen de timeouts tot een antwoord.) Of je kunt 96x keer zo veel kleine requests doen dan wat 1 core kan handelen. (mits je al die requests netjes weet over te dragen naar een eigen core natuurlijk).

[jbhc]

192 requests aangezien het ding ook nog eens hyper threading doet

[Ayporos]

je bedoelt natuurlijk SMT (Simultaneous Multithreading).
'Hyper Threading' is wat Intel het noemt.

[Osiummaster]

ML is zeker niet allemaal parallel. Sterker nog, omdat er vaak Python gebruikt wordt draait het meestal allemaal op slechts 1 core.

Het parallelle gebeurt op videokaarten welk daar veel geschikter voor zijn,

[rjkers]

Dat denk ik niet. Als je pure Python gebruikt en zelf alles doet heb je allicht gelijkt, maar Python haalt z'n kracht uit het gebruik van wrappers die als library te gebruiken zijn. Om een voorbeeld te noemen, Keras loopt vrij zeker niet op 1 core.
https://keras.io/

Het resultaat aggregeren zou prima op 1 core kunnen draaien, maar dat is peanuts als je de load vergelijkt met het daadwerkelijk trainen (matrix multiplicaties) van het netwerk.

Edit:
iets directer voorbeeld: https://stackoverflow.com...n-keras-on-multiple-cores

[Reactie gewijzigd door rjkers op 23 juli 2024 15:54]

[MSalters]

Ik heb hier net een Ryzen 7950X in gebruik genomen voor ML. Numpy met MKL kan prima gebruik maken van meerdere cores (wel even de Intel check uit MKL slopen)., en sowieso kun je preprocessing van je inputs parallelliseren.

[Tricyrtis]

Als je zelf pipelines programmeert kun je paralleliseren waar het kan en waar je wil. Dingen als cross-validation en subset selection zijn allemaal perfect te paralleliseren.

[Verwijderd]

je kan een boel python processes spawnen en die individueel hun eigen taak geven.
bijv met een lib zoals multiprocessing

[strompf]

Webservers zijn inderdaad een geweldig voorbeeld van paralleliseren, maar het kan veel dichter bij huis: Elke keer als je een loop programmeert, is dat een kans om dingen parallel te laten uitvoeren. Ipv. seriëel door een reeks getallen te gaan, bied je de complete loop als een vector aan. En dat is geen ver-van-je-bed-show: Binnen Bash (standaard Linux-shell) kun je dat doen mbv. GNU Parallel. En SQL werkt standaard op deze manier (in SQL programmeer je eigenlijk nooit loops). Ik vermoed dat dit veel vaker de situaties is rondom 4GL's/declaratieve talen. Het staat me bij dat je bv. rondom XML ook niet met loops werkt.

Voorbeeld: Ik doe marketing automation waarbij ik oa. tegen WordPress programmeer via de WP-CLI (API). Die is geschreven in PHP en is vreselijk traag. Gelukkig zijn die calls moeiteloos te paralleliseren, zodat alle 32 cores van de betreffende server tegelijkertijd bezig zijn. Dat scheelt een hoop.

[hooibergje]

Parallel in bash is inderdaad al geniaal.
Een paar threads is snel gemaakt. Zo heb ik laatst een practicum voor studenten aangepast zodat 6 plotjes van data die ze hebben gegenereerd tegelijk worden gemaakt. Scheelt ze weer wat tijd. Maar het aantal situaties waarom je 96 threads kan maken is dun gezaaid...

OpenMP directives of Concurrent do loops helpen ook al enorm, maar in mijn ervaring zie ik niet zo vaak plekken waar er eenvoudig vele tientallen threads te genereren zijn.

[jaxxil]

Maar het aantal situaties waarom je 96 threads kan maken is dun gezaaid...

Is dat zo? Ik weet dat ik bijvoorbeeld als webdev vaak loops had over alle deelnemers van een bepaald evenement, of alle reacties op een pagina, etc. Ik had achteraf gezien best vaak 96 cores, 192 threads kunnen inzetten, en dat was al in gewoon een kleine webdev startup met 3 man personeel.

[hooibergje]

Je *kan* wel 96 threads maken, maar het maken van een thread kost ook tijd, en als de taakjes in een thread maar heel klein zijn is die overhead al snel meer dan wanneer je alle 96 gewoon serieel er doorheen zou jagen op 1 core.

Als de taken groter worden is het natuurlijk wel een enorm voordeel. Als je per deelnemer een hoop moet doen dan zal zo'n processor daarbij een wereld van verschil maken.

[jaxxil]

Ah, makes sense. Meestal waren de taken inderdaad klein genoeg om het inderdaad niet waard te zijn om te paralleliseren, zoals bijvoorbeeld in het geval van de reacties. We deden er dus ook niet aan. Maar er waren zeker ook wel zwaardere loops over deelnemers die flink voordeel hadden kunnen krijgen uit multithreading, helaas werden de problemen vaak opgelost door er gewoon een dikkere VM tegenaan te gooien. Het developen van features had af en toe flink prioriteit boven tech debt, zoals het gaat bij veel startups. Maar overhead verklaart waarom er minder nuttige situaties zijn dan je zou denken, dank voor de uitleg!

[hooibergje]

Graag gedaan!

Het helpt ook om te realiseren dat een CPU veel sneller kan rekenen dan vaak gedacht.
By typische alledaagse taken is een CPU ongeveer 80% van de tijd kwijt aan data kopieren tussen verschillende geheugenlagen (disk, ram, lvl [3-2-1] cache, register]. Slechts 20% wordt er echt iets uitgerekend. Dat is ook precies waarom multithreading zo goed kan werken. Als de ene thread moet wachten op data, kan de andere thread in de tussentijd rekenen. Als de context switches heen en weer tussen de threads sneller zijn dat de wachttijd heb je gratis runtime.

Als je de goede data eenmaal in het cache hebt staan, en je kan er meteen aan doorrekenen, dan kost dat maar heel weinig extra tijd om nog meer aan diezelfde data te rekenen!

[Wolfos]

Behalve dan in algoritmes die de resultaten van de vorige iteratie nodig hebben, en dat zijn er enorm veel.

[dasiro]

multicore/thread-CPU's zijn ondertussen al een eeuwigheid in IT-termen verkrijgbaar, dus ik denk dat het merendeel van de systemen waar dit soort CPU's in terecht komt wel degelijk software draaien die ervoor geoptimaliseerd is, anders ga je geen duizenden euro's tegen een enkele component gooien

[flippy]

hoeft nog niet eens, je kan ook 48 VM's maken om werknemers op te laten werken.

[dasiro]

een hypervisor is ook software

[flippy]

Software zoals proxmox kan dat makkelijk hebben.

[dasiro]

daarom juist: proxmox is een hypervisor

[Yzord]

Toch wel een dikke poep cpu zeg. Zou best wel een kastje willen bouwen met deze badass erin. Hopelijk komt deze snel de consumentenmarkt op. Lekker over the top kastje bouwen.

[amelsander]

Waarom zelfs, Threadripper voor consumer gebruik is als een Lamborghini kopen om binnen de bebouwde kom te rijden, allemaal goed en wel maar je gebruiktnog geen 10% van het vermogen. Flexen kan je met zoveel meer dan met een TR cpu.

[silenoz]

Dit is eerder een Lamborghini traktor voor in de bebouwde kom
Ja je hebt erg veel koppel vergeleken met een normale auto maar erg snel is het niet.

[SG]

In de auto branch is W16 motor het max
Maar ja een 10 liter 40cillinder in 8cil banks zal ook niet veel meerwaarde brengen om dan A naar B te rijden. Naast complexiteit.

De pcores zijn voor algemene non game task voor de massa kwa kloks en 8 stuks al overkill. Meeste consumenten taken hebben aan 2 pcores al genoeg met paar ecores.
Het zijn vooral games dat slecht schalen maar dat is meer bij design. Games doel is volume sales en efficient ontwikkelen dus produceren van game. En dat betreft game content. En dus de target is low bound mainstream target dat pas begint te shifter voorbij 4 cores. Dus het kan mogelijk stuk beter MT maar dat is niet in het grootste belang voor game engine. Daar is efficient content team en asset pipeline zijn belangrijker. Op enkele dev die tech wel willen pushen.
Maar voor 16core 32 thread kijg je het volgende probleem dat 6pcore instapper of 8core zen instapper het in te veel task het stuk beter doet of performance benaderd van 16c/32core halo SKU en dat die in enkele specifieke voornamelijk pro software wel goed maar soms ook matig schalen .
Dan is een 96/192 kan dan voornamelijk alleen in deel van de pro software schalen die ver voorbij de 16 cores schalen. Sommige pro software schaald ook niet zo lekker bij 64cores.

Naast dat veelsoftware dat wel goed schaalt gpgpu kan gebruiken
Naast dat in de toekomst ook nog beter acceleratoren worden toegepast voor specifieke taken die kwa performance watt zelfs gpgpu overtreffen.

[Troepje]

En toch ben ik erg blij met mn (niet pro) threadripper. Op het moment voor een ontwerp een beetje aan het testen met cfd. Wanneer mn simulatie loopt kan ik tegelijk gamen en merk dr praktisch niks van.

[amelsander]

Dat is logisch, maar de post waarop ik reageerde spreekt van de 96cores versie in in consumer case te zwieren.

[Troepje]

Ik had het kunnen gebruiken nu, maar idd wel een beetje overdreven

[Verwijderd]

Idle verbruik van die dingen wel eens gezien? 😂

[strompf]

Pff. Dat ding maakt de herrie van een stofzuiger en je hebt gelijk geen verwarming meer nodig vanwege het stroomverbruik. 's Winters misschien wel geinig, maar 's zomers wat minder geslaagd. Nog afgezien van de energierekening

[Milanobrotchen]

Kan je hier mee gamen? ik neem aan dat dit eigenlijk puur voor servers / datacenters is. Of voor Computers die kij veel simulaties moeten berekenen?

[Nox]

Het kan maar gaat waarschijnlijk minder fps opleveren dan een ryzen 7950X. Is voor simulaties o.a.

[Reactie gewijzigd door Nox op 23 juli 2024 15:54]

[SinergyX]

Beetje het idee, kan je met een 18wieler truck naar je werk? Ja, maar of het ook echt nut heeft?

Deze CPU's zijn gemaakt voor software die extreem is geoptimaliseerd op multi-CPU usage, of extreem goed schalen met meerdere cores. Games in de regel, zijn dat absoluut niet. Ja, ze kunnen best gebruik maken van 16 of 32 cores, maar zijn qua performance niets beter dan hoge clock 4-core of 8-cores.

Gros van games hebben meer profijt van hoge clocks per core, deze CPU's zijn veelal lagere clocks, maar in extreme aantallen, dat de prestaties binnen een game eerder gelijk zijn aan lager gelokte 'gaming CPUs', en de hogere coreclock CPU's simpelweg sneller zijn. Al blijft dit erg game afhankelijk, er zullen best games die zich gedragen als een 'renderstudio' met extreem veel berekeningen, mogelijk dat je daar een verschil zal zien.

Dat is alleen niet het complete plaatje, een game draait per saldo op een limiet van GPU en CPU. Een game die tegen de GPU limiet aanloopt (dus GPU 100%, maar CPU bv 80%) zal aanzienlijk mindere impact hebben van een andrere CPU, dan een game die CPU-limiet heeft (GPU 60%, CPU 100%). Bij deze laatste zal de CPU veel grotere impact hebben op de performance en zal je Threadripper 'minder' presteren dan bij de GPU limitatie.

[Reactie gewijzigd door SinergyX op 23 juli 2024 15:54]

[Milanobrotchen]

Erg interesant, dankjewel voor de goede uitleg

[jaenster]

Niet de hele wereld draait om games

[Milanobrotchen]

Dat zeg ik ook niet

[dasiro]

het kan, maar de Threadripper Pro is gericht op zware workstations en kost een pak meer dan de gewone Threadripper die voor de HEDT markt is/was (het gerucht gaat dat AMD er mee gestopt is), terwijl Ryzen voor de gewone markt is en EPYC voor servers/datacenters bedoeld is.

[JDx]

Dit maakt 3D renderen wel leuker. Al die blokjes in VRay

[JerryJerryJerry]

Je bedoelt eerder Corona Vray is tegenwoordig meer GPU based.

[Ontzettend]

Dat is onzin. GPU en CPU versie bestaan naast elkaar. CPU versie is nog steeds heel veel gebruikt.

[JerryJerryJerry]

Geen onzin. Het bestaat inderdaad naast mekaar, echter GPU is voor Vray veel effectiever/sneller. Doe je naslagwerk maar En ja ik kan het weten. Heb 18 jaar met Vray gewerkt en sinds dit jaar overgestapt op Corona.

[Reactie gewijzigd door JerryJerryJerry op 23 juli 2024 15:54]

[Villean]

Dan alsnog wordt de CPU versie flink veel gebruikt. Het lukt je niet om displacement met 4k in je videogeheugen te stoppen.

[Ontzettend]

ik ken vray. de mogelijkheden met materialen zijn echt veel groter in de cpu versie. er zijn bovendien veel plugins die met vray cpu samenwerken, die deel uit maken van pipelines die jaren lange ontwikkeling gekend hebben. mijn inschatting is dat de cpu versie nog steeds veel meer gebruikt wordt dan de gpu versie.

[xray1x]

192 Threads zijn voor gaming dan wel een enorme overkill, echter zijn hier mooie user scenarios voor te vinden waar een hoge core-count en een niet al te hoge drempel tot aanschaf een rol spelen. Bijvoorbeeld in de wetenschap, of voor studenten die vergaande berekeningen of simulaties moeten maken voor opdrachten, kleine video studios. En er is daarnaast nog een hele wereld aan gebruikers die een krachtig workstation nodig hebben, zoals mensen met een DAW (Desktop Audio Workstation), een PC voor in de muziekstudio. Als ik het geld had, dan zou ik die 96-core TR zeker voor mijn toepassingen hebben gekocht, maar moet het voor de DAW-build van vorige week, met een 5800X doen. De uitgaven moeten ergens beperkt blijven. Voor een DAW geld meer cores is meer virtuele instrumenten en plugins kunnen inladen.

Het nadeel van een workstationplatfrom als de TR vind ik de veel hogere mobo prijzen en hogere geheugen vereisten. De "lichtere" 5950X en 5900X zijn voor budget workstations waar hoge thread counts tellen, uitermate geschikt.

[SG]

Je kan dan mogelijk software rendering doen dat concurreerd met ouwe XeonPhi kwa core hoeveelheden. Naats dat shader cores zeer lichte cores zijn die dus kleine instructie en register set hebben en xeon phi daar al meer bied maar full blow fat core.
Complexte instructie routine local in register samen met meer data in de registers plus grotere L1 naast L2 erbij. Vooral het verschil in instructie blok wat afhankelijk is van algoritme is.

[SCS2]

Iemand had (dacht ik) ooit een programma gemaakt om Doom te spelen met Windows Taakbeheer als display ?
Hiermee wordt de resolutie een stuk beter .....

[Roel1966]

Ik ben wel eens benieuwd naar de afmetingen van zo'n cpu is zeker wanneer ik naar de vorige generatie Threadrippers kijk die ook echt niet klein waren. Maar in elk geval wel apart om te lezen, 96 fysieke cores, en dan te bedenken dat we voor een aantal jaren terug blij waren met 4 of 6 cores. En tja tegenwoordig zitten er al in een simpele i5 12600 K 10 cores gepropt.

[killercow]

Want we hebben behoefte aan meer namaak porno en fake news van echte mensen die daar niet voor gekozen hebben?