Intel-website bevestigt core-configuraties van komende Alder Lake-processors

Intel heeft ontwikkelaarshandleidingen voor zijn komende Alder Lake-processors gepubliceerd. Daarin bevestigt de chipmaker de verschillende core-aantallen voor laptop- en desktopmodellen. De eerste Alder Lake-cpu's verschijnen naar verwachting 4 november.

Intel meldt op zijn website dat er verschillende varianten voor desktop en mobiele toepassingen uitkomen, die beschikbaar komen met verschillende combinaties van cpu-cores en gpu-execution units. Het bedrijf meldt dat Alder Lake-P-cpu's voor laptops maximaal zes krachtige P-cores en acht energiezuinige E-kernen krijgen. Datzelfde bleek eerder al uit een uitgelekte roadmap, maar is nu officieel bevestigd. Ook schrijft Intel dat alle Alder Lake-sku's voor laptops geleverd worden met E-cores. De laptopmodellen krijgen daarnaast geïntegreerde gpu's met maximaal 96 execution units.

De chipmaker schrijft daarnaast dat Alder Lake-S-desktopprocessors maximaal acht P-cores en acht E-cores krijgen. Er zullen ook desktopmodellen zonder E-cores verschijnen. Dat is in lijn met eerdere verwachtingen; recent dook een Intel Core i5-12400 met alleen zes P-cores op. De desktop-sku's met geïntegreerde gpu's krijgen verder 32 execution units, zo schrijft Intel.

Afbeelding via Intel

Core-types en instructiesets

Het bedrijf publiceert verder details over de verschillende cores die worden gebruikt in de Alder Lake-chips. Zoals het bedrijf eerder al bevestigde, krijgt Alder Lake onder P-cores, die de codenaam Golden Cove dragen. Die cores zijn op prestaties gericht en ondersteunen hyperthreading. Tegelijkertijd krijgen de chips E-cores, die het bedrijf Gracemont noemt. Die zijn gericht op efficiëntie en bieden geen hyperthreading.

Beide core-types beschikken over hun eigen pools met L1- en L2-cache, zodat ze grotendeels onafhankelijk van elkaar kunnen werken. De L3-cache wordt wél gedeeld. De cores ondersteunen volgens Intel ook dezelfde instructiesets. De fabrikant stelt daarbij wel dat alleen de P-cores AVX-512 ondersteunen, en dat die instructies alleen kunnen worden uitgevoerd wanneer de E-cores zijn uitgeschakeld in de bios. Ian Cutress van Anandtech stelt op Twitter echter dat dit een fout is, en dat AVX-512 helemaal niet wordt ondersteund op Alder Lake. "De guide wordt geüpdatet. Het is bevestigd dat AVX-512 niet in Alder Lake zit", schrijft hij.

Afbeeldingen via Intel

Softwareoptimalisaties voor Alder Lake

Intel richt zich in de ontwikkelaarshandleiding verder op softwareoptimalisaties voor deze hybride architectuur. De processors maken gebruik van een Intel Thread Director. Die moet het gebruikte OS bewust maken van de verschillende prestaties en efficiëntie van de twee soorten cores. Zo kan de Thread Director verschillende rekentaken verdelen tussen de juiste core-types. Zonder deze director zou een OS denken dat alle cores even snel zijn, en zouden taken onder de verkeerde cores verdeeld kunnen worden.

Het bedrijf deelt daarbij verschillende 'optimalisatiestrategieën' voor ontwikkelaars van applicaties en games. Applicaties die op geen enkele wijze geoptimaliseerd zijn voor Alder Lake, kunnen alsnog gebruikmaken van de twee core-types dankzij de eerdergenoemde Intel Thread Director, die probeert om de workloads automatisch te verdelen over de cores. Dat moet 'in de meeste gevallen' zorgen voor betere prestaties, maar Intel schrijft dat het in bepaalde gevallen kan voorkomen dat sommige taken worden uitgevoerd op het verkeerde core-type.

In een 'goed' scenario, waarin de ontwikkelaar 'minimale stappen' heeft genomen om hybrid awareness te creëren, zouden de primaire taken verdeeld worden onder de P-cores. Niet-essentiële achtergrondtaken zouden gericht moeten worden op de E-cores.

