Intel Xeon Sierra Forest-serverprocessors krijgen maximaal 144 E-cores

Intels komende Sierra Forest-cpu's voor servers worden geleverd met maximaal 144 efficiënte E-cores per processor. Dat meldt Intel tijdens een update van zijn datacenterroadmap. Sierra Forest verschijnt in de eerste helft van volgend jaar.

Intel deelde tijdens zijn Data Center and AI-webinar verschillende updates voor zijn serverroadmap, die tot en met 2025 loopt. Het bevestigt onder meer de coreaantallen van zijn komende Xeon Sierra Forest-cpu's. Het bedrijf kondigde die chips vorig jaar al aan, maar deelde toen nog weinig concrete details.

Sierra Forest-cpu's bestaan volledig uit op efficiëntie gerichte E-cores. Intel levert de chips met maximaal 144 E-cores per processor. Het worden de eerste Xeon-serverprocessors met dergelijke kernen. Intel gebruikt E-cores sinds Alder Lake in zijn consumentenprocessors, hoewel die dan worden bijgestaan door krachtigere en traditionelere P-cores. E-cores zijn zuiniger en nemen minder oppervlak in dan die P-cores, maar zijn ook minder krachtig en ondersteunen geen hyperthreading.

Sierra Forest verschijnt in de eerste helft van 2024. Het bedrijf produceert de chips op zijn Intel 3-node, die eind dit jaar gereed moet zijn voor volumeproductie. Intel zegt daarnaast dat Clearwater Forest, de tweede generatie Xeon-cpu's met E-cores, in 2025 uitkomen. Die processors worden geproduceerd op het Intel 18A-procedé, de geavanceerdste node die het bedrijf op zijn technologieroadmap heeft staan. Het bedrijf deelt verder geen details over Clearwater Forest.

Xeon-cpu's met P-cores: Emerald Rapids en Granite Rapids

Het bedrijf blijft daarnaast Xeon-processors met P-cores uitbrengen. Dit jaar komt het bedrijf nog met Emerald Rapids. Die cpu's dienen als opvolger van de onlangs uitgebrachte Sapphire Rapids-cpu's voor servers. Het bedrijf produceert deze chips wederom op zijn Intel 7-procedé, dat voorheen bekendstond als Intel 10nm Enhanced Superfin. Intel is begonnen met het uitdelen van de eerste Emerald Rapids-samples aan bepaalde klanten. De officiële release moet in het vierde kwartaal volgen.

Deze cpu's worden opgevolgd door Granite Rapids, die eveneens gebruikmaken van P-cores. Granite Rapids wordt geproduceerd op het Intel 3-procedé en krijgt een hoger coreaantal dan de Emerald Rapids- en Sapphire Rapids-cpu's. Hoe hoog dat aantal cores precies ligt, is niet bekend. De chips ondersteunen verder maximaal DDR5-8800-snelheden. Deze processors moeten vlak na Sierra Forest uitkomen, in de eerste helft van volgend jaar. Granite Rapids en Sierra Forest gebruiken dezelfde socket.

Reacties (41)

[Coolstart]

Het grote voordeel aan e-cores is dat ze 4x kleiner en efficienter zijn dan complexe P cores. Geen AVX512 etc.

Voor high performance computing is het niet geschikt maar wel in omgevingen waar vele vCPU’s de norm zijn. Bijv bij cloud applicatie servers.

Als je dan een 2 socket moederbord hebt, heb je per rack 288 cores. Dat levert voor bedrijven zoals amazon een hoge core density op van duizenden cores per m2.

[Reactie gewijzigd door Coolstart op 23 juli 2024 23:47]

[Mars Warrior]

Het voordeel van de E-cores is voornamelijk dat ze 4x kleiner zijn, en dat Intel er een hoop op een die kan kloppen om zo zoveel mogelijk cores te kunnen hebben.

Maar - afhankelijk van de frequentie - zijn E-cores gewoon NIET, NIET, NIET efficient!

Ik heb dat zelf ook goed kunnen meten, en Chips And Cheese heeft dit ook onderzocht in Alder Lake’s Power Efficiency – A Complicated Picture

"This looks bad for the Gracemont based E-Cores. According to Intel, they can’t beat the P-Cores at any power level, meaning the E-Cores are only efficient in terms of area."

"Average power draw is only part of the picture. Gracemont cores are called E-Cores for efficiency, not LP-Cores for low power."

