AMD Epyc-serverprocessor met 64 cores heeft tdp van 225 watt

De typenummers, core-aantallen en de tdp's van AMD's nieuwe generatie Epyc-processors voor servers zijn bekend. De details staan in een Euraziatische database, waar de fabrikant ze heeft aangemeld. Kloksnelheden zijn nog niet bekend.

In totaal staan er negentien uitvoeringen in de database, waaronder drie varianten met 64 cores. Het topmodel is de Epyc 7742 met een tdp van 225W. De twee andere 64-corevarianten hebben een tdp van 200W en waarschijnlijk lagere kloksnelheden. In de database staat echter geen informatie over de kloksnelheden.

Er komen ook Epyc-processors met 48, 32, 24, 16, 12 en 8 cores. De tdp's van de Epyc-processors zijn hoger dan die van de nieuwe Ryzen-consumentenprocessors met een gelijk aantal cores. Zo zijn er Epyc-versies met 16 cores en een tdp van 155W, terwijl de Ryzen 9 3950X voor consumenten een tdp van 105W heeft.

Net als de nieuwe Ryzen-processors zijn de komende Epyc-processors gebaseerd op Zen 2-cores die op 7nm worden gemaakt. De opbouw met cpu-chiplets naast een i/o-die is gelijk aan de consumentenprocessors. Bij de Epyc-varianten is de i/o-die groter en wordt deze op 14nm gemaakt, in plaats van op 12nm zoals bij de Ryzen-processors.

De Epyc-processors voor servers hebben daarnaast meer cores dan de tegenhangers voor consumenten en kunnen ook in systemen met meerdere sockets geplaatst worden. De P-modellen zijn varianten die alleen werken in systemen met één socket.

Eind vorig jaar bleek al dat er Epyc-processors met 64 cores komen die op 2,35GHz draaien. Dergelijke chips worden gebruikt bij de bouw van de Hawk-supercomputer van het High-Performance Computing Center van de universiteit van Stuttgart.

AMD heeft de Epyc-processors nog niet formeel aangekondigd. Ze staan tot nu toe bekend onder de codenaam Rome en moeten ergens in het derde kwartaal van dit jaar uitkomen.

Update, vrijdag: Een aantal nieuwe Epyc-processors staan bij een Nederlandse webwinkel met prijzen en kloksnelheden. De 7702P met 64 cores zou op 3,35GHz draaien en zo'n 7600 euro kosten.

Processor	Cores	Threads	Tdp
Epyc 7742	64	128	225W
Epyc 7702P	64	128	200W
Epyc 7702	64	128	200W
Epyc 7642	48	96	225W
Epyc 7552	48	96	200W
Epyc 7542	32	64	225W
Epyc 7502P	32	64	180W
Epyc 7502	32	64	180W
Epyc 7452	32	64	155W
Epyc 7402P	24	48	180W
Epyc 7402	24	48	180W
Epyc 7352	24	48	155W
Epyc 7302P	16	32	155W
Epyc 7302	16	32	155W
Epyc 7282	16	32	120W
Epyc 7272	12	24	120W
Epyc 7262	8	16	155W
Epyc 7252P	8	16	120W
Epyc 7252	8	16	120W

Reacties (146)

[Ijsklont]

Misschien handig om erbij te vermelden dat de ....P achter een type-nr de indicatie is dat die betreffende EPYC CPU ontworpen is om alleen gebruikt te worden in Single CPU opstellingen.

[Chocomel_Deluxe]

"speciaal ontworpen" als in betere single performance, of als reden om de "speciaale" cpu's voor multi o plossingen duurder te maken?

[Ijsklont]

De CPU's die alleen gebruikt kunnen worden in een 'Single CPU' of ook wel 'UP' opstelling, zijn goedkoper in aanschaf dan de CPU die gebruikt kan worden in de 'Dual CPU' of ook wel 'DP' opstelling.

Als je bijvoorbeeld in de Pricewatch kijkt naar de 7401P en 7401. De 7401P Tray kost 1182,50 en de 7401 Tray kost 2237,79.

