AMD brengt hoger geklokte Epyc-serverprocessors uit met 8, 16 en 24 cores

AMD voegt de Epyc 7F32, 7F52 en 7F72 toe aan zijn assortiment. De cpu's voor servers zijn met turbosnelheden tot 3,9GHz flink hoger geklokt dan eerdere modellen. De cpu's worden ingezet door fabrikanten als Dell, HPE, IBM en Lenovo.

De Epyc 7F32 en 7F52, met 8 en 16 cores, zijn uitgerust met 16MB L3-cache per core. De Epyc 7F72 is een variant met 24 cores met minder L3-cache; 8MB per core. Daardoor is die variant ook goedkoper dan de 7F52 met minder cores. De drie nieuwe Epyc-processors hebben overigens allemaal meer cache dan de modellen die AMD eerder uitbracht met het gelijke aantal cores.

De maximale turbosnelheid van de nieuwe cpu's is tussen de 400 en 600MHz hoger dan bij eerdere Epyc-cpu's met soortgelijke core-aantallen. De F-modellen zijn de snelst geklokte Epyc-cpu's tot nu toe. Ook de baseclock is een stuk hoger. De cpu's kunnen gebruikt worden in systemen met twee sockets.

Volgens AMD zijn de nieuwe Epyc-cpu's met name geschikt voor werken met databases en andere workloads die baat hebben bij een hoge kloksnelheid. In de aankondiging noemt AMD een lijst van bedrijven die de cpu's gaan toepassen in servers. Daarop staan Dell Technologies, HPE, IBM Cloud, Lenovo, Microsoft, Nutanix, Supermicro en VMware. Reviews van de Epyc 7F52 zijn verschenen bij AnandTech en ServeTheHome.

Nieuwe Epyc-processors (april 2020)
Processor	Cores/threads	Kloksnelheid	Max turbo	L3-cache	Tdp	Prijs (per 1000)
Epyc 7F72	24 / 48	3,2GHz	3,7GHz	192MB	225W	$2450
Epyc 7F52	16 / 32	3,5GHz	3,9GHz	256MB	180W	$3100
Epyc 7F32	8 / 16	3,7GHz	3,9GHz	128MB	200W	$2100

De nieuwe serverprocessors zijn een aanvulling op de oorspronkelijke line-up, die in augustus vorig jaar werd aangekondigd. In de tussentijd kwam AMD ook al met een hoger geklokte Epyc-processor met 64 cores, de 7H12. Daarnaast presenteerde de fabrikant een aantal goedkopere varianten van Epyc-cpu's met 64 cores.

Oorspronkelijke line-up van Epyc 7000-processors (augustus 2019)
Processor	Cores/threads	Kloksnelheid	Max turbo	L3-cache	Tdp	Prijs (per 1000)
Epyc 7742	64 / 128	2,25GHz	3,40GHz	256MB	225W	$6950
Epyc 7702	64 / 128	2,00GHz	3,35GHz	256MB	180W	$6450
Epyc 7702P	64 / 128	2,00GHz	3,35GHz	256MB	200W	$4425
Epyc 7642	48 / 96	2,40GHz	3,40GHz	256MB	225W	$4775
Epyc 7552	48 / 96	2,20GHz	3,35GHz	192MB	180W	$4025
Epyc 7542	32 / 64	2,90GHz	3,40GHz	128MB	225W	$3400
Epyc 7502	32 / 64	2,50GHz	3,35GHz	128MB	180W	$2600
Epyc 7502P	32 / 64	2,50GHz	3,35GHz	128MB	180W	$2300
Epyc 7452	32 / 64	2,35GHz	3,35GHz	128MB	155W	$2025
Epyc 7402	24 / 48	2,80GHz	3,35GHz	128MB	180W	$1783
Epyc 7402P	24 / 48	2,80GHz	3,35GHz	128MB	180W	$1250
Epyc 7352	24 / 48	2,30GHz	3,20GHz	128MB	155W	$1350
Epyc 7302	16 / 32	2,80GHz	3,30GHz	128MB	155W	$978
Epyc 7302P	16 / 32	2,80GHz	3,30GHz	128MB	155W	$825
Epyc 7282	16 / 32	2,80GHz	3,20GHz	64MB	120W	$650
Epyc 7272	12 / 24	2,60GHz	3,20GHz	64MB	120W	$625
Epyc 7262	8 / 16	3,20GHz	3,40GHz	128MB	155W	$575
Epyc 7252	8 / 16	2,80GHz	3,20GHz	64MB	120W	$475
Epyc 7252P	8 / 16	2,80GHz	3,20GHz	64MB	120W	$450