In het 'beste' scenario zouden ontwikkelaars een taaksysteem met twee thread pools maken. Een primaire pool zou gericht zijn op zware rekentaken die bedoeld zijn voor P-cores. De secundaire thread pool moet taken uitvoeren die 'goed bij E-cores passen'. Intel noemt daarbij verschillende voorbeelden, zoals audio mixing, shader compilation, asset streaming, en decompression. Ontwikkelaars zouden ook primaire taken kunnen offloaden naar E-cores wanneer de prestatiekernen overbelast zijn en er capaciteit over is op de efficiënte cores.

Het bedrijf bevestigt verder dat het samenwerkt met middleware-bedrijven om ondersteuning voor het Alder Lake-platform en diens 'hybride architectuur' toe te voegen aan engines als Unreal Engine en Unity. Dat moet in 'toekomstige releases' gebeuren. Het bedrijf werkt ook met bedrijven als Denuvo om ervoor te zorgen dat bepaalde drm-software de Alder Lake-architectuur kan herkennen.

Eerste chips verschijnen dit kwartaal

Intel bevestigt wederom dat het Alder Lake-platform wereldwijd wordt geïntroduceerd in het vierde kwartaal van dit jaar, hoewel de chipmaker zelf nog geen concrete data noemt. Naar verwachting brengt Intel de eerste Alder Lake-modellen op 4 november uit, zo bleek eerder uit uitgelekte informatie van MSI. Het zou daarbij gaan om overklokbare K- en KF-processors voor desktops, waarbij de laatstgenoemde modellen geen geïntegreerde gpu hebben. De eerste laptopchips en lager gepositioneerde desktopmodellen worden later verwacht.

Reacties (51)

[Raymond Deen]

Ik vind het maar ingewikkeld klinken, die verschillende types core aansturen. Terwijl dat op arm al geruime tijd gedaan wordt en dus niet nieuw is.
Het kan dus zo zijn dat sommige applicaties soms voor geen meter performen omdat je ze net op het verkeerde moment start en ze niet geoptimaliseerd zijn om specifiek op een p-core bepaalde taken uit te voeren…

[ari3]

Er al nagedacht over de aansturing van grote en kleine cores, dit bestaat immers al ruim 10 jaar voor ARM processoren.

In principe regelt het besturingssysteem hoe taken verdeeld worden over cores. Het OS moet daarvoor de relatieve prestaties van de cores kennen. In de Linux kernel heet dit Capacity Aware Scheduling, zie https://www.kernel.org/do...duler/sched-capacity.html

[Reactie gewijzigd door ari3 op 26 juli 2024 21:18]

[loekf2]

Bij ARM Big.Little kunnen taken ook automatisch van het performance cluster naar het efficiente cluster gaan, of tussen gepaarde cores uit beide clusters. Ik krijg het idee als ik het artikel lees dat er bij Intel veel meer aan de programma’s wordt overgelaten. Leuk als je dan AMD en Intel goed wilt ondersteunen.

[dasiro]

zo lees ik het idd ook, wat rampzalige gevolgen gaat hebben voor x86-software in zijn geheel en op den duur wel eens tot een splitsing zou kunnen komen als elke fabrikant aan zijn principe vasthoudt en er op een tussenliggend niveau geen oplossing voor wordt geboden (lees OS of CPU), want zoals het er nu uit ziet gaan AMD's en niet alder lake Intel's sucken onder windows 11 en is het voor alle alder lake-derivaten en opvolgers net het omgekeerde onder windows 10.

[Dennism]

want zoals het er nu uit ziet gaan AMD's en niet alder lake Intel's sucken onder windows 11 en is het voor alle alder lake-derivaten en opvolgers net het omgekeerde onder windows 10.

Dat is helemaal niet zoals het er nu uitziet. Niet Alder-Lake Intels presteren gemiddeld genomen bijvoorbeeld onder Windows 11 niet wezenlijk anders dan onder Windows 10. Zie o.a. reviews: Prestaties in Windows 11 - Wat levert de upgrade je op?

Voor AMD cpu's zijn er 2 bekende bugs die in bepaalde workloads de performance negatief kunnen beïnvloeden, een heeft betrekking op de L3 cache latency, de ander op de werking van preferred cores via CPPC2, die voor zover nu bekend, op 19 oktober (L3 cache latency via een Windows Update, is momenteel al gefixed in het Dev channel van Windows 11) en 21 oktober (CPPC2 issue, via een nieuwe AMD chipset driver). Zie ook https://www.amd.com/en/support/kb/faq/pa-400 en nieuws: 'AMD Ryzen-performancepatches voor Windows 11 verschijnen volgende week'

