Specificaties van AMD EPYC Milan-X-processors met 768MB L3-cache lekken uit

Er zijn specificaties van vermeende AMD EPYC Milan-X-cpu's verschenen. Deze serverprocessors zouden gestapeld '3D V-Cache' krijgen. AMD heeft de Milan-X-serie nog niet officieel aangekondigd.

Deze informatie is afkomstig van ExecutableFix. Deze Twitter-gebruiker deelt vaker informatie over onaangekondigde AMD-cpu's en deelde onder andere de correcte specificaties van de reguliere AMD EPYC Milan-cpu's voordat deze uitkwamen. De leaker voorspelde vorig jaar ook dat de Ryzen 5000-apu's beschikbaar zou komen als varianten met Zen 2- of Zen 3-cores, wat later bleek te kloppen.

De leaker schrijft op Twitter dat alle Milan-X-processors beschikken over 768MB aan L3-cache, dankzij het gebruik van gestapeld 3D V-Cache. De 'reguliere' AMD EPYC Milan-chips beschikken over maximaal 256MB L3-cache. Dit zou betekenen dat de acht ccx'en van deze EPYC-cpu's ieder beschikken over 32MB reguliere L3-cache, aangevuld met 64MB aan 3D V-Cache, merkt ook VideoCardz op.

ExecutableFix noemt de komst van vier Milan-X-modellen. AMD zou 280W-modellen met 64 en 32 cores en 240W-cpu's met 24 en 16 cores introduceren. Het model met 64 cores zou daarbij een kloksnelheid van 2,2GHz hebben. De cpu's met 32 en 24 cores zouden op 2,8GHz geklokt zijn en de variant met 16 kernen zou een base clock van 3,05GHz hebben.

AMD presenteerde 3D V-Cache tijdens Computex en meldde toen dat de technologie als eerste zal worden toegepast in 'hoogst gepositioneerde producten', waarmee vermoedelijk de EPYC-serie werd bedoeld. De Milan-X-cpu's verschenen eerder al bij een Amerikaanse webshop, meldde momomo_us recent op Twitter. Tweakers schreef in juni een achtergrondverhaal over AMD's 3D V-Cache-technologie en de prestatieverbeteringen die het zou opleveren.

Vermeende AMD EPYC Milan-X-line-up (via ExecutableFix)
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

Reacties (34)

Ik ben benieuwd naar de prestaties van deze CPU's. Het kan bij bepaalde workloads wel erg interessant zijn.
Volgens dit lijstje zou dus ook het 16 core model 8 chiplets gebruiken. Maar dan staan er slechts 2 cores per chiplet aan dat is wel erg zonde. Of AMD moet een manier gevonden hebben om ook de cache te plaatsen en aan te sturen zonder dat er een CCD onder zit. Maar ik had eerst het idee dat de CCD de aansturing van de cache zou gaan doen. Gezien het totaal van 768MB moet je ook de 32MB cache van de CCD zelf er bij hebben.
We zullen over een tijdje wel zien of dit lijstje klopt of dat de 16 core modellen het toch met iets minder cache moeten doen.

Ik ben vooral erg benieuwd hoe deze processoren het qua stabiliteit doen. De laatste AMD processoren die ik zelf in servers heb gehad waren Opterons en dat waren om zacht uit te drukken helse processoren. Niet alleen de performance was laag (wat ik bij de Epycs niet verwacht), maar de stabiliteit op Linux systemen liet echt te wensen over. Configuraties die exact hetzelfde waren als hun intel broertjes (hypervisors, webservers) waren altijd extreem onstabiel op de Opteron varianten. Crashes waren niet ongewoon en regelmatig dat er "rare" dingen in het OS gebeurden die we op de Xeons nooit hebben gehad.

AMD wordt qua performance steeds interessanter voor de servermarkt, maar ik vind het nog steeds heel lastig om te vertrouwen op een merk die toch jaar in, jaar uit ontzettend slecht gesupporte CPU's voor servers maakte. Dus als iemand ervaringen te delen heeft, dan hoor ik ze graag .

