Intel wil meerdere fysieke cores via software combineren tot één virtuele core

Intel heeft een patentaanvraag ingediend voor een techniek om via software van meerdere processorcores één virtuele core te maken. Zo'n softwarematige singlecore zou dan kunnen komen in plaats van een fysieke singlecore die krachtig is, maar ook meer energie verbruikt.

De techniek waar Intel patent op aanvraagt heet software-defined super cores (sdc) en is in wezen het tegenovergestelde van Intels hyperthreading. Sdc laat meerdere cores samenwerken alsof ze één core zijn. Het besturingssysteem kan dit flexibel in- of uitschakelen afhankelijk van het soort taken dat de cores te verwerken krijgen. Sdc werkt onzichtbaar voor de applicaties die draaien op het besturingssysteem.

Het voornaamste voordeel van sdc is een betere efficiëntie, schrijft Videocardz.com. Intel hoeft door deze techniek niet per se fysieke singlecores te maken die hoge prestaties neerzetten in singlethreaded taken. Bij software die singlethreaded draait worden alle instructies achter elkaar uitgevoerd. Bij multithreaded verwerking worden instructies verdeeld over meerdere cores die het werk parallel uitvoeren. Voor sommige toepassingen kan singlethreaded verwerking door één krachtige core betere prestaties geven dan multithreaded door meerdere cores die relatief zwak zijn.

De prestaties van een singlecore worden in de regel verbeterd door de kloksnelheid te verhogen of zo'n processorcore uit te breiden. Het eerste kost meer energie en kan meer koeling vereisen. Uitbreiden betekent grotere cores, waardoor een chipfabrikant minder stuks kan halen uit één chipwafer. Wafers zijn de ronde plakken die worden gemaakt door chipproductiemachines zoals die van ASML.

Reacties (120)

[RobertMe]

Maar hoe gaan ze het werk dan verdelen? Want single threaded code impliceert juist dat alles sequentieel wordt uitgevoerd en afhankelijk van elkaar is. Het werk verdelen, over meerdere cores, kan in principe dus niet. Tenzij de processor ineens per instructie moet gaan uitzoeken of die afhankelijk is van het resultaat van een voorgaande instructie, zo nee kan dat werk ook op een andere core alvast worden gedaan. Maar dat lijkt mij dan weer zeer complex, past potentieel niet eens fatsoenlijk in de microcode, (zal wel weer leiden tot nieuwe bugs en security issues), en geeft ook een enorme berg overhead om elke keer de instructies te moeten analyseren en opsplitsen.

Een taak die de software ontwikkelaar dus veel beter kan doen. En dan dus gewoon dergelijke multi threaded code kan schrijven.

Leest IMO dus meer alsof Intel een oplossing aan het zoeken is voor een probleem dat niet echt bestaat (want multithreaded is beter) en niet echt op te lossen is.

En ik als leek lees altijd "AMD heeft een betere performance per Watt". Leest dus alsof Intel beter eerst daar een inhaalslag kan maken. Snellere cores met behoudt van enige "zuinigheid". I.p.v. de huidige turbo waarbij het energieverbruik extreem toeneemt voor een klein beetje extra performance.

[laurxp]

Dat is dus precies wat CPUs al een jaartje of 40 aan het doen zijn!

Iedere core bestaat uit een half dozijn onafhankelijke rekeneenheden, en er gaat haast meer energie naar het uitvogelen van de uitvoer-volgorde dan naar het daadwerkeljike rekenen zelf. Eén instructie kan meerdere rekentaken worden, of meerdere instructies kunnen één rekentaak worden. Instructies kunnen van volgorde veranderen, parallel uitgevoerd worden, of zelfs speculatief uitgevoerd worden.

Op papier zou je inderdaad denken dat een programmeur dat veel beter zou kunnen - en het gevolg daarvan was de faliekant mislukte Itanium architectuur. En ja, dat zorgt inderdaad af en toe voor lastige bugs: dit is waar Spectre en Meltdown vandaan kwamen.

Op zich is het helemaal niet zo héél gek om virtueel cores te combineren - want dat is eigenlijk precies wat Hyperthreading al doet: meerdere cores delen dezelfde rekeneenheden, waardoor rekeneenheden die niet gebruikt kunnen worden door een thread op de ene core in kunnen worden gezet voor werk van de andere core. Intel wil hier alleen ietsje verder mee gaan.

[uiltje]

Op zich is het helemaal niet zo héél gek om virtueel cores te combineren - want dat is eigenlijk precies wat Hyperthreading al doet: meerdere cores delen dezelfde rekeneenheden, waardoor rekeneenheden die niet gebruikt kunnen worden door een thread op de ene core in kunnen worden gezet voor werk van de andere core. Intel wil hier alleen ietsje verder mee gaan.

Je ging zo goed, tot deze bewering. Een core bestaat niet alleen uit ALU's. De registers, branch predection unit PC etc. zijn er ook deel van. Bij hyperthreading worden de rekeneenheden wel gedeeld tussen twee of meer threads, maar de rest niet. Dit gaat meer over het benutten van de ongebruikte rekeneenheden binnen de core; de threads zelf worden wat trager maar je kan tot 30% snelheid winnen, verdeelt over de twee threads natuurlijk.

Dit is meer het omgekeerde: het samenvoegen van twee cores voor snellere verwerking in een thread ten koste van de algemene rekensnelheid. We hebben nu zo veel cores dat het niet uitmaakt. Dit staat ook in het artikel, en dat is in ieder geval correct.

[Hardfreak]

Helemaal mee eens. Ik zie hier in de comments gigantisch goeie info terugkomen, maar de lijn tussen single en multithreaded is blijkbaar niet altijd even duidelijk naar voor gebracht.

Wat heel belangrijk is bij multithreading (of je nu één core hebt of meerdere), is dat wanneer een core moet wisselen van thread, dit vaak gepaard gaat met volledige flush van de caches (dit was vroeger zeker zo, tegenwoordig gebeurt het minder, maar cache misses zijn waarschijnlijker). Het gevolg hiervan is dat informatie (context) die nodig is voor de andere thread terug uit het RAM geheugen gehaald moet worden (of erger, vanaf de harde schijf). Hoe snel DRAM ook mag zijn, het is enorm traag tov het SRAM dat ze gebruiken in de caches. Context switches zijn enorm kostelijk (net zoals branch prediction misses).

Wat hyperthreading zo mooi maakte was dat het mogelijk was om zonder dure context switching twee verschillende threads te laten draaien op één core door ongebruikte rekenunits in te zetten voor de andere thread. Als één thread bijvoorbeeld alleen integer operations nodig had, dan kon een andere thread nog altijd gebruik maken van de vrije floating point units (zolang er geen integer operation in de pipeline zat van de 2e thread).

Als ik zo even snel door de aanvraag ga lijkt het mij alsof ze de 2e core meer als "prediction unit" willen inzetten; namelijk het rekenwerk verderop in de pipeline al uitvoeren en op het einde checken of er geen afhankelijkheden waren van het werk dat de eerste core gedaan had. Het klinkt heel leuk, maar ik vraag mij af hoeveel winst ze kunnen maken hiermee, want de kans lijkt mij toch vrij groot dat sequentiële code niet zomaar op te splitsen is omdat je nu eenmaal werkt op dezelfde data.

[uiltje]

Inderdaad, maar zoals ik ondertussen wel 10x getyped hebt: dit wordt wel degelijk ondersteund door HW in het patent, bijvoorbeeld door het delen van registers waaronder de PC en manieren om met jumps om te gaan.