Kijk je echter naar bovenstaande test van Tweakers (maar ook soort gelijke resultaten van andere reviewers) zie je dat gemiddeld genomen de performance verschillen van AMD cpu's onder Windows 10 en 11 ook vrijwel niet aanwezig zijn en over het algemeen binnen de foutmarge vallen, echter zie je ook een paar negatieve uitschieters veroorzaakt door bovengenoemde bugs.

Wat mogelijk wel zo gaat zijn dat Windows 10 niet het uiterste uit Alder-Lake kan halen, echter in hoeverre dat daadwerkelijk zo gaat moet nog blijken, er gaan zowel verhalen rond dat het inderdaad niet best is, terwijl andere bronnen aangegeven dat de verschillen minimaal gaan zijn. Ik denk dat het verstandig is de onafhankelijke benchmarks van de gerenommeerde reviewers af te wachten voor hier over een conclusie te trekken.

[Reactie gewijzigd door Dennism op 26 juli 2024 21:18]

[SG]

Nou de rveiw wordt dan heel interresant hoe doet vorige gen intel het op win11
En wat zal verschil zijn tussen alderlake op win 10 en win11
En wat AMD in de mix doet. En wat doet Linux met ALderlake. tov vorige gen.

[Raymond Deen]

Alleen bij amd maakt het toch niet uit op welke core het draait? Alle cores zijn tenslotte gelijk.
In het artikel wordt de mogelijkheid genoemd dat een taak naar de verkeerde core gaat bij alder lake en dat lijkt me een veel groter risico totdat ontwikkelaars en compilers rekening gaan houden daarmee.

[watercoolertje]

Alleen bij amd maakt het toch niet uit op welke core het draait? Alle cores zijn tenslotte gelijk.

De opbouw van de cores is gelijk maar er zijn wel degelijk betere cores en voorkeurs-cores bij AMD.

https://www.anandtech.com...-cores-vs-preferred-cores

[Reactie gewijzigd door watercoolertje op 26 juli 2024 21:18]

[Raymond Deen]

Interessant! Maar dat is alleen onderscheid maken tussen hoe goed elke core gebakken is en daarop besluiten dat een single threaded app op die core draaien moet. Die cores hebben verder precies dezelfde features en dat is bij die p- en e-cores dus anders.

[SG]

AMD architectuur is in geval van de Chiplets een NUMA ook met de Zen3.
NUMA is gewoon dat elke core de memory local en ook niet lokaal ziet.
In Zen1 Zen 2 had je de 2 CCD per chiplet. En bij huidige dubbele chiplet uitvoering is er dus extra hop naar die andere chiplet. Maar is wel de chiplet 1 CCD geworden. Dat is dus ook vorm van numa alleen niet zo extreem als bij Dual of multi socket systemen.

[MSalters]

Nope, alle Zen SoC's hebben een Uniform Memory Architecture. Geheugentoegang gaat via de gedeelde Infinity Fabric.

Je zóu chiplets kunnen maken waarbij elke chiplet een eigen memory controller heeft, en je CPU package dus één geheugenbus per chiplet. Dat is dan een NUMA ontwerp. Dan heb je wel veel pootjes op je CPU nodig; zelfs ThreadRipper doet dat niet. Die heeft wel 4 controllers, maar die zijn uniform gedeeld tussen 8 chiplets.

[Pep7777]

Er wordt meer aan het OS overgelaten. Er is een (AI) chip die in de gaten houd wat welke thread ongeveer doet (hoe druk die is). En het os kan informatie van die chip dan weer gebruiken om threads aan kernen toe te wijzen. En ja je kan als programmeur (of met configuratie) wel aangeven waar je je programma op hebt willen draaien (thread affinity)

[SG]

Ik vermoed dat WIN API van windows 11 ook andere of extended Thread API zal hebben.
pseudo code
#define __PCORE ;
#define __ECORE ;

DCOM interface zoals Call
creatthreadEX3( ... , ... , .. , PCORE ) ;

Tenzij je dat gewoon met affiniteit moet aangeven.
Maar elk win API per OS wijkt de API op subtiele details af.
Dus verwacht toch dat er DCOM nieuwe interface gekomen is.
Kan mis hebben maar dat verwacht ik.

Dan zal je dus op zijn mist the thread source code moeten aanpassen.

[Pep7777]