Deze trend zie je ook bij de 7551 CPU (als je de prijsfout van Azerty even niet meer rekenend.

[Pathogen]

Ja, maar komt dit door een hardwarematig verschil dat dan ook de hogere prijs verklaart? Of is er bij de UP-versies alleen iets uitgeschakeld ten opzichte van de DP-versies?

[Ijsklont]

Ja er is een werkelijk verschil, dit heeft te maken met de interconnect tussen de CPU's in een DP opstelling vs UP opstelling.

Laat ik weer de voorbeeld van de 7401P en 7401 pakken. Beide CPU's beschikken over 128 PCIe lanes.

De 7401P heeft alle 128 PCIe lanes beschikbaar voor eventuele PCIe devices in een Single CPU server, deze kan echter niet gebruikt worden in een Dual CPU server, alleen in een Single CPU server.

De 7401 heeft ook 128 PCIe lanes maar 64 van de PCIe lanes worden gebruikt voor de interconnect tussen CPU's wanneer twee van deze CPU's gebruikt worden in een Dual CPU server, daarom heb je bij een Dual CPU server nog steeds maar 128 PCIe lanes beschikbaar voor PCIe devices en niet 256.

Je kan de 7401 CPU ook gebruiken in een Single CPU server, echter vanwege zijn design zullen er maar wel 64 PCIe lanes beschikbaar zijn ipv 128 PCIe lanes zoals bij de 7401P.

[kidde]

Op ServeTheHome staat een mooie uitleg:

-Rome heeft waarschijnlijk 129 PCIe kanalen, 1 daarvan is voor 'supertrage zooi' zoals server management,
-Er zijn er dan inderdaad 8*16 over,
-Een single-socket heeft dan inderdaad 8 'aansluitingen' voor PCIe x16,
-Een dual-socket kan verbonden zijn met 4 van die 8 'aansluitingen', er blijven dan 2*4*16=128 (ex mgmt) kanalen over, maar,
-Een dual-socket kan ook verbonden zijn, naar keuze, met 3 van de 8 aansluitingen Beiden (2) houden dan 5 kanalen over, dus 2*5*16 = 160 kanalen (ex management) totaal.
-Theoretisch kan je twee sockets ook met slechts 2 van de 8 'aansluitingen' interconnecten, maar kennnelijk is hier geen klantvraag naar.

Heb je veel communicatie tussen je sockets nodig dan gebruik je de 128-kanaals variant, wil je echter (10 stuks van?) de gister gepresenteerde Xilinx Versal ACAP* met 'Coherent Cache' aansluiten (waarbij de ACAP toegang heeft tot het geheugen zonder dat via de 'CPU omweg' te hoeven doen), dan wil je liever meer kanalen, dus wil je waarschijnlijk de 160-kanaals variant.

*ACAP: Dit is een 'programmeerbare' accelerator, bijv. 'programmeerbare AI accelerator', maar verwacht worden ook toepassingen voor 5G, radar en automotive. Op deze manier zou een Xilinx-AMD combo in de buurt moeten kunnen komen van een Intel-Intel (ex-Altera) combo; echter Xilinx loopt voor qua proces-technologie (TSMC 7).

Ed: Even nagezocht hoe het zit met Intel 10nm FPGA's.

Nadat de pers inc. Tweakers de fotofops overnamen van de 'een half jaar naar voren gehaalde' niet-bestaande Intel-5G-vapourware farce, heeft Intel-advertentiekanaal Purch nu weer een onzin-plaatje van een 'droom-10nm-product' met niet bestaande DDR5 en PCIe5-controllers voor een niet bestaande FPGA geplaatst, waarvoor ook nog eens geen datum is aangekondigd. Niet dat het wel bestaande 10nm ook maar enigszins presteert, werkt of winst maakt natuurlijk... Maar wordt wel weer lekker massaal gepubliceerd op alle klikbeet-websites! Dit commentaar laat echter zien dat Intel's FPGA-tak praktisch dood is.

[Reactie gewijzigd door kidde op 23 juli 2024 08:46]

[sympa]

Interessant commentaar. Ik zou denken dat Altera nog wel even bestaat, en Intel daar nog voor kan blijven fabben (maar inderdaad: waarom, als ze capaciteitsproblemen hebben).
De combi maakt het makkelijk de FPGA snel met RAM te verbinden. Maar dan kan ook via PCI lanes, toch? FPGA's gebruik je toch voor data streaming, niet voor pointer chasing dus de CPE cache wil je niet gebruiken. Dus latency is minder belangrijk.
En als je de FPGA op een aparte chip hebt kan je lekker kiezen wat je wil: kleine CPE, grote FPGA (farm desnoods), of andersom.

[kidde]

Klopt, Intel FPGA gaat zeker nog bestaan zolang Intel er geld in pompt. Natuurlijk was ik ook overdreven negatief over Intel.

Maar wat ik ervan begrepen heb, zal degene die als eerste de nieuwe 'node' heeft in de FPGA-race, altijd het merendeel van het marktaandeel winnen. 'TSMC 7' is een proces dat op dit moment in massaproductie is (al enige maanden voor o.a. Apple, en vast een flinke voorraad opgebouwd voor Zen 2), terwijl we weten dat Intel 10nm slechts in kleine productie is voor apparaten die max 4 gHz halen. Voor een laptop misschien leuk, maar voor een peperdure FPGA ga je niet een slecht presterend proces nemen. Dus Xilinx loopt bij deze node voor, en gaat het grootste marktaandeel pakken lijkt me. Omdat Apple TSMC betaalt om ieder jaar met een nieuwe node te komen, gaat Intel de achterstand ook niet zomaar meer inhalen; terwijl Xilinx er juist aan werkt dat hun FPGA's met allerlei andere apparatuur verbonden kan worden.

De combi maakt het makkelijk de FPGA snel met RAM te verbinden. Maar dan kan ook via PCI lanes,

CCIX is een 'protocol-laag' bovenop de 'PCIe4 transportlaag'. Waar PCIe4 tot 16GB/s haalt, kan je met CCIX erbovenop kennelijk tot 25GBps komen. Daarbij zit de FPGA gewoon lekker op z'n eigen chip, mogelijk samen met een AMD Server CPU op een interposer. Maar kan dus ook gewoon iets 'moederbordachtigs' met PCIe sloten zijn, waarbij je de FPGA op de PCIe aansluiting klikt.

FPGA's gebruik je toch voor data streaming, niet voor pointer chasing dus de CPE cache wil je niet gebruiken. Dus latency is minder belangrijk

Durf ik niet te zeggen; er wordt in het reclame-materiaal ook gemikt op automotive, radar en beurshandelen en telco's. Voor die toepassingen lijkt 'latency' me toch al iets belangrijker te worden.

[Reactie gewijzigd door kidde op 23 juli 2024 08:46]

[sympa]

Latency in een cpu schaadt op het niveau van losse instructies. Dat zijn er een paar miljard per seconde - latency worst gemanaged in de nanoseconden.
Voor een telco en beurshandelen kan ke met microseconden werken. Ik denk dat bij radar een juist antwoord in 1 ms ook prima is.

[Ayporos]

Volgens mij is er in der daad wel een hardwarematig verschil.. of dit gerealiseerd word door middel van uitschakelen van functionaliteit die in de basischip wel zit óf het toevoegen van extra functionaliteit tov de basischip is mij onbekend.. het heeft iig te maken met interconnects zodat de 2 die's met elkaar kunnen communiceren.

[Xtuv]

Klopt, toegevoegd

[Tricolores]

Ongelofelijk, 64 cores! Als noob, kan iemand me enlighten of dit praktisch al enig nut heeft, of is dit vooral future proofing?

[kiang]

Maar 1 voorbeeld: server verhuur. Als jij een server huurt bij bvb Linode, dan krijg jij een aantal cores, wat opslag en wat RAM.
Fysiek is dat niet een bepaald stuk hardware, maar krijg jij je eigen VM.

Als een enkele CPU 64 cores heeft kan je dus meer VMs verhuren met minder fysieke servers, wat dus betekent dat je minder ruimte moet voorzien, en met dit TDP (225W is enorm weinig voor 64 cores) bespaar je ook nog eens op stroom en koeling.

[bbob]

Ideaal voor servers in datacenter, meer klanten per rack.

225watt voor 64 cores is idd ook mooi.
150-180 watt voor 32 cores.
120-155 watt voor 8 cores.

De logica zegt dan meer cores is naar verhouding veel zuinger per core.

64 cores, 1 core 3,51 watt
32 cores, 1 core 4,68 watt
8 cores, 1 core 15 watt

Vraag me trouwens in datacenter wel op een gegeven moment af, 64 cores, dan moet je ook snel 128 of 256 gb geheugen hebben. Je moet dan met meer klanten op een vps ook richting 10gb netwerk gaan, idem de aansluiting op een nas.
CPU is natuurlijk 1 ding bij een vps geheugen, netwerksnelheid, storagesnelheid speelt ook mee. Dat moet je ook opschalen en meer cpu's

[Reactie gewijzigd door bbob op 23 juli 2024 08:46]

[JohanNL]

Zeker zijn meer cores efficiënter, maar zó efficiënt ook weer niet ( tenminste de verhouding die je schetst )
Je kunt de TDP namelijk niet als daadwerkelijk stroomverbruik zien, het enige wat het concreet aangeeft is wat voor koeler je minimaal nodig hebt voor de desbetreffende cpu.

Het zit er namelijk best dik in dat die 64core in full load een aardig stuk meer dan 225w verbruikt, terwijl die 8 core met een TDP van 155w een heel stuk minder verbruikt dan wat de TDP aangeeft.

[kiang]

2 verklaringen mogelijk:

1) de modellen met minder cores draaien op een hgoere snelheid -> wss wel waar, maar in het server segment denk ik neit dat de kloksnelheid ver boven de 3GHz zal liggen. Ik gok dat de 64 core tussen de 2.2 en 2.5GHz draait, en de 8 core modellen onder de 3.5GHz blijven.
2) binning -> Dit is denk ik het grootste verschil: de duurste modellen met de meeste cores krijgen van AMD de meest efficient gebinde Zen2 cores.

Dat laatste zie je nu ook al wat in de Ryzen 3000 serie: de hoger geklokte 16 core 3950X heeft dezelfde TDP als de 3900X met 12 cores. En er is een 8 core versie met een TDP van slechts 65W, terwijl het andere 8 core model 95W verstookt, terwijl die slechts 100MHz sneller geklokt is.

Voor mij is het duidelijk dat AMD hier echt goud in handen heeft met hun chiplet aanpak: minder kwalitatieve chiplets zijn alsnog vrij zuinig tegenover Intel's 14nm CPUs, terwijl de beste chiplets echt absurd zuinig zijn en in de duurdere chips terecht komen..

[Dennism]

2 verklaringen mogelijk:

1) de modellen met minder cores draaien op een hgoere snelheid -> wss wel waar, maar in het server segment denk ik neit dat de kloksnelheid ver boven de 3GHz zal liggen. Ik gok dat de 64 core tussen de 2.2 en 2.5GHz draait, en de 8 core modellen onder de 3.5GHz blijven.
2) binning -> Dit is denk ik het grootste verschil: de duurste modellen met de meeste cores krijgen van AMD de meest efficient gebinde Zen2 cores.

1 en 2 zullen waarschijnlijk kloppen. Of het < 3.5Ghz weet ik echter niet, AMD lijkt nu ook met wat Frequency optimised Sku's te komen. Die kunnen nog wel eens hoger gaan klokken. Intel heeft bijv. Sku's als de https://ark.intel.com/con...4-75m-cache-3-60-ghz.html voor workloads die weinig cores maar hoge snelheid per core nodig hebben, ik denk (en hoop) dat AMD daar ook wel wat concurrenten voor in de markt gaat zetten.

Dat laatste zie je nu ook al wat in de Ryzen 3000 serie: de hoger geklokte 16 core 3950X heeft dezelfde TDP als de 3900X met 12 cores. En er is een 8 core versie met een TDP van slechts 65W, terwijl het andere 8 core model 95W verstookt, terwijl die slechts 100MHz sneller geklokt is.