"With a vectorized load, Golden Cove finishes the task so much faster that it ends up using less total energy than Gracemont, even though Gracemont draws less power. That means running Gracemont above 3.2 GHz is pointless if energy efficiency is your primary concern. Running the E-Cores at 3.8 GHz basically makes them worse P-Cores. But that’s exactly what Alder Lake does by default."

En verder:
"Below 3 GHz, Gracemont shines. It’s able to maintain better performance at very low power targets (as we saw in the previous section) while consuming less energy. With an integer workload, it’s especially efficient."

Dus afhankelijk van de snelheid mag je de E-cores dus wel "efficient" noemen. Ik heb geen idee hoe snel deze cores draaien in deze nieuwe CPU.

Ik heb in mijn server de E-cores op 2-2.5Ghz draaien. Op die frequentie verbruiken ze bij een workload ca 3x minder (in Joules) dan op de max. frequentie van 3.8Ghz

[Reactie gewijzigd door Mars Warrior op 23 juli 2024 23:47]

[skelleniels]

Het is maar allemaal te zien hoe je het bekijkt. Als je voor je performancevraag kan toekomen met 1 machine met 144 cores op 3,8 GHz en je dat aantal cores nodig hebt (4 E-core op de oppervlakte van 1 P-Core), dan is dat beter dan 2 machines te vullen met 2 * 144 cores @ 2,5 GHz om de lagere GHz te compenseren of 2 machines met enkel P-Cores om het aantal cores te compenseren.

Voor virtualisatie met veel machines die ook wat Single thread performance nodig hebben, zou ik dus lekker gaan voor een machine met hooggeklokte E-Cores.

[Reactie gewijzigd door skelleniels op 23 juli 2024 23:47]

[Ventieldopje]

Maar daardoor heb je ook geen HT waardoor je dus ook maar 1 thread per core hebt (en dus 144 threads), dit terwijl AMD met de AMD EPYC 9654 je 96 cores hebt met 192 threads. Plus dan heb je het over "normale" cores dus met alle fratsen.

Dit zou dus echt op prijs moeten geen concurreren en daar zal vast wel een markt voor zijn inderdaad (bijv. webservers/clouds).

Al is bijv de Ampere Alta Max (128 core 64-bit ARM server processor) ook een goeie als het komt op prijs/kwaliteit volgens mij.

[Reactie gewijzigd door Ventieldopje op 23 juli 2024 23:47]

[B127]

Zoals @d3x al zegt, komt AMD dit jaar al met iets vergelijkbaars: 128c/256t Bergamo op basis van Zen 4c. Ik kan me best voorstellen dat er een markt is voor dit soort CPU's bij de grote could diensten, maak ik vraag me af of ze op SF gaan wachten.

[PolarBear]

Maar daardoor heb je ook geen HT waardoor je dus ook maar 1 thread per core hebt (en dus 144 threads), dit terwijl AMD met de AMD EPYC 9654 je 96 cores hebt met 192 threads

Nou is een hyperthreading thread ook niet altijd gelijkwaardig aan een echt thread.

[d3x]

Dat klopt, maar wat als je competitor al bijna 1j eerder op de markt komt met een soortgelijk design?

Waarbij de cores dan nog eens dezelfde logic hebben als de echte full cores? En zelfde hoge core count vs e-cores.
Waarbij er enkel een reductie in cache is, geen truukjes van reductie van AVX en andere accelerators
Waarbij wel SMT aanwezig is.
Die wel werkt in een bestaande socket en technology (drop in cpu just BIOS)
Die ook in 2024 een tech refresh heeft op de moment dat intel komt met e-cores maar dan wel met eenzelfde socket compatibiliteit

Ze blijven nog enkele jaren gewoon een gigantische server technologie achterstand hebben, Zelfs Saphire Rapids is door OEM nog maar net te leveren, dat is 2 maanden na hun officiele announcement.

[Reactie gewijzigd door d3x op 23 juli 2024 23:47]

[Gamebuster]

ik ben niet zo "into intel" op dit moment; wat is de performance van zo'n E core eigenlijk, op een moderne 13-serie chip?

[StackMySwitchUp]

Ik heb mogen testen/troubleshooten op een 12-serie chip met E- en P- cores. De performance is met renderen ongeveer de helft-2/3 van een P core. Het is een moeilijke vergelijking vanwege het missen van multithreading.
Stroomverbruik is wel aanzienlijk lager.

Wat ik me afvraag is waarom zou men een CPU met meer E-cores afnemen als zo'n beetje alle licentiemodellen tegenwoordig per core gaan?

[ACM]