Reacties (40)

[Balance]

Reviews

• Hexus
• ServeTheHome
• AnandTech
• Phoronix

[MSalters]

$3100 voor de 16-core Epyc 7F52? Dat is meer dan de 32-core Epyc 7502. Ja, hoger geklokt, maar je ruilt 100% meer cores in voor maar 40% meer Ghz, en dan ben je ook nog eens 25% duurder uit. Dat zijn dure Ghz. Kortom, goed schalende multi-core code betaalt zich uit.

Uiteindelijk is die 7282 wel een aantrekkelijke keuze, voor iets meer dat $40 per core, of $14,50 per core per Ghz. Dan is die nieuwe 7F52 voor hetzelfde aantal cores (16) een stuk prijziger met $55.36/core/Ghz.

[Astennu]

Het ligt heel erg aan je software of je wel wat hebt aan meer cores. Soms zijn die hogere clocks gewoon nodig.
En het aantal chips dat betrouwbaar continu 3.9GHz kunnen halen is aanzienlijk lager dan het aantal chips dat op die zelfde voltages 3,35GHz kunnen halen. Dit heeft gewoon met speed binning te maken. Op de 7502 kan je een aantal chiplets kwijt die relatief slecht zijn en dus maar 3,35GHz hoeven te doen. Op de 7F52 moet je 2 8 chiplets hebben met cores die onder dezelfde omstandigheden 20% hoger moeten clocken en dat wel 100% betrouwbaar.

Natuurlijk verdient AMD er ook leuk aan maar het is niet dat het helemaal onzin is dat die CPU's met de betere chiplets duurder zijn.

En wat andere ook al aan gaven er is ook meer cache actief. Ook dat kan weer met binning te maken hebben.

[Reactie gewijzigd door Astennu op 22 juli 2024 23:55]

[Damic]

Dat klopt niet, de 7F52 heeft 8 chiplets aanboort want volle cache (32MB/chiplet), d.w.d.z. 2c/4t per chiplet.

[born2rule]

daarom zal ie ook wel zo duur zijn, dubbel zoveel L3 cache zoals @mvt ook al aangaf. Zal vast wel een usercase te bedenken zijn waarbij die nuttig kan zijn

[MrFax]

SRAM als L3 is inderdaad extreem duur om te maken, dus het is zo gek niet idd.

[Astennu]

Je hebt gelijk.
Er wordt dan veel afgeschreven om. Toch die cache hoeveelheid te geven. Daarnaast moeten ze ook allemaal cores bevatten die wel hoog clocken.

[peter van uils]

Je moet ook rekening houden met de kosten van server software die soms per core of per 16 core berekend wordt. Goed voorbeeld hiervan is Windows server 2019. Dus dan wordt het in bepaalde gevallen kosteneffectief om een cpu met een wat lagere core count te draaien.

[Dennism]

Voor Windows Server is dat eigenlijk nog niet eens super interessant met kort door de bocht 1000 euro per 16 cores (of 6500 euro bij Datacenter), zaken als MS SQL server, Oracle Enterprise e.d. dan weer des te meer aangezien daar de prijzen kunnen oplopen tot $50k per core list, gaat ook nog wel wat korting vanaf, maar toch, dat zijn iets forsere prijzen.