Die maximale boost zou ik niet direct naar kijken, dat is namelijk waarschijnlijk op 1 of 2 cores. Voor het TDP is juist normaliter de hoogst gegarandeerde all core kloksnelheid belangrijk, daar er in de regel meer warmte genereert wordt wanneer de hele cpu volledig belast wordt dan wanneer er 1 of 2 cores belast worden. Die snelheden zijn 3.6Ghz voor de 3700X en 3.9Ghz voor de 3800X, daar zit dus "al" 300Mhz verschil in. Neemt niet weg dat ik ook denk dat relatief gezien de 3800X de slechts gebinde chiplets krijgt van alle nu aangekondigde Ryzen 3000 Sku's.

[Reactie gewijzigd door Dennism op 23 juli 2024 08:46]

[kiang]

Neemt niet weg dat ik ook denk dat relatief gezien de 3800X de slechts gebinde chiplets krijgt van alle nu aangekondigde Ryzen 3000 Sku's.

Hangt er van af wat je 'slecht' noemt

Je hebt namelijk ook de 3900X: 12 cores, nog hoger geklokt. Maar dat zijn dus 2 chiplets, die normaal elk 8 cores hebben, maar nu zijn er dus 2 inactieve cores per chiplet: kan best dat dat simpelweg defecte cores zijn.

De 3800X daarentegen bevat slechts 1 CCD, met 8 volledig werkzame cores. Sure: trager/midner efficient, maar wel werkzaam. Vanuit dat opzicht is de 3900X dus eigenlijk de 'slechtste' CPU: je koopt chiplets die half defect zijn

Imo maar weer bevestiging dat AMD echt goud in handen heeft: de grillen van een nieuw proces die normaal in lagere yield resulteren vangen ze helemaal op: zowel minder efficiente als deels defecte chips kunnen ze alsnog inzetten.

[Dennism]

Imo maar weer bevestiging dat AMD echt goud in handen heeft: de grillen van een nieuw proces die normaal in lagere yield resulteren vangen ze helemaal op: zowel minder efficiente als deels defecte chips kunnen ze alsnog inzetten.

Klopt maar dat was voorheen natuurlijk grotendeels niet anders. deels defectie of minder efficiente Zen 1 en Zen+ worden ook gewoon ingezet. Chiplets zijn uiteraard wel net weer wat efficiënter hierin.

[Reactie gewijzigd door Dennism op 23 juli 2024 08:46]

[daellat]

Ik las dat dat laatste (65W tegenover 105W) eerder komt omdat die TDP's meer categorisch zijn dan super precies. Daarmee bedoel ik dat als een chip 72W TDP heeft het in de 95W categorie komt, en er niet 72W staat. Als je naar de lineup sheet kijkt, zie je over de hele linie Ryzen 3000 chips alleen 65, 95 en 105 TDPs. Ook is de TDP eerder op basis van de base clock welke 300mhz hoger ligt. Gok dat er hardwarematig dus relatief veel verschil tussen de 3700 en 3800 gaan liggen.

[Iruk1981]

Een andere factor kan ook zijn dat niet al het opgenomen vermogen door de cores wordt opgenomen.

Wellicht dat de I/O chip ook wat verbruikt. De geheugencontroller, pcie controller etc.

[Bonez0r]

[...]

Dat laatste zie je nu ook al wat in de Ryzen 3000 serie: de hoger geklokte 16 core 3950X heeft dezelfde TDP als de 3900X met 12 cores. En er is een 8 core versie met een TDP van slechts 65W, terwijl het andere 8 core model 95W verstookt, terwijl die slechts 100MHz sneller geklokt is.

Kleine correctie. Ook de 8 core 3800X heeft een TDP van 105W (niet 95W). Het enige 95W model in deze serie is de 6 core 3600X. Dus je hebt een 16 core, 12 core en 8 core model die alle drie een TDP van 105W hebben.

https://en.wikipedia.org/wiki/Zen_2#Products

[Reactie gewijzigd door Bonez0r op 23 juli 2024 08:46]

[Dennism]

De logica zegt dan meer cores is naar verhouding veel zuinger per core.

64 cores, 1 core 3,51 watt
32 cores, 1 core 4,68 watt
8 cores, 1 core 15 watt

Klopt uiteraard, dit om een aantal zaken. Meer cores betekend vaak een lagere kloksnelheid. Dus minder verbruik per core.

Wat je hier ook nog ziet is natuurlijk het verbruik van de I/O die. Bij 64 cores kan je dat verbruik delen door 64 om op verbruik per core te komen. Bij een 8 core kan je dit slechts door 8 cores delen.

Ik verwacht trouwens dat machines met deze 64 core Sku's wel wat meer geheugen dan 128/256GB zullen hebben. Als ik kijk in virtualisatie deployments is dat al snel 256 tot 512GB Ram in nodes met rond de 16 cores. Nodes met een grotere density in cores zullen dan ook vaak nog (veel) meer geheugen nodig hebben om een zelfde consolidatie factor te behalen.

[MSalters]

Wat je hier ook nog ziet is natuurlijk het verbruik van de I/O die. Bij 64 cores kan je dat verbruik delen door 64 om op verbruik per core te komen. Bij een 8 core kan je dit slechts door 8 cores delen.

Daar staat tegenover dat je per core dus ook maar 1/64ste van de I/O bandbreedte hebt. Leuk dat je 2 TB aan RAM kunt installeren, dan heb je genoeg RAM per core, maar de toegang moet nog steeds via 8 channels. Elke core heeft dus 1/8 channel.

Dit soort CPU's is dus vooral nuttig voor reken-intensieve toepassingen die vanuit de L1/L2 cache van elke core werken. Voor web-hosting is een dual-socket 2 * 32 core oplossing waarschijnlijk beter, omdat je dan 2*8 DDR4 channels hebt.

[Jay-v]

Geheugen is goedkoop en er zijn PCIe NIC's waarmee VIF's aangeboden worden aan VM's. Dergelijke machines kunnen prima 4 PCIe 10G NIC's hebben. Ook die zijn niet meer bizar duur (200 eur).

[Uberprutser]

Helaas moet je ook zorgen dat je data erin en uit kan, je de hoeveelheid power per rack kan leveren en voldoende koeling hebt.

Wij hebben bewust gekozen voor minder cores per rack voor zowel bovenstaande als redundancy.

[JohanNL]

De TDP moet je niet gaan zien als daadwerkelijk stroomverbruik, dat is nattevingerwerk.
Het zegt vooral wat voor koeler je erop moet zetten; een koeler die een TDP van minimaal 225w aan kan.

[GewoonWatSpulle]

Ik zou dit niet aanschaffen voor future proofing, je moet software hebben die er vandaag goed gebruik van kan maken, denk aan simulaties, websites met rekenkracht intensieve taken etc.

[hichelay]

Dan krijg je toch juist een kip/ei verhaal? Ik ben zelf geen programmeur, maar als ik het goed begrijp, moet je eerst hardware hebben die dingen kan (zoals meerdere cores tegelijk inzetten voor verschillende processen uit één applicatie), voordat je je programma er op kunt schrijven.

[mjtdevries]

maar als ik het goed begrijp, moet je eerst hardware hebben die dingen kan (zoals meerdere cores tegelijk inzetten voor verschillende processen uit één applicatie), voordat je je programma er op kunt schrijven

Nee hoor, dat is helemaal niet nodig.

In principe wil je geen software schrijven die specifiek voor één hardware scenario werkt. (bv specifiek voor een machine met 8 cores, want dan werkt het niet meer optimal voor 4 of 16 cores.)

Wat je doet is multithreaded code maken, onafhankelijk van het aantal cores dat je tot je beschikking hebt.
Een thread is een taak die parallel afgehandeld kan worden. Zodra er in je code een mogelijkheid is om zo'n taak af te splitsen maak je daar een aparte thread van.
Op die manier krijg je al snel tientallen threads waarvan een aanzienlijk deel onafhankelijk van elkaar gestart kan worden, terwijl anderen op de resultaten van eerder taken moeten wachten.

Vervolgens kun je die code draaien op 1 core, of 4 cores of 16 cores. Dat maakt niet uit.
Op 1 core kun je maar 1 thread tegelijk draaien, net zoals met traditionele software die niet voor meerdere cpus geschreven is. En op 4 of 16 cores draaien er net zoveel threads parallel als mogelijk is zonder dat ze op het resultaat van een andere staan te wachten.
Je hoeft er zelf echter niets voor te doen. Je moet alleen die threads maken en je OS regelt de verdeling over de cores voor je.

