AMD bevestigt komst consumentenprocessors met hybride architectuur

AMD bevestigt dat het werkt aan consumenten-cpu's met een hybride architectuur. Deze hebben vaak grotere prestatie- en kleinere efficiëntiecores. Het bedrijf wil per toepassing beslissen wanneer de hoeveelheid cores wordt verhoogd, en wanneer er gekozen wordt voor een hybrideontwerp.

Dat zegt AMD's chief technical officer Mark Papermaster in een interview met Tom's Hardware. Hij stelt dat het verhogen van de hoeveelheid cores 'niet langer de enige manier is om aan de eisen van klanten te voldoen'. In sommige gevallen willen klanten bijvoorbeeld dezelfde hoeveelheid cores, maar meer versnelling, beweert hij.

Papermaster vervolgt: "Maar je ziet ook variatie in de cores zelf, waarbij prestatiekernen gemixt worden met efficiëntiekernen die gemixt worden met acceleratie. Dus we krijgen nu niet alleen variaties in coredichtheid, maar ook variaties in het type core en hoe je de kernen configureert." Op de vraag of we een hybride architectuur kunnen verwachten in consumentenprocessors zegt Paperman: "Absoluut. Dat zie je nu al, en dat wordt alleen maar meer." Hij zegt dat de Ryzen 7040-cpu's al een vroeg voorbeeld zijn van een hybride structuur, aangezien deze processors geïntegreerde AI-acceleratie bevatten.

In maart gingen er door gelekte documenten al geruchten dat AMD werkt aan Phoenix-apu's met een hybride architectuur. Daarbij zouden er twee verschillende soorten cores worden ondersteund: Performance en Efficiency. De twee soorten cores zouden ieder een andere featureset krijgen. De prestatiekernen doen het zwaardere werk, terwijl de kleinere cores de achtergrondprocessen regelen om zo de algehele efficiëntie te verhogen.

Met de komst van een hybride architectuur volgt AMD concurrent Intel. Laatstgenoemde introduceerde in 2021 zijn Alder Lake-processors, die ook beschikken over prestatie- en efficiëntiecores. Intels zuinigere E-cores nemen minder chipoppervlakte in beslag en hebben een lager stroomverbruik dan de krachtigere P-cores. Ook ontbreekt ondersteuning voor hyperthreading in Intels efficiëntiecores.

Reacties (78)

[betwetor]

Wanneer je bij intel naar het verbruik per type core kijkt zie ik vooral dat de e cores juist slecht zijn voor de efficiëntie.
Bij de tests waar gekeken wordt naar het verbruik om een bepaalde opdracht af te ronden. Blijken de CPU's met relatief de minste e cores het efficiëntste.
Meegenomen dat CPU'S idle al heel weinig verbruiken zie ik niet in welk voordeel hybride heeft tov bijvoorbeeld bredere pipelines.
Grotere cores, minder hoge frequenties, meer prestaties bij minder verbruik. Kleine cores brengen weinig positiefs.

[Richardus27]

Zal waarschijnlijk iets met certificatie te doen hebben, energielabels of iets dergelijks. Mogelijk dat dit type CPU aanslaat bij bedrijven waar PC doorgaans niks doen en de efficiency-cores stroom besparen.

Of het hybride ontwerp is een buzzword die populair is bij consumenten omdat ze denken dat het veel bespaart.

Buiten dat kan ik me geen reden bedenken waarom AMD dit zou doen.

[Astennu]

Ligt er aan hoe je het implementeerd. Als je het goed doet zijn E cores zeker zuiniger voor betaalde taken. Maar zodra je wat performance nodig hebt kan je het al snel beter op een P core doen die korter veel stroom verbruikt naar dan weer snel uitgeschakeld kan worden.

[Caelestis]

Als je puur naar watt/tick kijkt dan gaat het inderdaad scheef.
Het gaat meer om de boven en ondergrens van het verbruik voor beide type cores.
Een P core heeft bijvoorbeeld een verbruik tussen 20 en 80 watt en een E core tussen 5 en 30 watt.
Zodra je in het overlap gedeelte terecht komt tussen 20 en 30 watt dan zal de P core de taak al efficienter uit kunnen voeren dan de E core.
Als je een taak uitvoert wat niet boven 20 watt uitkomt dan is juist de E core "efficienter" omdat de P core minimaal 20 watt verbruikt.