Ik zou hier echt niet specifiek DCOM voor gebruiken (of bedoel je de OS API), en zoveel mogelijk gebruik maken van de standaard C++ libraries voor threading abstractie. Ik gebruik bij voorkeur std::async uit <future> voor. En dan waar nodig een strategie injecteren die de OS specifieke variant van SetThreadAffinityMask (of eventueel windows11 opvolger) aanroept.

Naast code is er ook dit:
https://www.windowsdigita...ermanently-in-windows-10/
schijnt ook te werken voor windows 11

[MSalters]

't Is zeker geen DCOM, en dat heeft met de gelaagde architectuur te maken. CreateThread en varianten zijn té fundamenteel - DCOM moet CreateThread kunnen aanroepen, en daarom moet CreateThread in een onderliggende laag zitten. Concreet: het is een kernel32 functie, en die zit onder Ole32.lib.

[Moortn]

Ik denk/hoop dat het wel meevalt en dat het alleen een probleem gaat zijn bij applicaties die alle cores vol benutten maar niet aangeven welke threads de belangrijkste zijn. Het OS of de Thread Director zullen wel voorkomen dat een E-core op 100% belasting zit terwijl al je performance cores niks doen.

[Amanoo]

Ik zit me eigenlijk wel af te vragen of 0% P en 100% E zo'n slechte strategie is, mits dat genoeg processing is. Stel dat je aan al je E cores precies voldoende hebt, betekent dat dan niet dat als taken alsnog naar de P cores gaan, je energieverbruik per instructie omhoog gaat? Dan kan je de P cores beter uit laten.

Maar ik weet het ook niet. Misschien dat de E cores minder zuinig worden onder hoge load, ook omdat dan het voltage omhoog moet, en dat een beetje belasting op de P cores alsnog zuiniger is. Dan kan je dat weer beter doen. Ik heb weinig verstand van energieoptinalisatie in de praktijk. Ik kan alleen wat hypothetische scenario's bedenken.

[Tomatoman]

Nul P-cores en uitsluitend E-cores zou dramatisch uitpakken bij single tread performance, omdat dat nou juist het scenario is waarin je meer hebt aan 1 P-core dan een willekeurig aantal E-cores. Bij een typisch gebruiksscenario speelt single thread performance nog steeds een wezenlijke rol - vandaar dat het heel onlogisch zou zijn om geen P-cores te hebben.

Mocht je überhaupt geen behoefte hebben aan hoge single thread performance, dan heeft Intel een Atom processor voor je in de aanbieding. Die is lekker zuinig en een stuk goedkoper.

[Amanoo]

Ik bedoel meer dat je soms verschillende dingen doet. Soms ben je een beetje aan het browsen en wat aan het typen en videobellen, dan is inderdaad een Atom ook voldoende. Maar misschien wil je een uur later gamen op hetzelfde apparaat. Soms heb je veel processen waarbij voor geen een proces performance heel belangrijk is, maar wil je een andere keer hetzelfde apparaat gebruiken voor iets waarbij de P cores wel belangrijk zijn.

En ik vraag me hier dus af of het niet beter is om de P cores uit te schakelen wanneer je een heleboel simpele taken doet. Het is misschien een wat specifiek geval dat niet altijd zal voorkomen, want je moet wel een berg low power processen hebben.

[t_o_c]

Dat zal aan heel veel factoren liggen. Het zal bijvoorbeeld ook heel erg afhangen van hoe lang het duurt voor een taak is afgerond. De kleine cores zijn zuiniger maar als die kleine cores bijvoorbeeld drie keer zo lang nodig hebben om een taak uit te voeren dan een snellere core, dan kan het best zijn dat het totale energieverbruik lager is als je de snelle ipv de zuinige cores gebruikt.

[Xander2]

Ik zit me eigenlijk wel af te vragen of 0% P en 100% E zo'n slechte strategie is, mits dat genoeg processing is.

Dat is dezelfde strategie als 100% P, zou betekenen dat verhouding P/E zodanig is dat schakelen geen winst levert, ofwel er is geen markt.

[Spockz]

Ik denk ook dat dit iets teveel van de software vraagt. Namelijk om zelf thread Pools te gaan lopen beheren met affinity voor een bepaalde soort processor. Dit is vragen om problemen. In MacOS geef je aan wat voor soort taak het betreft en dan scheduled het OS je op de juiste processor. Ongeacht welke thread pools je hebt gedefinieerd, etc. Dit lijkt mij een stuk handiger.