Het is wel een andere manier van denken, om zoveel mogelijk threads te maken. En dat is vaak het moeilijkste. In server software heeft een applicatie vaak honderden threads waarvan er tientallen parallel kunnen draarien. Op desktop software valt dat echter vies tegen.

In spellen zie je bv dat veel code redelijk overweg kan met 2 tot 4 cores. Maar 8 worden er zelden gebruikt. Terwijl het juist in spellen heel simpel is.
Denk aan een shooter. Voor iedere vijand moet berekent worden of die jou kan zien en op je kan schieten. Voor elk van die vijanden kun je een aparte thread maken om die berekeningen te doen. En die kunen ook allemaal parallel van elkaar gedraaid worden. Op die manier kun je al heel snel 8 of 16 cores benutten.

[uiltje]

Tegenwoordig probeer je niet meer zelf de (hardware) threads aan te maken, behalve als je het beheer van de threads zonodig zelf wilt doen. Je maakt eerder zoveel mogelijk taken, en een scheduler beslist dan op welke thread die geplaatst wordt. Hardware threads zijn namelijk relatief duur, dus je wilt er niet honderden aanmaken. Dat kan je met taken wel doen. Dit is overigens een nuance, het doet verder weinig af aan de post van mjtdevries.

[GewoonWatSpulle]

Waarschijnlijk gebruiken die mensen momenteel:

• 2x 32-core machine, of
• 4x 16-core machine, of
• 8x 8-core machine

Gekoppeld via netwerk, als de netwerk laag weg gehaald kan worden passen er meer cores op minder oppervlakte of je hebt minder latency tussen de processen. Je kan prima multi-core software schrijven op een single-core machine en tot op zekere hoogte ook prima testen.

[vectormatic]

Klopt, maar het is niet zo dat je op een 4 core machine geen software kan schrijven die schaalt naar 64 of 128 cores, sterker nog, als je het een beetje netjes doet maak je je software zo dat ie of automatisch schaalt, of dat je zelf bepaalde parameters (aantal threads voor bepaalde taken) zelf kan tweaken terwijl de boel draait.

[likewise]

Het is vrij eenvoudig om een multi-core programma te schrijven wat meerdere identieke taken met verschillende data sets over meerdere cores verdeeld. Het aantal cores is eigenlijk niet belangrijk, de stap van 1 naar 2 cores is programmeertechnisch het grootst, daarna kom je bij hogere waardes van N weer met congestie problemen.

2-core systemen bestaan al heel lang, dus software ervoor is er wel.

[Secsytime]

Voor een server heeft dit absoluut nut.. voor een desktop (afhankelijk van de toepassing), nu nog niet..

[Zer0]

Dat ligt er natuurlijk aan wat die server doet, voor servers die veel parallelle taken hebben kan het inderdaad nut hebben, voor servers die dat niet doen kan het totaal geen nut hebben.
Er is dus geen sprake van een "absoluut" nut.

[primanocte]

dit is toch vooral voor VPS bakken lijkt me.. dan kun je cores verdelen over je Virtual machines

[bbob]

vps kan de cores idd mooi verdelen.

Voor een single computer die alle 64 cores gebruikt is en blijft het de vraag of de software zo ook echt effectief alles 64 kan gebruiken. Vaak zie je dat de software hier de beperking is en dat de 64 cores niet helemaal tot hun recht komen.

[SG]

100% effectief niet nee.
Maar er zijn taken waar supercomputers voor gebruikt worden waar load relatief goed verdeeld kan worden over 1000den cpu verdeeld over racks en multi-socket nodes.

voor als die zo belabberd zijn als veel desktop apps die op user input wachten. Is Supercomputer niet voor.

Er zijn dus in bepaalde bedrijf takken waar er genoeg toepassing zijn die wel schalen.

[SuperDre]

Aan de andere kant, als het OS goed met meerdere core's overweg kan, dan is het bij elke doorsnee server wel interessant, elke service zijn eigen core (of zelfs meer). Ook voor desktop zou dat handig zijn aangezien daar toch veel achtergrond services draaien.

[Zer0]

Maar wat gebruiken die achtergrond-services aan CPU? Als ik nu op mijn pc kijk zie ik naast de apps dit ik open heb geen enkel proces dat meer dan 1% CPU gebruikt. Leuk als die over 64 cores verspreidt worden, maar dan heb ik waarschijnlijk 60 cores die uit hun neus staan te vreten...
Zie het als een fabriekshal, je kunt hem tien keer zo groot maken, zolang je er geen extra machines en/of mensen in zet gaat de productie niet zomaar omhoog. Alleen als de hal nu te klein is om alle machines en/of mensen tegelijk aan het werk te houden heeft het nut om hem groter te maken.

[SG]

500 mensen die elk volledig onafhankelijk hun taak kunnen doen schaal ook 100%
500 mensen die complexe afhankelijkheden hebben werken niet efficient en vereist ook de nodige overhead (management en afdelingen) om daar meeste uit te halen.

Geld ook voor software er is software wat vaak ook intern ontwikkeld wordt voor supercomputers. Maar ook bepaalde server specifieke taken schalen goed.

Er is dus vraag naar en kan goed gebruikt worden.

Het is ook niet bedoeld voor algemene desktop taken of office. Maar vaak ook nog overkill voor meeste workstation taken. Bij zware server taken brengt het meestal wel meerwaarde.

[Zer0]

Het is ook niet bedoeld voor algemene desktop taken of office

Ik reageerde op de volgende stelling van SuperDre:

Ook voor desktop zou dat handig zijn aangezien daar toch veel achtergrond services draaien.

[bandidoloco]

Daar heb je de Threadripper reeks voor.

[NitroSizer]

Heeft zeker al praktisch nut, we hebben nu al servers met meerdere sockets voor meer cores/threads te hebben.

Dit is een goeie stap vooruit. Als we aan servers denken mag je er zeker van zijn dat er nooit genoeg cores zullen zijn, hoe meer hoe beter.

Ik denk aan render farms, Virtual machines die verhuurd worden voor websites op te hosten, cloudstorage, enzovoort.

[hottestbrain]

Klein voetnootje voor de toekomst: Op een gegeven moment moet er zo veel ram per mobo in dat het de moeite niet meer loont meerdere sockets op 1 mobo te gebruiken. Geen ramp natuurlij,k maar het vraagt wel omdenken. Daarnaast is uitval van 1 cpu gelijk een veel groter issue dan als die workload verdeeld zou zijn over 2 cpu's.

[NitroSizer]

Je hebt natuurlijk volledig gelijk, maar ik herriner mezelf ook nog een tijd waar de gedachte aan 512 gig aan ram een ondenkbaar iets was, tuurlijk ik was jong toen ik zelf een PC had met 128 megabyte aan ram.

Maar ik ben een sterk gelover in de eeuwige bottleneck, als we nu te ver gaan met onze CPU's zullen we een manier gaan uitzoeken dat we meer ram kunnen gaan hebben op een efficientere manier.

Ik ben blij om te zien dat iemand deze reactie gaf want het was iets dat ik verwachte.

En je hebt ook gelijk dat 2 CPU's vaak veiliger is, ik heb twee servers bij me thuis draaien en eentje heeft inderdaad al eens een kapotte CPU gehad, ik vind twee sockets prima, is lekker veilig dan blijft hij normaal wel draaien als het enkel CPU problemen zijn.

Maar het ding is ook dat je niet mag onderschatten hoeveel servers kosten in stroom verbruik, ik heb niet meer nodig dan 8/16 cores/threads per server voor mijn hobby projecten en studie doel einde, dat realiseert zich nu dus als iedere twee servers met beide twee xeon E5550's.

Maar ik moet toegeven dat de Epyc lijn mij wel warm maakt in wat ik zou kunnen besparen in electriciteits kosten.

We gaan altijd groter en beter proberen gaan als het aan komt op servers, en ik denk echt dat CPU cores nooit een harde limiet gaat behalen in hoeveel we er kunnen gebruiken, we gaan altijd nog wel wat meer kunnen gebruiken.

Dat RAM probleem daar vinden we wel een oplossing voor dat hebben we altijd gedaan, wanneer dat gaat gebeuren daar ga ik me niet over uitspreken.

[hottestbrain]