Wat ik me afvraag is waarom zou men een CPU met meer E-cores afnemen als zo'n beetje alle licentiemodellen tegenwoordig per core gaan?

Is dat echt zo'n gebruikelijk licentiemodel?

Ik ben niet zo bekend met enterprise software, maar zie toch wel ook wel allerlei software met andersoortige licentiemodellen. Aantal voorbeelden van licentiemodellen die ik ben tegengekomen:
- "Free as in beer"
- Op basis van aantal accounts/gebruikers
- Op basis van aantal "developers"
- Op basis van hoeveel dataverkeer (bijv loadbalancer software)
- Per node (dus een volledige al-dan-niet virtuele server ongeacht aantal cores)

[Reactie gewijzigd door ACM op 23 juli 2024 23:47]

[bjp]

EDA tools voor electronica... heel vaak extra licentie als je meer parallel wilt doen. Simulatoren zijn zelf hoofdzakelijk singlethreaded nog, waardoor trage cores in een grote regressie er gewoon voor zorgt dat je licenties langer bezet. En die dingen zijn duur.

[ACM]

Dat ze bestaan weet ik. Ook Oracle is/was een klassiek voorbeeld.

Maar er wordt gesuggereerd dat het de defacto standaard is ("zo'n beetje alle"). En daarvan vraag ik of dat wel echt klopt

[Arrigi]

Tja, software is flexibel, hardware een stuk minder. De meest schaalbare en efficiënte optie op hardwarekant is cores toevoegen. Voor hetzelfde verbruik kan je wel 8x iets tragere cores doen, maar niet 1x een 8x zo snelle core.
Aan de softwarekant vraagt dat dan ook een investering. Men kan blijven wachten op die 8x snellere core, maar die komt er niet zomaar.

Ik vind snel wel even https://mlech26l.github.io/pages/2020/12/17/cpus.html , als je recente data erbij neemt zitten we wel aan 8x in iets minder dan 20 jaar. Intussen zijn we ook van single-core naar 96 cores in een socket gegaan.

Geld vragen puur omdat ze multithreading hebben moeten implementeren is een beetje een criminele belasting.

[Sissors]

Voor meeste van die tools moet je gewoon geen efficiënte cores willen maar performance cores. Nog helemaal los van licentiemodellen, het schaalt gewoon niet goed genoeg met aantal cores. Maar efficiëntie cores wil je juist inzetten bij taken die wel goed schalen met meer cores.

[StackMySwitchUp]