Om het in een notendop te zeggen is een E core een range extender van het mogelijk verbuik
Wat in bovenstaand voorbeeld 5-80 watt is.
Zit je nagenoeg altijd minimaal 30 watt te slurpen dan doen juist die E cores helemaal niks voor je. Zit je een beetje op google te zoeken of je mail te lezen dan zal je een verschil merken.

[Reactie gewijzigd door Caelestis op 23 juli 2024 11:27]

[Veyrah]

Dit is ook deels overgenomen van de mobiele industrie, waar ARM64 cpus dominant zijn. Voor ARM64 zijn efficiency cores veel waardevoller dan voor AMD64 cpus.

[Hans1990]

Als je voor alle variabelen controle houdt, dan zullen E-cores efficienter draaien. De stelling dat processors met de minste e-cores efficienter zijn, kan ook te maken hebben dat die processors vaak zijn beperkt tot een 65W TDP. De K processors van Intel komen met de meeste E-cores aanboord, maar mogen ook boosten in regionen van 150-250W voor een paar honderd MHz meer frequentie. De -K skew voegt niet enkel overclocking toe, maar ook hogere clocks en dus een minder gunstig verbruik/efficientie.

Het verbruik in idle is een lastige vergelijking, aangezien daar meerdere aspecten meespelen. Denk aan het verbruik van ringbussen of infinity fabric (zie idle en SoC verbruik bij AMD in verschillende CPU families en chiplet samenstellingen). Daar komt nog bovenop dat de cores in idle vaak gepowergate zijn. Die verbruiken dan 0.0W. Het maakt dan niet uit of je 8 snelle cores hebt of 16 langzamere cores. Het verschil in verbruik waar ik bij AMD op wijs, zal dus eerder in die (chiplet) bussen zitten.

Als cores wel aan het werk zijn, dan zijn grotere cores ook grotere energieslurpers. Naast de bekende Moore's law, is daar ook een "regel" gemodelleerd die dit gedrag vat, namelijk Pollack's Rule. Die stelt dat processor prestaties toenemen met de wortel van de complexiteit (denk aan area op een gegeven process node, ofwel transistor count). Als we verder stellen dat het aantal actieve transistors per area ook nog eens is beperkt door de power density, dan is parallelisme in aantal cores wel een verstandige keuze. De clocks omhoog krijgen kan totdat het silicon opbrandt. Het aantal transistors omhoog krijgen kan, maar wel met als voorspelling dat 2x zoveel transistors maar 40% meer prestaties oplevert. Een tweede core copy-pasten levert 2x zoveel (multi-thread) prestaties op.

[Reactie gewijzigd door Hans1990 op 23 juli 2024 11:27]

[codekloppertje]

Er zijn vele maatstaven voor het optimaliseren van een multiprocessor. Stroomverbruik is er een, latency, doorvoer hoeveelheid, kosten chip, geheugen/cache gebruik, hoeveelheid communicatie, etc.

[mac1987]

Dat hangt er vooral vanaf hoe de verhouding zware workload/idle is. Staat de computer 40 uur per week aan voor een tekstverwerker of browser, en een halfuur voor een game of videobewerking, dan is het idle verbruik van grotere invloed op het totale verbruik dan het verbruik onder zware belasting. Hoe meer de computer zwaar wordt belast, hoe belangrijker dat verbruik onder zware last wordt. In absolute zin zijn de verschillen groter onder last, maar de relatieve verschillen onder lage belasting zijn best significant en dat is wel waar de meeste computers zich het grootste deel van de tijd bevinden.

[Timoo.vanEsch]

Zou dat dan voor Zen 6 zijn?
Want voor Zen 5 lees ik geruchten dat het een opgeschaalde Zen 4 wordt. Ik had eerlijk gezegd zelf verwacht/gehoopt dat ze dit in Zen 5 zouden introduceren, mais bon.

[White Feather]

Juist niet:

AMD bouwt Zen 5 naar eigen zeggen vanaf de grond opnieuw op, waarmee grote wijzigingen in de architectuur te verwachten zijn.

nieuws: Op AMD Zen 5 gebaseerde cpu's op 3nm verschijnen in 2024

Ze zouden zowel bij Zen 4 als Zen 5 zowel volledige cores hebben, core met extra cache en efficiency cores.

[hooibergje]

Dat is ontzettend vervelend om voor te programmeren.

