Gerucht: Intel Raptor Lake-chips krijgen 8 Raptor Cove- en 16 Gracemont-cores

Intel brengt volgens geruchten eind 2022 een processorgeneratie met de naam Raptor Lake uit, die uit tot aan acht krachtige en zestien zuinige cores bestaat. Raptor Lake zou de opvolger van Alder Lake zijn, die Intel dit jaar zou onthullen.

De krachtige cores van Raptor Lake zouden de codenaam Raptor Cove dragen en hierbij zou het om geoptimaliseerde Golden Cove-cores van Alder Lake gaan. Het gaat in beide gevallen om processors met een heterogeneous computing-ontwerp dat lijkt op ARM's big.Little-ontwerp. Dat beweert Moores Law is Dead, een YouTube-kanaal dat eerder correct Intel-informatie naar buiten bracht. De verbeteringen zouden de instructions per clock, kloksnelheid en efficiëntie betreffen. De zuinige cores betreffen Gracemont-cores, waarvan Intel er tot aan acht bij Alder Lake gaat gebruiken, maar bij Raptor Lake zou het om zestien Gracemont-cores gaan. Raptor Lake zou de LGA1700-socket ondersteunen, net als Alder Lake.

Over Alder Lake meldt Moores Law is Dead ook nieuwe details. Intel zou de K-serie van de Alder Lake S-processorgeneratie voor de desktop in oktober van dit jaar willen onthullen, waarbij het om processors met een tdp van 125W zou gaan. Een Core i9-K zou dan uit acht Golden Cove- en acht Gracemont-cores bestaan, terwijl de Core i7 acht krachtige en vier zuinige en een Core i5 zes Golden Cove- en vier Gracemont-cores zouden bieden. De chips ondersteunen PCIe 5.0 en socket LGA1700 en hebben een UHD-gpu van de Xe-generatie met 32 execution units.

Begin 2022 zou Intel vervolgens de minder krachtige A-serie van Alder Lake voor de desktop en de zuinige P- en M-series voor laptops aankondigen. Ook zou het bedrijf een HX-serie op de planning hebben voor krachtige laptops zoals gamelaptops. Deze moeten in het tweede kwartaal van 2022 verschijnen en dan tot aan acht Golden Cove- en acht Gracemont-cores, en tdp's van 45W tot 65W hebben.

Intel Alder Lake en Raptor Lake, bron: Moore's Law is Dead

Reacties (48)

Verkeerde knop, was reactie op parsa2020 in 'nieuws: Gerucht: Intel Raptor Lake-chips krijgen 8 Raptor Cove-...

Voor mobiele apparaten is het big little concept wel logisch, maar voor een desktop CPU lijkt het me niet zo heel veel toevoegen toch? De stroom die je er mee bespaart zal minimaal zijn als je het bekijkt op de hele pc, en je zit aan de netstroom dus het is ook niet noodzakelijk om battterijduur te verlengen.

Ook ik vraag dat me heel erg af, voor laptops, oké. Voor desktops? Ik heb één potentiele verklaring die het logisch maakt, maar of het juist is durf ik niet te zeggen.

Maar je hebt altijd diminishing returns. Oftewel een big core die 2x zo groot is en 2x zoveel verbruikt als een little core, zal waarschijnlijk niet 2x zo snel zijn, maar bijvoorbeeld maar 50% sneller. Of potentieel afhankelijk van de workload. Gezien ik meer bekend met embedded ARM cores: Een M4F ARM core rent rondjes rond een M0 core als we floating point berekeningen moeten doen. Het verschil is gigantisch. Maar willen we integer optellingen doen, dan is die M0 core net zo snel, voor een fractie van de area en power.

Dus ik kan me voorstellen dat als je 8 big cores hebt en 16 little cores, dat die 16 little cores bij elkaar voor multi threaded berekeningen, danwel simpelere berekeningen, sneller zijn dan de 8 big cores, terwijl ze wel zuiniger en kleiner zijn.

(Let wel, dit is allemaal speculatie vanuit mijn kant).

