Intel Alder Lake-laptopprocessor met 14 cores en 20 threads verschijnt online

Er is een Intel Alder Lake-P-processor voor laptops verschenen. De cpu dook op in Geekbench en beschikt volgens die benchmark over 14 cores en 20 threads. De processor zal gebruikmaken van een ontwerp met verschillende snelle en energiezuinige cores.

Vermoedelijk heeft deze Alder Lake-P-laptopchip, die werd opgemerkt door VideoCardz en Twitter-gebruiker Benchleaks, zes krachtige cores met hyperthreading en acht energiezuinige kernen zonder hyperthreading. Daarmee komt het totaal uit op de genoemde 14 cores en 20 threads. De cpu haalt volgens de Geekbench-resultaten een turbofrequentie van 4,70GHz. Het is echter niet duidelijk welk type core deze kloksnelheid haalde tijdens de benchmark. Geekbench meldt daarnaast dat de cpu op een gemiddelde kloksnelheid van 4,27GHz draaide. De chip beschikt verder over 24MB L3-cache en een geïntegreerde Xe-gpu met 96 execution units op 1,15GHz.

Intel bevestigde eerder dit jaar al dat Alder Lake gebruikmaakt van een zogeheten big.Little-configuratie. Daarbij worden de cpu's voorzien van twee verschillende architecturen op één chip, met zowel snelle als zuinige cores. Dergelijke configuraties worden al langer gebruikt in soc's voor smartphones en tablets. Intel introduceerde vorig jaar al zijn Lakefield-cpu's voor laptops en tablets, met één 'grote' Sunny Cove-core en vier 'kleine' Tremont-kernen.

Eerder verscheen er al een Alder Lake-S-desktopprocessor in de Geekbench-database, schrijft ook VideoCardz. Die desktopchip heeft volgens Geekbench 16 cores en 24 threads, wat neerkomt op acht 'grote' cores met hyperthreading en acht 'kleine' cores zonder hyperthreading. Intel brengt zijn eerste Alder Lake-processors naar eigen zeggen in de tweede helft van 2021 uit. Het is niet duidelijk of de laptop- en desktopchips in deze serie tegelijkertijd verschijnen. De cpu's worden gemaakt op 10nm en krijgen volgens eerdere geruchten ondersteuning voor DDR5 en mogelijk ook PCIe 5.0, hoewel dit nog niet officieel is bevestigd.

Afbeelding via Geekbench

Reacties (41)

[royalt123]

Ik ben echt wel benieuwd naar deechte realiteit of dat nut heeft of iets oplevert tegenover normale gang van cpu architecture.

Voor mij komt er 2 dingen naar boven.

• Optimalisatie, samenwerking met programma's en O.S.
• Marketing strategie, kijk die laptop heeft 16 cores en andere maar 4

[Wulfklaue]

Zie Apple's M1 ... Veel taken kan je gewoon op de zuinig cores steken. De performance cores gebruiken 10 of 11 Watt, en de energie efficiente cores was minder dan een watt of 2.

Je kan taken sneller afhandelen op performance cores maar de energie dat het nodig heeft is vaak enorm. Stel dat je een lage taak hebt dat lang duurt. De huidige performance cores van AMD/Intel eenmaal dat je ze wakker maakt zuigen al snel 3 Watt gewoon voor de wakeup. Zonder echte gebruik. Zet er een domme 1 a 10% taak op ( wat HEEEEEL wat van je systeem en apps background taken zijn ), dan zie je de cores op 70 of hoger van hun TDP springen. Vaak zelf in de turbo ( hello energie gezuig ) als de taken kleine spikes heeft.

In de praktijk zijn onze PC cores voor de meeste taken gewoon overkill. Office? Browsing? Zie eens naar de activiteiten op je cores. De meeste zaken draaien gewoon enorm zuinig. Er is een reden dat we pc's voor office taken gewoon niet meer upgraden en pas om de 5 jaar soms doen. En dat ARM smartphone/tablets zelf snel genoeg zijn voor heel wat van die taken. Voor een fractie van de energie.