Als je per core een andere configuratie hebt, moet je het werk zo verdelen dat de langzame cores minder werk krijgen dan de snellere cores. Dat lijkt me niet eenvoudig.

[i-chat]

wacht, dat lijkt me juist ontzettend onhandig, ik zou eerder verwachten dat je bijvoorbeeld in staat bent om bepaalde complexere zaken in dezelfde structuur te houden en lichtere zaken in een aparte thread te zetten, en ook te zorgen dat je dergelijke treads niet vervuild met ingewikkelde zut. dan mag de taakbeheerder in de kernel lekker bepalen welke core welke thread moet oppakken.

kortom als je nu al overweg kunt met multi-treaded aplicaties dan gaat er niet heel veel veranderen. behalve dan dat je er IETS logischer over nadenkt bij de start.

wanneer je ontzettend time-critical wilt optimaliseren zoals in geavanceerdere software met meer low-level meuk worden de zaken natuurlijk wel veel complexer. maar goed, het brengt tegelijk ook weer meer mogelijkheden.

[hooibergje]

In rekenwerk doet elke thread typisch even veel.
Bijvoorbeeld, bij een matrix-vector vermenigvuldiging wordt de matrix typisch in even grote blokken over de threads verdeelt.

Met dit plan van AMD moet je als programmeur actief gaan bepalen dat de zwakke cores bijvoorbeeld blokken van 1000 rijen krijgen en de snelle cores blokken van 2000 rijen om te zorgen dat ze er even lang over doen.

[Robbierut4]

Met dit plan van AMD moet je als programmeur actief gaan bepalen dat de zwakke cores bijvoorbeeld blokken van 1000 rijen krijgen en de snelle cores blokken van 2000 rijen om te zorgen dat ze er even lang over doen.

Dit wordt grotendeels door het besturingssysteem gedaan toch? Ik hoor over Intel ook weinig klachten betreft de e-cores en denk niet dat elke programma speciaal daarop is aangepast.

[hooibergje]

In parallelle software heb je doorgaans threadID, die oploopt van 0 tot [veel], en op basis daarvan kan het werk verdeeld worden, bijvoorbeeld in pseudocode:

Ik heb thread index ID
Ik doe matrix rij 1000 * ID tot (but not including) 1000 * (ID+1).

Dan doet thread 0 rij 0 t/tm 999
Thread met ID 1 doet rij 1000 t/m 1999
Thread met ID 2 doet rij 2000 t/m 2999
etc.

Het is dan erg handig om de zekerheid te hebben dat al je cores even hard kunnen rekenen en evenveel geheugen hebben. Als dat niet zo is staan de snelle cores te wachten tot de langzame cores klaar zijn, en cores die wachten is zonde van de nieuwe dure processor.

Edit: De firmware van het CPU bepaalt welke thread op welke core draait, en zal dan vast als de snelle cores klaar zijn de threads op de langzame cores overzetten naar de snelle cores, maar het blijft nog steeds ongelukkig.

[Reactie gewijzigd door hooibergje op 23 juli 2024 11:27]

[Croga]

Ik ga er van uit dat dit soort zware lasten alleen op de snelle cores zullen draaien. De efficiënte cores zijn dan nuttig voor het sturende proces (wat tijdens deze bewerking vooral aan het wachten zal zijn) en de achtergrond taken van het OS.

De P/E scheiding is vooral aangebracht om te zorgen dat achtergrond taken niet in de weg zitten voor het zware werk, niet om het zware werk verder onder te kunnen verdelen. Een Matrix-vector berekening moet helemaal weg gehouden worden van de efficiënte cores; daar zijn ze helemaal niet voor bedoelt.

[Superstoned]

De efficiëntie van de kleine cores is beter - je zou het dus eigenlijk juist andersom moeten doen. Een multithreaded taak verdeel je liefst over de efficiency cores want die krijgen meer werk gedaan binnen je energie budget. Alleen de grote aan het werk zetten als je nog budget over hebt of als je single/low threaded werk doet.

[sympa]

Maar Intel biedt geen "zware" AVX aan als er e-cores in de processor zitten, omdat de e-core dat niet ondersteunt.

[Croga]

Geen idee waarom je dat denkt maar de 13900 (die zeker over e-cores beschikt) ondersteund gewoon AVX2. Wellicht niet op de e-cores maar toch zeker op de p-cores.
https://ark.intel.com/con...cache-up-to-5-60-ghz.html

[sympa]