n=1
Ik heb precies het tegenovergestelde meegemaakt. Opterons waren wat mij betreft sneller, goedkoper en stabieler dan hun xeon broertjes toendertijd. Ook op linux. Nog los van het wazige hete ram dat Intel gekozen had voor hun machines die periode ipv gewoon DDR2/DDR3 met ecc.

Ik ken maar weinig mensen die positief waren over die processoren, maar laat ik ook voorop stellen dat ik absoluut niet de bedoeling heb om Intel de hemel in te prijzen hoor. Ook Intel heeft genoeg rare keuzes gemaakt over de jaren en aparte dingen gehad, maar doorgaans heb ik betere ervaringen met Intel dan AMD op Linux. Maar je hebt gelijk, mijn verhaal is inderdaad een n=1 verhaal.

Opterons waren kieskeurig wat betreft het geheugen. Niet noodzakelijk de schuld van AMD, want veel geheugenfabrikanten testten hun geheugen alleen op Intel-processoren, maar ik heb meegemaakt dat van een partij geheugen tientallen procenten uitval had, niet omdat het geheugen stuk was, niet omdat het op papier niet compatibel zou zijn, maar omdat het in praktijk niet compatibel was.

Met eenmaal het juiste geheugen was een Opteron-systeem zeer stabiel en kon (kan) jarenlang zonder reboot draaien.

Heb afgelope jaar een epyc proxmox cluster opgezet. Draai als een tierelier, echter heb ik beide gevallen prima ervaringen (en ook mindere)

Deel dezelfde mening.

Zeer stabiele systemen, wij kochten deze toen van Sun systems... Het echte probleem zat em vooral in de nvidia chipset.

Performance was laag vna opterons? Heb jij toen wel gekeken wat intel te bieden had met FSB ???
Alles wat een hypervisor had was niet vooruit te branden op die Intels, Opteron was een verademing kwa core performance en memory performance. Waarom denk je dat Intel Nehalem zo dringend nodig had?

Dat waren echt zulke fijne servers die Sun spullen. Echt eindeloos jammer dat het nu Oracle is.

Met de eerste generaties Ryzen processoren waren de ervaringen vergelijkbaar.
Een vriend van me compileert zijn eigen kernels en de Ryzen 1600 (zowel de oude als de nieuwe) deden daar heel erg moeilijk over. De Epycs van die generatie zullen dat niet anders gedaan hebben. Over de nieuwere generaties hebben we geen data want met die ervaringen hebben we het op gegeven.

Vergelijkbare ervaring heb ik op Windows met de Ryzen processoren; ze doen het "net effe wat anders" en daarmee zijn er af en toe onverwachte resultaten. Zoals een HP Augmented Reality bril die niet werkt waarbij diepgaand onderzoek tot resultaat heeft dat AMD zegt "Microsoft doet iets fout", Microsoft/HP zeggen "AMD houdt zich niet aan de standaarden" en uiteindelijk het ding simpelweg niet werkt.

Al met al heb ik heerlijk gebruik kunnen maken van een Ryzen 3950X voor machine learning toepassingen maar blijven de Ryzens (en daarmee dus ook de Epycs) het hier en daar dusdanig "anders" doen dat er soms iets niet lekker gaat.

Ik heb gelijk 3 servers gekocht met AMD EPYC Rome (2e generatie) CPUs voor in het rack. Deze draaien echt super stabiel. Ze draaien als hypervisor met lokaal NVMe storage. Super snel en super stabiel. Ze draaien nu iets meer dan een jaar en heb geen crash meegemaakt. Development machine heeft een EPYC 3000 (embedded series) CPU. Ook geen problemen mee. Tevens voor home-lab ook een EPYC (Rome) CPU gekocht, deze draait ook zonder problemen. Draai wel enkel Linux.