Sorry misschien had ik wat specifieker moeten zijn. Het gaat voornamelijk om hypervisors, databases en ander spul dat direct op ijzer draait (en zo'n beetje de doelgroep is van dit soort CPUs)
accounts/gebruikers/devs/dataverkeer en nodes zijn 1 of meerdere lagen hoger in de keten, en daar zou het inderdaad een vreemd licentiemodel zijn.

[batjes]

Microsodr is wel de bekendste denk ik.

[etamminga]

Dat vraag ik mij ook af. Een kleine enterprise serverruimte word zo onbetaalbaar, vmware, Windows, veeam, alles per aanwezige core. Word de cloud iig nog aantrekkelijker

[sircampalot]

Word de cloud iig nog aantrekkelijker

De cloud is niets anders dan iemand ander's computer.
Die ander loopt tegen dezelfde licentie problemen aan.

[barbarbar]

Als voor de cloud je software aanpast in plaats van één op één overzetten, dan heb je met veel van die licenties niets meer te maken.

[d3x]

Niemand zegt dat een kleine enterprise dit type moet gebruiken. De toekomst portfolio zal zich dan ook dermate aanpassen aan de verwachtingen van de afnemers, waaarbij er verschillende positionering zal zijn van product types.

[recyclebin]

Misschien tijd dat die licentiemodellen bijgewerkt mogen worden waarbij er onderscheid wordt gemaakt en andere prijzijn worden gehanteerd tussen P en E cores?

[Riesch]

Misschien tijd dat die licentiemodellen bijgewerkt mogen worden waarbij er onderscheid wordt gemaakt en andere prijzijn worden gehanteerd tussen P en E cores?

Licentiemodellen versimpelen/op de schop ben ik altijd voor. Maar om het nou nog lastiger te maken met verschil tussen E & P cores zit gok ik niemand op te wachten.
Nouja behalve de sales afdeling die deze licentie bedenkt natuurlijk, die zullen er van smullen.

[Fiander]

tja, het is ook lastig.
Microsoft is een paar jaar terug overgegaan van licentie per CPU naar licentie per core ( wel goedkoper per core ),

Het eerlijkste zou zijn betalen per mips/specint score ( met glijdende schaal ) denk ik, een snellere processor is dan qua licentie duurder, maar zal naar gelang dat ding ouder wordt, en er snellere uitkomen, goedkoper worden.

Als een snellere cpu zorgt dat medewerkers minder tijd kwijt zijn om hun werk te doen, dan wint het bedrijf. ben je een startup, neem je een trage intel, ben je serieus, neem je een AMD EPYC. ben je cheapass, doe je ARM. ( puur ter illustratie!! )

[Cergorach]

Als de performance van een E-core 1/2 tot 2/3 is van een P-core, wat bedoel je dan met 'aanzienlijk' lager stroomverbruik? Ook 1/2 tot 2/3? Of meer richting 1/10?

Afhankelijk van het stroomverbruik van die E-cores vs de P-cores kan dat leiden tot (significant) meer performance per watt, wat ook weer vertaald naar minder warmte. Wat vertaald naar OF minder koeling of meer servers in dezelfde ruimte voor mogelijk dezelfde kosten. Wat je meer uitgeeft aan licentiekosten bespaar je mogelijk op server density (serverruimtes zijn duur) en/of stroomverbruik.

Maar is rendering niet efficiënter op GPUs? Waardoor je veel minder last heb van het per CPU core licentie model?

Het zou me inderdaad niets verbazen als bepaalde leveranciers E-cores in de toekomst slechts voor een gedeelte gaan rekenen of wellicht helemaal niet. Lijkt me geheel afhankelijk van het type software en hoeveel baad het heeft van een E-core.

[StackMySwitchUp]

It depends (want boost enzo) maar 1/8e van het verbruik in nominale gevallen is niet ongewoon.

Rendering wordt in veel applicaties nog op CPU gedaan omdat het heel lang de default was. dit omdat op GPU renderen vaak veel minder nauwkeurig was vanwege.. redenen die ik niet meer weet

In dit specifieke geval ging het om een pakket dat bedrijven gebruiken om keukens in te tekenen, dit renderde via een vage closed source plugin, dus klant had dikke CPU besteld, alleen renderen ging in low priority, en dan word je in Windows 10 automatisch gescheduled op de 4 E-cores, en niet de 8 P cores

[wildhagen]

Wat ik me afvraag is waarom zou men een CPU met meer E-cores afnemen als zo'n beetje alle licentiemodellen tegenwoordig per core gaan?

Energiezuiniger. Daardoor genereert hij minder hitte, en heeft dus minder koeling nodig. Erg handig voor een datacenter bijvoorbeeld, waar geen heavy duty werk gedaan wordt.

[bzzzt]

Wat ik me afvraag is waarom zou men een CPU met meer E-cores afnemen als zo'n beetje alle licentiemodellen tegenwoordig per core gaan?

Als je per se software moet gebruiken die zo'n achterhaald licentiemodel heeft is dit gewoon niet de CPU die je moet hebben.
Er bestaat zat software die niet mank gemaakt is met dit soort flauwekul. Linux, applicatieservers, OSS databases draaien er waarschijnlijk prima op.

[wildhagen]

Op Reddit heeft iemand een review gemaakt over de performance van een E-core tov een P-core. Dit is weliswaar een 12e generatie CPU, maar toch.

Conclusie was dat één E-core ongeveer 40 procent van de prestatie biedt van één P-core op die CPU.

Dit is een CPU die heel nuttig kan zijn in een datacenter, waar hij bijvoorbeeld VMware/HyperV draait en veel verschillende servers kan hosten met een 'normale' workload.

Voor echt heavy duty is een "all E-core" CPU minder geschikt, maar in een datacenter kan dit juist heel nuttig zijn door het aanzienlijk lagere energiegebruik, en daarmee ook minder hitte ontwikkeling (en dus minder koeling benodigd).

[Navi]

Same, we zijn hier overgestapt van Intel naar AMD. De keuze was bv voor een 24 Core Xeon 5318Y, maar als je goed kijkt heeft die 8 P-cores en 16 E-cores.

Zijn toen voor een AMD EPYC 7443P gegaan, gewoon 24 volwaardige cores, hogere klokfrequentie, en nog iets voordeliger ook!

[JoepPannekoek]

De Xeon 5318Y heeft gewoon 24P cores hoor... E-cores zitten nog niet in xeons op het moment.

[Navi]

Op deze pagina:
https://www.intel.com/con...0-ghz/specifications.html

Staat:

High Priority Cores 8
High Priority Core Frequency 2.30 GHz
Low Priority Cores 16
Low Priority Core Frequency 1.80 GHz

Misschien iets andere techniek, maar komt volgens mij op hetzelfde neer?

[JoepPannekoek]

Ja maar het 24c/48t en E-cores hebben geen hyperthreading. Dus denk dat dat iets anders betekent.

[recyclebin]

Op het eerste aanzicht lijkt me Sierra Forrest vooral aantrekkelijk voor servers die your average business webapplications draaien; computationeel niet te intensief maar nadruk op het kunnen afhandelen van een groot aantal requests doordat er veel simultaneous threads/cores beschikbaar zijn.

[Paul]

Niet alleen web applications, ook "traditionele" servers. Onze VMware clusters zitten qua procent belasting lang niet aan de max, maar de verhouding pCPU/vCPU is wel redelijk scheef, en dan letten we toch echt al wel op wat een VM gebruikt (dus geen 16 cores toekennen aan een simpele Windows server die de hele dag uit zijn neus staat te peuteren omdat de leverancier dat vraagt; 1 of 2 werkt ook)

[d3x]

Er is een verschil in vCPU, PCPU,de over commitment die je doet op CPU en het effectieve verbruik van CPU cycles (en hopenlijk vooral niet op memory). CPU cycles hangen sterk af van type applicaties en load en kan je niet veralgemenen of een model gebruiken van een ander, dat moet je designen, onderhouden en ondervinden.

In deze gevallen zijn de laatste generaties kwa cores idd omhoog gegaan maar alsook het aantal geheugen lanes rechtstreeks op de CPU. Daardoor blijft het nog steeds mogelijk om een goede balans te maken tussen CPU, memory en de totale load.

[Moonspring]

Als Intel op tijd overstapt naar zijn Intel 3 procede zijn ze uit de problemen. Tot die tijd lijken de producten maar zo zo.

[d3x]

helaas voor intel niet enkel bij een node verkleining Intel 3, want met een monolithical die approach gaan ze nog altijd tegen dezelfde problemen aankijken. Een approach die 3-4j R&D kost om het schip te keren van beweging. De Granite rapids zijn nog steeds 4 monolitic dies naast elkaar geplakt en dit is dan ook nog maar hun eerste versie, remember het verschil tussen Epyc 1 en 4, een gigantisch verschil in topologie en technologisch voordeel.

Ze willen het niet toegeven en hebben er lang mee gelachen, maar jaren geleden heeft AMD de weg gezet naar een veel betere schaalbare optie, één waar silicon logic per tile kan geplaatst worden op verschillende node types en prijs klasses, één waar sommige logic gewoon niet denser gaat ook al smijt je het op een kleinere node of de kost voor verkleining dermate hoog is dat het geen goede financiele zaak is. Nvidia zit op dat vlak identiek op hetzelfde probleem en beide moeten dus inhalen.

Deze logica maakr nu ook dat AMD op een veel simpelere manier andere technieken kan combineren, iets wat je voorbeeld zal zien bij MI300 maar ook op consumenten schaal al toegepast word als je kijkt naar de opkomende laptop generatie.

[Reactie gewijzigd door d3x op 23 juli 2024 23:47]

[Keeper of the Keys]

@AverageNL Heb je misschien meer informatie over wat er op de tweede slide staat?

Excellent Silicon Health Silicon Power-on Operating Systems booting in <18hours

Ik neem aan dat we het hier niet hebben over OS boot zoals normaal want daar zou <18uur niet echt indrukwekkend zijn.

Begin tot einde productie zou heel indrukwekkend zijn maar lijkt me ook erg onwaarschijnlijk.

[AverageNL]

Ik weet het niet 100% zeker, maar volgens mij gaat dit over de eerste keer dat een vroege versie van Sierra Forest is aangezet (in het lab van Intel). Dat noemen ze ook wel het 'silicon power-on'-proces. Het duurde dus 18 uur om een OS draaiend te hebben. Dat gaat dan om een chip die nog vol in ontwikkeling is en pas over een jaar uitkomt. Dat is inderdaad niet indicatief van de daadwerkelijke opstarttijd bij release

[Reactie gewijzigd door AverageNL op 23 juli 2024 23:47]

[DeSoepkip]

Leuk al die cores... maar veel software betaal je per core, lekker verdien model zo.

[SCS2]

Ik dacht dat de licentie per CPU is, niet per core.

Dus meer cores per cpu, misschien cpu minder nodig en dan goedkoper ?