Ik dacht dat die p-cores van een cpu afstammen die AVX3 doet. Maar dat het uitgeschakeld is omdat de e-cores dat niet kunnen. Op vanwege markt segmentatie natuurlijk.

[Croga]

Hmmm... goed punt....
Het gaat echter specifiek over AVX-512; AVX-2 blijft gewoon ondersteund, AVX-512 functionaliteit is in oudere processoren via BIOS uitgeschakeld en bij nieuwere zelfs gewoon weg gebrand. En inderdaad, in processoren zonder e-cores (zoals bijvoorbeeld de i5-11400) blijft het wél gewoon aan staan.

Redelijk vaag; ze zijn bezorgd dat AVX-512 code richting een e-core gestuurd wordt. In plaats van zelf te zorgen dat dat niet kan gebeuren zetten ze het dan maar uit

[sympa]

Of laat de e-core een trap geven op de illegale instructie, en het dan op laten pakken door een p-core. Maar dan moet het OS meewerken, en zo'n afgebroken instructie op een andere core oppakken is ook iets heel nieuws.
Dan is het nog makkelijker die AVX512 heel erg langzaam uit te laten voeren op de e-core, in microcode. Als dat kan qua registers.

[batjes]

Voor zulke workloads zal AMD dus CPU's hebben die op alle cores even hard gaan.

[Super_Fred]

Het is dan erg handig om de zekerheid te hebben dat al je cores even hard kunnen

Ik volg jouw redenatie, maar hierbij ga je er wel van uit dat je de volledige beschikking hebt over de cores. In de praktijk kan het zijn dat een aantal cores idle is en een ander aantal bezig is met bijvoorbeeld een realtime virusscan op de achtergrond. Met HyperThreading ingeschakeld (bij een Intel CPU) wordt dit nóg onvoorspelbaarder. In Windows kun je per applicatie ook nog eens de affinity aanpassen.

Ik denk dus dat het sowieso lastig is om exact op de core/thread te programmeren op een manier dat je taken goed kunt verdelen in stukken die parallel door de cores worden uitgevoerd en gelijktijdig klaar zijn.

[Reactie gewijzigd door Super_Fred op 23 juli 2024 11:27]

[Caayn]

Voor CPUs kan je relatief eenvoudig zelf bepalen wat voor specs een core heeft en in het geval van Intel ook of het een P of een E core is. Dit vereist wel wat extra werk ten opzichte van gewoon de volgende X cores pakken maar lastig is het niet. Ik gok dat wanneer AMD met eenzelfde verdeling komt dat ook voor die CPUs werkt.

(Windows only)
Zie bijvoorbeeld: https://github.com/GameTechDev/HybridDetect en dan specifiek HybridDetect.h -> GetLogicalProcessors() waarbij netjes een array gevuld wordt met cores met correcte core info. Hierop kan je vervolgens vrij eenvoudig twee arrays maken met P (efficiencyClass == 1) en E (efficiencyClass == 0) cores waar je vervolgens je threads aan toe kan wijzen.

[DataGhost]

Of je doet het op een gangbaarder manier en pakt een typischer producer/consumer model met een task queue waarvan elke thread een task kan pakken op het moment dat deze niets te doen heeft. Zo kan je alle cores (ook de E-cores) gebruiken en is het alsnog min of meer tegelijk klaar, waarbij de P-cores het meeste werk verricht zullen hebben. Van tevoren al het werk verdelen zorgt altijd al voor ongelijke eindtijden. Cores zijn sowieso al niet even snel maar halen verschillende kloksnelheden, er kunnen andere taken op de achtergrond draaien die een of meerdere cores vertragen en dat soort gedoe.

De firmware van het CPU bepaalt welke thread op welke core draait

Nee, dat doet het OS. Intel heeft een Thread Director in de CPU's ingebouwd ja, maar die geeft alleen maar een soort advies van welke thread op welke core te schedulen. Daarom heb je voor fatsoenlijk gebruik van de Intel P/E-cores op Windows dus versie 11 nodig, Windows 10 praat niet met die TD en doet z'n eigen ding.

[Reactie gewijzigd door DataGhost op 23 juli 2024 11:27]

[miklas]

