AMD kondigt EPYC-cpu's met 3D V-Cache aan en deelt details over Zen 4 en Zen 4c

AMD heeft tijdens een virtueel evenement diverse nieuwe EPYC-cpu's aangekondigd. In het eerste kwartaal van 2022 komt 'Milan-X' beschikbaar, een variant van de bestaande Zen 3-gebaseerde processors met 3D V-Cache. Ook gaf AMD de eerste details over de toekomstige Zen 4-cpu's vrij.

Refresh van derde EPYC-generatie met 3D V-Cache

Nadat AMD aankondigde dat ook Facebook-moederbedrijf Meta EPYC-cpu's gaat gebruiken in zijn datacenters, deed de processorontwerper eerst de processors uit de doeken die gebruikmaken van de eerder dit jaar getoonde 3D V-Cache. Het gaat om een nieuwe versie van de bestaande derde generatie EPYC-cpu's op basis van Zen 3-cores, maar dan met 64MB 3D V-Cache letterlijk boven op de reeds aanwezige 32MB L3-cache van elke chiplet. In totaal komen er vier EPYC-modellen met 3D V-Cache, die elk gebruikmaken van acht chiplets. Hierdoor krijgen de chips in totaal ieder 768MB L3-cache.

Omdat er aan de architectuur en formfactor van de processors niets is veranderd, zijn de nieuwe cpu's compatibel met bestaande servers en moederborden voor de derde generatie EPYC-chips. Wel is er een bios-update nodig om de nieuwe varianten te kunnen gebruiken. Volgens AMD leidt de enorme L3-cache in specifieke workloads tot een prestatiewinst van wel vijftig procent. Daarbij noemde het bedrijf de toepassingen Ansys Fluent 2021.1, Ansys CFX 2021.R2 en Altair Radioss 2021 als voorbeelden. Dat zijn alle drie softwarepakketten die meerdere fysische modellen tegelijk simuleren.

Model	Cores/threads	Kloksnelheid	Boostclock	Tdp	L3-cache
EPYC 7773X	64C/128T	2,20GHz	3,50GHz	280W	768MB
EPYC 7573X	32C/64T	2,80GHz	3,60GHz	280W	768MB
EPYC 7473X	24C/48T	2,80GHz	3,70GHz	240W	768MB
EPYC 7373X	16C/32T	3,05GHz	3,80GHz	240W	768MB

Vierde generatie EPYC komt met twee soorten Zen 4-cores

Naast de aankondiging van de 3D V-Cache-cpu's, kondigde AMD ook alvast de komst van de volgende generatie EPYC-chips aan. Genoa wordt de directe opvolger van Milan en krijgt maximaal 96 Zen 4-cores, nog eens de helft meer dan het huidige maximum van 64 cores. De processors worden geproduceerd op TSMC's 5nm-node en zullen zowel DDR5 als PCI Express 5.0 ondersteunen. Ook de CXL-interconnect zal worden ondersteund, nadat AMD in 2019 toetrad tot het consortium achter die standaard. De Genoa-cpu's komen in 2022 op de markt.

Ook Bergamo maakt deel uit van de vierde generatie EPYC-cpu's en zal dezelfde socket gebruiken als Genoa. Deze processor maakt echter gebruik van een geheel nieuwe core genaamd Zen 4c, die zijn geoptimaliseerd voor cloudcomputing. Dit is een compactere en zuinigere versie van de reguliere Zen 4-cores, waardoor AMD er maximaal 128 in een processor zal kunnen stoppen. Bergamo staat op de roadmap voor de eerste helft van 2023.

Of AMD ook van plan is om de normale Zen 4-cores en de zuinigere Zen 4c-cores in één product te gaan combineren, zoals Intel voor het eerst deed met zijn Alder Lake-cpu's, heeft de fabrikant nog niet bekendgemaakt.

Reacties (37)