Volledig met je eens. Ik werk tegenwoordig voor een van de top10 techbedrijven wereldwijd en hoor in de wandelgangen her en der gezoem over deze CPU's, zowel positief als negatief: het kunnen draaien met Optane als persistent RAM is momenteel nog een duidelijke troefkaart van Intel. Dat zou tegelijk het RAM issue wel eens kunnen verhelpen... Intel kan met dit core-count geweld niet stil blijven zitten en is ongetwijfeld in navolging van AMD ook met chiplets aan de gang gegaan: De tijd zal het leren of AMD bij tijds (nu ze nog momentum hebben/voorlopen op corecount) met een alternatief kunnen komen.

[Cergorach]

Tegenwoordig zie je dan ook veel vaker Blades met 1 of 2 CPUs waarbij je 'vroeger' veel vaker servers had met 4-8 CPUs. Een deel komt omdat je natuurlijk veel meer cores heb per CPU, maar ook omdat VM software daar veel beter mee om kan gaan in cluster verband dan vroeger, niet te vergeten, veel goedkoper. En niet te vergeten automatisering bij beheer is een stuk beter geworden.

[the_stickie]

Voor virtualistaie betekent meer cores (en bijhorend meer geheugen) dat er meer VM's kunen draaien in dezelfde fysieke ruimte. Dat is volgens mij het scenario waarin die cpu's het meest gezien zullen worden.
maar er zijn genoeg andere servers te bedenken die niet echt exotisch zijn maar wel kunnen genieten van veel cores:
Webservers starten vaak veel processen, meer cores bekent dan meer performance. Meer cores betekent de mogelijkheid op meer parallelle processen, dus meer websites op dezelfde hosting.
Voor sommige databasetoepassingen is de hardware schalen de eenvoudigste (enige) oplossing. Drukke DB servers zijn dan ook veelal stevig uit de kluiten gewassen. (al wens ik niemand de licentiekost van Oracle of MS SQL toe op een 64 core machine)
Applicatieservers kunnen om het even wat doen. Als die taak rekenintensief is en multithreaded of in een proces per gebruiker, zijn meer cpu-cores eenvoudige performancewinst.
Terminal servers zijn ook soms cpu-bound, dat hangt natuurlijk af van de applicaties die erin gebruikt worden.

Er zijn dus zeker servers waar de eerste bottleneck de cpu is, zowel single threaded (waar deze 64 core dus weinig soelaas biedt) als in multithreading of ook (en misschien vooral) waar meer cores meer consolidatie toestaan. Je zou er versteld van staan welke kosten uitgespaard worden als je 2 servers kan vervangen door één, laat staan 32 (ofzo) door één!

[Dennism]

Bij DB servers zie je juist vaak dat er, wanneer mogelijk, zo min mogelijk cores gebruik worden. Juist vanwege de per core licentie kosten inderdaad die aardig kunnen oplopen. Als ik even snel kijk naar de list prijzen betaal je voor MS SQL Enterprise zo'n 1.5 miljoen enkele aanschaf, of 6 ton per jaar als met SA. Nu zijn dat list prijzen en kun je daar dus nog (flink) over onderhandelen, maar die prijzen zijn zeker zeer pittig. Volgens mij zit Oracle qua list prijs zelfs op $50k per core of iets in die richting.

[Reactie gewijzigd door Dennism op 23 juli 2024 08:46]

[psychicist]

Waarom zou je op zulke servers niet gewoon Postgres draaien, misschien met support van EnterpriseDB? Adyen draait ook alles op Postgres, dus waarom zou je jezelf nog afhankelijk maken van Oracle of MS SQL Server?

[Uberprutser]

Dan kan je ook nog naar AWS / Azure kijken.

Vergeet niet dat het migreren naar een andere database ook niet altijd gratis is (uren, applicatie aanpassen etc).

[the_stickie]

klopt helemaal. Maar dat is juist omdat (als je RAM en snelle disks even buiten beschouwing laat) cpu bound is. met meer cpu's kan je meer databases draaien (en dus de support kost van extra systemen uitsluiten) en meer gebruikers serven. Dat verklaart waarom de licentiekost per core is.

Dus men kiest inderdaad die cpu die net genoeg cores heeft. Maar er zijn zat implementaties waar men dan bij high-end multicores uitkomt, met krankzinnige licentiekosten tot gevolg. Als je de cores nodig hebt, is het nu eenmaal nog steeds kosteneffectiever die in zo weinig mogelijk machines te steken.
De vraag was waar kan je dit zoal voor gebruiken... een net hiervoor kàn zo'n cpu wel degelijk nuttig zijn, al is het niet de meest voorkomende configuratie (net zoals zelfs niet elke virtualistaieoplossing gebaat is bij een 64 core systeem).

Bovendien is niet elke database gebonden aan dat soort licentiekosten...

[ShockWave_Omega]

Virtualiseren van servers enz. Meer cores = meer virtuele machines mogelijk\snellere virtuals door meer cores toe te kunnen voegen. Of je maakt een monster pc.. net wat je leuk vindt.

[Reactie gewijzigd door ShockWave_Omega op 23 juli 2024 08:46]

[Rataplan_]

Toch zou ik huiverig zijn voor onze omgeving. Wij draaien nu op een aantal bakken met 2 10 core CPU's, met momenteel HT nog aan (maar dat gaat uit denk ik gezien de security (Intel CPU's)). Maar we zien dat memory de bottleneck is, niet CPU. Echter, het lijkt me erg afhankelijk van wat je met je servers doet. CPU is er plenty, maar geheugen bandbreedte zal uiteindelijk toch gedeeld moeten worden. 100 webservertjes op zo'n Epyc zal wel loslopen, maar bv 50 hard stampende SQL servers (mocht je genoeg geheugen kwijt kunnen) lijkt me toch wel impact te hebben op de algehele performance.

Maar wat een bakbeesten. 64 cores aan 225 watt (TDP zegt niet alles, I know) is 3.5 watt per core. Dat is minder dan bv een 8250U cpu terwijl hij ongetwijfeld veel sneller is per thread (aanname). Wat mij betreft een geweldige prestatie.

[supersnathan94]

Maar dan ga je aps aanbieder andere dingen doen en bijvoorbeeld DBaaS oplossing neerzetten. Dan heb je 1 SQL server met meerdere schemas eronder. Voor de buitenwereld heb je dan meerdere databases draaien maar intern is het eigenlijk gewoon 1 hele dikke.

[Rataplan_]

Dat snap ik ook wel...het was maar een voorbeeld. Wat ik bedoel is dat je bij memory-intensieve applicaties waarschijnlijk een sweet spot hebt vwb aantal vm's op een host die een dergelijke CPU niet rechtvaardigt / tot zijn recht laat komen.

[supersnathan94]

Uiteraard. Maar daar zijn deze CPUs dan ook niet voor bedoeld. Dit soort units zijn voor cloud providers. Waar je in vaste combinaties werkt van cores/GB waar je dan containers op kunt draaien bijvoorbeeld. Of CPU intensief spul.

[Dennism]

Per thread zou ik niet direct verwachten dat zo'n Epyc sneller gaan zijn dan de meeste cpu's. De kracht van server cpu's zit hem nu vaak niet in de kracht per thread (behalve bij een aantal frequency optimised Sku's), maar juist in het feit dat je zeer veel threads hebt.

[boonzaai]

Deze ga je terugzien in datacenters. Wij zetten regelmatig (golfsimulatie)jobs aan die we op 700+ cores laten draaien, dat doen we nu door VM's op te spinnen met 16 cores per stuk en de rekenpakketten hierover te verdelen.

Grappig is wel dat je binnen één machine voor dit soort jobs beperkt snelheidswinst ziet bij meer dan 32 cores. Blijkbaar wordt dan binnen het proces de communicatie-overhead te groot.

Kortom, deze 64 core chips zouden in ons geval dan 4 (aparte) VM's draaien.

[d3x]

ik denk dat je hier beter wat uitleg geeft over de beperkte snelheids winst...

2 tips:

1) een HT of SMT core is geen echte cpu, in vele cpu intensieve gevallen is het beter daar geen rekening mee te houden. maw 16cores/socket zijn geen echte 32 cores met HT/SMT