Na wat verder gelezen te hebben over ITD lijkt het erop dat IDT in de processor draait. De scheduler van Windows 11 is aangepast om het onderscheid te kennen tussen performance en niet performance cores en IDT kan vertellen aan de scheduler welke thread welke karakteristieken heeft waarmee de scheduler dan weer een beslissing maakt op welke processor het process of de thread te schedulen. Dit is nog steeds een heuristiek ipv een declaratie door de developer zoals op macos. Maar misschien werkt het goed genoeg.

[Reactie gewijzigd door Spockz op 26 juli 2024 21:18]

[Raymond Deen]

Ik dacht zelf meer aan compiler optimalisaties. Dan kan het programma dat geoptimaliseerd is door de compiler aangeven wat van type thread er wordt gestart zodat de scheduler daar op kan acteren. Nu kun je met decoraties op classes en namespaces ook al dingen doen; waarom dan ook niet ermee aangeven wat van performance klasse er optimaal is voor een stuk code?

[Spockz]

Dat kan. Maar dan zullen de concepten zoals background of user facing task toch ergens moeten doorkomen. Dus dit moet dan in de OS api ondersteund worden. Daarna kan het in de runtimes ondersteund worden, en daarna in user facing libraries. Zodra je dat gebruikt en erop leunt dan weet je alsnog niet zeker hoe goed je applicatie draait op processoren zonder bigLittle cores.

[Wolfos]

Nee, dat gaat via het besturingssysteem. Zal net zo automatisch gaan als op ARM.

[SG]

Bij arm ligt de consument er niet wakker van omdat daar het geen AMD vs intel CPU concurentie is.
Maar ARM Soc als onderdeel van totaal product zoals smartphone of tablet. Waar OS big little aware is.

Bij windows is men dus afhankelijk van de thread director voor oude hardware wat nog niet gepatched is met P/E core awareness. En dat is lastige want even je Thread pool aanpassen is toch software kern implementatie die invloed heeft op achitectuur en zal de software dan ook grondig getest moeten worden.
Kan dus wel even duren eer men die software Big/little aware geworden is.

Ik vemoed dat er van iNtel wat software onwikkelaars bij MS team close samen gewerkt hebben en uiteraard wordt daar geen rekening gehouden door die leen krachten met het andere merk.

Daarnaast als iNtel ook leen tech naar EPic en Unity sturen kan zijn dat na patch AMD ook weer genaaid wordt.

Al helemaal als ze met iNtel plug in compiler aan komen.

[field33P]

Het kan dus zo zijn dat sommige applicaties soms voor geen meter performen omdat je ze net op het verkeerde moment start en ze niet geoptimaliseerd zijn om specifiek op een p-core bepaalde taken uit te voeren…

Lijkt mij dat de scheduler van Windows erop berekend zal zijn om programma's op de voorgrond die niet weten wat Alder Lake is veel sneller naar de P-cores te sturen.

[Raymond Deen]

Dat doet die thread director waarover wordt geschreven in het artikel, maar die kan dus verkeerd gokken bij niet aangepaste software.

[mr_evil08]

Er zal vast een mogelijkheid zijn om ze uit te schakelen net als bij HT kon.

[MGsubbie]

Zowel het OS (Win11 is zogenaamd geoptimiseerd voor de nieuwe architectuur) als de hardware thread-scheduler op de chip zouden dit op moeten lossen.

[shredder]

Het nut van E-cores begrijp ik nog wel op een laptop, maar op een desktop niet. Kan iemand mij vertellen wat het voordeel van E- cores zijn op de desktop, bijvoorbeeld ten opzichte van een reguliere CPU die terugklokt in snelheid als er geen zware taken zijn?

[Dennism]

Multithread performance, 1 kan 4 E-Cores kwijt op de ruimte die 1 P-Core inneemt op een die. Als voorbeeld:

Kijkende naar de top Alder-Lake Sku had Intel op de die space die ze nu gebruiken voor de 12900K bijvoorbeeld 10 P-Cores plaatsen, of 8 P-Cores en 8 E-Cores. Wat je veel gaat zien, ook in lagere Sku's, denk aan de 12600K bijvoorbeeld. Is dat Intel t.o.v. de AMD concurrentie ineens een stuk meer multithread performance gaat hebben. Kijk er niet vreemd van op dat waar een AMD 5600X nu een 11600K vaak vrij ruim verslaat in Multithread performance dat een 12600K er straks ruim overheen gaat en misschien zelfs wel in de buurt gaat komen van een 5800X. Hetzelfde met de top Sku's, ik zou er niet vreemd van op kijken als straks de 12900K qua multithread performance ergens tussen de 5900X en 5950X zit, terwijl deze 'maar' 8 P-Cores heeft.