[Scriptkid]

die mag je ook gewoon uit zetten,

Als je een 24 core hebt en je gebruikt er maar 16 dan mag je in de bios 8 cores uit zetten en er maar 16 licenseren.

Dus dat is totaal geen issue of verschil.

[Gamebuster]

Maar dan... heb je 8 idle cores? Die niets doen?

[Scriptkid]

anders heb je 8 idle cores die niets doen en heel veel licenties geld kosten.


stel dat je hardware 24 cores is gekocht op toekomst groei.

dan kun je vaak gewoon 16 cores license en gebruiken. na 2 jaar besluit jij dat je meer capaciteit nodig hebt en enable je de cores en koop je de licenties.

nu spaar je 2 jaar windows en applicatie licenties uit , dat kan boven de 50K kosten besparing opleveren.


Dat is het zelfde idea als de ooude AS400 systemen, die waren kwa hardware ook het zelfde en een upgrade was alleen een andere licentie er in doen.

of net als tesla met de batteries. zodra je het pack koopt en de licentie invoert heb je ineens 90KW

[Reactie gewijzigd door Scriptkid op 22 juli 2024 23:55]

[MSalters]

Dan kun je beter een 16-core VM maken en een 8-core VM. Als je ooit die eerste VM wil groeien naar 24 cores, dan verhuis je die tweede VM naar nieuwe hardware.

[Scriptkid]

moet je nog steeds je licenties in VM ware betalen + niet alle applicaties draaien goed op virtual.

Daarnaast moet die machine dan dus ook weer shared storage en ram in extra hebben.

Daar weer boven op na de groei naar 24 cores zit je met een VM op dedicated hardware met 15 % overhead loss en een heleboel extra complexiteits overhead in de virtual laag.?? Of je moet de hele machine gaan herinstalleren.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 23:55]

[sprankel]

Multi core is allemaal heel leuk in theorie maar een applicatie die effectief 32 cores belast? Allemaal leuk met virtuele machines en databanken maar voor een dedicated server met dedicated software heb je 9 van de 10 niets aan al die cores. En gezien je geen desktop aan het draaien bent waar 20 applicaties op staan
zijn 8 cores ideaal en dan ga je kijken naar hun performance.
Gezien de markt hier meer vraag naar heeft, grootste reden volgens mij dat Intel nog altijd stevig de servermarkt in handen heeft, krijg je een hogere prijs. De clocks zijn overigens heel hoog, de server variant moet die snelheid vasthouden, ook op zuivere AVX workloads, iets waar zowel Intel als AMD het lastig mee heeft.

Los dan nog van licenties die per core beginnen rekenen zoals reeds aangehaald.

[psychicist]

Wat is het probleem om software multi-threaded te maken voor grote aantallen threads? Volgens mij maken C, C++ en Java het vrij eenvoudig om grote aantallen threads te starten en daarnaast zal het met Go en Rust ook wel moeten lukken.

Licentietechnisch zal het voor propriëtaire software inderdaad problematisch kunnen zijn, maar dat zie ik niet als een probleem van de hardware. Misschien is dat ook wel de reden dat processoren met grote aantallen cores voornamelijk ingezet worden voor cloud computing, waar dit soort zaken niet echt speelt.

[Reactie gewijzigd door psychicist op 22 juli 2024 23:55]

[MSalters]

Threads starten is het probleem niet. In c++ is 't niet meer dan een std::thread object aanmaken.

Het probleem is om 1 brok werk op te splitsen in 2 taken die tegelijk kunnen lopen. Sorteren is zo'n bekend probleem. Quicksort bijvoorbeeld is 1 thread. Een miljard getallen sorteren met 1 thread duurt een tijdje, dan is "quicksort" niet meer zo quick. Een parallelle soort kan dan sneller klaar zijn, ook al doet die meer werk om het werk te verdelen.

[Gamebuster]

Analogie: Boodschappen doen.