Dank voor de ervaringen (ook @Croga). Misschien toch maar eens een aantal AMD machines kopen om te zien wat ze doen .

Tja mij lijkt het ook dat Software en hardware zoals memory sticks voornamelijk ontwikkeld werd met intel als target. En met next gen Epyc langzamerhand ook AMD wordt meegenomen. Kip en ei probleem. Daarnaast derde party juist meer moeite doen voor intel als markt leider en niet zo zeer voor de underdog. Als iNtel je bulk van je omzet is zal certificering van mem uiteraard prioriteit hebben en AMD meer van optioneel. Nu speelt AMD juist goed mee op de markt en is hun aandeel interessanter en wordt de hardware en software support ook

Voor alle servers gebruik ik alleen geheugen dat voor het moederbord gecertificeerd is. Was dat hier misschien niet niet het geval?
Ik heb een goede lading Opteron servers verkocht. Altijd met Linux er op Opteron 280's. Kan me geen storing herinneren. Of ik heb last van een Ruttetje

Wij werken inderdaad ook alleen met officieel geheugen van vendors, maar in hoeverre die wel of niet gecertificeerd waren weet ik niet uit mijn hoofd. Zou best kunnen hoor, maar dat kan ik je niet vertellen. De servers waren toendertijd niet door mijzelf aangeschaft.

Een eerste impressie, hoewel geen server, maar games:

Computex: AMD toont Ryzen 5900X-prototype met 3D V-Cache: 15% beter in games - Update
https://nl.hardware.info/...5-beter-in-games---update

Ik had eigenlijk eerder iets van een Level 4 cache in de i/o-die verwacht, maar dat kan altijd later nog.

Nou cache is buffer en je hebt daarom tiers. Tiers van zeer groot en daardoor langzamer tot klein zeer snel door beperkte grote. Als allemaal L3 dan valt het binnen dezelfde cache tier en mogelijk ook binnen dezelfde cache adressering en dus meer extentie van CCD L3 .
Een andere reden kan zijn dat de latency tussen 256 ccd total en 768 MB extended het verschil marginaal is binnen orde van 2 dat ondanks extra cache level het binnen de Tier3 cache valt.

Het zoeken naar hit in 32kB vs 1 of 2MB vs 256MB 768MB is grote orde dat tier mogelijk bepaald

Mij lijkt het dat elke core zijn lokale L3 uiteraard net wat sneller is maar elke non local L3 en deze extended L3 allemaal als non lokal L3 ziet.

Ieder tier buffert tier die eronder zit omdat flink stuk langzamer is.
Een L4 vs L3 zou factor 3 tot 10x verschil moeten hebben en die factor zou L4 ook tot systeem memory hebben

Persoonlijk denk ik dat de verwoording van "15% more frames on average" zal inhouden dat de average frame rate er met 15% op vooruit gaat.

Want die cache gaat vooral een geheugen bottle-neck wegnemen. Dus de dalen in frame rate zullen minder diep zijn - als ze veroorzaakt worden door die geheugen bottle-neck.

En vooral games die veel geheugen gebruiken (simulators, etc.) zullen er het meeste profijt van hebben.

AMD heeft nu ook al een 8 core Epyc met 8 CCDs. Die hebben een hogere kloksnelheid dan de versies met meer cores enabled en dus 32MiB cache per core. Deze nieuwe heeft 96MiB per 2 cores. De gehele L3 cache is aanspreekbaar voor alle cores in de CCD. Ook haalt de Zen architectuur veel voordeel uit meer cache om competitief te zijn met Intel op een per core basis.
Dit is voor applicaties die veel cache vereisen, vaak in combinatie met software met een per-core-license.

Ook neemt het cache veel fysieke ruimte in op de die, dus het verspilde materiaal valt relatief mee.

Denk toch echt dat die versie inderdaad slechts twee cores per CDD gebruikt en de rest bewust uit geschakeld is. Dergelijke SKU's bestaan puur om zoveel mogelijk performance te halen uit programma's waar je je licentie per core betaald.