[Reactie gewijzigd door Sissors op 10 juni 2021 09:14]

Je kan Pollack's rule toepassen: https://en.wikipedia.org/wiki/Pollack%27s_rule

Die zegt dat de snelheid van een microarchitectuur ongeveer proportioneel is aan de wortel van de complexiteit. Als we complexiteit in aantal transistors uitdrukken, kan je zien waarom het niet altijd aantrekkelijk is om steeds grotere cores te bouwen. In plaats van 2x zoveel transistors aan 1 core te besteden (die circa 41% sneller is), zou je ook 2 cores kunnen hebben (100% sneller)

Echter heb je ook Amdahl's law: https://en.wikipedia.org/wiki/Amdahl%27s_law

Die law zegt dat als een process voor bijvoorbeeld 10% single-threaded code bevat (dus 90% dat multi-threaded of parallel kan), je deze met oneindig veel threads niet meer dan 10x kan versnellen tov 1T. Om dus echt goed profijt te hebben van heel veel kleine cores, heb je dus goede software implementaties nodig.

Het is dus heel erg een trade-off van wat de markt nodig heeft. Intel heeft met Xeon Phi al laten zien een heleboel kleine cores op 1 CPU te kunnen stampen. Nu lijken ze m.i. Phi en desktop te combineren met big little. Er is wel wat voor te zeggen zoals Intel voorstelt, om veel simpele cores toe te voegen voor number-crunching applicaties, en een paar super snelle cores te houden voor applicaties die gebonden zijn aan single-core prestaties (die vaak ook maar 1-4 cores gebruiken).

Echter de cynische ondertoon (en speculatie) in mij zegt ook, dat ze dit wel moeten omdat ze hun process voordeel kwijt zijn. Ze moeten nu op zoek naar ruimte in hun architectuur om energy/power efficiency terug te winnen. We zien dat AMD daar al een factor 2x beter in presteert, dus m.i. is de prestatiewinst van 2x van de eerste slide heel mooi voor Intel... en mooi voor de markt (concurrentie), maar het zou ze waarschijnlijk op vergelijkbare hoogte brengen als een 16-core AMD 5950X CPU (die geen scheduler rompslomp nodig heeft).
De impact op mobile of entry kan een stukje groter zijn - een 2+8 core CPU als een entry level device zou fantastisch veel rekenkracht toevoegen voor iets wat voorheen misschien maar 4 cores (met/zonder HT) kreeg.

[Reactie gewijzigd door Hans1990 op 10 juni 2021 11:22]

Op de Universiteit Twente hebben ze me een paar jaar geleden de vuistregel geleerd dat increment in transistors van factor x, ongeveer een factor wortel(x) aan performance oplevert. Hoe meer transistoren je tot je beschikking hebt, hoe moeilijker je ze nuttiger kan inzetten. Dat is een grote reden om naar multicore ontwerpen te gaan. Dan heb je met twee keer zoveel transistor budget (theoretisch) twee keer zoveel performance (1 core vs 2 cores) ipv 1.4 keer zoveel perfromance (1 core vs 1 complexerre core met twee keer zoveel transistors). Praktisch gaat dit natuurlijk niet atlijd op, maar het geeft wel een leuk idee dat twee keer zoveel transistors en daarmee twee keer zoveel stroomverbruik zeker niet altijd twee keer zoveel performance oplevert.

big little, ok makes sense. Het is al bewezen in mobiele omgevingen dat dit de nodige winsten geeft kwa batterij. Wat ze hier mee willen bereiken in desktop is me echter helemaal niet duidelijk. Al zeker niet in deze update waar er meer cores little zijn dan big... wanneer ga je multithreaden? als je hoge performantie nodig hebt. Daily business (of noem het MS OS thread troep) kan je gerust op een kleiner aantal kleine cores doen...