1 core = 1 persoon.

Je moet 64 producten kopen en afleveren in de kofferbak van een auto.

1 persoon loopt de winkel in, pakt 1-voor-1 ieder product, rekent af, laadt de auto in.

Nu met 64 personen.

Ieder persoon krijgt de opdracht 1 item te kopen. Maar welk item? 1 persoon verdeeld het lijstje over de andere 63 personen, terwijl de 63 personen wachten op hun lijstje. De 64 personen stromen 1 voor 1 de winkel in, pakken het item, en rekenen af. Rijen bij de kassa, natuurlijk. Gelukkig gaan er wel een paar extra kassa's open.

Eenmaal klaar lopen de 64 personen gedruppeld de winkel uit en vullen ze de auto. Als er niet al een opstopping bij de kassa was, is die er nu wel bij de auto. Een groep van 10tallen mensen proberen dezelfde auto te vullen.

Nu hoef ik niet een rekensom erbij te halen dat boodschappen doen met 64 personen niet 64 keer zo snel gaat. Ook, als je de tijd dat ieder persoon bezig was bij elkaar optelt zal je zien dat de totaal gespendeerde tijd veel hoger is dan de tijd die nodig was voor 1 persoon.

Je kan bijna stellen dat het efficienter was om het gewoon met 1 persoon te doen. Misschien met 2, 3 of 4 was je sneller klaar, maar dan nog steeds is 1 persoon het meest efficient, omdat je niet boodschappenlijstjes hoeft te verdelen en samen hoeft te werken om de auto te vullen.

[sprankel]

Naast dat je altijd blijft zitten met de software moet het ondersteunen en vaak ondersteund men tot X cores hangt het zoals reeds aangehaald er nog altijd vanaf welke load je juist hebt.

En zelfs al heb je een load die vrij goed op meerdere threads kan lopen, hoe verder je in dat verhaal gaat hoe meer overhead je krijg zoals ook al uitgelegd in de andere reacties. Er komt dus een kantelpunt waarbij het multicore verhaal stopt tenzij je iets hebt wat daadwerkelijk volwaardig parralel berekend kan worden maar voor gewone loads daalt het voordeel met meerdere cores exponentieel.

Er is daar uiteraard onderzoek naar gedaan en de wet van Amdahl's zegt ons dat we de dikke winsten door multi core te gebruiken reeds hebben gehad op 64 cores, 128 & 256 cores zijn nog semi de moeite maar daarna is het echt wel gedaan.

Maar als je daar gaat kijken naar loads die maar 50% parallel te krijgen zijn, dan is het reeds gedaan na 8 cores.

https://en.wikipedia.org/wiki/Amdahl%27s_law

[Reactie gewijzigd door sprankel op 22 juli 2024 23:55]

[Dreamvoid]

Dat soort grote chips worden vooral gebruikt in database servers, en dat schaalt in de regel heel goed met cores omdat je heel veel gelijktijdige queries hebt - zie bv Oracles Sparc monsters met 32 cores/256 threads die speciaal voor DB toepassingen geoptimaliseerd zijn.

[MSalters]

Ik heb klanten die nu 3 16-cores draaien voor hun workload op 1 site. Bare metal, 3 instances van een single app. Vermoedelijk zouden die over kunnen stappen op een enkele EPYC 32-core. (Gaan ze niet doen; een enkele Xeon-D is voor hun nog sneller. AMD heeft geen AVX-512)

[mvt]

Ik zat ook al te kijken naar de prijs en waarom die zo duur was. Zag later pas dat de 7F52 dubbel L3 cache heeft. 256 vs 128 MB

[j005t]

Je kan het denk ik vergelijken met een grote auto en een snelle auto. Wil je ergens snel zijn zou ik een snelle auto kopen. Wil je met veel mensen ergens heen zou ik een grote auto kopen. Beide auto's zijn even duur maar hebben hun eigen toepassing.

[Rctworld]