Feit is dat men zich zot gekeken heeft op benchmarks/gaming test/... En dat men dan die tech naar laptop bracht. Maar voor veel werk is het gewoon overkill.

Als je de M1 van Apple tot 20h ziet doen op een 65Wh batterij... Mensen dat hun laptop voor dagen niet opladen. Het is best tijd dat we eindelijk big.little zien in laptops!

[bosbeetle]

Vergelijk je nu ARM core(s) met X86 cores kwa energie verbruik? Denk je dat die twee elkaar gaan naderen door ook hier big.little etc toe te passen?

[Wulfklaue]

Ja en nee... ARM is gewoon meer efficiënt dan X86. Maar het toepassen van big.little op X86 is een no-brain oplossing om de gap tussen ARM/X86 op laptop gebied te verbeteren.

Het probleem is dat laptops te vaak in turbo boost gaan voor zelf kleine activiteiten. Ja, de theorie zegt dat als je een piek hebt van activiteiten, het turbo boosten voor zo snel mogelijk af te werken van de taak spaart energie. Maar heel wat draait op je OS zijn achtergrond taken dat best wat energie zuigen.

En het constant ontwaken van energie onzuinige performance cores voor die taken is energie verspilling. Vergeet niet dat die grote L1/L2/L3 cache enz allemaal bedoelt is voor grote taken te draaien, niet om kleine maar langdurige taken. Daar zet je beter iets in als Atom cores wat een kleine cache hebben en gewoon veel efficiënter draaien voor langdurige lage activiteiten taken.

Dit verminderd de gap in energie efficiency tussen X86 en ARM voor die specifiek taken.

[scsirob]

Zal wel aan mij liggen, maar is dit niet een drama voor programmeurs om te optimaliseren? Hoe ga je zorgen dat een bepaalde thread op een krachtige of een zuinige core loopt?

[dmantione]

Ik denk dat het voor jou als programmeur het beste is om je programma te ontwikkelen voor de snelle kernen. Het gebruik van de langzame kernen is juist iets voor het besturingssysteem: Op het moment dat de processorbelasting laag is, zoals iemand die een reactie loopt te tikken, kan het besturingssysteem besluiten je programma te migreren naar de langzame kernen en zo de batterijduur te rekken, zodat de snelle kernen in diepe slaap gezet kunnen worden. Dit model bestaat al lang bij mobiele ARM-architecturen en leidt op deze manier niet tot ingewikkelde puzzels voor programmeurs.

[scsirob]