''Volgens AMD leidt de enorme L3-cache in specifieke workloads tot een prestatiewinst van wel vijftig procent.''
Dat lijkt mij een beetje onwaarschijnlijk door een beetje (veel) extra cache. Er zijn toepassingen die daar inderdaad voordeel van kunnen hebben, maar dit moet je uiteraard even afwachten en niet meteen die nieuwe Epyc cpu bestellen voor die 50% winst.

Beter is het wachten tot de cpu's daadwerkelijk getest zijn en deze benchmarks ook daadwerkelijk online verschijnen door onafhankelijke sites. Ook met de voorbeelden Ansys Fluent 2021.1, Ansys CFX 2021.R2 en Altair Radioss 2021 en kijken of dat een beetje klopt.

Ik geef eerlijk toe: ik heb niet zo heel veel verstand van software, maar wel van marketing, en een van die regels gaat als volgt: draai die test 1000e keren op de best mogelijke settings voor ons en het meest positieve resultaat nemen we mee in onze marketing campagne.

Wanneer je applicatie erg data afhankelijk is, dan zal de CPU relatief veel tijd wachten tot de data beschikbaar is. Ook al zijn DDR5 en NVMe nog zo snel, in CPU cycles kan dit nog steeds wachten betekenen. Caches maken dit alles efficiënter waardoor het sneller kan, maar ten opzichte van extern geheugen is het nog altijd duur.

Maar natuurlijk zal dit enorm van de workload afhangen, en zal de 50% winst zeker niet in het algemeen gehaald worden.

Dit is zo'n ontzettend vaag verhaal.

Cache heb je nodig omdat het veel sneller is dan RAM.

Erg data afhankelijk? Wat is dat? Ik neem aan dat er bedoeld wordt er veel instructies die niet door andere co-processors afgehandeld kunnen worden.

De meeste programma's gebruiken een relatief beperkte hoeveelheid instructies tegelijk, en een relatief beperkte hoeveelheid data tegelijk. Soms gaan ze iets verschillends doen, waardoor op dat moment de gebruikte instructies en/of de gebruikte data veranderen. Soms blijven de instructies gelijk, terwijl de data relatief langzaam verandert (als een CPU core een paar miljard instructies per seconde kan verwerken, dan is een seconde heel veel tijd).

Als alle instructies en alle data die een programma gebruikt uit de RAM moeten komen, dan moet de CPU elke keer dat die opgehaald worden lang wachten (in die tijd had de CPU tientallen instructies, of meer, kunnen uitvoeren.). Daarom is er cache. Als alle instructies en data altijd uit de L1 cache komen, dan is de wachttijd erg laag (alleen als de data al in de CPU registers zit, is het nog sneller). Bij L2 cache is de wachttijd wat langer etc.

Stel dat als de CPU moet wachten op data uit het geheugen, hij in die tijd 100 instructies had kunnen uitvoeren. Stel dat als die data in L3 cache zit, dat hij in die tijd 30 instructies had kunnen uitvoeren (dus L3 cache is 3x zo snel als gewoon geheugen). (ik weet niet zo snel wat de werkelijke getallen zijn).
Als een programma nu meer data gebruikt dan in L3 past, dan zal de CPU vaak moeten wachten op data uit het geheugen, en dus effectief minder werk verzetten. In het ergste geval 3x zo weinig. Als de L3 cache echter groter wordt, dan past die data misschien wel in L3, zodat de wachttijd misschien wel van gemiddeld 100 (in het ergste geval) naar gemiddeld 30 (in het beste geval) gaat. Dan wekt de CPU dus voor die taak ineens 3 x zo snel.

Nu neem ik aan dat die extra cache wel langzamer is. Zeg dat de gemiddelde wachttijd daardoor niet naar 30 gaat, maar naar 50. Dan nog kan de CPU 2 x zo veel werk verzetten, alleen maar door die extra cache.