Ik ben zelf ook altijd sceptisch op parallellisatie op laag niveau (i.e. niet door de programmeur ontworpen) of zo goed als inherent aan het systeem (GPU's, web-servers etc.), maar ik kan me ook voorstellen dat met slimme HW ondersteuning + slimme JIT's het misschien een ander verhaal wordt.

Dus ik ben echt heel benieuwd. Dit kan veel uitmaken voor Intel. Of het kan een doodgeboren kindje worden, bijvoorbeeld omdat het core design te veel op de schop moet.

Misschien kan dit praktisch wel alleen vanwege de power supply via de backside waar ze het al een tijdje over hebben. Maar dan ga ik wel erg diep en ben ik volledig aan het speculeren.

[Reactie gewijzigd door uiltje op 1 september 2025 15:44]

[laurxp]

Dit is meer het omgekeerde: het samenvoegen van twee cores voor snellere verwerking in een thread ten koste van de algemene rekensnelheid. We hebben nu zo veel cores dat het niet uitmaakt. Dit staat ook in het artikel, en dat is in ieder geval correct.

Mijn punt was dat er geen 1:1 relatie is tussen ALU en core, en dat de verschillende ALUs van een fysieke core onafhankelijk kunnen opereren. Dit maakt het mogelijk om meerdere ALUs tegelijkertijd aan één thread te laten werken, of ieder aan een andere thread.

In dit geval maakt Intel het mogelijk om een ALU "uit te lenen" aan een andere core. Conceptueel gezien is dat niet héél andere dan twee cores combineren (zoals met HT) en ALUs dynamisch toe te wijzen. De implementatiedetails zijn uiteraard wat anders dan bij HT en er zit een ander doel achter dan bij HT (sneller rekenen ipv effecten geheugentoegang beperken), maar het komt ruwweg op hetzelfde creatief-toekennen-van-ALUs neer.

[grasmanek94]

Als ik het patent een beetje skim is het idee dat ze juist een chip ontwerpen die zowel multi-core is, en ook mogelijkheid heeft om "samen" fysiek een core te vormen die juist heel erg veel IPC kan doen, dus er zit ook daadwerkelijk hardware support achter.

Eigenlijk kan je het andersom bekijken;

Intel maakt een single-core superprocessor met mega veel oppervlakte en IPC, en past dan super-hyperthreading toe om het 8 of 16 cores te maken etc (wat de default is bij power-on)..

Alleen dat verkoopt niet zo sexy als in de Pricewatch opeens alle moderne processors een corecount van 1 hebben. Het is maar net hoe het gemarket wordt, dus een 32 core CPU die 1 of 2 cores kan vormen is sexier voor de verkoop.

[Reactie gewijzigd door grasmanek94 op 1 september 2025 10:32]

[uiltje]

Nee, dan begrijp je het echt niet. Die processors zijn nog steeds grotendeels dezelfde cores op dezelfde chip, alleen met een HW aanpassing om sneller gegevens te kunnen delen met een processor die er naast zit. Het is in de verre verste niet 1 processor.

Hyper-threading is een speciale techniek die ervoor zorgt dat je de reken-kernen van een processor zo goed mogelijk gebruikt waardoor je twee wat tragere threads krijgt maar tot 30% winst aan IPC (de eerste CPU's met hyperthreading voegden overigens veel minder IPC toe, zelfs in het beste geval, en games waren vooral single-threaded, dus je kon het toen beter uitzetten).

En er staat nergens dat het dus werkt door alle cores samen te voegen. Het hele stuk hierboven heeft momenteel +2 maar het is echt complete larie.

[grasmanek94]

Sorry dat mijn vergelijking verkeerd is gevallen

Ik benadrukte vooral dat er hardware support zit, en gaf een "laymans perspectief" vanuit de huidige aanpak die bekend is (we hebben 1 core, en we splitten m op - en dat kan je ook omdraaien).

Ja technisch is het complexer met zelfs aanpassingen van de broncode van het originele programma die door de cpu gedaan worden. Ik zou er graag urenlang over discussiëren, maar daar is dan het forum beter geschikt voor denk ik.

[uiltje]

Ik heb niets tegen simplificatie en je probeert het goed uit te leggen. Maar dat moet stoppen als er daardoor onzin wordt verkondigd.

"Intel maakt een single-core superprocessor " Nee, dit gaat over twee of meer kernen die naast elkaar zitten en met hardware aan elkaar gelinked zijn met een snelle tunnel. Er is niet 1 pipeline maar meerdere, en met de huidige processors met tig kernen is er al helemaal geen sprake van een single-core superprocessor.

Als je meer tijd kwijt bent aan het verbeteren van de fouten in de simplificatie dan dat de simplificatie oplevert dan schiet het zijn doel voorbij.

[SG]

Zoals ik zie kan core combineren met aansluitende core. Dus cpu heeft bv 32 cores waar er enkele gecombineerd kunnen worden tot virtueel 1 en afhankelijk van vrije cores krijg context switch en combinering van twee naast mekaar liggende cores. Theoretisc heb je dan minimaal 16 max 32 al zal eerder 26 tot 32 zijn

[CAPSLOCK2000]

Maar hoe gaan ze het werk dan verdelen? Want single threaded code impliceert juist dat alles sequentieel wordt uitgevoerd en afhankelijk van elkaar is. Het werk verdelen, over meerdere cores, kan in principe dus niet.

Ik denk dat de grenzen tussen sequentieel en parallel, single-core en multi-core zachter zijn dan je denkt.

Al heel lang geleden hebben we losgelaten dat 1 instructie "machinecode" vertaalt in 1 atomaire actie van de CPU hardware. In werkelijkheid draait er software op je CPU die de "extern zichtbare machinecode" vertaalt naar interne instructieset en dat kunnen meerdere instructies worden.

Verder bestaat het uitvoeren van 1 instructie uit meerdere stukken. Een oude techniek om CPU's meer efficient te maken is "pipelining", waarbij een enkele instructie in delen wordt uitgevoerd en nog voordat de eerste instructie er helemaal doorheen is worden de volgende instructies al in de pipeline gestopt.

De eerste vormen van modere multiecore CPU's begonnen met multithreading waarbij bepaalde stukken van die pipelines dubbel zijn uitgevoerd om zo bottlenecks weg te nemen. Door een paar kleine stukjes te verdubbelen kon je de rest van de hardware beter gebruiken en leek het alsof je twee cpu-cores had.

Ik denk dat ze dat geheel nu nog een stap verder doorzetten en stukjes van die CPU op verschillende manieren kunnen inzetten (bv een low-power configuratie, een single-threaded config met of zonder floating point, etc).. De CPU kijkt welke instructies er binnen komen en kiest een passend profiel om die instructies te verdelen over de beschikbare hardware.

Over een paar jaar zal wel iemand bedenken dat het beter werkt als je de compiler en/of het OS betrekt in dat soort beslissingen. En weer tien jaar later bedenkt iemand dat het allemaal te complex is geworden en de CPU het maar allemaal weg moet abstreheren en zichzelf als simpele single-core moet presenteren. Dat is een beetje een cyclisch verschijnsel dat we iedere 20(?) jaar doorgaan.

[uiltje]

Ik denk dat ze dat geheel nu nog een stap verder doorzetten en stukjes van die CPU op verschillende manieren kunnen inzetten (bv een low-power configuratie, een single-threaded config met of zonder floating point, etc).. De CPU kijkt welke instructies er binnen komen en kiest een passend profiel om die instructies te verdelen over de beschikbare hardware.

Dat is een heterogene CPU met verschillende cores. Het wordt wel genoemd in het patent, maar waarschijnlijk alleen om alle mogelijkheden af te dichten. Er wordt in ieder geval niet dieper op ingegaan en we kunnen dus gerust stellen dat dit op homogene cores is getest (misschien met uitzondering van de hardware pipeline zelf want dit gaat wel degelijk ook over hardware).

[Astennu]

Ik ben hier ook wel benieuwd naar.
Met krachtige architecturen heb je ook binnen een core al het nodige parallel werk. Zo heeft een Zen4 chip bv 4x ALU en 3x AGU waar zit bij Zen5 naar 6xALU en 4xAGU is gegaan.
Bij intel zag je ook door de jaren heen dat ze steeds meer ALU's en AGU's aan de Pcores toegevoegd hebben om meer werk binnen een core te kunnen doen. Sunny Cove heeft 4 ALU's en 3 load en 3 Store AGU's. Bij GoldenCove (gebruikt voor Alder lake desktop CPU's) zijn dat 5 ALU's, 3 Load AGU's en 4 Store AGU's). De Reorderbuffer en Scheduler's moeten er dan voor zorgen dat het werk goed verdeeld wordt over de beschikbare units.

ALU = Arithmetic Logic Unit = kort gezegd doen deze de berekeningen zoals AND, OR, NOT, XOR en niet elke ALU kan perse alle types doen
AGU = Address Generation Unit = moeten uit zoeken waar de data in het geheugen is opgeslagen.

Het grote probleem door dit deels in software over meerdere cores te gaan doen is de latency. De latency binnen een core is veel lager vooral als je binnen de L0/L1/L2 cache kan blijven. Nu zijn er ook architecturen met Unified L2 (zoals IBM's Power architectuur) zo iets zou kunnen helpen om de latency lager te houden als data naar een andere unit/core moet. Maar als je dingen via software moet doen krijg je er ook weer latency bij. Dus ik vraag me af of dit pattent bij workloads die heel dynamisch zijn (bv Games) dan ook echt veel beter zal werken en of de latency penalty dan niet te veel van de winst teniet zal doen.

Voor mensen die het interessant vinden hier een architectuur info van Zen4:
https://chipsandcheese.com/p/amds-zen-4-part-1-frontend-and-execution-engine

Hier is meer van Zen5 te vinden:
https://www.guru3d.com/review/amd-zen5-a-deeper-dive-into-architecture/

En hier Golden Cove:
https://chipsandcheese.com/p/popping-the-hood-on-golden-cove

[Reactie gewijzigd door Astennu op 1 september 2025 10:56]

[Coolstart]

Natuurlijk is het altijd goed om software te optimaliseren maar het is ook vaak CPU-afhankelijk. Je ziet in de praktijk ook dat veel multi core software niet blijft schalen. En je kan als def niet zomaar single-thread workloads opdelen.

In het patent van Intel zie je dat ze inzetten op instructiemanagement (nagaan afhankelijkheden) in combinatie met super snel geheugen en inter core links zodat data razend snel nan reizen tussen de cores.

Ze gaan idd alle afhankelijkheden uitlezen en die zo optimaal mogelijk afsplitsen op verschillende cores. De instructie gaat er in en out als een single core maar in de realiteit zijn sommige instructies parallel afgewerkt en dankzij die ‘wormhole’ interconnect tussen de cores kunnen ze razendsnel de uitkomst van een instructie delen.

Je kan dus pure single-thread workloads die door devs niet op te splitsen zijn toch opsplitsen over meerdere cores door het op compiler niveau en hardware niveau te doen.

[TD-er]

Ik vermoed dat ze de penalty voor een verkeerde branch-prediction willen reduceren.

Sinds zeg maar ruwweg de Pentium-4 gebruikt Intel een stuk langere instruction pipelines.

Hiermee kunnen ze minder doen per kloktik en dus hogere klokfrequenties halen.

Nadeel is alleen wel dat de processor die pipeline "vol" moet zien te houden om nog een beetje performance te krijgen. En dus moet de processor "voorspellen" of een programma verder gaat op de ene weg of de andere bij bijvoorbeeld een "if-then-else" check.

De programmeur kan wel hints in de code stoppen zoals aangeven of iets meestal false of true is om de processor te helpen.

Deze branch prediction gaat dus alvast de code in de pipeline laden die komt na zo'n if-statement, gebaseerd op de voorspelde uitkomst van dat statement. Nadeel is dat de penalty nogal hoog is als de voorspelling fout is, want dan moet er een hoop teruggedraaid worden.

Ik vermoed dus dat Intel hier de extra cores voor gaat inzetten, om de penalty voor een verkeerde branch-prediction kleiner te maken.

[recyclebin]

Dit. Tegenwoordig om IPC te verbeteren wordt veel ingezet branch-prediction, maar bij een misprediction of cache misses moet de processor core toch nog het werk soort van overnieuw doen.

Met deze techniek denk ik dat de processoren meerdere instruction paths in parallel uitvoeren, en dat de core met het 'juiste' pad het overneemt wanneer een andere core de branch mispredict of cache misses heeft o.i.d.

[FreezeXJ]

Dat doen ze al jaren, speculative execution is standaard. Je CPU heeft best wat retirement paths naast elkaar, dus hij kan al meerdere instructies uitvoeren (tot een stuk of 10 als je em maximaal belast, en dat is zeldzaam).

Het is juist nog erger: ga je meerdere paden op verschillende cores uitvoeren dan moet je zorgen dat je registers wel allemaal tegelijk geupdate worden waar nodig, en dat is op z'n zachtst gezegd traag en tricky.

Gezien de breedte, efficiency en grootte van een moderne CPU-core (best ruim bemeten dus) denk ik dat het introduceren van extra overhead tussen cores vooral contraproductief werkt.

Als dit alleen een marketing-truc is zoals Grasmanek denkt dan snap ik het wel, en verandert dit weinig aan de realiteit. Non-news dus.

[uiltje]

Ik merk vooral dat hier gespeculeerd wordt met muizen in de hersenen. Zo moeilijk is het lezen van een patent nou ook weer niet? Maar hier wordt een complete wereld in je hoofd geschapen en daar op verder geredeneerd. Je snapt dat dit ook met hardware aanpassingen komt?

[GarBaGe]

Ik ben het absoluut met je eens.

Als ik de achterliggende artikelen lees, is het voor mij heel onduidelijk hoe Intel via software de belasting wil verdelen over de individuele cores binnen de "Super Core".

Het inherente probleem met single threaded is de afhankelijkheid van de uitkomst van de ene instructie die bepaalt welke instructie erna moet komen (IF-statements).

Heel misschien... als je 16 cores samenvoegt en je breidt branch-prediction uit naar: "voer alvast alle mogelijke uitkomsten uit op alle andere cores tegelijkertijd"....

en als je dan het juiste antwoord hebt, kunnen de 15 (van de 16 cores) die aan het verkeerde pad werken stoppen en wat anders gaan doen.

Dat klinkt super inefficient voor iets wat de software ontwikkelaars jaren geleden hadden moeten doen: namelijk fatsoenlijke multi-threaded code typen.

Het zijn vaak maar hele kleine stukjes codes die echt super efficient moeten, omdat die heel vaak herhaald worden, zoals encryptie of compressie.

[sfc1971]

Je zegt dat programmeurs het beter moeten doen, kun je zeker zeggen maar daarmee is het nog niet gedaan.

Ondertussen gooit AMD een grote cache tegen slechte game programmeurs aan met de X3D processors en heeft daarmee heel ferm de kroon van beste game CPU te pakken.

Ja het zou mooi zijn als games beter worden gecodeerd dat ze geen grote cache nodig hebben, maar ja dat is niet de realiteit.

Als dit idee van Intel werkt dan is het wel een methode om de single threaded performance krachtiger te maken zonder dat de CPU smelt door de hoge klok frequentie.

Er zijn CPU's met heel veel kernen, als je die sneller kunt maken door een aantal kernen te combineren dan zul je voor bepaalde taken een enorme stap maken, wellicht niet in efficientie maar wel in ruwe snelheid. Intel kan het wel gebruiken om weer een kroon te pakken.

[SG]

Maar dat gebeurt wel er zijn devs die hun game engine OOP tie passen en oo- is abstractie maar ook hardware en core en hardware thread abstractie het is ook p-core ecore en smt abstractie. Schedular is grote abstractie. Waar je al programmeur je software architectuur implementeerd en weet hoe afhankelijk sharde data wel of niet is. Is gemeenschappelijke L2 voor logic handig om te weten welke hardware thread gebruikt moet worden en welke gemeden. Ook dat je hardware threads de gemeenschapoelijke L3 logical en hardware prefereerd. En non shared independed data compute die ecores of dense cores en die andere L3 idieal voor zijn.

Dat meer independed en goed cache gebruik is ook mogelijk voor games door ipv OOP data oriented te programeren. In OOP is de 1st refactor stap om inheritance te mijden zeker deep inheritance en aggregation component te prefereren en dat zorgt voor minder branching bulk compute zodat icache minder getrasged wordt sequentiel data van component container wordt gestreamed en caches meer goed februik can hot data in de cache line en bext cacheline geprefetched kan worden.

Dat zijn dan de enkele games onder groepje games die niet of slecht schalen bij gebruik can veel meer L3 cache. Ook die minder last hebben van dual chiplet en memory latency.

De meer functional data oriented programmeer manier wat meer multithreaded vriendelijker is.

[laurxp]

Je kan ook een hoop met SIMD. In plaats van één 512-bit brede rekeneenheid kan je dezelfde instructie óók parallel uitvoeren op vier 128-bit brede rekeneenheden.

Branch prediction is in de praktijk niet zo'n héél groot probleem. Er is nou eenmaal niet zo veel code die bestaat uit een hoop volstrekt willekeurige branches direct achter elkaar. De meeste branch prediction is in de vorm van "is deze loop al klaar, of doen we nog een iteratie", en dat is prima te voorspellen. Misprediction is altijd al vrij duur geweest, dus er is enorm veel tijd en geld gestoken in het ontwikkelen van goede branch predictors.

[catfish]

Sommige algoritmes zijn gewoon sequentieel en kunnen niet multi-threaded gemaakt worden.
Dat ligt dus niet aan de software ontwikkelaars.

16 cores gebruiken waarbij er 1 master is en de rest alvast alle mogelijkheden uitrekenen klinkt misschien inefficiënt, maar 1 supercore met zeer hoge klokfrequentie werkt ook inefficiënt.

Ik vermoed dat ze op die manier het aantal P-cores kunnen verminderen per cpu en toch de prestaties gelijk houden en ook lager verbruik.

[BertVI]

Het lijkt me ook dat de verwachte performance winst voor die core niet 1+1=2 zal zijn maar eerder iets als 1+1= 1,5, en dan nog eens afhankelijk van de workload.

[System]

idd. Zou zomaar kunnen dat gegroepeerde cores lagere kloksnelheden kunnen halen.
En hoe dit zal lopen is maar de vraag.
Sequentiële opdrachten parallel uitvoeren lijk maar catchy

[uiltje]

Nou ja in het artikel en het patent wordt 5% overhead geclaimed. Er staat natuurlijk ook dat dit het beste resultaat is, natuurlijk is alles afhankelijk van de type load.

Kijk eerst even iets na voordat je iets de wereld in gooit. Dit soort specifieke dingen kan je zo nakijken. Of vraag het even aan een AI en laat het ding quoten (moet ie dat wel kunnen, sommige hallucineren quotes!).

[RiDo78]

Ik heb niet de hele patentaanvraag doorgelezen, maar ik zie een aantal keren de term branch-prediction tegen komen.

Branch-prediction is iets wat al jaren in CPU's wordt toegepast om te voorspellen van welke geheugenadressen iets gelezen gaat worden, zodat dat alvast in de processorcache geladen kan worden. Is de voorspelling juist? Dan is die data al snel toegankelijk en kan de CPU snel door. Zo niet, dan wordt de cache geleegd en wordt de data alsnog uit de (relatieve trage) geheugenbanken gehaald.

Ik kan me zo voorstellen dat als je meerdere cores vrij hebt, dat je méér kunt doen met de data in de cache. Je zou bijvoorbeeld al aan de slag kunnen met (een deel van) de verwerking daarvan. Dus je kunt CPU-registers instellen / instructie en data laden enz. Vervolgens kun je dat aanvullen met de data die uit de huidige bewerking komt en de berekening voortzetten op de nieuwe core. Tenminste, als de branch-prediction klopt. Zoniet, dan ga je door met de berekeningen op de 'oude' core en maak je ongedaan wat je op de 'nieuwe' core hebt ingesteld om het later nog eens te proberen.

Maar zoals gezegd, ik heb het patent niet helemaal gelezen. Dus kan er gigantisch naast zitten.

[uiltje]

Wat de meeste mensen missen is dat er hardware is toegevoegd om snel register-waarden met de core ernaast te delen. Dit staat ook niet in het artikel en is daarmee de grootste blunder. De meeste threads hier kunnen daarom zo de prullenmand in.

[RiDo78]

Of het een blunder is moet nog blijken. Het OS kiest er immers voor om de functionaliteit aan of uit te zetten. En als een super-core als één core gezien moet worden dan is het delen van de registers evident.

In tegenstelling tot hyperthreading waarbij de ‘andere core’ feitelijk niet meer is dan een extra set registers en cache, kan de super-core maar door één thread tegelijk gebruikt worden. Bij HT heb je dat meerdere threads (eventueel van meerdere VMs) tegelijk op die ene core draaien. Dan zit je inderdaad met de spectre/meltdown risico’s.

[uiltje]

Ah, klein misverstand, ik bedoel dat het een blunder is om het niet in het artikel mee te nemen. De techniek kan best interessant zijn, hoewel het de vraag is wat de effectiviteit is voor de meeste loads.

Nu denken mensen dat het direct toepasbaar is op bestaande processoren, maar dat is dus niet het geval. het vereist wel degelijk specifieke HW.

[Koetjes Reep]

Ja maar dus dat probleem wat jij omschrijft is juist wat ze oplossen denk ik. Zij schrijven de microcode waardoor hun processor volautomatisch meerdere cores samenvoegt voor applicaties die voor single Core geschreven zijn, zodat je 1.X maal tot 2/3/4/? maal de snelheid kan hebben. De software ontwikkelaar hoeft er dus juist niet over na te denken, omdat Intel het voor ze oplost, mits het goed werkt. Je zegt dan dat multithreaded beter is, maar dit gaat juist over alle gevallen die niet multithreaded zijn. Als het goed werkt, lijkt het me een goede oplossing.

[3d-pint]

Als je de load over meerdere cores kan verspreiden, worden deze vanwege het grotere oppervlak minder heet en kan je ze wellicht overclocken. Als elke core maar 1/4 van de normale load krijgt, is de snelheid van die cores waarschijnlijk flink op te schroeven, waardoor je uiteindelijke "single" thread veel sneller afgehandeld wordt. Zal geen factor 4 zijn, maar misschien wel factor 2?

[BorgMan]

Wat je nu zegt "want multithreaded is beter" is niet per sé waar. Er zijn softwarepakketten die, echt waar, nog steeds single threaded zijn. Bijvoorbeeld SketchUp (de discussie over hoe kak de huidige uitgever het aanpakt is voor een ander moment). SketchUp zou heel erg voordeel halen uit een krachtigere single-thread CPU. Als softwarematig dat geregeld kan worden, helemaal top.

[uiltje]

Vast, alleen het patent bevat ook een hardware component, het idee is dus dat het wel software-matig verdeeld wordt, maar met hardware ondersteuning. Daarom zijn het ook naastliggende CPU kernen.

[matroosoft]

3D CAD is voor zover ik weet een inherent single threaded / single core proces. Ik ken namelijk geen 1 CAD systeem wat multi-threaded is.

[knirfie244]

Als je bijvoorbeeld kijkt naar AMD z'n huidige cores (en ook diverse architecturen uit de laatste 10 jaar), dan worden er diverse resources in de pijplijn gedeeld door twee cores. Een versnelling zou daarbij zijn om de resources tijdelijk exclusief aan één core toe te wijzen.

Daarnaast heb je in huidige architecturen ook Speculative execution, hierbij probeert de processor te gokken eventuele berekeneningen gaan zijn die over een aantal klokslagen kunnen komen, en hiermee de pijplijn te vullen, mocht die processor "goed gegokt" hebben, dan staat het antwoord al klaar. Misschien dat ze dit wat extremer zullen uitvoeren bij SDC? Hoe meer voorspellingen, hoe groter de kans dat een juiste berekening al klaar staat.

[uiltje]

Jouw quote:

Daarnaast heb je in huidige architecturen ook Speculative execution

Intel's quote:

The same program is run on the separate cores of the super core, but markers in the program ensure that the cores run different portions of the program. The retirement of the program is in order which gives the appearance to an operating system, virtual machine, etc. of being a single core. All memory ordering constraints are satisfied.

Eerder wordt er aangegeven dat vorige architecturen juist dezelfde instructies uitvoeren (dezelfde instructies met andere data).

Dus dit is grotendeels net niet wat er gebeurd. Sterker nog, bij te veel branches wordt aangegeven dat het misschien beter is om weer naar 1 core te schakelen.

[Stoney3K]

Maar hoe gaan ze het werk dan verdelen? Want single threaded code impliceert juist dat alles sequentieel wordt uitgevoerd en afhankelijk van elkaar is. Het werk verdelen, over meerdere cores, kan in principe dus niet. Tenzij de processor ineens per instructie moet gaan uitzoeken of die afhankelijk is van het resultaat van een voorgaande instructie, zo nee kan dat werk ook op een andere core alvast worden gedaan. Maar dat lijkt mij dan weer zeer complex, past potentieel niet eens fatsoenlijk in de microcode, (zal wel weer leiden tot nieuwe bugs en security issues), en geeft ook een enorme berg overhead om elke keer de instructies te moeten analyseren en opsplitsen.

Er is eigenlijk geen enkele applicatie die puur singlethreaded draait. Eigenlijk lopen er altijd wel een aantal processen parallel, maar komt het vaak voor dat die op elkaars input/output staan te wachten en maakt het dus in een singlethreaded applicatie niet uit of ze na elkaar worden uitgevoerd. Dan kun je dus slim gebruik maken van analyse van de code om de gedeeltes die parallel lopen, te verhuizen naar een andere core.

Tegelijkertijd kom je in veel applicaties stukken tegen waar de code een keuze moet maken, bij een if/then/else statement bijvoorbeeld, dat noemen we een branch. Het vervelende van branches is dat je niet van te voren weet welke tak van de beslisboom er wordt genomen, dus je kan ook geen code die er op volgt preventief inladen en alvast uitvoeren, want voor elke branch heb je 2 afzonderlijke datapaden nodig.

Laat dat nu net precies zijn wat je met meerdere cores hebt - in plaats van 'branch prediction' in een single core waar je de pipeline al vult met de meest waarschijnlijke instructies (en dus te gokken welke kant van de branch wordt gekozen), kun je nu 2 of meer uitvoeringstakken al preventief uitvoeren en als die tak gekozen is, direct naar de uitkomst springen waardoor een singlethreaded programma ineens stukken sneller wordt.

Je hoeft dan niet te 'gokken' en alle instructies op te halen als je fout hebt gegokt, maar allebei de kanten van een branch worden gelijkwaardig uitgevoerd en je hebt dus altijd 'raak' gegokt. Doe je dat over meerdere cores (8 of zelfs 16 cores) dan kun je van te voren al een hele beslisboom uitvoeren en over 3 branches ineens naar het einde springen.

[Reactie gewijzigd door Stoney3K op 1 september 2025 12:53]

[uiltje]

Natuurlijk is branch-prediction een belangrijk iets en je kan er op rekenen dat dit ook een onderdeel is van de versnelling. Liever heb je natuurlijk workloads met minder (of makkelijk te voorspellen branches), maar goed. Even geteld en het woordje branch komt 202 keer voor in het patent. Best veel dus - zo veel dat ik er een studie van moet maken om je gok over het gokken te valideren

Een onderzoek met ChatGPT geeft aan dat deze techniek juist probeerd om instructies niet over twee cores te verdelen. Dus alle berichten die denken dat de CPU's dezelfde code met een andere branch berekend zijn larie. En er staat heel duidelijk in het artikel dat bij te veel branches de code weer naar een single core gaat:

[0015]
In some examples, once a thread is running in super core mode, it is monitored in case it needs to be switched back to a conventional core. This need for reversion to conventional core can happen due to various reasons such as: a) the application suffers a high amount of branch misprediction due to a program phase change or loses instruction level parallelism; ...

Deze quote is niet direct de weerlegging natuurlijk, maar het geeft goed de gedachtengang aan. En ik heb geen tijd voor een diepere analyse.

[kiang]

Tenzij de processor ineens per instructie moet gaan uitzoeken of die afhankelijk is van het resultaat van een voorgaande instructie, zo nee kan dat werk ook op een andere core alvast worden gedaan.

Dat doet de CPU nu al voor out of order execution.

[A Lurker]

Naast alle zeer goede info in reacties die ik lees over waarom SDC fundamenteel iets kan toevoegen in de hardware, is een mooi voorbeeld ook games en threads. Games zijn vaak heel erg gebaat bij een snelle core; de main code loop draait daar op. Die zijn vaak niet inherent multithreaded, danwel het is lastig om die echt multithreaded te maken.

Je kunt het als zwaktebod zien maar games zijn nu eenmaal gewoon een lijstje met vrij grote taken:
- main loop / orchestration
- input control
- sound
- physics
- misc

Sommige van deze grote taken zijn alsnog goed onder te verdelen in kleine taken, bv geluiden afspelen lijken me een goed voorbeeld, dat gebeurt 'relatief' onafhankelijk van andere geluiden (ja er is vanuit de natuurkunde interferentie, maar het gros zoals volume / spaciality van geluid kun je vrij losstaand uitrekenen). Maar anderen taken zijn dat weer niet, zoals de main gaming loop, welke allerlei afhankelijkheden heeft op de subtaken hetgeen multitrheaded lastiger toe te passen maakt of minder effectief door synchronisatie die benodigd is tussen threads. Dan is het goed dat Intel ook aan de hardware-kant aan de weg timmert.

[Reactie gewijzigd door A Lurker op 1 september 2025 16:06]

[sympa]

Dit lijkt me een soort van omgekeerde hyperthreading. Waarbij het uitgangspunt anders is, namelijk 2 delen die kunnen werken als 1, in plaats van 1 deel dat kan werken als 2.

[Henk Poley]

Efficient Computer's aankomende Electron E1 chip belooft ook bestaande software met broncode heel snel parallel te kunnen uitvoeren. Mogelijk dat Intel gewoon wat patent-prikkers in de grond wil zetten om ze lekker dwars te kunnen zitten.

YouTube: A New CPU Breakthrough Promising 100x Efficiency

Na de "dot com" beurscrash in 2001 was ook het bezitten van patenten doorslaggevend om te overleven.

[Reactie gewijzigd door Henk Poley op 1 september 2025 16:37]

[dnnns]

Volgens het patent van Intel willen ze dit fixen met een wormhole interconnect tussen cores en een shadow store buffer. Idee is dat die cores een snelweg krijgen om registers en data direct uit te wisselen zonder via cache of RAM te gaan.

Zo kun je singlethread code deels over meerdere cores laten lopen zonder dat de volgorde in de soep loopt. Slim bedacht en meer dan alleen softwaretruc. Er zit zo extra (hardware) logica achter. Maar dan denk ik ook aan de drama van Spectre en Meltdown uit 2018: dat waren ook “handige” CPU-trucs die achteraf een behoorlijk wat securitylekken opleverden.

[StackMySwitchUp]

'wormhole interconnect' is wel verzonnen door Marketing gok ik.. ik verwacht net als jij dat dit vooral weer een securityrisico wordt. Maar wellicht dat dit soort chips niet voor hypervisors bedoeld is en meer voor werkstations of misschien zelfs laptops

[dnnns]

Zeker! Uiteindelijk is bijna alles een marketingterm. Hyperthreading klinkt ook spannender dan "twee threads in dezelfde core proppen". Maar in dit geval gebruikt Intel de naam “wormhole interconnect” echt in het patent zelf. Hoe dat in hardware uitpakt is natuurlijk weer een heel ander verhaal.

[DitisKees]

Ik wordt oud Artikel uit 2006

[Vinez Initez]

Grappig dat artikel kan ik mij ook herinneren !

[ALittleTooLate]

Reverse hyper threading was ook het eerste waar ik aan moest denken. Dat was een discussie toen intel quadcore CPU's begon te maken en iedereen klaagde dat er geen software was die hier iets mee kon.

[uiltje]

Nou ja, we zitten ook min of meer in dezelfde situatie. Mijn kleine Ryzen laptopje heeft al 12 "logical threads" en mijn Intel PC van het werk heeft er 22 ofzo. Die staan grotendeels te idlen zelfs als er wel wat moet gebeuren.

Op zich is het in die zin ook logisch dat Intel Hyperthreading weg heeft gedaan. Maar het bracht in veel situaties wel 15% tot 25% meer instructies per core (!) dus dat was misschien wat prematuur - zeker als je naar benchmarks voor multi-threading gaat kijken.

[FreezeXJ]

Dat is idd AMDs gooi naar het efficienter gebruiken van je core-hardware, en gezien de performance van Bulldozer denk ik dat we rustig kunnen zeggen dat dat niet werkte.

Overigens werd er daar iets tegenovergestelds geprobeerd van wat Intel nu voorstelt, bij CMT werd de SSE/Float unit gedeeld tussen 2 aparte cores (eigen decode, branch prediction registers etc) terwijl dit patent gaat over het snoopen van state van een andere core, waardoor je meelift op wat die core al gedaan heeft, en daar extra power aan toevoegt. Of zoals Intel zelf stelt: "a second processor core to execute a second set of instruction segments of the single threaded program," meeliftend op wat de eerste core al uitgedokterd heeft.

Dat vereist dus extra hardware, want "the first processor core is to support a synchronization store instruction to store at least register data in an internal memory location that is accessible to the second processor core."

Daarnaast moet ergens een stukje logica bepalen dat dat blok code afgesplitst kan worden, dus ik voorzie nog iets meer hardware (aangenomen dat dit weggeabstraheerd wordt van je kernel) om dat in je decode bij te bouwen.

[Terr-E]

"Omgekeerde hyperthreading"
Dus in feite "hypothreading" ?

[B127]

Dit is waarschijnlijk een overblijfsel van Jim Keller z'n Royal core project. Het idee was om chips te maken die bestonden uit modules die elk als één, 2 of 4 threads konden werken. Dan had je voor single threaded taken minder threads met hogere ipc of veel threads met minder ipc voor taken die daar geschikt voor zijn.

Vergelijk het met amd z'n bulldozer of RDNA dual CU. Die delen ook sommige elementen in silicon tussen verschillende "cores". Als je dit op een slimme manier doet dan kun je voor minder silicon alsnog in de buurt komen van de prestaties van meerdere onafhankelijke cores. Het probleem is alleen dat dat niet voor elke taak even goed gaat werken. Ook zijn veel taken maar in beperkte mate schaalbaar. Zelfs blender of cinebench hebben liever een 64 core op 4ghz dan een 512 core op 1ghz.

Met cores die je dynamisch samen kan voegen en splitsen kun je dus per taak analyse maken wat het beste werkt en die oplossing toe passen.

[Osiummaster]

Welke gek bij Intel heeft Jim Keller van het project gehaald?

[xorpd]

Hier zat ik ook aan te denken. 'Zwevende' ALUs en cache clusters die je aan een core kan 'klikken'.

[youridv1]

Dit wordt niks. Als je meerdere cores samen 1 taak laat doen dan heb je in feite 100% register misses en moet je direct door naar cache

[laurxp]

Niet als je de cores op registerniveau onderling data laat uitwisselen - en laat dat nou precies zijn wat ze hier voorstellen!

Het patent stelt voor om instructies dynamisch dusdanig te herschrijven dat ze als invoer een register van een andere core kunnen gebruiken. Als core 1 klaar is met zijn instructie komt het resultaat in een mailbox, deze stuurt het direct naar core 2, en de instructie op core 2 kan er vervolgens verder mee rekenen. Maak je core-to-core transport snel genoeg, en het is net alsof het twee rekeneenheden in één core zijn.

[youridv1]

Maak je core-to-core transport snel genoeg, en het is net alsof het twee rekeneenheden in één core zijn.

Dat is dus heikelpunt 1 en geen kleine ook. AMD heeft al eens iets soortgelijks geprobeerd. Ik ben een beetje skeptisch of Intel meer succes heeft.

Als core 1 klaar is met zijn instructie komt het resultaat in een mailbox, deze stuurt het direct naar core 2, en de instructie op core 2 kan er vervolgens verder mee rekenen.

Dit is nog steeds sequentieel. Waar zit de winst hier precies? Wat is er sneller dan Core 2 laten verder rekenen dan Core 1 gewoon de volgende stap te laten doen? Ik lees vooral overhead en geen winst in deze omschrijving.
Losse berekeningen paralleliseren en multistep-pipelines zitten al ik weet niet hoe lang in de x86 implementaties van AMD en Intel.

[Reactie gewijzigd door youridv1 op 1 september 2025 12:32]

[uiltje]

Voor het aantal instructies p/s in een multi-threaded scenario gaat dit sowieso niet helpen.

Bij sommige applicaties zegt Intel 5% overhead te halen. Dat is zeer significant, maar natuurlijk wel erg applicatie specifiek.

Maar goed, op de meeste PC's zijn de meeste cores continue aan het idlen. Als je dan multi-threaded performance kan opofferen voor single threaded performance zonder de kloksnelheid en dus het verbruik te verhogen dan kan dat erg voordelig zijn. Mensen leggen best veel geld neer voor 10% extra Hz. Als je dat met zo'n truc kan bewerkstelligen...

Food for thought.

[Reactie gewijzigd door uiltje op 1 september 2025 15:03]

[FreezeXJ]

De winst zit hem in het combineren van de ALUs etc van 2 cores, waardoor je opeens een 2x zo brede core krijgt (assuming 2 cores als 1 'super core'). Dat betekent dat je nog meer tegelijk kunt doen, mits je je registerdata etc kunt delen voor en na de berekening.

[laurxp]

Het ontwerp van Bulldozer is hier compleet niet mee te vergelijken, dat waren in essentie twee gefuseerde cores die hun onafhankelijke integer clusters en L1$ hielden. Intel maakt daarintegen twee grotendeels onafhankelijke cores, die een supersnelle communicatiebus krijgen. Stop de registers aan de zijkant van de core, plak het spiegelbeeld ernaast als partner, en je hebt bijna gratis al die communicatiebus.

Moderne rekentaken hebben vaak een wat complexere data-afhankelijkheid. Zoiets als "x = max(1,2,3,4)" kan je op één core uitvoeren als:

a = max(1, 2); b = max(3,4); x = max(a,b)

, dus drie instructies achter elkaar. Gebruik twee cores en je kan het uitvoeren als

a = max(1,2); x = max(a, b)

b = max(3,4)

De eerste twee voer je parallel uit, waardoor het geheel één instructie eerder klaar is.

Maak dit 30x zo ingewikkeld om een realistisch programma te krijgen, en er zijn ineens een hoop mogelijkheden om winst te behalen.

[Aschtra]

Ik denk dat dat wel meevalt en Intel het beter weet dan jij

[youridv1]

Want dit zou de eerste keer zijn dat intel een technologie introduceert voor cpu’s waarvan de performance increase in benchmarks niet meetbaar is

[lenwar]

Dat kan ook aan de benchmarks liggen natuurlijk Benchmarks zijn tenslotte maar benchmarks en zeggen vrij weinig over de realiteit (een CPU die 2x zo snel is in een benchmark, maar niet dat de uitgevoerde taken 2x zo snel worden.)

Of dit wat gaat worden is natuurlijk even afwachten, maar eens in de zoveel komen bedrijven als Intel, IBM of AMD wel ineens met iets 'bijzonders', en dit zou dat kunnen zijn van Intel. Even afwachten. Wat ik ervan begrijp is dat het in elk geval ook hardwareondersteuning nodig heeft. Het is niet alleen een driver

[youridv1]

Een benchmark hoeft niet per se een speciale tool te zijn. Een "benchmark" kan ook slaan op het renderen, exporteren, archiveren, comprimeren of compileren van een testproject of het afdraaien van een testrun in een game. Een benchmark kan prima indicatief zijn van de echte wereld.

[lenwar]

Je hebt gelijk. Ik doelde uiteraard op statische benchmarks. Of van die vage Tweakers Praktijktests (van een RAMdisk naar een SSD schrijven of zo.) Om een één of andere reden doen ze videokaarten wel realistischer (gewoon fps in een spel meten)

Maar goed. Je opmerking is volkomen terecht. Een belangrijk detail.

[ppotter10]

Als jij dit kunt bedenken, dan neem ik aan dat Intel dat ook kan.

[youridv1]

Zullen ze ook wel gedaan hebben, maar ik ben geen gigantische processorbakker die volop ingezet heeft op “efficiency cores” die in de praktijk geen meerwaarde hebben op de desktop buiten renderen en compileren. Ik ben niet op zoek naar een manier om die dingen aantrekkelijker te maken

[kevlar01]

Ben benieuwd of dit ook helpt bij de performance van legacy software die geen multicore/ multithreading ondersteund.

[Killemov]

Dat lijkt mij DE use case. Er bestaat overigens ook software die je PER CORE afrekent.

[PolarBear]

Ach ja niets is zo flexibel als licentie voorwaarden, als dit opeens een hit blijkt te zijn worden de voorwaarden aangepast.

[uiltje]

Denk niet eens dat het nodig is. Je vraagt aan de processor hoe veel cores ie heeft en daarop zijn de licentie-voorwaarden gestoeld. Het aantal fysieke cores blijft hetzelfde, dus het antwoord en het benodigde bedrag dus ook. Misschien interessant voor gevirtualiseerde processors, maar zelfs dat betwijfel ik.

[Vulcanic]

'maar software maker. een sdc core is ook maar 1 core'

[Oon]

Dat is op basis van dit artikel wel de insteek

[uiltje]

Klopt, maar dan moet je toch even het patent induiken en dan kom je erachter dat ze in eerste instantie JIT (managed talen zoals Java / C# en natuurlijk script talen) en re-compilatie targetten, maar dat het wel kan werken zonder hercompilatie. Dus ja, kan, maar logischer voor een hercompilatie / JIT omdat er dan beter rekening gehouden kan worden met de data die geshared moet worden. Geen cijfers bekend behalve dan de 5% overhead (wat duidelijk de best-case is natuurlijk).

[Oon]

5% overhead is natuurlijk wel acceptabel als je het over 5% op '200%' hebt, dus dan zou je single-threaded workload niet 2x maar 1.9x zo snel uitkomen.

Ben benieuwd wat voor impact de rest heeft, als er geen vertaallaag tussenkomt maar alles een eigen build nodig heeft dan ben je alsnog afhankelijk van softwareleveranciers, en dat is dan weer heel jammer

[uiltje]

Nou ja, verdacht veel code draait op een JIT en hier kan je natuurlijk ook een "fat-binary" voor maken met bijvoorbeeld support in GCC. Voor de gebruiker zal veel spul zal toch min of meer auto-magisch versneld worden denk ik. Als het al gaat werken en populair wordt natuurlijk.

Merk op dat dit dus draait op HW support; dat de cores op hoger niveau bij elkaar worden gesprokkeld neemt niet weg dat er data via een tunnel met de hoofd-core wordt gedeelt.

[Reactie gewijzigd door uiltje op 1 september 2025 15:25]

[Cid Highwind]

Eindelijk een CPU geschikt voor Crysis.

[CriticalHit_NL]

Zou eerder aan WoW denken die zelfs met DX12 in de drukke gebieden nog belabberd draait, met als lapmiddel Nvidia Smooth Motion om de FPS te verdubbelen of zelfs meer, ook omdat raytracing meer vreet van de CPU en anders voor een halvering zorgt.

Met Crysis weinig last met de moderne processoren, de i9 13900K op de remastered versie liep vrijwel altijd op de 165Hz/FPS cap met 1440P op Max met DLAA.

[Cid Highwind]

Alleen zijn er nog altijd velen die het origineel verkiezen boven de op de consoles gebaseerde remaster. Je kan er zeker van zijn dat er iemand is die de originele versie in z'n benchmark meeneemt, aangezien het een iconische game is die precies is uitgekomen op het moment dat men eigenlijk dacht dat we qua single core performance grote stappen zouden maken, in plaats van dat de ontwikkelingen in een multi-core richting zouden gaan.

[CriticalHit_NL]

De benchmark die is ingebouwd is niet echt fatsoenlijk te noemen, maar ook het origineel heb ik momenteel geïnstalleerd staan en in veel gevallen is het 100-165 fps, maar het ziet er niet perse beter uit. Dx10 in x64 mode. Op de Remaster draai ik de Blackfire mod maar dat maakt niet echt uit voor de peformance en haal daar met gemak 165-250 fps.

Dus behalve kleine verschillen in de keuzes van de looks van het spel lijkt het me niet echt een goede reden aan het origineel vast te houden.

[Cid Highwind]

Dat is allemaal irrelevant. Het punt is dat je er amen op kunt zeggen dat er iemand is die met een dergelijke CPU het originele Crysis opnieuw op de pijnbank zal leggen, puur voor de fun en nostalgie onder het mom van "Can it run Crysis"

[CriticalHit_NL]

Ik denk dat het alleen nog weinig relevant is voor dat spel, want er is weinig reden de oude te gebruiken als de nieuwere er én beter uitziet én beter presteert i.v.m. de upgrade van CryEngine 2 naar een gemodificeerde versie van Cryengine 3. Lijkt me eerder een vorm van zelfkastijding wat weinig zin heeft.

Zeker gezien de oude CryEngine 2 gewoonweg zelf ook de bottleneck is en moeilijk kan omgaan met veel multi-tasken, een soort-van GTA IV'tje met de vroege RAGE Engine die domweg niet om kon gaan met veel gelijktijdige physics waardoor zowel GPU als CPU verbruik omlaag gingen in plaats van omhoog waardoor het geen goede hardware test is.

Zo had ik eens een hele zwik aan explosieve barrels in de oude CryEngine 2 sandbox gespawned, dat werd de oude engine gewoonweg teveel waardoor de helft gewoon bevroor in zijn physics.

Bij GTA IV was het dubbelop omdat DirectX9 niet genoeg drawcalls kon verwerken voor wat er op het beeld getoverd moeten worden afgezien van de RAGE engine die het niet trok, daarom krijgt de DXVK wrapper een flinke FPS-boost in dat spel.

Dus nee ik denk dat het niet relevant is, hoe leuk het ook op nostalgisch vlak lijkt, het is in dit geval eerder een "Can your engine run the game" in plaats van je hardware het spel te kunnen draaien.

[WigaDan]

Of Supreme Comander (Forged Alliance)

[uiltje]

Het wordt expliciet in het patent genoemd (legacy binaries). Maar de term geeft al aan dat het beter werkt voor nieuw gecompileerde en JIT code. Maar goed, het zal grappig zijn om te zien hoe veel het mijn stokoude Sudoku solver in Java sneller maakt (het ding werkt al in microseconden zo niet minder, maar goed). Overigens niet voor legacy hardware: "The SDC hardware component adds a small amount of hardware to each core"

[SG]

Nu is P-core een big chip gebaseerd op big high klok power sapping transistors in groot aantal stages architectuur ver boven de ideale efficiëntie vermogen klok curve sweet spot. Wat leid tot extreem kort single of few core klok boosting. En all core klok wat nogal laag uitvalt dan wat transistoren en hoge stages architectuur kan geven en ook voor die situaties een diespace waste is. En tov ARM voor laptops verre van ideaal is ivm batterij duur en throthling unpluged lagere performance.

Dit is dus een nieuw soort van ecore dat gebundeld kan worden tot big core als software matige pcore.

Waar je de lage klok idealere vermogen efficientie combineerd met core met dubbele resources van twee ecores. Hogere IPC ipv hoge kloks.

Maar dit zal uiteraard ook wat aanpassingen vereisen van windows en linux schedular.

Naast dat nextgen ecore ook ipc en klok bump krijgen door kleinere node en compact en zuinig zijn 5ghz 18A dan niet eens zo hoge klok is. Apple silicon zit met 3nm op 4,5ghz. Wat eigenlijk al een dense low klok big core is en daardoor veel meer transistoren heeft wat voor hogere ipc gebruikt kan worden.

Gezien willekeurig twee core gekoppeld kunnen worden zal de cpu en hardware thread ID ook op de schop moeten. Naast de schedular. Naast hoeveel meer context thread switch bij omschakelen kost.

[SG]

Dit zou moeten werken volgens het patent met de legacy code, maar ook in de jit compiler en native compilers. Het patent in google patent link omvat heel veel plaatjes deel er van is ook Soc en platform maar ook GPU.

Dit is zeer complexe innovatie. Net zoals met larabee en kan net zoals met IA64 Epic een brug te ver zijn.

Wat ARM doet is paar little cores en big core is little core maar dan groter waarbij al die extra veel transistoren voor Ipc verbetering. Ipv huidige x86 hoge stages voor enorme hoge klokken ver buiten het ideale efficiëntie curve.

Dit vergt groep cores die heel dicht op elkaar zitten met front end en 2 side bus waar master core een core ernaast zijn resources kan gebruiken soort van ringbus. Doet mij denken aan gpu CU workgroup. Maar dan voor cpu cores. Dit zal ook nodige samen werking met os partners vergen om die schedular aware te krijgen. Meest optimale is dus supercore aware te compileren. Dus krijg die plugin compiler van intel weer. Maar windows zou hier in ook moeten voorzien met hun compiler. En JiT compiler.

[roelofz]

Is dit niet wat VMware jaren geleden al wist te doen in virtuele machines?

[Marctraider]

Als dit zo is, zouden single thread workloads in VMWare niet mijlen sneller zijn dan op een native OS?

Klinkt vooral als 'magic'.

[roelofz]

"stapelen" van cores naar een single core is een belangrijk verschil met andere hypervisors.

Ze waren inderdaad sneller, ook een reden dat in Azure (kostbare) ESX omgevingen worden aangeboden.

Een hypervisor heeft overhead, maar hier was dat kleingeld tov de geboekte winst.

Ik ken trouwens ook omgekeerde voorbeelden, dus kan ook andersom.

[mduijvendijk]

Misschien is dit ook te gebruiken door cores te specialiceren tot bepaalde instructie sets.

Stel je hebt de situatie van de 12600K

Daarbij was de AVX512 instructieset uitgeschakeld, omdat de efficientie cores die niet ondersteunden.

Als je nu 2 kleine cores maakt, waarvan 1 de AVX512 instructieset heeft en de ander de rest. dan zou je 1 virutele core kunnen hebben die alle instructiesets onderstreund.

[DitisKees]

Klinkt als AMD's Bulldozer architectuur. In theorie een mooi idee, maar bleek in de praktijk toch flink tegen te vallen

[uiltje]

In het patent worden "heterogenous" cores wel genoemd, waarbij "heterogenous" zowel op de core architecture / performance als op de ISA kan slaan. Echter, het wordt volgens mij meer genoemd om het expliciet in de patent aanvraag te noemen dan iets anders; er wordt niet dieper op ingegaan.

Dus volgens mij is het voor Intel ook "misschien". Het maakt het werk van de scheduler er natuurlijk niet makkelijker op. Ik denk zeker dat zulke tech gaat komen, maar het kan nog wel even duren voordat hier grote stappen in worden gezet vanwege de complexiteit. Maar goed, we hebben al een tijdje gescheiden chiplets en verschillende cores met interessante cache architectures, en dat werd eerst ook vermeden.

[Rataplan_]

Dat is wel gunstig voor applicaties / OS'en die met core licenties werken :-)

[Drexz]

Toevallig weet ik dat sommige systeembeheerders specifiek hardware kopen met weinig cores, maar wel hele krachtige, zodat een Oracle licentie een stuk goedkoper uitvalt. Ik weet niet of Oracle in de toekomst dan kijkt naar je hardware of hoeveel cores de software aanspreekt.

[uiltje]

Meestal zullen die gewoon werken door de processor te identificeren. Als dat het geval is dan nee. Met misschien een kanttekening voor gevirtualiseerde omgevingen, maar goed, ik werk niet op de IT afdeling of met dit soort contracten.

[Oon]

Dat zou heel mooi zijn. Er zijn nog altijd héél veel workloads die niet goed genoeg gebruik maken van losse threads, en de focus van CPU-ontwerp ligt steeds meer op multithreading.
Als je zo'n Ryzen CPU met 16 cores om kunt zetten naar 4 cores die 4x zo snel zijn denk ik dat dat voor veel usecases voor betere performance zou zorgen.

[Hetisweergezell]

Of de threadripper met 96 cores...

[uiltje]

"The SDC hardware component adds a small amount of hardware to each core"

Dit is een hardware implementatie, het is niet voor bestaande processors. Je moet immers snel registers enzo kunnen delen. \

[SG]

Meer cores is gevolg van dieshrinks je moet iets met extra veel transistoren doen. Het is dat high performance demand games zeer slecht schalen met heel veel meer cores. En dat hier omheen de prestige strijd en chip architectuur design met klok race en singlecore performance omheen zit.

Wat slechte richting is aangezien ARM dit oplost met lage klok met bigchip.

Intel zou ipv quad ecore groep een bigcore zo groot als 4 e-cores 4x transistoren om ipc te boosten en ook plek voor AVX512. Dat is de ARM way of big. Dan verdwijned het insane klok boosten en sustained normale niet extreem throtlende all core klok.