Dan komt er ook nog bij de definitie van zuinig... light threaded verbruiken desktops niet veel... tenzij je single thread uber ghz moet pompen in een ++++++ design en oud core design om toch nog maar mee te kunnen met de competitie. Dat dit dus mogelijks werkt op een laptop? zeker. Maar om er nu zo een hype van te maken? AMD kan hier gewoon 2 verschillende ccx cluster tegen plaatsen en nieuwe IO logica en ze hebben hetzelfde resultaat.

Waarom voelt dit wederom als een weg die Intel ingeslagen is een tijd geleden waar ze nu niet op terug kunnen komen... dit biglittle concept is enkel voor midrange doelpubliek en wat heb je dan aan 8+8mini of 8+16mini... dat zijn 16 -24CPU dat is niet midrange en ze worden omver geblazen door 16 high performance cores... als er niks anders is dan alderlake dan is het nog 2 extra jaren compititie op prijs en niet op performance tenzij ze nog een ander core design gaan positioneren in lijn met hun Xeon platform.

en wees maar zeker dat het een paper launch zal zijn hun 10nm opschaling loopt nog altijd niet vlot als je kijkt naar de hoeveelheden dat ze nu nog maar leveren van Xeon 10nm tov 14nm Xeon (komt uit hun eigen presentaties)

[Reactie gewijzigd door d3x op 10 juni 2021 09:01]

Desktop PCs gebruiken steeds meer achtergrond processen. Steeds meer applicaties die TSR draaien. Je EMail client, IM client, chat systemen, update-check processen, drivers die altijd actief zijn (geluid, beeld).... Allemaal zaken die eenvoudig op zuinige, 'trage', cores draaien.
Geef ieder van die threads een eigen zuinige core en het zal zowel sneller als zuiniger uitgevoerd worden.

En nee, de meesten van ons zullen nogsteeds geen 16 zuinige cores nodig hebben. Maar de 4-8 van de i5 en i7 die hier beschreven worden zullen zeker een positief effect hebben. Zowel op stroomverbruik als op de performance van de snelle cores die plots geen timeslicing meer hoeven te doen op de langzame threads waardoor cache-misses een stuk minder waarschijnlijk worden.

Ja, een 8/8 bL zal qua performance omver geblazen worden door een 16 zware cores maar dat is een zinloze vergelijking; die laatste gaat zonder enige twijfel veel meer stroom verbruiken, ook per instructie.

Zoals in de slides staat lijkt Windows in de herfst ook een update met betrekking tot scheduling te krijgen en dus wellicht achtergrondtaken efficiënter weg kan zetten bij de zuinige cores zodat de grotere cores zich op het zwaardere rekenwerk kunnen focussen.

Ik snap dat dit op papier efficiënter is, maar moet dit nu ook al te merken zijn? Of geeft dit windows potentie om te groeien.

Bij gelijke procedés, maar we weten dat dat niet zo is: Raptor Lake zal op 10nm worden gebakken, terwijl Zen4 op 5nm zal word gebakken. Nu verwacht ik dat AMD Zen4 flink zwaarder zal maken en Zen4 om die reden geen zuinige processor wordt, wat de aankondigingen in ieder geval wel duidelijk maken is dat Intel meer richting de mobiele en zuinige hoek kijkt dan AMD.

Bij gelijke procedés, maar we weten dat dat niet zo is: Raptor Lake zal op 10nm worden gebakken, terwijl Zen4 op 5nm zal word gebakken.

En we weten ook dat procedé helemaal niets (meer) zegt. De gates van Intel's 14+++ waren vergelijkbaar met AMD's 7nm. Daarmee is het concept "Stroomverbruik verlaging door het verkleinen van de gates" erg relatief geworden.

Ook de conclusie dat Intel meer naar zuinig kijkt dan AMD is er eentje die ik niet trek uit het huidige nieuws. De hele manier waarop AMD zijn processor in elkaar steekt zorgt er voor dat als ze morgen een bigLittle CPU uit willen brengen, ze dat eenvoudig kunnen doen door een paar van de chiplets van andere cores te voorzien.

Al met al blijft het complexe materie waarbij ik het volste vertrouwen heb dat de knappe koppen bij AMD en Intel het beter weten dan ik ;-)