"Dat zijn dure Ghz. Kortom, goed schalende multi-core code betaalt zich uit.", het is maar hoe je het ziet... Die prijs is vaak een listprijs (voor korting vanuit een OEM) en staat natuurlijk in schril contrast met de kosten van één of meerdere FTEs die de software schrijven. Als die zich door de hogere kloksnelheid kunnen toeleggen op het toevoegen van nieuwe features die meer klanten aantrekken ipv optimalisatie dan is die op het eerste gezicht "dure CPU" ineens een koopje. 😊

[Reactie gewijzigd door Rctworld op 22 juli 2024 23:55]

[Dennism]

Je moet ook de prijs van je software meerekenen, een berekening op basis van alleen cpu's zegt niet zoveel. Als jij 50K per core (over je hele cluster) aan Oracle Enterprise af mag tikken bijvoorbeeld dan zijn dedicated clusters met cpu's met wat minder cores, maar wel heel snelle cores ineens heel interessant in bepaalde gevallen.

Daarom ook altijd naar het volledige TCO plaatje kijken bij dit soort hardware, op grote IT projecten valt de prijs voor de cpu's vaak in het niet wanneer je kijkt naar het totaal plaatje aan kosten.

Het is goed dat AMD met deze Sku's komt om ook hier met Intel de concurrentie aan te gaan en niet alleen op het high core count vlak.

[Reactie gewijzigd door Dennism op 22 juli 2024 23:55]

[dasiro]

tja als Intel geen dual-socket CPU's wil uitbrengen, dan claimt AMD simpelweg héél deze markt, "too easy" moeten ze in Santa Clara gedacht hebben

[Dennism]

Ik denk dat je de achtergrond dat artikel niet goed begrepen hebt, Intel schrapt de dual socket Sku's Cooper Lakes omdat die vrijwel niets extra's brengen over Intels Cascade Lake refresh Sku's. Ga je kijken naar de markt dan heeft AMD volgens de laatste cijfers (IDC Q4 2019) zo'n 7% van de 1-2 socket server markt in handen, de andere 93% is Intel.

AMD wil Q2 2020 10% van 1-2 socket markt in handen hebben (met een beetje geluk gaan ze daar zelfs wat overheen), maar maak je geen illusies, AMD komt nog niet in de buurt van Intel om "deze hele markt" te claimen. Ik vraag me echt af op wat voor cijfers je dat baseert.

[MSalters]

Cooper Lake voegt alleen DLBoost 2 toe (BFloat16). AMD heeft nog geen support voor AVX-512, laat staan AVX-512 VNNI (DLBoost 1, INT8). Dus voor de Cooper Lake doelgroep heeft Intel toch geen concurrentie van AMD. De concurrentie daar is NVidia met de GTX2080 TPU's. Die tikken 20 TFlops aan in Float16.

[d3x]

en al die instructiesets zijn nichemarkten

[psychicist]

Daarom zie ik ook meer heil in het gebruik van accelerators, omdat je dan slechts de accelerators zelf hoeft te vervangen om betere prestaties te behalen en niet de processoren of zelfs het hele systeem. Intel is nu eindelijk wel competitief qua prestaties, wat met de verscheidene Xeon Phi accelerators volgens mij nooit het geval was.

[MSalters]

Ik heb voor nieuwe servers al AVX-512 gespec'ed, dat is niet heel erg exotisch. Ons probleem met accelerators is de latency. Op het moment dat je een taak naar een accelerator stuurt heb je al gauw een paar milliseconde latency. Dat is helemaal niet erg als de taak daar enkele seconden sneller runt. Als je echter real-time video-analyse doet (40 ms/frame) of audio (0.03 ms/sample) dan is die latency een probleem.

Op zich kan die latency lager met in-socket accelerators, maar dat zijn exotische plannen. Sockets zijn bepaald niet gestandaardiseerd.

[KabouterSuper]