Helemaal eens, en ik weet/snap dat dit bij ARM gangbare kost is. Maar dan moet het OS er wel mee om kunnen gaan, het is ingrijpend voor de scheduler. Tenzij ik iets gemist heb (en da's heel goed mogelijk) is Windows op x86 er niet op gebouwd.

[HoD85]

Zoals gelinked in het artikel bestaat Lakefield met 1 Core + 4 Atom combinatie al en werd er toen al gesproken van aangepaste schedule: "Intel heeft met Microsoft samengewerkt zodat Windows 10 goed de taken kan verdelen tussen de krachtige core en de zuinige core. Taken op de voorgrond worden aan de Sunny Cove-core toegewezen en dingen die op de achtergrond draaien worden afgehandeld door de Tremont-cores."

Of dat al helemaal op punt staat weet ik niet.

[hottestbrain]

Windows 10 phone draaide overigens ook gewoon big.little met dezelfde kernel als windows 10.

[dmantione]

Dat klopt dus Microsoft heeft werk. Ik denk dat Intel en Microsoft hier al samen mee aan het werk zijn, maar op zich is het marktaandeel van Intel zo groot dat het zich kan permitteren om Microsoft voor het blok te zetten. Linux ondersteunt het al (Android is immers Linux, dus de telefoonfabrikanten hebben het al geregeld), dus de functie is wel meteen nuttig voor velen.

[Peran]

Benieuwd naar de batterij duur met Linux ten opzichte van Windows!

Edit: .. in combinatie met de aangekondigde Intel Alder Lake CPU's ;-) Daar gaat het artikel tenslotte over en Linux is hier mogelijk juist wel bijzonder goed voor geoptimaliseerd.

[Reactie gewijzigd door Peran op 26 juli 2024 21:51]

[killercow]

Die is meestal prima, en soms zelfs beter (bijna al het datacenter spul draait linux), maar met hele nieuwe trucjes missen er soms drivers, en dan blijft het natuurlijk lastig om te optimaliseren..

[kaaas]

Nou die ervaring deel ik niet.
Meestal is windows energie zuiniger.
De drivers voor windows hebben vaak meer optimalisaties om energie zuinig te zijn.
En dat zeg ik niet als windows fanboy, maar als iemand op zijn dagelijkse laptop linux draait.

[migjes]

ik heb het een keer geprobeerd op mijn router.
windows was daar de midden moot. (eigenlijk de slechte, maar miste de juiste driver die alles goed pakte, een beetje hacken was nodig. best lastig als je router geen video uitgang officieel heeft.)
linux (distro's) waren daar niet veel beter in, wisselend resultaat.
maar een geoptimaliseerde linux(gentoo) voor de router gecompileerd, maakte het toch weer een flinke stap beter, ruim over windows heen.
helaas kun je dan wel het argument geven, dat het geen desktop ervaring meer geeft.
(uit eindelijk zelfs de com poort als videokaart gebruikt en dat maakte ook veel uit.)

[kaaas]

Het was ook een reactie specifiek op laptops.
Problemen op laptops die ik heb zijn dat je bijv het switchen tussen integrated en dedicated gpu niet even soepel gaat als in windows wat onnodig energie gebruik met zich mee brengt.
Ik weet dat intel optimalisaties heeft voor ssd's en gpus die er voor zorgen dat die in een veel lagere powermode gaan in standby in windows.
Zelfde voor meerdere draadloze chips.
Zo zijn er heel veel kleine dingen die bij elkaar wel verschil maken.

Het is ook niet iets waar linux heel veel aan kan doen. Als de fabrikanten niet evenveel tijd steken in linux en windows drivers heb je gewoon pech en is het hopen dat de community het voor je doet.

Maar laat dat niemand stoppen om linux op je laptop te zetten, want het is echt veeeel beter geworden door de jaren heen en het verschil is afhankelijk van je hardware echt niet heel groot meer.

Bij servers/routers is het een ander verhaal en inderdaad de optie om je os te tunen bied je een hoop mogelijkheden om het beter te doen dan windows.

[BugBoy]

Migreren klinkt als heel ingewikkeld en zwaar. Volgens mij kan die bij elke thread-switch de juiste core alloceren. Wellicht dat de high-speed cores ook over een uitgebreidere instructieset beschikken (bijv. AVX), maar dan kan het OS ook beslissen om vanaf dat moment de thread uitsluitend op passende cores te laten draaien. Het voordeel is dat dit in een gecentraliseerd stuk van de kernel zit, dus ik verwacht dat dit redelijk "eenvoudig" kan gebeuren.

[dmantione]

Het klopt dat het migreren van een proces naar een andere kern een prijs heeft. In beginsel kan het besturingssysteem gewoon de betreffende context van het proces in de registers van de kern laden en de processor doet de rest. Maar... de kern waar het proces eerst draaide heeft allerlei data van dat proces in de cache zitten, terwijl de nieuwe kern geen relevante gegevens van dat proces in de cache heeft. Je krijgt dus een hoop verkeer tussen de caches en waarschijnlijk ook het hoofdgeheugen voordat de situatie zich weer stabiliseert.

Om die reden zijn schedulers nu al terughoudend met het verplaatsen van processen tussen kernen en als het besturingssysteem besluit om een proces op een andere kern te zetten, dan liever een kern dichtbij op dezelfde die of anders socket, dan 'm naar een kern ver weg verplaatsen.

Die logica bestaat dus al, maar moet wellicht nog wat verfijnd worden voor dit soort big-little-processoren.

[MSalters]

"Gelukkig" is door Spectre en dergelijke bugs al duidelijk geworden dat je bij elke context switch de L1 cache moet refreshen, om data leaks te voorkomen. Dan is dit geen extra overhead meer.

Overigens zal je niet naar het hoofdgeheugen toemoeten, omdat de L3 cache groter is dan alle L1 caches samen.

[sleiN13]

Hopelijk lost het os dat op. Het principe is niet nieuw meeste telefoons doen het al op die manier

[scsirob]

Klopt, alleen is Windows niet echt ontworpen op a-symmetrische processor units.

[Rataplan_]

Dat was Android (Linux) ook ooit niet. Kan toch met een update aan de scheduler (?) toegevoegd worden?

[AmigaWolf]

Vind het wel heel appart van Tweakers dat er in die hele nieuws bericht including de screenshot die ze gebruiken NIKS gezegd woord over de score die deze CPU krijgt in Geekbench 5 in OpenCL, en dat is een score van 13438,

_{Ja je kan drukken op de hele kleine link onder aan de screenshot.}

[Reactie gewijzigd door AmigaWolf op 26 juli 2024 21:51]

[Shaidar]

Ehhmm, een score can 5 cijfertjes? Mijn 2080Ti heeft een score van 6 cijfertjes, dus dat is toch helemaal niet spannend?

[J Kortje]

2080Ti is een GPU. Deze Geekbench score van 13438 is voor een CPU.

[Shaidar]

Klopt, dus ik snap niet wat er dan zo noemenswaardig is aan die OpenCL score?

[J Kortje]

Omdat een CPU en een GPU niet bedoeld zijn om elkaars taken over te nemen.
Een CPU is goed in CPU taken en een GPU goed in GPU taken. Echter is een CPU niet goed in GPU taken en een GPU niet goed in CPU taken.

[Fireshade]

Klopt, alleen is Windows niet echt ontworpen op a-symmetrische processor units.

En Windows 10 Mobile?
Die heeft dezelfde kernel als de desktop versie, dacht ik.

[John Doos]

Zal wel heel kort door de bocht zijn voor mij, maar er zal wel een controller op de CPU zitten en de data die je erheen stuurt gaat "linksom" naar de snelle cores of juist "rechtsom" naar de zuinige cores.

Het lukt programmeurs op mobiele platforms anders ook prima

[Danfoss]

Maar gebruik op een mobiel os is heel anders dan op een desktop os. Op mijn mobiel is er meestal 1 foreground app, vaak 1 of 2 'prio' achtergrond apps met interactie (spotify, teams etc) en de rest doet in low power de dingen op de achtergrond.

Op de desktop heb veel meer applicaties naast elkaar open en switch ik ook veel sneller heen en weer tussen andere. Ik ben dan ook heel nieuwsgierig hoe het os dan door heeft wat op op de langzame cores mag.

[BugBoy]

Dat switchen tussen cores kan natuurlijk zeer snel gebeuren. Thread-switching gebeurt nu ook al continu en bij elke switch kan je naar een andere core uitwijken. In veel operating systemen kan je ook al de prioriteit per thread instellen en daar zal de scheduler ook rekening mee houden.

Verder is er heuristisch natuurlijk ook veel te doen. Het OS kan "leren" van processen en rekenintensieve taken naar een snelle core verschuiven. Het zal ook steeds verder geoptimaliseerd kunnen worden.

[MSalters]

Threads zijn een OS ding, geen CPU ding. Dat kun je dus ook niet met een controller op de CPU oplossen.

Om maar een concreet voorbeeld te noemen waar dat fout gaat; SQL server onder Windows gebruikt fibers in plaats van threads. Windows snapt het verschil tussen een fiber en een thread, de CPU niet. Dat hoeft ook niet; de CPU moet gewoon de instructies van de fiber uitvoeren, op de core die Windows aanwijst.

[koekjebakker]

ARM chipjes in smartphones volgen hetzelfde 'big little' principe dus het valt wel mee denk ik.

[Anoniem: 390704]

Zie de mogelijkheden genoemd op https://en.wikipedia.org/...ITTLE#Run-state_migration

[GewoonWatSpulle]

Nee dat is geen drama, sterker nog de meeste programmeurs zijn zich volkomen onbewust van de core waar het eventueel op draait. Als je gewoon de standaarden volgt van jouw platform dan zorgt jouw platform* er onderwater voor dat het op de juiste core(s) verdeeld word. Pas met exotische software die performance kritisch is gaan programmeurs daadwerkelijk met het platform de strijd aan om de best mogelijke performance te behalen, ik denk dat de meeste programmeurs uit hun hoofd niet weten waar ze dan zouden moeten beginnen voor hun specifieke platform.
* Platform is hier jouw programmeer taal en bijbehorende SDK en/of tooling

[DennisH82]

Veel mensen zullen denken, huh gebruiken ze nu processors met defecte hyperthreading cores ??

[Van der Berg]

Eindelijk dat Intel over de 10-cores gaat, mede door de concurrentie AMD

[dmantione]

Nou nee, afgezien dat ze in de marketing kunnen zeggen dat ze veel kernen hebben is het appels en peren. Wat niet gezegd is dat Intels peren niet gewenst zijn, want dit levert hele interessante zuinige processoren op. In praktijk zal het echter vooral als een 6-kerner presteren, omdat de 8 kleine kernen dienen voor een laag verbruik, normaliter niet gebruikt worden en überhaupt weinig rekenkracht bieden. Je kunt hier dus laptops mee maken die weliswaar een flink piekverbruik kunnen hebben, maar in praktijk juist heel erg zuinig zijn. AMD's appels dienen allemaal voor de rekenkracht, alle 16 stuks van een Vermeer rekenen mee en helpen de processor benchmarks te winnen.

[Cobalt]

Wordt dit de 11th gen i9?

[mr_evil08]

Mijn oude hasswell quadcore CPU gebruikt nu pas alle 8 threads(met HT aan), daarom ben ik nogal terughoudend met CPU,s met veel threads/cores want hoe lang duurt het wel niet voordat programmeurs het daadwerkelijk voor elkaar krijgen om ze allemaal tegelijkertijd aan te spreken.

(Voordat er weer iemand begint, nee je achtergrondprocessen gebruiken maar weinig tijdens gamen en kan prima op 1 thread draaien de rest staat er dan nutteloos bij als een game de andere threads niet kan aanspreken).

Ik heb daarom liever minder cores op de CPU welke fors sneller zijn per core dan meer/langzamer Cores en de rest er nutteloos bij staat op idle.

[Reactie gewijzigd door mr_evil08 op 26 juli 2024 21:51]

[Anoniem: 57411]

Bij dit ontwerp is, als ik het goed begrepen heb, het idee juist dat niet alle 14 kernen tegelijk gebruikt worden, maar ingezet worden afhankelijk van het gewenste energie gebruik:

Vermoedelijk heeft deze Alder Lake-P-laptopchip, die werd opgemerkt door VideoCardz en Twitter-gebruiker Benchleaks, zes krachtige cores met hyperthreading en acht energiezuinige kernen zonder hyperthreading.

Of het idee bij deze processoren werkt (en beter werkt dan de gangbare energie-besparingstechnieken) of niet is natuurlijk een andere vraag, maar bij de ARM architectuur is al gebleken een dergelijk ontwerp wel degelijk nuttig kan zijn.

[Reactie gewijzigd door Anoniem: 57411 op 26 juli 2024 21:51]

[Jan Onderwater]

intel wordt steeds beter in het aankondigen. Nu nog leveren.
Ik ben benieuwd hoeveel stroom deze Processor gaat trekken, en wanneer deze op de markt komt. Denk dat hij het tegenover de M1x het gaat afleggen wat performance/verbruik betreft..