Procedénamen zijn tegenwoordig nietszeggend, maar niet overdrijven: Intel loopt met zijn 14nm intussen behoorlijk achter, dat is (naast ook chiplets) de reden dat AMD nu 16 kernen kan leveren op de desktop en Intel maar 8. In transistordichtheid is Intel 10nm vergelijkbaar met TSMC 7nm, maar ja, dat proces van TSMC presteert wel stukken beter dan dat van Intel, dus ook dat is slecht vergelijkbaar.

De reden om te concluderen dat Intel zich vooral op zuinig richt, is dat ze de grens voor krachtige kernen op 8 lijken te leggen voor de toekomst en de hoeveelheid kleine kernen wel verhogen. Als je met een Raphaël van 16 of 24 kernen wilt kunnen concurreren ga je dikke kernen toch nodig hebben.

Daarbij zeg ik niet dat AMD niets op mobiel gebied kan, maar AMD is juist wel geïnteresseerd in de powerdesktops, waarbij ze itt. Intel ook nog HEDT doen.

er is ook nog verschil in densiteit tussen core logic en cache logic... blijkbaar door weinig tech opgenomen en idd de meeste lopen graag mee met de marketing hype. Er is een reden waarom Intel niet langer de densiteit meegeeft na zijn laatste 10nm updates om dit degelijk productief te kunnen doen werken...

[Reactie gewijzigd door d3x op 10 juni 2021 11:39]

Toch heeft @Croga een punt met ongeveer gelijke gate afmetingen tussen Intels 14nm en TSMC's 7nm, jij ook met betrekking op de transistordichtheid.

Transistors bekeken met een elektronenmicroscoop: Intel's 14nm vs. TSMC's 7nm -update
https://nl.hardware.info/...14nm-vs-tsmcs-7nm--update

Het verkregen beeldmateriaal is uitvoerig geanalyseerd met een opvallende uitkomst. Hoewel TSMC's 7nm-proces een veel grotere transistordichtheid mogelijk maakt (90 MT/mm2 tegenover 37,5 MT/mm2), zijn bij beide processors de transistor-gates ongeveer even breed. De gates zijn 24- en 22nm breed, breder dan de 14- en 7nm naamgeving doet vermoeden.

De hele manier waarop AMD zijn processor in elkaar steekt zorgt er voor dat als ze morgen een bigLittle CPU uit willen brengen, ze dat eenvoudig kunnen doen door een paar van de chiplets van andere cores te voorzien.

AMD lijkt met Zen 5 ook met een big.little concept te komen met inderdaad Zen 4 cores als de little cores.

"AMD Strix Point krijgt hybride ontwerp met 3nm Zen 4- en 5-cores"
https://nl.hardware.info/...met-3nm-zen-4--en-5-cores

Volgens eerdere informatie maakt Strix Point gebruik van big.Little, waarbij Zen 5 de 8 krachtige kernen levert en Zen 4 de 4 zuinigere. Waar Zen 4 nog op 5nm geproduceerd zal worden, moeten de kleine Zen 4D-cores op 3 nanometer gebakken worden.

[Reactie gewijzigd door Rudie_V op 10 juni 2021 12:13]

big.little voor desktop lijkt mij een noodgreep om TPD onder controle te houden en toch meer cores kunnen leveren, zodat het voor een leek lijkt dat de Intel processoren meer cores hebben dan de AMD tegenhangers.... Maar zit nu te denken, terwijl ik dit typ, dat je dan wel langer je snellere cores hoger kunt klokken, en dat zou zomaar voor een hoop applicaties kunnen werken, applicates die all met 4-8 snelle cores goed overweg kunnen, zoals games.

Ik denk niet dat het een noodgreep is. Om eens een voorbeeld te geven;