Klopt, een hybride design bestaat natuurlijk al langer bij Intel en een hele hoop ARM-gebaseerde producten.
Ook kan je zelfs het design van de "X3D" CPU's van AMD, waarbij de ene Core Complex meer/snellere cache krijgt, als een hybrid beschouwen. Om dan nog maar niet te spreken van het feit dat de SMT/"hyperthreads" vaak een stukje trager zijn, zowel bij AMD als bij Intel.

Om op het voorbeeld van @hooibergje terug te komen, wil je gewoon al het werk mooi in stukjes van 1000 delen. Het is dan inderdaad aan het OS en de scheduler om te zorgen dat dit zo snel mogelijk gebeurt, kijk maar eens naar hoe cinebench dat doet op een I9 13900K. Daar is geen processor specifieke code voor geschreven.

[hooibergje]

Wat CineBench volgens mij doet is net als wat er op GPU's typisch gebeurt met CUDA: dat er veel meer threads zijn dan cores. Als overdreven voorbeeld: Ik heb nu zelf een programma met 64 miljoen threads. Die gaan niet allemaal tegelijk af want dan wordt de scheduler gek, maar ze worden gebuffered en zodra er een core klaar is, krijgt-ie een nieuwe thread, totdat ze allemaal op zijn (Preciezer: zodra er een blok van een paar honderd threads op even zoveel cores klaar is, krijgen die cores als groep een nieuw blok met threads)

Klopt dat vermoeden?

[miklas]

Threads creëren en schedulen kost redelijk wat tijd. De Windows scheduler geeft elke thread een paar milliseconden, en geeft dan de kans aan andere threads. Dit omdat het systeem responsief zou blijven aanvoelen, want meestal heb je een hoop meer threads die runnen dan je fysiek in je machine hebt. Kijk maar eens in Task Manager naar de performance tab. Blijkbaar heeft mijn systeem er momenteel een goeie 4822. En ik heb niet zo veel cores

Wat de meeste processen doen, is even veel threads starten als het systeem fysiek aankan (of nuttig zijn voor jouw workload). Anders veroorzaak je inderdaad gewoon extra werk voor de scheduler. Dan verdeel je al het werk in een bepaald aantal, liefst zo gelijk mogelijke, jobs. Cinebench lijkt dat te doen in een goeie ~450 aparte "jobs". En dan laat je die worker threads gewoon de volgende van die lijst nemen, tot al het werk gedaan is.

Het is altijd een beetje zoeken naar een balans, want je wilt dat de units zo klein mogelijk zijn zodat elke core zo lang mogelijk bezig is, onafhankelijk van hoe snel die is. Maar je wilt ze ook groot genoeg, dat de cores ook effectief bezig zijn met nuttig werk, en niet de hele tijd naar nieuw werk op zoek zijn.

Tevens is dit enkel het geval in synthetische workloads, want de meeste applicaties hebben helemaal geen nood aan zoveel threads. Maar, dan kan Windows de achtergrondtaken zoals updates of een chatprogramma op de zuinigere cores uitvoeren, terwijl dat spel dat je op de voorgrond hebt juist de snellere cores mogen gebruiken. Windows kan trouwens ook zomaar beslissen dat een ander proces nu belangrijker is, en al jouw threads zonder pardon deschedulen.

Over het algemeen komt het er op neer om zo generiek mogelijk te programmeren: je werk zo gelijk mogelijk verdelen, en zeggen tegen de scheduler welk werk 'high' en welk werk 'low' priority is. Zo heb je de meeste kans dat je software vlot draait op vorige, huidige en toekomstige hardware.

[Rogers]

Hangt van de implementatie af.
Hoe ik het vroeger maakte bijv. was het één thread per core elke thread kreeg jobs om af te werken, is die klaar krijgt die een nieuwe job. Het maken van een thread heeft overhead dus dat wil je minimaliseren. 1000 jobs verdelen over 1 thread per core is sneller dan 1000 threads maken.

Er kunnen ook situaties zijn waar je main thread of worker thread een hogere prioriteit heeft en als die dan op zo'n zuinige core wordt gezet ben je de zak.

[Reactie gewijzigd door Rogers op 23 juli 2024 11:27]

[johnbetonschaar]

Als je per core een andere configuratie hebt, moet je het werk zo verdelen dat de langzame cores minder werk krijgen dan de snellere cores. Dat lijkt me niet eenvoudig.