2) in een 1/1 load omgeving maw waar je 16+16cpu gebruikt op 32 echte cores moet je rekening houden dat een VM een world heeft, dus alle overhead van IO etc worden afgehandeld met omringende cores. dus in uw geval met 16+16 op een 32 heb je eigenlijk te weinig cores voor de world en gaat hij dus socket swappen etc om toch maar te kunnen schedulen.

[boonzaai]

Hoi,

Helaas kan er weinig van zeggen, heb het meer meegekregen dat ze bij de conculega met 64 cores maar marginaal sneller konden draaien dan op 32. Ons rekencluster spint gewoon een aantal losse machines op en knipt de jobs op over die losse machines, waardoor wij er binnen de machines geen last van hebben en dus wel lineair kunnen schalen door meer machines aan te haken. Zo kunnen wij op honderden cores draaien.
Is overigens onder water precies hetzelfde trucje als Hadoop (map/reduce), wij doen dat echter op Windows/Azure met gescripte throw-away VM's.

[d3x]

ah je hebt het dus over het verschil van 1 systeem tot max cores vs meerdere systemen. Inside scaling. was niet echt duidelijk in je uitleg. dat probleem komt wel vaker voor.

[vectormatic]

puur uit nieuwsgierigheid, op welk OS draait jullie "rekenmachine"? Naar ik begrijp kan de windows scheduler niet goed omgaan met hoge corecounts. (zie de threadripper 2990wx reviews)

[boonzaai]

Hoi,
Da's Windows. Het betreft hydrografische simulaties, ze zijn ook beschikbaar onder Linux. Wellicht dat Linux inderdaad ook hierbij een betere optie is, het is mij in elk geval verteld dat de (extreem) hoge corecounts binnen een enkele windows machine niet echt soelaas biedt.

[vectormatic]

Dan zou ik eens navragen of linux idd een mogelijkheid is, de windows scheduler heeft inderdaad beperkingen kwa core-count, bij de 32 core threadripper reviews zag je dat de 32 core nauwelijks beter presteerde dan de 24 core op windows, op linux schaalde alles gewoon lineair

[Verwijderd]

Ik vind het nogal stekend om die mensen dom te noemen. Er loopt meer dan genoeg volk rond dat slimmer is dan jij bent, maar geen idee heeft hoe een command line werkt.

Het voordeel van windows is dat iedereen ermee kan werken, dat moet je niet onderschatten.

[FreezeXJ]

Nee, het voordeel van Windows is dat iedereen getrained is om ermee te werken.

[Verwijderd]

Ah, en dat maakt mensen dus dom? Got it.

Misschien eens tijd om uit je ivoren toren te komen.

[RGAT]

Behalve jij, volgens je eigen profiel
Wat als ik je vertel dat de tegenhanger van RedHat niet Windows 7/10 is maar Windows Server 2016?
Hoe vaak je 'servers' tegenkomt met Ubuntu Desktop als OS...

[latka]

haha. Iedereen denkt het te kunnen gebruiken. Als er een pop-up verschijnt die er gisteren niet was gaan ze bellen met de helpdesk.

[Cergorach]

Het voordeel van windows is dat iedereen ermee kan werken, dat moet je niet onderschatten.

Pfft! Zeker nog nooit op IT support gewerkt...

"After making something foolproof, we found out that they keep making more foolish people!"
-- Unknown IT technician

[vectormatic]

Weet ik, maar daarmee is niet gezegd dat @boonzaai 's applicatie ook daadwerkelijk op linux draait. Ik ben zelf ook die-hard linux fan, en software engineer, maar weet ook dat in de wetenschappelijke gemeenschap nog wel eens met vrij aparte software gewerkt wordt, ik weet bijvoorbeeld niet of matlab ook op linux draait.

[FreezeXJ]

MatLab is gewoon Java, dus yep, dat werkt. Zie ook de site. Wetenschappers zijn vrij apart, maar ze lopen niet zo ver uit de pas, zeker tegenwoordig niet. Ze gebruiken zelfs GitHub!

[vectormatic]

haha check, geen idee dat matlab java was (overigens is dat hele "write once, run everywhere" ook wel een beetje aan het afbrokkelen, zeker nu met oracle aan het stuur)

[springtouwtje]

sorry, daar geloof ik geen biet van. Sommige instructies gebruiken een java heap, maar de instructies zijn echt van te voren gecompileerd. Matlab heeft echt de performance nodig.

[Lord Thunder]

Ik werk met dit soort systemen. Ze draaien allemaal op Linux (meestal een smaak van RedHat Enterprise Edition). En nee, er wordt niet met Matlab of java meuk gewerkt. Dat is zonde van de compute cycles. De meeste software is geschreven in (schrik niet) Fortran of C. Voor multithreading wordt meestal OpenMP en/of OpenMPI gebruikt.

[mario963]

“Waar veel domme mensen mee moeten werken”? Deze opmerking laat je niet al te intelligent overkomen.

[Dennism]

Webservers wel, Datacenters valt m.i. wel mee, ik kom veel meer dan 5% Windows tegen in Datacenters. Volgens mij draait bijv. Azure grotendeels op een van Hyper-V afgeleide Hypervisor. Al draait een deels van de SDN software dan weer wel op Linux (de ACS).

Verder nogal jammer om mensen op deze wijze dom te noemen, nergens voor nodig.

[Reactie gewijzigd door Dennism op 23 juli 2024 08:46]

[Kek]

Hangt volledig van de use case af. Een gemiddelde consument heeft er niets aan..

Voor bijvoorbeeld webservers is deze corecount dan wel weer handig..

[Timoo.vanEsch]

Ik zie consumenten ook geen Epycs kopen, maar goed.

[jesha]

Dit is meer gericht op data centers en niet op consumenten.

[MaxTheKing]

Is vooral handig voor virtualisatiebakken welke een heleboel VMs draaien.

[his.dudeness]

servers en software waar je zware berekeningen moet doen waar je vele uren of dagen (of weken) moet wachten. niet voor thuisgebruik, daar is threadripper voor.

Renderen van animatie films, berekenen van belichting voor bijv games, simuleren van physics voor wetenschappelijke doeleinden maar ook films, protein folding en nog veel meer!

[Reactie gewijzigd door his.dudeness op 23 juli 2024 08:46]

[mbosma]

Dit soort processoren worden over het algemeen gebruikt voor virtualisatie.
Hierbij kan je met meer cores (afgezien van andere factoren) simpelweg meer virtuele machines op de server draaien.

Met twee van deze cpu's en ram wat over het algemeen wel in de terabytes loopt draaien met gemak honderden servers op één machine.

[Kain_niaK]

Natuurlijk heeft het nut. Met meer cores kun je meer programma's tegelijk of meer services tegelijk draaien. Vermits het hier over server processoren gaat is dat dus wel handing.

Stel dat je een verkoper bent van VPS. (virtueel private servers). Je verkoopt dat virtuele servers waar er meerdere op een machine draaien. Als je nu van 32 naar 64 cores gaat kun je er dubbel zo veel verkopen!

[Mopperman]

Dit heeft voornamelijk nut voor Virtuele servers, en in mijn gevoel, voornamelijk grotere systemen met veel redundancy.

met 64 cores per CPU, 2 CPUs per systeem, een totaal van 128 Cores. kan je op 1 systreem met gemak 32 machines laten draaien welke nog steeds 4 cores totaal hebben. De praktijk leert echter dat veel toepassingen aan 2 cores meer dan genoeg hebben.

Los van dat feit: in bedrijven zie je ook steeds meer virtualisatie met een reservatie van cores. Bij ons in het bedrijf vervangen we momenteel liever 30 servers voor 1 VM bak (+ 1 redundancy) dan 30 nieuwe, losse servers.

[Jeffrey_KL]

Applicaties die een multithreaded workload hebben. Denk aan een website of API die meerdere aanvragen tegelijk moet kunnen afhandelen.

[Scriptkid]

ehmm tja 64 klinkt veel maar is nog lang niet genoeg. ligt er maar aan wat je er mee wilt gaan doen. Als je kijkt naar AZURE zie je dat bepaalde workloads al niet meer op CPU worden afgehandeld maar op GPU of zelfs op FPGA waarbij die laatste nog een heel veel sneller kan zijn dan GPU. Zijn vast wel al wat filmpjes van te vinden en ander is hier je docs:

https://docs.microsoft.co...ept-accelerate-with-fpgas

Als ik kijk naar mijn eigen workstation die soms dingen een half uur lang staat te compilen op 4/8 cores kan ik niet wachten om over een maand te upgraden naar Ryzen 3. Soms zit ik zelf 5-10 minuten te wachten bij laden van een single asset omdat shaders nog compiled moeten worden. Bij dit soort workloads helpt het wel om veel mem en cores te hebben.

[spoonman]

Dit is voor servers bedoeld, niet voor workstations. In een workstation denk ik niet dat je hier veel aan zou hebben, tenzij misschien voor 3d rendering.

[kidde]

Mwah, toch ook iets om mensen met koude voeten een alternatief voor Intel's onzin-voetkachel (alles voor de specs!!!) te geven.

Iets serieuzer, dat hierboven door anderen nog niet genoemd is; wat nu een keer niet over de giga-'hyperschalers', defensie-supercomputers en 'server-boerderijen' gaat:

Het schijnt dat er nu 'kleinere gebruikers' (MKB??) zijn die een 'klein clustertje' draaien, met <=64 cores. Die kunnen dat hele clustertje straks lekker buiten schoppen en vervangen door 1 computer. Tel uit je winst!

[SadisticPanda]

Bwa, filmpje encoden gaat wel retehard gaan

[nelizmastr]

Wat dacht je van een hele renderfarm van deze dingen? Quadrootje ernaast en biem.

[Praetextatus]

Rare opmerking dit. @Tricolores weet niet waar dit soort cpus voor worden gebruikt en stelt daar een vraag over. Of mag dat tegenwoordig niet meer?

On topic, ik ben echt benieuwd hoe deze serie scoort tegenover de directe concurrenten. Ook ben ik ben ik benieuwd waarom de TDP van de epics hoger is terwijl de opbouw vrijwel gelijk is aan de Ryzen series.

[catfish]

Hoezo rare opmerking? In de titel staat letterlijk dat het een server cpu is, rara waar gaan ze deze gebruiken...

[Praetextatus]

Geloof het of niet, er zijn nog steeds mensen die niet weten wat een server is. Los daarvan had je het ook op een fatsoenlijke manier kunnen verwoorden toch?

[mae-t.net]

Sowieso zet je kwaad bloed als je gelijk begint dat iets een rare vraag is. Als je al een sneer wilt uitdelen dan zeg je: ik VIND dit een rare vraag. Daardoor geef je aan dat het ook aan jou zou kunnen liggen (beleefdheid) en dat je er niet zo een bent die van hier tot het volgende zonnestelsel overtuigd is van zijn eigen gelijk (practisch nut, want dan hou je voor jezelf de kans open om bij te leren).

En als je wilt laten zien dat het een vraag is met een heel simpel antwoord dat zelfs jij weet (hee, was dat nou een sneer? ) dan geef je gewoon droogjes dat antwoord, eventueel met uitleg waarom het eigenlijk simpel is. Dat geeft je ook gelijk de kans om over dat antwoord na te denken en misschien zelf nog met vragen te komen waardoor je bijleert en een beter antwoord geeft.

En verder vind ik dat Praetextatus wel een punt heeft. Servers worden in de marketing tegenwoordig cloud genoemd om zoveel mogelijk verwarring te zaaien over wat het nou eigenlijk is. Als je de cloud aanhaalt in je antwoord, is intuitief meteen duidelijk waarom veel cores goed is; in de cloud gebeurt in het algemeen veel tegelijk voor verschillende software en gebruikers.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 08:46]

[SG]

Eigenlijk niet.
Naar wiki en dan search "server".
Dit lijkt mij algemene kennis.
verdwaald op tweakers .

Nu hele boom aan reply over iets wat meer Algemeene kennis is ook voor beetje computer site.

[Tricolores]

Geen rare vraag, ik ben namelijk totaal niet thuis in het server gebeuren.

[qbig1970]

Rare vragen bestaan niet, wel rare antwoorden.

[Countess]

64 cores, in de helft van het TDP (of een klein beetje meer) dat intel aan zijn 56 core chips plakt!

Als AMD hiermee geen significant marktaandeel kan veroveren dan weten we zeker dat intel weer smerige spelletjes aan het spelen is.

wat het verschil met de consumenten 16 core betref: de 8 channel geheugen controller en extra PCIe lanes zullen ook extra stroom nodig hebben, en de links tussen de die's zijn ook niet gratis.

Vraag me af hoe de core verdeling is bij een 8 en 16 core chip. zouden die ook echt alle 8 CPU chiplets hebben? lijkt me sterk eigenlijk

[Reactie gewijzigd door Countess op 23 juli 2024 08:46]

[longtime_lurker]

Details over deze low-core Rome CPUs zijn vooralsnog onbekend. Er wordt gespeculeerd dat voor deze SKUs chiplets 1 tot 2 cores actief hebben waardoor alle L3-cache van een CCX beschikbaar wordt voor een enkele core.

Dit zou een niche-oplossing zijn voor server-taken waar cache-per-core leidend is.

[Countess]

Zelfs met maar 1 core per CCX zou een 8 core aan 4 die's genoeg hebben.
de L3 van een andere CCX op de die kan niet gevuld worden van buiten de CCX (want het is een victim cache) dus met maar 1 core per chiplet zou de helft van de L3 leeg blijven.

Maar op deze manier zou dat wel alleen gelden voor de 8 core variant.

[Reactie gewijzigd door Countess op 23 juli 2024 08:46]

[longtime_lurker]

Exact. Daarom vraagtekens bij de 8-core SKUs. Deze theorie gaat wel goed op voor de 16-cores.

Wellicht 4 chiplets i.p.v. 8 voor de 8-cores? Zullen we snel genoeg achter komen vermoed ik.

[Countess]

Het zou ook een manier kunnen zijn om van de die's af te komen waarbij er een fout zit in de L3 van een van beide CCX's. dan zouden zelfs die dies gebruikt kunnen worden.

op zo'n manier zou AMD bijna 100% yields kunnen halen op de chiplets.

[Reactie gewijzigd door Countess op 23 juli 2024 08:46]

[Scriptkid]

Alleen waarom zou je een 8/16 Epic kopen als je voor minder geld een betere Ryzen kunt nemen met veel minder stroom verbruik (zeg maar de helft).

[Countess]

Simple: 16x16mb L3 ipv 4x
8x memory channels ipv 2x
128x PCIe 4.0 lanes ipv 40.

[itcouldbeanyone]

Ryzen heeft toch maar 24 lanes vanaf cpu ?

[Countess]

570x chipset heeft er 20 over nu.
4 van de pci-e lanes van de CPU zijn overigens gebruikt voor de verbinding met de chipset.

[itcouldbeanyone]

Lanes vanaf een chipset is niet het zelfde,
Dat zal betekenen dat ik 200Gbit internet heb aangezien mn procurve zoveel aansluitingen heeft

[Countess]

Terugnaar de originele vraag gaande is dat alleen maar meer reden om voor Epyc te kiezen.

[Dennism]

Die 40 is chipset en CPU samen, een Ryzen 3000 CPU zelf heeft 16 lanes (of 2x8) voor normaliter een GPU, 4 lanes voor NVME en 4 lanes naar de chipset toe.

[Scriptkid]

en al die extras gaan die paar cpus gebruiken ?

denk dat je tegen cpu power issues gaat lopen voordat je 40 lanes dicht trekt. zelfde geld zoon beetje ook voor de memory en L3 cache.

Leuk maar alleen is zeer speciale gevallen en ik denk dat je dan zoiezo beter af bent met een paar maatjes groter voor paar euro meer.

[Countess]

Redelijk wat software betaal je per core. En als je dan toch meerdere GPUs wil aansluiten, of veel snelle storage, of een mix van beide dan kan een 8 core Epyc uitkomst bieden.

[madmaxnl]

Gezien het TDP verwacht je wel aanzienlijk wat chiplets, het kan dus ook om modellen gaan met heel veel L3 cache t.o.v. aantal cores. Daarnaast kunnen ze natuurlijk ook heel specifiek chipslets gekozen hebben die op een paar cores veel hoger dan gemiddeld kunnen draaien.

[Dennism]