Ieder systeem heeft achtergrond processen.
Stel dat je een spel speelt wat al je grote cores kan gebruiken.
Op 1 core draait dan niet alleen het spel maar ook een achtergrond proces. Hij voert een instructie van het spel uit, de resultaten gaan naar cache. Vervolgens voert hij een instructie van een achtergrond proces uit die ook wat naar de cache schrijft en de resultaten van het spel er uit gooit. Vervolgens weer een instructie van het spel maar plots moet die de eerdere resultaten uit een langzamere cache halen met als gevolg dat het spel langzamer draait dan wanneer het achtergrondproces op een little core (met eigen L1 cache) gedraait zou hebben.
Dan hebben we het nog niet over de clock cycles die je verliest aan de cache move van L1 naar L2.

Dit heeft, in mijn ogen, weinig met noodgreep te maken en alles met het feit dat PCs nou eenmaal best veel dingen doen die helemaal niet zo'n grote, onzuinige, core nodig hebben.

In een review werd laatst al duidelijk dat de meeste spellen aan 4-6 cores genoeg hebben. Wat heb je dan liever; een CPU met 6 van die grote cores en nog een paar kleintjes om de achtergrond taken uit te voeren, of een CPU met 16 grote cores? Ik denk persoonlijk dat die eerste goedkoper, zuiniger en niet minder snel is.

Vrag is alleen of het zo werkt,

Big little is vaak alles big of alles little, niet workload verdelen,


Zelfs al kan je de workload verdelen dan nog kun je beter een Big core hebben die down throtthled naar 800Mhz en dan 8 of 12 Bigs , dan 8 + 16 small.

Enige waar je echt voordeel kunt halen is met dingenb die graag veel threads hebben en weinig power per thread , maar daan hebben we een GPU voor , Of wil intel zijn cpu aan miners gaan slijten

Big little is vaak alles big of alles little, niet workload verdelen,

Waarom denk je dat? Dat is in ieder geval niet hoe het op telefoons werkt en dus ook niet hoe Windows daar mee om gaat.

Zelfs al kan je de workload verdelen dan nog kun je beter een Big core hebben die down throtthled naar 800Mhz en dan 8 of 12 Bigs , dan 8 + 16 small.

Again; waarom denk je dat? Ik denk dat een gedownclockte Big core nogsteeds meer energie zal verbruiken dan een Little core. Anders heeft het hele bigLittle concept geen enkele waarde. De performance per watt van Little is juist het grote voordeel.

Enige waar je echt voordeel kunt halen is met dingenb die graag veel threads hebben en weinig power per thread , maar daan hebben we een GPU voor , Of wil intel zijn cpu aan miners gaan slijten

Dingen zoals Windows bedoel je? Die bij mij op dit moment rustig een stuk of 30 threads heeft lopen die grotendeels onder de 1% CPU zitten. Dingen die perfect op Little cores zouden kunnen draaien en dan een stuk minder stroom zouden verbruiken dan ze nu doen....

Als 16 smalls minder power verbruiken dan 4 bigs hebben ze een 75% power improvement over de bigs,

Je kan me veel vertellen maar dat gaan ze niet halen. probleem is niet een little minder verbruikt dat snappen we allemaal maar 16 Littles ?

Verbruik zit echter niet in cores. Verbruik zit in het verzetten van werk. Dus ja, het kan best zijn dat 16 littles minder verbruiken dan 4 bigs voor hetzelfde werk. Dat heeft niets te maken met 75% power improvement. Als de performance per watt van een little core beter is dan die van een big core dan kunnen 16 little cores voor minder verbruik hetzelfde werk doen als 4 big cores.

dus pak hem beet een throttled down big core verbruikt 25 watt x 4 = 100 watt

100/16 = 6.5 watt wat een enkele little dan mag verbruiken , Hoezo is dat geen 75%

Je bent nu alleen aan het kijken en rekenen met tijd. Dat is weinig zinvol in CPU land. In CPU land praten we niet over verbruik over tijd maar over performance per watt.

Stel dat een little core 10 watt verbruikt maar 16 little cores in staat zijn om de opdracht in de helft van de tijd van vier BIG cores te voltooien. Dan mag de BIG core slechts 20 watt verbruiken om voor dezelfde opdracht even veel energie te verbruiken.