Het is zeker niet eenvoudig, maar grotendeels een taak van het OS om threads aan de juiste cores toe te kennen. Hooguit zal je als programmeur rekening moeten houden met het aantal threads dat intensieve taken uitvoert (maar dat moet nu bij niet-hybride CPU’s op zekere hoogte ook al), en/of het OS hints geven welke threads bij voorkeur op een P-core of een E-core moeten draaien door ze de juiste QoS class toe te kennen.

Hoe het OS dit vervolgens zo optimaal mogelijk verwerkt voor alle verschillende processen die lopen, dat is inderdaad een lastig probleem vol corner cases, zowel Windows als Linux hebben het er nu al lastig mee. Maar dat is iets voor de OS bouwers om op te lossen en niet direct voor de applicatie programmeur.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 11:27]

[andru123]

In Linux kan je per applicatie aanwijzen op welke cores moeten die draaien. Dus bijv. onbelangrijke achtergrondtaken - op efficiënte cores, energie besparend.

[johnbetonschaar]

Ja dat klopt, op Windows ook. Dit wordt meestal gebruikt voor dingen als HPC achtige taken of om vCPU’s van een VM 1 op 1 aan cores te assignen. Het gaat er dan vaak om om te voorkomen dat threads migreren naar cores op andere dies (hogere latency), cores met de working set niet in de cache, etc

Bij dit soort hybride processors is eigenlijk het idee dat het OS de scheduling zo veel mogelijk automatisch doet, zodat applicaties niet zelf rekening te hoeven houden met alle verschillende CPU configuraties etc, en omdat de OS scheduler informatie heeft over alle processen en threads en dus betere keuzes kan maken voor alle taken op het systeem. Handmatig threads aan cores assignen is te beperkt hiervoor.

[Reactie gewijzigd door johnbetonschaar op 23 juli 2024 11:27]

[arjankoole]

Dat is ontzettend vervelend om voor te programmeren.

Als je per core een andere configuratie hebt, moet je het werk zo verdelen dat de langzame cores minder werk krijgen dan de snellere cores. Dat lijkt me niet eenvoudig.

Als,ik het goed begrepen heb, neemt de scheduler dat voor de rekening. Niet de developer. Lichte threads draaien door de ingebouwde predictor op efficiency cores, terwijl zware threads op de performance cores gescheduled worden. Op mobiele devices doen ze dat al een hele tijd, en Intel doet het het ook al een tijdje, de meeste bugs zijn er nu wel uit. (En zaten vooral aan OS kant).

Als je toepassingen hebt waar je dat allemaal zelf wilt regelen, dan zijn er ook CPU’s met alleen maar performance cores beschikbaar. Duurder, vreten meer stroom, maar draaien voluit.

Ik ga als het vakantie geld binnen is eens testen met een 6P/8E i7 (als die Nuc dan beschikbaar is) en proxmox. Eens kijken of ik kan zien en monitoren wanneer wat op de ene of andere type core land.

[Raymond Deen]

Ik denk dat je, als je bewust multi threaded programmeert, je dat niet zoveel moeite extra voor hoeft te doen behalve misschien de class markeren voor een specifieke load. Verder doet het ontwikkel framework dat wel wel voor je.
Dat is het voordeel van abstractie van de hardware.
Wanneer je wél bleeding edge performance nodig hebt, ben je ook wel in staat om hiervoor te programmeren, denk ik zo, want dat is al tijden moeilijk door al die extensies die er aan processoren gehangen worden.

[Damic]

Zen5 kan het volgende ontwerp zijn met 1 "helft" E-cores en de andere "helft" P-cores of 1 cDIE met P cores en een andere cDIE met E-cores. Als je modulair werkt kan je heel veel kanten uit.

[Caayn]

Zou natuurlijk mooi zijn als de P cores zoveel mogelijk bij elkaar gegroepeerd zijn om de core-to-core latency zo laag mogelijk te houden voor de P cores.

Core latency voor achtergrond taken is een stuk minder relevant.

[Reactie gewijzigd door Caayn op 23 juli 2024 11:27]

[andru123]

Waarom is het van belang? Praten cores met elkaar? Ik dacht allen met cache en execution queue.

[Croga]

Een cluster op een AMD processor deelt ook het cache geheugen. Ofwel: Ja, cores praten met elkaar via de cache dus als die cache per cluster gedeeld is helpt dat met de performance.

De 7900X3D en 7950X3D zijn hier mooie voorbeelden van. Beiden hebben een cluster mét 3D cache en een cluster zonder en dat heeft een negatieve invloed op de performance waar die 3D cache gebruikt wordt.