Dit is ook één van de redenen dat EPYC CPUs met weing cores wel zin hebben: als een core meestal aan het wachten is op data uit RAM, dan heeft het toevoegen van cores geen zin - er komt niet meer data per seconde uit RAM. Echter, als je de cache verdubbelt (of in het geval van 16c EPYC tov 64c EPYC: 4 x zo veel cache per core), dan hoeft de CPU gemiddeld minder lang te wachten, en gaat de berekening ineens wél sneller.

Edit: nog even als toevoeging: data-afhankelijk betekent dat de taak een grote hoeveelheid data nodig heeft, en dus veel en vaak moet wachten totdat de data uit RAM (of L3 cache, etc) opgehaald is: de snelheid van uitvoering van de taak is afhankelijk van de snelheid waarmee de data beschikbaar komt. Het kan ook zijn dat een taak CPU-afhankelijk is. Dan is de snelheid afhankelijk van de rekensnelheid van de CPU.

[Reactie gewijzigd door RJG-223 op 8 november 2021 21:17]

Om het eenvoudig uit te leggen neem ik even Excel als voorbeeld, iedere cel is een instructie die door de CPU moet waarbij je cel per cel door de CPU duwt.

Als een cel bestaat uit = 5 + 3 => CPU kan instructie meteen uitvoeren
Als een cel bestaat uit = A5 + A9 => CPU moet eerst wachten op de 2 datapunten van A5 & A9 voor hij + kan doen
Als een cel bestaat uit = vlookup op tabel X + vlookup op tabel y => CPU moet eerst 2 andere instructies uitvoeren waarbij 2 tabellen aan data ingelezen moeten worden voor hij + kan doen. Die tabellen kunnen bestaan uit duizenden datapunten.

Hoewel je altijd maar A + B doet, het aantal data dat aan de CPU geleverd moet worden kan verschillen. Uiteraard zijn dit server grade CPU's waarbij je niet mag vergeten dat servers soms totaal andere workloads heeft.

Zo heb ik een database server die 25 228 800 000 000 records per dag levert on demand en daar ook nog berekeningen op moet doen. Dat is dan nog maar enkel wat er dagelijks opgevraagd word en maar een fractie van de complete databank.
Of in andere woorden, een relationele database met tables of indexen zoals SQL of gelijk ​gelijk welk type/merk relationele database slaagt gewoon tilt met een dergelijke load. Daar heb je een (complexe) niche file based database voor nodig waar de doorsnee databank expert niet veel van begrijpt.

Als je dan in mijn voorbeeld een berekening wilt doen op een paar miljoen records dan is 768MB L3 cache wel zo handig want de CPU rekent sneller dan wat het geheugen aanlevert. In mijn geval ligt de bottleneck dus niet in de CPU maar echt in de (juiste) data van een disk naar ram en van ram naar de CPU. Echter dit is een workload die heel ver afwijkt van wat een gewone PC zoal uitvoert.

Astronomie of deeltesfysica? 25.2 T records / dag is best wel veel :-)

Geen van beide, gaat om metingen van sensors die samplen om de 10 seconden * 70k inputs verspreid over meerdere locaties in meerdere landen. Als dan iemand een gemiddelde opvraagt van 30 dagen op 1 sensor dan heb je 259 200 records om 1 maandgemiddelde te krijgen. Sommige users willen dat dan op 100 sensors en zo tikt die teller vrij snel door.

Die berekening is eigenlijk niet correct want standaard gebruikt het systeem niet alle records in calculaties (om de boel performant te houden) tenzij je het expliciet vraagt (wat sommige users ook doen) maar langs de andere kant moeten het systeem wel al die records overlopen om een selectie te maken (hoe die selectie gebeurd is instelbaar door de user).

Dat valt tegenwoordig onder de noemer Industry 4.0 bij het breder publiek onder de noemer IoT maar de feitelijk correcte naam is time based data.