De performance per watt is het enige wat telt, zolang de CPU in staat is om fatsoenlijk power management te doen. Dat heeft dus niet persé iets te maken met puur wattage.

Let overigens op dat de cijfers die je noemt nog best hoog zijn. Ik verwacht dat een Little core eerder rond de 2.5 Watt uit zal gaan komen, als het niet minder is. En dat BIG cores zo rond de 10-20 Watt zullen zitten; kijk maar eens naar de huidige packages van Intel en AMD.

Big little is vaak alles big of alles little, niet workload verdelen

Hoe het bij Windows werkt weet ik niet, misschien is daar nog wat aan de weg te timmeren. Maar bij MacOS op M1 CPU's geven processen bij het aanmaken van threads een QoS level aan waarmee het OS kan besluiten om taken op de efficiency cores of op de performance cores te schedulen. Als er achtergrond processen lopen die niet performance kritiek zijn (en dat zijn er bij een desktop systeem al gauw 10-tallen tot 100-en), dan worden die op M1 CPU's letterlijk nooit op de performance cores gescheduled [1].

Het voordeel hiervan is precies wat hierboven al geschreven staat. Een 'slow-burning' achtergrond taak vervuilt niet de L1 cache van de performance cores, vreet geen TDP weg omdat de CPU ze sneller dan strikt noodzakelijk verwerkt, latency van processen op de high-performance cores is lager omdat het OS minder hoeft te context switchen, etc. Dus wel degelijk zinvol op een desktop, het is 1 van de redenen waarom de M1 Macs zo snappy aanvoelen.

[1] https://www.extremetech.c...-apple-m1s-responsiveness

Gaat helemaal aan de prijs liggen. Als je voor het geld van een 8+16 een 12-core kan krijgen die net zo goed gamed en veel sterker is in Multi-core dan is de keuze simpel genoeg.

Voor laptops is het een ander verhaal. Maar op Desktop ligt het puur aan de prijs en wat je voor het zelfde geld kan krijgen in volwaardige cores.

Neem aan dat dit sarcastisch bedoeld is?

Wel, laten we zeggen dat ik er vroeger veel meer likes mee zou mee scoren

Komt er natuurlijk van als je cores veel krachtiger maakt dan het merendeel van de taken die ze moeten uitvoeren. Als je enkel 8 ferrari's in de garage hebt staan, dan heb je voor het ritje naar de supermarkt geen andere keuze.

Het is dus geen noodgreep, maar een bewustwording dat "1 core to rule them all" niet meer houdbaar is, zelfs met het terugclocken naar lagere snelheden zijn de nadelen ervan blijkbaar groter dan de voordelen.

big little, ok makes sense. Het is al bewezen in mobiele omgevingen dat dit de nodige winsten geeft kwa batterij. Wat ze hier mee willen bereiken in desktop is me echter helemaal niet duidelijk. Al zeker niet in deze update waar er meer cores little zijn dan big... wanneer ga je multithreaden? als je hoge performantie nodig hebt. Daily business (of noem het MS OS thread troep) kan je gerust op een kleiner aantal kleine cores doen...

Het geeft je mogelijk ook meer rekenkracht per vierkante mm chip. En aangezien moderne chips zo lastig te koelen zijn geeft betere efficiëntie misschien ook betere prestaties.

Welke threads op de snelle cores mogen is al een systeem voor, bij ryzen kan de ene module hoger klokken dan de ander en dan krijgen threads met haast voorrang op die net wat snellere cores oid

Volgens mij wil AMD ook iets met big.little gaan doen. Kan even de bron niet vinden.
In potentie lijkt big.little me zeer interessant, als de Win eendows scheduler er goed mee kan omgaan. En dat heeft Intel (itt AMD) vaak goed op orde.

[Reactie gewijzigd door eL_Jay op 10 juni 2021 10:22]