Die E-cores zijn er niet alleen om achtergrond taken te doen, maar ook om bij zwaardere multithread workloads meer performance te leveren dan dat 1 P-Core had kunnen doen qua performance per die space.

[Wilfred86]

Wat ik zo jammer vind is dat er voor de desktop geen opties zijn als 4 snelle en 24 efficïente cores. Omdat 4 kleine cores net zoveel ruimte innemen als 1 grote, zou dat qua die-space hetzelfde zijn als de 8+8 die nu het topmodel is.

[Tomatoman]

Ongetwijfeld heeft Intel goed nagedacht over de optimale balans tussen P-cores en E-cores. De reden dat er op dit moment geen combinatie is van 4 P- en 24 E-cores is dat andere combinaties kennelijk meer voor de hand liggen.

[Wilfred86]

Dat hoop je dan. Maar bijvoorbeeld bij een i3 had ik zoiets echt wel verwacht. Ik ben benieuwd naar de benchmarks in elk geval.

[robin15243]

Dan had een i3 evenveel die-space gehad als een core i9, en dan was de prijs ook veel hier geweest. Je moet in het lagere segment concessies doen, zeker bij i3,'s.

[Wilfred86]

Ik bedoel meer iets van 2-4 zware cores en dan nog 8 lichte erbij bijvoorbeeld voor de i3. Ik had echt verwacht dat de zware cores "premium" zouden zijn, ook op de desktop. Maar kennelijk heeft dit alleen zin voor laptops.

[Frame164]

Als daar vraag naar is zullen de andere leveranciers daar wel op inspringen lijkt me.

[cricque]

Allemaal mooi en wel al die cores en efficiency, maar het begint stilaan tijd te worden om benchmarks te zien. En dit niet alleen op Windows 11, maar wil het ook wel eens zien op een linux systeem.
Nuja als programmeur vraag ik mij gewoon af, als je ook gaat kunnen zeggen doe dit maar op die cores. Ik hoop eigenlijk van niet, want dat gaat een ramp worden. Nuja tot zover heb ik dit nog nergens gelezen, dus we zullen wel zien.

[field33P]

Wat mij opvalt in die developer's guide is dat Intel aanraadt om een hele rits aan dingen op de E-cores uit te voeren (AI, physics, pathfinding): precies de dingen waarvoor de SPEs in de Cell van de PS3 gebruikt werden. Het idee van heterogene processoren bleek zijn tijd dan toch ver vooruit. (met dien verstande dat E-cores aanzienlijk makkelijker te programmeren zullen zijn)

[BaBy-G]

Het klinkt allemaal veel belovend, maar ik hoop dat Linux deze nieuwe hybride architectuur goed ondersteunt. Het zal uit eindelijk allemaal wel goed komen, maar voor iemand zoals ik die opzoek is naar een nieuwe laptop en deze wilt gebruiken in combinatie met Linux is het vanuit een stabiliteitsperspectief misschien toch verstandiger om voor een laptop met een 11th gen CPU te gaan.

[lordawesome]

Intel zegt dat zonder een patch een applicatie kritische taken op de E cores kan uitvoeren. Dus als we pech hebben, moeten alle spellen een patch krijgen.

[Frame164]

Is dat zo erg? Software wordt continu gepatcht.

[lordawesome]

Ik verwacht dat oudere spellen niet gepatched zullen worden. Als je op 144hz wilt gamen is dat niet ideaal.

De 6 core zonder E cores lijkt dan het aantrekkelijkst. Of het valt allemaal reuze mee. We zullen het zien in de benchmarks. Als het niet goed werkt, is een big little CPU over een aantal jaar pas leuk.

[svenM]

Je kan nu toch al in Windows aangeven op welke core een applicatie kan draaien? Als Microsoft het zelf niet doet zal er wel iemand iets op vinden om legacy applicaties op de P Cores te draaien.

[Bruin Poeper]

Ik vraag me af of ze wel Windows 12 kunnen draaien.
Als dat niet zeker is wacht ik maar even met kopen.

[napata]

Nee, Intel 7.

[killerdemon]

10nm+ dus? Of nog geen '+' maar alleen nieuwe marketing?

[napata]

Het is inderdaad nieuwe marketing maar dat geldt voor alle nodes momenteel. Intel zat altijd het dichste bij de werkelijkheid maar gaat nu TSMC achterna.