Ik verwacht eigenlijk wel dat deze, in ieder geval in bepaalde configuraties, ook alle chiplets hebben. Dit zie je namelijk ook al in huidige generatie en o.a. de cache configuratie zal daar van afhangen. Kijk bijv. naar een 3800X en een 3900X, een 3800X met 1 chiplet heeft 36mb cache en 3900X met 2 chiplets heeft 70mb cache.

Mogelijk krijg je nu dus Sku's met veel cache ten opzichte van het aantal cores, misschien Sku's met minder chiplets en dus ook minder cache.

Wel mooi dat de Epyc lineup ook weer uitgebreid wordt, zeker op low core count Sku's deed de vorige generatie het nog niet heel best.Zo waren met maar enkele Sku's met low coe counts, volgens mij maar 1 frequency optimised Sku.

Dit lijken ze nu eindelijk aan te pakken. Want anders dan veel mensen o.a. hier, maar ook op bijv. Reddit lijken te denken is zijn de high core count sku's in veel marktsegmenten niet de hardlopers. Als ik kijk naar gemiddeld aantal cores per server die ik verkocht zie worden ligt dat vaak nog op rond de 16 cores per server ("toevallig" ook het minimaal aantal cores dat je voor Windows Server in licentie moet nemen).
Maar ook servers die software gaan draaien die per core afgerekend moet worden (denk bijv. aan bepaalde varianten van MS SQL, Oracle Enterprise), maar er is ook de verwachting dat gezien de "Core" races van AMD en Intel meer vendoren naar "per core" licensing zullen gaan. In dat soort gevallen zie je vaak dat er zo min mogelijk cores worden afgenomen met een zo hoog mogelijke snelheid per core.

[Brousant]

Ik snap niet goed waarom het TDP van de zuinigste van de 16-core-modellen meer dan de helft is als dat van het onzuinigste 64-core-model. Je zou verwachten dat het in de buurt van een kwart zou zijn.

[Dennism]

Waarom zou je dat verwachten? 16 cores v.s. 64 cores zegt daar in principe niets over. Om dat te kunnen beargumenteren moet je ook de kloksnelheden weten.

Daarnaast speelt hier mee dat deze Sku's een I/O die hebben. Deze zal bij een 8 of 16 core model relatief gezien veel meer impact hebben op het TDP dan bij een 64 core Sku. Terwijl in absolute zin de bijdrage aan het TDP mogelijk gelijk is.

[Brousant]

Waarom zou je dat verwachten? 16 cores v.s. 64 cores zegt daar in principe niets over. Om dat te kunnen beargumenteren moet je ook de kloksnelheden weten.

Zouden de cores van het onzuinigste 64-core-model dan aanzienlijk langzamer lopen dan die van het zuinigste 16-core-model? Dat lijkt me sterk.

En uiteraard zit er op zo'n processor nog meer dan de kale processorcores, maar het verbaast me als dat gemeenschappelijke deel zoveel van het stroomverbruik voor zijn rekening zou nemen.

[Cuqebaqer]

Vaak hebben minder cores hogere clocks.

[Countess]

De I/O die is bij al deze modellen het zelfde. Daar zit met 8 geheugen kanalen en 128 PCIe 4.0 lanes best wat verbruik.

Daarbij zal de clocksnelheid van de lagere core count modellen waarschijnlijk ook hoger liggen.

[TheSanderZone]

Oef, 64cores én windows datacenter draaien als host, daar gaat je SPLA bijdrage flink van omhoog

[NiLSPACE]

Licenties die per socket gaan zullen hiervan echter profiteren.

[Dennism]

Dat klopt, er gaan echter wel geluiden op dat door deze "Core races" van AMD en Intel meer en meer software huizen overwegen om "Per Socket" de deur uit te doen en ook naar "Per Core" te gaan, omdat dit soort zaken hun bottomline zal gaan raken.

[Countess]

Wat hun klanten dan weer zal doen bewegen om andere vendors te gaan zoeken, of open source, omdat het anders hun bottom line gaat raken.

[Dennism]

Dat kan inderdaad en zal ook zeker voorkomen, echter vergis je niet in de kosten die soms zitten in het vervangen van software. De hardware kosten vallen dan regelmatig in het niet en dan is het soms makkelijker om andere hardware te kopen dan flinke kosten te maken aan de software kant. Zeker opensource is niet gratis wat veel mensen denken, en dat hebben een aantal relaties waar ik in verleden mee te maken gehad heb ook flink gemerkt (aantal migraties van MS Office naar Open Office, of een variant daarvan. Veelal zeer snel en na een boel kosten weer teruggedraaid om dat het toch niet lekker werkte met de andere bedrijfssoftware en de productiviteit af nam en het personeel ontevreden werd).

[Countess]

Nee, de kosten voor zo'n migratie onderschat ik ook zeker niet.
(al denk ik wel dat de open source situatie voor backend software beduidend beter is als de desktop software)
En het is zeker niet voor iedereen een optie om te migreren (naar open source of iets anders).vendor lock-in is niet voor niks een bekende term.

Maar ik denk ook dat die software vendors wel moeten gaan inzien dat de performance verbeteringen per core niet meer zo hard zullen stijgen, en dat als ze over gaan op een per core model, ze het risico lopen dat hun software, voor een x bedrag, steeds verder achter zal gaan lopen wat performance betreft met software die een per socket licentie heeft of alleen support in rekening brengt.

Dat gaat ze wel parten spelen bij het binnenhalen van nieuwe klanten, ook al hebben ze hun huidige klanten in hun software kunnen locken.

[Scriptkid]

hoe is dat anders dan bij 2 machines van 32 ?????

juist door de core calculatie maak dat nu niet meer veel uit.

[TheSanderZone]

Omdat het helaas niet zo 1-op-1 werkt in de praktijk. Een verdubbeling van cores betekent niet perse een verdubbeling van de running VM's zeg maar. Je komt dan weer andere limieten tegen.
En als je in de praktijk er minder running VM's op kwijt kan moet je toch ergens de kosten doorberekenen.

[Scriptkid]

als je van te voren weet dat je ze niet gebruikt dan koop je die hardware toch niet ???

of je zet de cores uit dan heb je geen licentie addon daar voor nodig.

dus jouw redenatie gaat niet op.

[kaas-schaaf]

De hogere TDP klinkt alsof dat te maken heeft met de IO chip. Deze dient meer PCIe lanes aan te spreken en meer features the hebben dan de consumenten cores. Daarnaast zijn de epyc IO chip op 14nm en de consumenten IO chip op 12nm gebakken. Wellicht maakt dat ook nog uit.

edit: verduidelijking

[Reactie gewijzigd door kaas-schaaf op 23 juli 2024 08:46]

[Weliz_music]

De Epyc cores(chiplets) zijn op 7nm gebakken. Ik denk dat je de I/O-die bedoelt.

[kaas-schaaf]

Dat bedoelde ik ook maar met het typen op de telefoon heb ik IO weg gelaten ...

[Tao]

De SP3 socket was toch voorbehouden aan Threadrippers?
Ik surf naar die Euraziatische database, mik die tekst in Google Translate en zie dan b.v. entrees als
number (article): 100-000000075, SVR EPYC 7542 225W SP3. (Er staan er meerdere tussen met SP3.)

Is dat dan een Epyc server cpu of een Threadripper...?
Je zou denken een server vanwege Threadrippers voor 1p opstellingen uitgebracht worden. Zij het dat die SP3 me dan weer doet fronsen.

[|sWORDs|]

TR4 of SP3r2 voor Theadripper en SP3 voor EPYC.

[Chiron]

Dat scheelt ook wel in de kosten bij software die een licentie per socket hebben

[Cuqebaqer]

Wel geweldig hoe AMD na jaren niks nu opeens al deze mooie nieuwe hardware laat zien. Ik ben dan ook volledig unbiased als het op merken/bedrijven aan komt. Elke nieuwe ontwikkeling heeft de consument profijt van zowel als bedrijf als particulier. Concurrentie is immers goed in de meeste gevallen. Dit betekend ook dat we waarschijnlijk binnenkort leuke xeon's via eBay gaan zien. Dit is dan voor mij weer leuk voor hobby projecten.

[snarfj]

misschien kunnen we hier ook de treadripper varianten en verbruiken aan deze lijst ontleden