Ik vind het wel interessant dat Intel gewoon AMD helemaal niet wil erkennen als competitie. Daardoor ben ik meteen heel erg benieuwd of dat intern ook zo is. Dat je naar buiten toe presenteert 'alles is prima', ookal kan iedereen zien dat dat niet helemaal waar is, snap ik wel. Maar als je ook intern gewoon AMD niet als serieuze concurrent ziet, dan snap ik wel waarom Intel zo achter is komen te lopen in deze sector (relatief natuurlijk, ze zijn gewoon nog steeds de grootste al is het alleen maar door naamsbekendheid).

Ben ook wel benieuwd naar de toepassingen die ze hier voor zien. Voor mobiele apparaten is het big little concept wel logisch, maar voor een desktop CPU lijkt het me niet zo heel veel toevoegen toch? De stroom die je er mee bespaart zal minimaal zijn als je het bekijkt op de hele pc, en je zit aan de netstroom dus het is ook niet noodzakelijk om battterijduur te verlengen.

Stroombesparing in combinatie met ATX12V zal echter wel benoemingswaardig zijn. Sowieso is die standaard bedacht om minder om te hoeven zetten (en dus efficiëntie te verliezen) wanneer er geen SATA in gebruik is en een processor die amper wat verbruikt in idle terwijl het apparaat bruikbaar blijft, gaat daar nog weer wat bij helpen. Met het oog puur op stroomverbruik ben ik benieuwd hoe dit gaat lopen!

Raptor lake, Gracemont cores, Raptor cove, Alder lake, Golden cove.

Juist!

Inderdaad. Ik snap ook al een tijd niks meer van Intel.

Zelf heb ik maar 1x in mijn leven een AMD-systeem gehad: een Thunderbird 1400 op een VIA KT-133A chipset in 2001; zeer slechte ervaring toen, om dat stabiel te krijgen onder Windows 2000.

Sindsdien ben ik toch altijd een Intel-persoon geweest.

Dat big.LITTLE gedoe is wat mij betreft gerommel in de marge op de desktop. Ze mogen er best een paar "little" cores bij zetten voor als de computer weinig te doen heeft, maar ik zit niet te wachten op 16 littles en 8 big cores, als AMD al 16 big cores kan leveren.

Het enige dat ik van Intel wil zien, is een (betaalbare) opvolger van de 10980XE die kan concurreren met de 5950X, op een opvolger van de X299 chipset. Het is toch absurd dat Intel's high-end desktop-platform effectief uit 2017 stamt?

Nu AMD gaat uitkomen met de refresh van de X570-chipset zonder ventilator (X570s), zit ik wel een beetje in dubio: ga ik voor een heel ver uit-ontwikkeld systeem (Socket AM4, X570s, 5950X), of wacht ik op de nieuwe Zen 4 op AM5?

Waarschijnlijk maakt het weinig uit.

Mijn oude i7-6700K uit eind 2016 voldoet voor alle taken nog steeds prima, en de nieuwe computer zou waarschijnlijk vooral gebruikt worden voor berekeningen op het gebied van machine learning. (Het zou me dan ook niets verwonderen dat als die dat een paar jaar gedaan heeft, die computer mijn primaire systeem wordt, en er een nieuwe computer voor de berekeningen komt.)

Hetgeen ik vooral nodig heb in mijn situatie is niet ultra-snelle cores, maar zoveel mogelijk cores, van allemaal dezelfde snelheid (en big.LITTLE voldoet dus niet aan die laatste eis; ik zie me de "little" cores ook nog wel uitschakelen.)

hoe moet ik mij dit voorstellen bij bijvoorbeeld future games.

4 snelle cores voor heavy duty tasks en bijvoorbeeld voor "onbelangrijke NPC" op de trage cores? of is het snel of traag?

ik zie bijvboorbeeld wel leuke toepassingen in CAD programmas. die wat ik gebruik zijn voornamelijk single core wanneer je bezig bent met drafting renderen is dan wel weer multicore. 1 cpu met bijvoorbeeld 2 stuks super snelle cores en 8 stuks "trage" low power cores voor renders in de background zou echt fijn zijn. dan kun je gewoon blijven werken terwijl een test render op de achtergrond draait.