Sinds de tech giganten (MS/Amazon/Google/etc) door hebben hoeveel data die industrie eigenlijk wel niet heeft komen ze allemaal af met time based data in de cloud maar ik heb geen idee op wat voor databank systeem ze dat intern draaien. Je kan dan ook nog diepgaand gaan analyseren op die data, meest vergaand is een predictive model. Denk aan temperatuur, druk en vochtmetingen waar je vervolgens een weermodel op los laat om te voorspellen dat het morgen niet echt zomer weer gaat worden.

Dan moet je nog weten dat de vraag komt om op 1 seconde te sampelen, soms willen ze op cyclus tijd samplen en dan is het om de 100ms. Historiek gaat 10 jaar terug, mag jij gaan rekenen hoeveel records dat zijn

Data-afhankelijk betekend dat je, bijvoorbeeld, een database in laad. Dan is het beter om zoveel mogelijk in het geheugen te houden, ipv je SSD, omdat je geheugen sneller is dan je SSD.

In tegenstelling van iets CPU intensief, zoals Folding@Home waar CPUs proteïne moleculen vouwen. Daar heb je niet veel data voor nodig, maar wel veel berekeningen. Hier zou die grote hoeveelheid cache minder uit maken.

Daarom, meestal zijn deze testen in zeer specifieke loads en inderdaad is ddr en nvme veel langzamer als wanneer deze rechtstreeks op de cpu ingebakken zitten.
Cache is ook zeer duur, waarmee er in het algemeen nogal zuinig mee omgesprongen wordt.

Dus helemaal niet onwaarschijnlijk wat AMD zegt. Servers draaien namelijk hele specifieke workloads; als je een of andere general purpose server hebt dan zal de winst niet zo groot zijn als bij een server met een hele specifieke workload.
Ik geloof prima dat die 50% winst gehaald gaat worden. Het zal vast niet de beste usecase zijn maar ik denk dat een NGINX server hier best veel winst mee kan halen.

[Reactie gewijzigd door Sp3ci3s8472 op 8 november 2021 18:50]

Het zal vast niet de beste usecase zijn maar ik denk dat een NGINX server hier best veel winst mee kan halen.

Kun je me het verband tussen l3 cpu cache en nginx uitleggen?