[Caayn]

De manier hoe een core in conctact staat met een andere core verschilt enorm.

Als je data uitwisselt tussen Core 0 op CCX 0 en core 8 op CCX 2 dan zal het langer duren dan tussen Core 0 en Core 3 binnen dezelfde CCX simpelweg door de fysieke afstand tussen de cores, meerdere cache lagen en de Infinity Fabric (in het geval van AMD) die je passeert.

[MrMonkE]

Houden OS'n hier rekening mee als de kernel core's 'toekent' aan processen?

[the_stickie]

De Phoenix APU waarvan sprake zou gebaseerd zijn op Zen 4!
Ik denk dus niet dat je op Zen 6 zal moeten wachten tot dit in de winkels ligt

[White Feather]

Inderdaad. AMD zou bij Zen 4 3 verschillende cores gebruiken. Zen 4, Zen 4 3D en Zen 4c. Die laatste zouden volgens mij de efficiëncy-cores moeten zijn.

De enige vraag is dus of ze ze tegelijkertijd in 1 cpu stoppen. Maar met chiplets wordt dat een stuk simpeler dan bij een monolithische cpu.

[Damic]

ZEN4C is toch data center only (Bergamo) en echt E cores zijn het niet (zoals we ze bij Intel kennen) vermits ze ook HyperTreading kennen)

For EPYC Bergamo, the chip is said to feature hyperthreading support so you get 128 cores and 256 threads

https://www.anandtech.com...mo-up-to-96-and-128-cores

[White Feather]

Intel heeft de grootste cores en hoog verbruik en moet dus relatief zwaar compenseren. AMD heeft kleinere core die ook nog een stuk zuiniger zijn. Zij hoeven dus minder extreem zuinig/kleiner te gaan dan AMD.