hierin moet ik wel beseffen dat volgens mij programma's steeds meer CPU links laten liggen en renderen op de gpu.

Dan zal de software toch echt slimmer oeten en aan gaan geven waar ze welk process willen hebben draaien , volgensmij zijn game engines echt niet daar op gemaakt ,

Ik denk dat je meer moet denken aan achtergrondprocessen die in principe zo lang mogen duren als nodig: die kunnen lekker op die little cores draaien. Vooral in idle (met enkel achtergrondprocessen die her en der lopen) zal het verbruik wel kunnen dalen lijkt me.

Maar het voordeel is ook dat er meer tijd over is voor je game op de big cores; die zal niet lastig gevallen worden door die achtergrondprocessen. Ik verwacht dat al je game-processen altijd op big draaien, lijkt me wel zo handig ivm boosting ook bv.

Wellicht ook minder TDP daarmee en dus meer boostmogelijkheid voor de big cores. Nu heb je met all-core boost toch al snel een aantal honderd megahertz minder, als ze dat kunnen verbeteren door de big cores altijd voluit te kunnen laten draaien zou dat winst zijn.

[Reactie gewijzigd door A Lurker op 10 juni 2021 11:15]

De toepassing die je hier beschrijft is dan ook alleen van toepassing als de processor ook daadwerkelijk sneller is dan een andere processor in de zelfde prijsklasse met alleen big cores.

Ik ben er een tijdje uit maar gaan alle ontwerpen in de toekomst BigLittle zijn? En geld dit ook voor Xeon? Ik wil mijn 3d Render systeem upgraden en heb daar juist veel "sterke" cores voor nodig. Is AMD de enige keuze op dit moment?

In het kort. Ja, AMD is de enige die voor 'high-end' CPUs maakt. (Alle huidige intel chips met veel cores zijn voor servers volgens mij.)
Maar kijk naar wat je software aan kan aan cores etc. Maar het is op dit moment 99% zeker dat je meer gebaadt bent met een Threadripper setup dan iets van Intel.

[Reactie gewijzigd door EXos op 10 juni 2021 10:34]

Als je ermee gebaad bent, moet je opletten dat je niet verdrinkt.

Met Cpu's ben ik eerder bang voor scherpe randen. ;P

Tnx! Ik zat al te kijken naar een Threadripper. Jammer dat Intel HEDT meer maakt.

AMD is op dit moment de enige optie voor een systeem met spierballen en voor een rendersysteem zijn de Threadrippers de geëigende processoren. AMD zou voor Zen5 ook BigLittle gaan doen, maar dat is enkel een gerucht.

Volgens mij is amd voor veel sterke cores op dit moment vaak een heel goede keuze, maar zeker voor zoiets als renderen zou ik gewoon kijken hoe de software die jij gebruikt presteert op Intel en op amd en dan gewoon het beste wat in je budget past kopen.

Dit hele big little verhaal is er nog niet en het lijkt mij ook niet bedoeld voor een taak waar je lange tijd hee veel performance van zoveel mogelijk cores wil.

Ben blij dat de marketing van Intel nog wel wijs uit al die namen kan worden.

Stuiptrekkingen van een partij die jaren lang marktleider geweest is en dat tot op het bot heeft uitgemolken. Nu voorbij gestreefd door meerdere andere partijen en zo probeert weer een beetje terug te komen. ik hoop dat het ze lukt I.V.M. Concurrentie (voordeel consument en tweaker) maar ik ben bang dat het allemaal een beetje te laat is.

Stuiptrekkingen?
productie loopt op volle toeren

core per core doen ze het even goed als de concurrentie

kinderziekten van 10nm zijn er zo goed als uit.

ik denk niet dat ze nog wakker liggen over een onzekere toekomst bij intel

Kan me niet voorstellen dat dit lekker werkt.
Maak gewoon allemaal snelle cores maar geef ze een turbo mode voor games en een saving mode voor all core multithreaded loads en voor de idle gewoon alle behalve 3 cores op standby en de overige cores terug schalen naar 400 mhz idle. Dat is meer als genoeg.