Die 2 cores per chiplet kan je dan wel wat hoger boosten, wat dan ook weer leuk is.
(En AMD kan mogelijk weer wat chiplets recupereren die anders de schroothoop op zouden gaan, aangezien er hooguit 2 cores moten werken, en ook de clockvereisten niet erg hoog zijn.)

Trouwens erg mooi van AMD dat ze door een extensie van een product dat al even in productie is gewoon een nieuw product met meer meerwaarde kan bieden dan gewoon een andere configuratie/hogere clocks.

Die chiplet-strategie heeft AMD al aardig opgebracht.

I know maar het blijft zonde om de rest weg te gooien. Het feit dat er geen quad core desktop cpu's meer zijn geeft wel aan dat de yields te hoog zijn en dat die chips er gewoon zo goed als niet zijn waar 4 cores niet werken.

Maar ik snap het vanuit het licentie oogpunt. En het hoger boosten kan ook met meer cores alleen moet je die dan niet gebruiken dat doen de desktop CPU's ook zo.

Het zou verbazen als alle 7000 serie EPYCs zo veel cache hebben.
Ik vermoed dat alleen de 64-core variant zo royaal is bemeten.
De processoren met minder cores hebben vast proportioneel minder cache...

Zou mij op zich niet echt verbazen, AMD verkoopt nu zelfs 8 cores met CCD's zodat je de volle hoeveelheid cache hebt. Het zou mij wel verbazen als er naast deze modellen geen modellen komen met minder CCD's en cache, .

Ik denk al jaren dat deze zogenaamde 'leaks' gewoon een vast deel van de PR uitmaken.
Misschien wordt het tijd om "leaks" om te dopen naar "pré-release spec info" of iets dergelijks.

Het is niet alleen maar PR, maar ook haast onvermijdelijk als meer mensen toegang tot de processoren krijgen. Bij een aanbesteding die nu loopt ga je al met deze processoren bieden, omdat tegen de tijd dat er geleverd moet worden deze processoren al lang en breed beschikbaar zijn. Ik heb daarom toegang tot AMD's cluster in München, zodat ik alvast benchmarks kan draaien. En op dat cluster zijn deze processoren al een tijdje beschikbaar.

Als ik zou lekken, dan zou dat geen kwestie van AMD PR zijn, maar dat ik onzorgvuldig ben met de vertrouwelijkheid. En met talloze personen wereldwijd die met deze processoren bezig zijn, zijn lekken onvermijdelijk.

Misschien dat AMD dan ook maar eigen productieplants moet gaan opzetten. Productiecapaciteit is ook onderdeel van de markt (werking).

En dat terwijl ze.die juist hebben afgestoten om zich te richten op de ontwikkeling van hun CPU's, APU's en GPU's.

Dat afstoten van Goobal Foundries heeft ze die mogelijkheid gegeven.

En het vermogen en winst zijn te klein dit weer op zich te gaan nemen.

Arme Intel...

Vooralsnog maken ze bakken met winst, t arm valt wel mee

Die winst maken ze omdat er een vraag in de markt is die niet door AMD gedekt kan worden. Ze maken die winst niet omdat ze betere producten hebben, maar omdat ze productiecapaciteit hebben

En wat leren we hiervan...?

Heb je het over dezelfde intel 🤔

https://www.anandtech.com...t-computing-leads-the-way

En hier lijkt het nog wel redelijk,
alleen wat je ziet is dat andere factoren bijdragen aan zowel de omzet als winst.

Daarnaast hebben ze naar alle waarschijnlijkheid niet de buffers om investeringen te doen voor nieuwe productielijnen;
https://ycharts.com/companies/INTC/stock_buyback