Tweakers test (helaas) geen applicaties die geheugen gelimiteerd zijn. Kijk je (bijv) naar bepaalde spec workloads zoals bwaves of openfoam (zie de tests van Anandtech, Phoronix, of Igor's lab) dan zitten er een aantal tussen die wel geheugen gelimiteerd zijn. Voor dit soort programma's geeft DDR5 een serieuze boost (+15-17%) over DDR4. Ook caches dragen bij dit soort programma enorm bij aan een efficientere communicatie met het geheugen

Er zijn lichte compute loads over zeer grote data. Dan is compute power eigenlijk probleem niet maar data brengen naar die compute cores. En als de date ook nog veel groter is dan L3 caches En kan de mem de caches niet snel genoeg vullen dan schuift de performance afhankelijkheid naar memory subsysteem. Kunnen de caches het prefetchen goed bij houden dan maakt sneller memory minder uit to zekere hoogte. Nou moet je wel naar die edge case zoeken. Blijkbaar zijn er programma die meer leunen op de mem dan de caches. Of de cahces zijn voor sommige apps toch nog te klein.

Het gaat er altijd om om de bottlenecks zoveel mogelijk weg te halen zodanig dat de rest van de hardware ten volle benut kan worden. In de ene situatie is dat memory, maar het kan even goed de interconnect zijn of de cores, daarom dat er ook telkens over specifieke workloads wordt gesproken.
Dat gezegd zijnde, tweakers is op het internationale toneel niet diepgaand genoeg, laat staan toonaangevend, maar dat is niet het publiek waarvoor ze schrijven. Zoals je aangeeft zijn er daarvoor meer technisch georienteerde sites en youtube-kanalen die dat wel doen en het zich kunnen veroorloven omdat ze het globale publiek aanspreken en zo een groot genoege doelgroep weten te vinden. Hier in het Nederlandse taalgebied is daar te weinig interesse in.

Dit zijn data center cpu's, niet cpu's die je snel voor je huis gebruik zult kopen
Een gemiddelde aankoop order zal wel in de miljoenen lopen en dan heb je dus echt wel een business case nodig om een upgrade te mogen doen.

Excuses, waarschijnlijk iets te spontaan gereageerd.
Ik hoopte met mijn marketingkennis iets van toegevoegde waarde hier te zijn, maar aangezien de tweakers met echte kennis over dit product is dit niet echt het geval.
Ik zal er in vervolg op letten bij het plaatsen van reacties

Dat is ook de reden dat ze over "specifieke" workloads spreken

Jammer dat je het niet gelooft want er lijkt mij niets onwaarschijnlijks aan.

Volgens AMD leidt de enorme L3-cache in specifieke workloads tot een prestatiewinst van wel vijftig procent. Daarbij noemde het bedrijf de toepassingen Ansys Fluent 2021.1, Ansys CFX 2021.R2 en Altair Radioss 2021 als voorbeelden. Dat zijn alle drie softwarepakketten die meerdere fysische modellen tegelijk simuleren.

In het laatste stukje leggen ze ook uit in welke testen zij dit geconstateerd hebben.

En als het een beetje een fatsoenlijk bedrijf is dan krijgt de marketing afdeling gewoon één getal en één uitleg zoals hier het geval is en daar moeten ze het mee doen.

En als het een beetje een fatsoenlijk bedrijf is dan krijgt de marketing afdeling gewoon één getal en één uitleg zoals hier het geval is en daar moeten ze het mee doen.

Weet niet hoe dit bij amd werkt maar je kunt als marketing zelden iets met wat de engineers opsturen zeker niet als het 1 getal is. Je zult met hen moeten praten en verschillende scenario’s moeten doorlopen. Je wilt nu niet doen wat the_leonater zegt - een super obscuur resultaat nemen. Het hoeft geen gemiddelde te zijn, maar ook geen 1 in 10.000… iets optimistisch-realistisch zeg ik altijd.

het is duidelijk dat ze vooral in samenwerking met andere bedrijven en instellingen hebben gekeken waar de grootste improvements te halen zijn en die moeten ze ook verkocht krijgen aan hun klanten, dus zonder specifieke cijfers die consistent te halen zijn krijg je in dit segment niet veel hardware verkocht. Vergeet niet dat dit klanten zijn met zeer technische kennis die je niet zomaar wat wijs kan maken op basis van een flashy presentatie (misschien daarom dat ze zo sober is, anderen zouden het ronduit saai noemen). Als je marketing wil zien, dan zou ik eerder wachten op de high-end desktop markt presentatie, daar zal je wel wat meer hype te zien krijgen.

FYI : Phoronix bevestigt (impliciet) dat de gemelde claims terecht zijn en met name voor het interessante HPC werk (Finite Element Simulations, computational fluid dynamics, ... Dit soort software wordt gebruikt in alle oceaan stromings modellen, slib/sediment transport in rivier stromen, grondwater modellen, weersmodellen, reservoir simulaties in de olieindustrie/ geothermie, modellen die de spanningen in materialen of objecten bereken al dan niet door druk/stress verandering of thermische krimp/uitzetting, deformatie modellen van bijv human tissue by swelling, of deformatie van een dijklichaam, berekening van krachten en spanning en de lucht stroming langs windmolens, berekening van de verspreiding van polutants/ontlasting in fish farms en de daarbij horende ecologische impact, etc., etc. Verre van niche dus..)
Aangezien de resultaten onder NDA zijn tot de launch date en hij de nummers dus niet kan weergeven zullen we het moeten doen met zijn "If you have demanding, memory bandwidth intensive and cache-happy workloads, buckle up for an exciting Q1"

link naar Phoronix
https://www.phoronix.com/...le&item=amd-milan-x&num=2

[Reactie gewijzigd door vladimirN op 8 november 2021 23:47]

L3 cache is vaak 2x zo snel als RAM, dus als een applicatie erg data intensief is - laten we een fysisch model nemen -, dus veel data heen en weer schrijft en leest naar RAM, dan gaat de factor 2 verschil tussen RAM en L3 cache flink meetellen in de overall performance.

Het is niet voor niets dat grafisch geheugen ook erg snel moet zijn om een GPU niet op te houden, en met Infinity Cache op de RX GPU’s heeft AMD ook laten zien al hoe belangrijk cache is

Nou nee cache is flink stuk sneller maar de het gaat niet om de snelheid van Sram cell.
Maar de snelheid van de gemiddelde lookup in de cache een kleine L1 32K is dus zeer snel omdat de data in 32K sneller gevonden wordt dan in 1MB L2 en die weer sneller dan 768 L3 memory is flink stuk langzamer maar wordt in cacheline opgehaald dus de volgende byte in cacheline is dan zeer snel.
Server software is vaker beter prefetch en cachline aware en multithreaded ontwikkeld dus wordt daar goed gebruik van gemaakt. in tegen stelling tot consumenten apps en games
cache heeft 1 doel en dat is bufferen dus maskeren van traag medium tov snelle verwerker.
In tijd van 8086 was CPU == RAM en was Cache niet nodig beide evensnel. Nu is zo extreem verschil dat er meerdere niveau gebufferd wordt.

Maar de snelheid van de gemiddelde lookup in de cache een kleine L1 32K is dus zeer snel omdat de data in 32K sneller gevonden wordt dan in 1MB L2 en die weer sneller dan 768 L3

Is dat zo ? In Zen3 zijn de L1 en L2 caches beiden 8-way set associative. L3 is 16-way. Volgens mij is de lookup tijd in L1 en L2 dus in principe even snel. Ik neem aan dat 16-way iets langzamer zou kunnen zijn dat 8-way, maar dat weet ik niet.

Ik denk dat het voornaamste oorzaak is, dat de L1 cache véél dichter bij de ALUs zit, zodat de data van minder ver hoeft te komen, en dus sneller ter plaatse is. En wellicht is de L1 cache ook sneller ontworpen (wat ook meer chip-oppervlakte zou kosten per byte, of meer warmteontwikkeling, of zo). De afstand van ALUs naar L3 is het grootst, terwijl die ook nog eens door meerdere CPUs gebruikt wordt, zodat ze misschien ook nog eens af en toe op elkaar moeten wachten. En het feit dat er ook nog eens eerst in L1 en L2 gezocht moet worden, maakt ook dat de latency van L3 hoger is.

Edit: ik denk overigens, bij nader inzien, dat de lookup-snelheid in een cache in principe helemaal niet afhangt van of hij 8-way of 16-way is.

[Reactie gewijzigd door RJG-223 op 9 november 2021 00:02]

Ben erg benieuwd naar de Ryzen 6000 serie voor consumenten. Heb mezelf voorgenomen pas met AM5 (of nieuwe intel socket) een nieuwe PC samen te stellen.

Zal deze aangekondigd worden rond of tijden CES?
In dat geval begin volgend jaar..

Ook wel benieuwd hoe AMD en Intel tegen elkaar zullen opboksen, zowel op server gebied als voor de consument.

''Ook wel benieuwd hoe AMD en Intel tegen elkaar zullen opboksen, zowel op server gebied als voor de consument.''

Ik ben ook heel erg benieuwd, concurrentie is altijd goed, zo houd je elkaar wakker en dalen de prijzen en stijgt de performance per euro.
Daar wordt je als consument alleen maar blij van.

Intel heeft heel lang kunnen doen en laten wat ze willen zowel qua prestaties en performance, maar vanaf Ryzen kan dat niet meer en moeten beide partijen echt aan de bak.

Het is nu sinds een tijdje eindelijk weer leuk om hardware liefhebber te zijn op dit gebied, ben zeer benieuwd wat beide partijen nog in petto hebben.

Dalende prijzen weet ik nog zo niet, de CPU's lijken met toch duurder te worden met de jaren.

Zal voor beide toch maar een tijdelijk verhaal zijn, data center markt zit hevig richting inhouse CPU's aan het gaan, zeker omdat ARM cores meer dan voldoende zijn voor de meeste taken en R&D en deployment van hun eigen producten tot 6 maal lager ligt dan wat ze aan Intel/AMD betalen.

Het bedrijf waar ik werk is er ook recent bij begonnen met R&D naar het oprichten van hun eigen CPU's op basis van ARM.

Uiteindelijk gaan iNtel en AMD ook concurreren directer met ARM high dense server cpu. En iNtel heeft al langer wat licht gewicht cores om daar vanuit te gaan. Atom en XeonPhy Larrabee.
Arm cores zijn niet ontworpen om idioot maximaal te kunnen klokken dus hebben korte pipeline stages. In de desktop markt wordt 4 cores low budget dus core te ontwerpen die in 4 core setting maximale uit TDP haalt is dus ook niet van deze tijd want dan lever je in met 8 cores en meer.
In de server hpc pro markt kan je puur met efficiëntie cores gaan om maximale uit diespace en tdp te halen met chip die voldoende klok marge heeft voor die klok target.
X86 sweetspot ligt nog te ver onder 16cores. Er is dus al serieuze R&D om met dense cores een aanval op ARM uit te rollen.
Biglittle zal bij intel ook met de tijd HPC xeon gaan en door ontwikkeld worden AMD is er met Dense Zen cores ook mee bezig. Zou kunnen dat met Zen6 AMD ook competatief tegen ARM is.
Dan is de gang naar eigen ARM design niet altijd zo voordelig. Maar baten kosten dilema.

Komt er ooit nog een nieuwe threadripper?

Dat vraag ik me dus ook af..
Heb een trx40 systeem aangeschaft als workstation maar ook om af en toe een game op te draaien.
AMD maakte des tijds nog reclame dat ze ook geschikt waren voor gaming.

Het enige wat tot nu toe bekend is, dat ergens volgend jaar de zen3 threadrippers zullen verschijnen, maar of er ook varianten komen met deze 3D V-Cache weten we niet.

Ik hoop het wel, want als alles straks Zen4/DDR5 is, zou het ruk zijn als trx40 slechts een enkele (veel te late) update naar het inmiddels verouderde zen3 (zonder 3D cache) heeft gekregen.

Precies. Dat zou zeker ruk zijn.
Ik begin een beetje het gevoel te krijgen dat HEDT eruit aan het gaan is.
Nu kan ik wel voor een Zen4 gaan, daar kan vast ook wel 128GB Ram in maar toch. Ik wilde liever naar 256GB. En HEDT heeft gewoon veel banken dus dat is goedkoper.

Ja dat zeker, dat word dan zen4 + een nieuw moederbord + DDR5..
Een dure grap.

Hoop toch stiekem dat ze later in 2022 nog een zen3 threadripper met 3D V-Cache uitbrengen...

Wat ik niet begrijp uit dat artikel, is waarom al deze Epyc processors gebruik maken van 8 chiplets. Voor de 64-core variant is dat logisch, maar hoezo zou voor de 16-core versie ook 8 chiplets gebruikt worden? (En dus geen 8x64MB geheugen op de 8-core versie)

Mischien berg chiplets waar deel wel voldoet aan spect maar cores kaduk zijn.

Is niet te geloven, heb pas ge-upgrade naar Ryzen 5600X !

Alsof je daarmee in de markt was voor een EPYC cpu?