De 4c-cores zijn de enige zuinigere cores waar AMD ooit over gesproken heeft. Tuurlijk is het een aanname dat die gebruikt gaan worden, maar volgens mij is er niets dat het tegendeel bewijst (behalve de uitspraak van AMD dat ze Bergamo zijn en “bepaalde klanten”.

AMD heeft al genoeg issues om alle verschillende afleidingen van hun CPU’s te maken, en dan zouden ze ook nog een 3e cpu-Core gaan maken?

Ik betwijfel het.

[Astennu]

Zen4 is de laatste doorontwikkeling van wat er bij Zen1 gestart is. Ze 5 zou een ground up nieuw design Zijn. Jim van Adored tv heeft er ook een mooie video over gemaakt wat ze mogelijk met connectie tussen de cores en de cache van plan zijn:

https://youtu.be/3FDh9C59Z1A

Dit gaat er ook voor zorgen dat ze naar meer dan 16 cores in een ccx kunnen. Zen4c met 16 cores schijnt uit 2x8c te bestaan dus 2 ccx'en net als Zen1 en 2 hadden (daar was het een 2x4 config). Echter zorgt dit voor meer latency.

En er gaan ook gewrichten over een unified L2 cache dus niet per core maar mogelijk een grote waar alle cores gebruik van maken. Dit is echt niet nieuw IBM heeft dit al in de nieuwste Power architectuur. Maar voor X86 CPU's zou het wel nieuw zijn.

[Cowamundo]

Dus voor het zelfde geld krijg je straks maar voor de helft aan krachtige cores en de andere helft van de cores zijn “meh”? Snap dat je niet altijd 24 cores nodig hebt voor alle toepassingen maar ik vindt het een vreemd iets als je de helft van je cores maar op 75% van hun max klokt en dan zegt “energie zuinig” omdat wij vinden dat iets ook wel minder snel kan.

Of is dit niet hoe het p/e core verhaal werkt?

[johnbetonschaar]

Nee, de P-cores en E-cores zijn bij Intel, Apple, Qualcomm, Samsung etc, daadwerkelijk verschillende ontwerpen, waardoor er veel meer E-cores op dezelfde die passen en het verschil in verbruik (en prestaties) tussen P-cores en E-cores veel groter is dan alleen maar een lagere kloksnelheid. Ik weet niet of het nog steeds zo is, maar bij Intel waren de E-cores van in ieder geval de eerste hybride CPU’s gebaseerd op de Intel Atom cores, bijvoorbeeld.

[eheijnen]

Dan wordt het tijd voor een door de consument vrij te configuren CPU waarop je naar keue cores kunt toevoegen of wegnemen...

[Silent7]

pas op, voor je het weet koop je een grote chip en moet je met abonnementen features unlocken.

[eheijnen]

Aach, prijs/performance is zeer goed bij AMD

[BlaDeKke]

En dat is een constante? Waarschijnlijk ook de reden dat Intel van Core2X tot Ryzen de markt gedomineerd heeft.

[Reactie gewijzigd door BlaDeKke op 23 juli 2024 11:27]

[Damic]

Te laat Intel heeft dat al met de Xeon's

[Jehannes Z]

ik heb geloof ik iets gemist, heb je hier misschien wat leesvoer over?

[Damic]

https://www.techpowerup.c...ilicon-as-intel-on-demand

https://www.intel.com/con...cs/ondemand/overview.html

Meer: https://duckduckgo.com/?t...res+behind+paywall&ia=web

[Reactie gewijzigd door Damic op 23 juli 2024 11:27]

[BlaDeKke]

Haha, mooie voorspelling. CPUAAS.

[Damic]

Is geen voorspelling Damic in 'AMD bevestigt komst consumentenprocessors met hybride architectuur'

[Marc H]

Alsjeblieft niet.

Dat zou voor de fabrikant een mooie reden zijn om er een abonnement model aan te koppelen. Wil je veel performance cores gebruiken? Kan, maar dan mag je eerst even je abo aanpassen, voor een stapeltje euro's per maand. High end hardware ondersteuning voor een codec nodig voor video render? Weer een extra stapeltje.

Zeg niet dat het niet gaat gebeuren, want het gebeurt al in de autobranche.

[Damic]

Te laat Intel heeft dit nu met de nieuwe Xeon's alles aanboord maar te unlocken met abbo service

[sympa]

Sun had dat 15 jaar geleden al. En IBM had het nog eerder.
Eigelijk doet Intel het al veel langer. Denk aan de low end CPUs die plotseling ECC kunnen doen als de goede chipset op het moederbord zit.
Maar snellere consumenten-CPUs met ECC blijft geblokkeerd.

[familyman]

Hoeft niet zo dramatisch te zijn. Je kan ook denken aan een basisplatform, waarop je zelf configureert hoeveel p, e, ai, en whatever cores je wilt, icm andere zaken als cache.

Beetje het auto business model, voor de services waar jij over praat.

[Kalis]

Ik hoop dat de toekomstige APU's ook waanzinnig DDR5 overklokken

[larspc]

Daar bestaat Lppdr5x voor.

[jb044]

Blij dat ik deze generatie ben ingestapt Ik geloof best dat Windows hier direct op geoptimaliseerd wordt, maar Linux is toch een ander verhaal. Zeker voor een homeserver met een sloot containers. Doe mij maar mijn 'ordainere' Ryzen 9 met 16 reguliere cores. Het was voor mij de afweging om voor AMD te gaan deze generatie ... en de gun factor natuurlijk

[nandervv]

Linux kan er inmiddels prima mee omgaan.

[mr_evil08]

De energiezuinige core,s kun je vrijwel altijd uitschakelen in de bios waardoor je OS er niks mee kan doen, en anders zet je de core,s in het OS hardhandig uit.

[Reactie gewijzigd door mr_evil08 op 23 juli 2024 11:27]

[Clevergyno]

Ben benieuwd. Bij Intel was het een excuus om vooral een hoger core count te krijgen zonder dat het zou afbranden, maar heel efficiënt zijn ze helemaal niet. Laatstaan vergeleken met de nieuwste AMD apu's.

[mduijvendijk]

Waarom moet ik hierbij toch steeds weer denken aan de aloude coprocessor.
Het verschil was echter wel dat die een andere instructieset bevatten.

[Palindrome]

Dat zou hier natuurlijk ook mee kunnen. Zie ook GPU'S met eenheden voor raytracing of AI.

[derikkert]

Hebben ze dat nu al niet eigenlijk, met de 7950X3D? Misschien geen Intel-achtige P en E cores, maar er zit wel degelijk genoeg verschil tussen de twee chiplets om de scheduler om te gooien, zoals bij de hybride Intel chips.

Naar mijn mening meer hybride dan een stuk AI op je chip toevoegen, dan zou je APU's ook hybride kunnen noemen.

[mr_evil08]

Dus eigenlijk wat Intel al een tijd heeft met de E-Cores.