Jarenlang hebben ze aandelen teruggekocht alleen nu moeten ze investeringen doen, maar wie wil nou gaan investeren (cq financieren) in een product dat en langzaam terugloopt en waarbij concurrentie betere producten neerzet.
Daarnaast heeft vb de M1 van Apple zoveel potentieel wat ook weer de natte droom van Nvidia was geweest met hun Tegra, alleen was die net verkeerd gepositioneerd en geen serieuze lange termijn klanten anders dan Nintendo.

De concurrentie is groot en wordt groter en intel x86 gaat het heel moeilijk krijgen in deze vorm als ze zelf niet meer eens leidend kunnen zijn in hun eigen techniek.

ARM?

We kennen wel een steeds complexere situatie wat betreft geheugen/geheugenbeheer. We hebben nu in bijna elke 'module' ook weer CPU'tjes, OS'jes en geheugenbeheer - wellicht dat een formalisme daar straks extra inzicht in kan gaan bieden, dat we bijvoorbeeld "generiek" via het OS bij zulke losse hardwarecomponenten kunnen (adresseerbaarheid adresseren).

Het is als programmeur helemaal niet makkelijk (of zelfs duidelijk) om goed gebruik te maken van 'snelgeheugen', en met zoveel snelgeheugen hoeft er eigenlijk niet per se geheugen bij. De pci-e 4x 'hardeschijven' zijn ondertussen zo snel dat het gelijkt op geheugen (en is Random Acces!).

Ik schrik er bijna zelf van, maar het zou kunnen betekenen dat we straks een diverser malloc moeten hebben in de unix architectuur! Vanuit het OS dan, bedoel ik! (nu werkt dit soort geheugen slechts als cache, zonder enige verdere inmenging van de applicatielaag)

Wie weet drukt het ons (~programmeurs) een geadvanceerder computationeel model als voet te hanteren, waarin de lokaliteit van executie en de beschikbaarheid van bronnen een grote rol spelen.

Ook de veiligheid van de computers zal daar van moge baten. Het is nu niet overzichtelijk waar executiedata precies slingert, hoe caches vol blijven (denk secure erase).

Het knaagt een beetje dat het model van een PC eerst een grote rekenmachine was, die je ook thuis kon hebben. Nu is er een computationeel landschap van allerlei (vaak redelijk onhandige) apparatuur. De System-on-a-Chip, een totaalpakketje dat op een PC lijkt, kwispelt zich witgoed, voertuigen en allerhande snuisterijen in, maar laat zich niet soortgelijk bezien. De functie van het OS is zodanig verschoven van het beschikbaar maken van de machine, naar het beschikbaar maken van de gebruiker.

Ondertussen gaan specialistische softwarepakketten vaker hand in hand met specialistische hardware. Op die manier ondermijnt software as a service de genericiteit van de computationele bronnen, of liever, dat zorgt ervoor dat een gebruiker zich dient te begeven tussen soortgenoten, die vervolgens vaak verbonden zijn aan een specifiek platform.

Al die uitgewerkte toepassingen, waarvan een legitiem doel uitgaat, vinden elkaar nog altijd rondom het PC platform? Nee, rondom het "web". Het is al een tijd niet meer zo dat iedere persoon toegang heeft tot een apparaat waarop ze volledige bedieningsvrijheid ontvangen; waarop alles mogelijk is. Het is een ongemak, zelfvoorzienend te zijn. Voor professionals vaak goed af te kopen.

Er is nu wel een gek marktmoment - waar de CPU en SoC door elkaar lopen, en (duur) geheugen nu (kortstondig?) redelijkerwijs als deel van de CPU verkocht kan gaan worden. Mogelijke bedrijfspolitiek wbt de snelheid van de bridges. Gezien de hoofdpijn van complexe caches kan dat nog best interessant worden.

OTOH kijk ik al tijden uit naar een Samsung geheugen-en-map-reduce module, die simpele functies (*kernals*?) toe kan passen op 'al het geheugen tegelijk', zodat het bijprikken van zo'n module al een balans in de performance kent en een lineaire performancewinst oplevert. Living memory! Aint that what it be?