Ik hoop dat amd eindelijk gaat meedoen bij database servers. Ik heb jarenlang cpu's tbv databases getest, en door de brute snelheid van Intel cpu's won intel het altijd van de rest (in elk geval voor de applicatie waar ik verantwoordelijk voor was).

[d3x]

EPYC2 is al uitvoerig getest in menig degelijke review site en daaruit is gebleken dat ze zeker op kunnen tegen Intel nu met DB toepassingen. Dat was nog niet het geval met EPYC1.

[Wim-Bart]

Ik hoop dat amd eindelijk gaat meedoen bij database servers. Ik heb jarenlang cpu's tbv databases getest, en door de brute snelheid van Intel cpu's won intel het altijd van de rest (in elk geval voor de applicatie waar ik verantwoordelijk voor was).

Ligt toch een beetje aan de workload van de database server en hoe deze gebouwd is. Wanneer je veel IOPS wil kan je met EPYC er voor kiezen om de PCIe lanes goed te benutten door meerdere controllers te gebruiken. Vaak zie je oplossingen waarbij er een 10Gbps kaart met 4 aansluitingen geplaatst wordt in plaats van twee dual of 4 single. Zelfde met raid controllers, waarom 1 en niet 2 of zelfs 4. Zeker in een dual socket heeft dat zo zijn voordelen waarbij IO load wordt gebalanceerd. Laatst zag ik nog een server aangeleverd door een gerespecteerd leverancier in een project waar ze een 4 poort 10Gbe en een 2*2 poort FC kaart op de zelfde interne PCIe bus hadden aangesloten en maar afvragen waarom de performance niet gehaald werd. Afgezien van het feit dat bij een storing op de 4 poort kaart het ook niets uit maakt dat het naar 2 switches gaat....

[bjp]

dit is wel een goeie zet van AMD. Ok ze zijn duurder, maar ze gaan recht in op wat Intel te bieden heeft, frequentie.
AMD deed het al beter op prijs/core, en aantal cores per CPU.

Als ze nu ook betere frequenties beginnen te bieden (ten koste wel van aantal cores)...

Mooi allemaal, concurrentie.

Ik snap ook dat ze beginnen met varianten met minder cores: die snellere cores zullen wel warmte afstotten. Zou je nu en het max aantal cores en max frequentie hebben, dan heb je een oven Op termijn, met betere cores gaat dit wel kunnen.

[Reactie gewijzigd door bjp op 22 juli 2024 23:55]

[BlaDeKke]

Waren Intel xeon met een hoge corecount per core sneller dan epyc?

[bjp]

heb je er twee specifieke modellen dat je wil vergelijken?

[Veneficus]

Doe maar "geklokt"...

[Swart_Arthur]

Ik denk dat Intel marketing duidelijker moet uitleggen dat met de Cascade Lake lijn een dual CPU configuratie weinig meer toevoegt. Op deze manier wandelt AMD weg met een marktaandeel waar Intel gewoon heel veel kwaliteit biedt.
Misschien is die $ 15.000 voor een Intel processor niet voor iedereen een hamerstuk, dat je voor dergelijke CPU's geen dual board maakt kan ik me voorstellen. Toch was het het eerste waar ik naar keek toen ze langs kwamen.

Ik hoop overigens wel over een paar jaar zo'n Epyx 7742 of een Xeon 9282 in de aanbieding aan te treffen. Al is het maar voor de heb. Van de extra kracht van mijn huidige dual 6c/12t boven de dual 4c/4t van twee jaar geleden merk ik eigenlijk alleen iets in locked 60fps CIV6 en Cities Skylines (die helemaal niet zo multithread geoptimaliseerd zijn). Hoe 112 of 128 threads zich gedragen als ik 3d Patience speel lijkt me de moeite van een investering waard.

[lasermen]

Ah, eindelijk een waardige opvolger van de 7371
De flitshandelaren zullen vast en zeker wel in de rij staan om hier een aantal van in gebruik te gaan nemen.