ARM DynamIQ volgt big.Little op voor configuratie processorkernen in socs

De Britse processorarchitectuurmaker ARM heeft DynamIQ gepresenteerd, een techniek die big.Little moet opvolgen voor de configuratie van processorkernen in socs. Het maakt meer clusters mogelijk en kernen op basis van meerdere microarchitecturen in hetzelfde cluster.

Het lijkt erop dat het met DynamIQ mogelijk moet zijn om bijvoorbeeld Cortex A73-processorkernen te combineren met A53-kernen in hetzelfde cluster, iets dat nu nog niet kan. De kernen in hetzelfde cluster kunnen verschillen in kloksnelheid en wat ze vragen van de accu. Bovendien kunnen er nu acht processorkernen in een cluster zitten en kan een soc een oneindig aantal clusters hebben.

Daarnaast bevat DynamIQ technieken om een betere accuduur mogelijk te maken, bijvoorbeeld door processorkernen sneller te laten schakelen tussen een hoge en lage kloksnelheid. Ook is er fijnmaziger controle mogelijk over de kloksnelheid. Volgens ARM is dat belangrijk bij toepassingen in virtual reality, waarbij de framerates gelijk moeten blijven terwijl ook de hitte-ontwikkeling onder controle moet zijn.

ARM richt DynamIQ op toepassingen als virtual reality, kunstmatige intelligentie en zelfrijdende auto's, maar de techniek is ook bruikbaar in traditionelere toepassingen als smartphones en tablets. ARM zegt dat socs op basis van DynamIQ dit jaar beschikbaar kunnen zijn. Huidige socs werken nog met een big.Little-lay-out, een techniek die ARM in 2011 presenteerde.

Reacties (10)

[MrHankey]

Maaruh, wat is het dan precies? Een design guideline, een nieuwe controller, een andere datapipe?

[Squee]

Maaruh, wat is het dan precies?

Dat is eigenlijk een vraag waar ik ook mee zat. En ik moet zeggen, na het bronartikel gelezen te hebben vol met marketing-blaat, was ik nog steeds niet heel erg veel wijzer Laat ik eens een poging wagen...

Mijn indruk is dat het een nieuwe platform specificatie is. Deze specificatie lijkt een bepaalde versie van de ARM instructie set te vereisen (ze hebben het over een uitbreiding met instructies voor kunstmatige intelligentie en machine learning), maar lijkt ook een bepaalde interconnect/topologie tussen de processoren te definieeren. Zo te zien hebben ze nu een volledig cache-coherent cluster van tot 8 CPU cores, terwijl in big.LITTLE dit in twee clusters was verdeeld (de low power "LITTLE" en high performance "big" clusters). Dat lijkt mij op een iets verder gaande integratie dan big.LITTLE gaf; je hebt nu een enkel cluster waar je verschillende CPU core typen met verschillende power/performance eigenschappen in kan hangen en makkelijk taken van de ene naar de andere kan migreren gebaseerd op het scenario (qua power/performance eisen) waar in je je bevindt. Het geeft werkelijk een heterogeen cluster, maar tegelijkertijd lijkt het ook zo gespecificeerd te worden dat het in feite een superset is van de big.LITTLE specificatie.

Wat is hier het voordeel van? Ik denk dat het migreren van taken tussen twee verschillende type cores in een cluster sneller zal verlopen (en dus ook energie-zuiniger) dan van het ene naar het andere cluster gaan in big.LITTLE. Dit omdat elk big.LITTLE cluster zijn eigen gedeelde L2 cache heeft, en je dus eerst via je coherence protocol de informatie uit de andere L2 cache naar jouw cluster gaat halen. Bij een werkelijk heterogeen cluster wat dit lijkt te zijn, staat het allemaal al in de lokale gedeelde L2 cache, en heb je deze migratie kosten niet.

[Reactie gewijzigd door Squee op 1 augustus 2024 21:42]

[Belgar]

Het is inderdaad een superset met meer flexibiliteit:

- In de eerste multi-core setup moesten alle cores hetzelfde zijn
- In de originele Big-Little mocht je twee soorten cpu's in een cluster hebben, maar moest je ook kiezen welk deel van je cluster actief was. Je werkt dus op "big" of "little", niet big+little.
- Latere Big.Little geeft toegang tot "big" + "little" samen via een software laag

In de nieuwe architectuur kun je willekeurig 8 CPU's hebben EN ze ook benutten in elke combinatie en frequentie. Bovendien heb je de optie om hardware scheduling te doen in het cluster en zodoende ook meerdere power states te creëren (big.medium.little?). Je kunt een "big" core op veel lagere frequentie inzetten als een tijdelijke little core, of een little core tijdelijk "overclocken" voor meer performance.

Hoeveel van dit alles ook werkelijk gebruikt gaat worden in designs is natuurlijk zeer de vraag. Het hebben van een homogene oplossing die flexibel ingezet kan worden en "oneindig" uitgebreid kan worden is natuurlijk een mooie ondergrond voor verdere ontwikkeling, maar ik verwacht geen radicale nieuwe designs.

Het wordt echter wel mogelijk om een custom cluster te maken die voor iedere taak precies een cpu krijgt met de juiste mogelijkheden voor die taak. Bijvoorbeeld een router chip met een "encryptie core" voor VPN versnelling, een "hashing core" voor NAT versnelling en 1/2 cores voor algemene processing. Dergelijke oplossing moet echter ook op software niveau dan ondersteund worden en daar zal veelal de schoen wringen.

[rjberg]

Ligt eraan hoe goed je een scheduler kan maken. Als een chip zelf specialistische taken kan toewijzen, hoef je in theorie niet bijzonder te programmeren.

Als dat echter niet gebeurt, krijg je een systeem waarbij je met behulp van drivers verschilllende cores kan aansturen met speciale instructies. Hetzelfde gebeurd al bij gpu's, waar je opengl gebruikt om via een driver een gpu aan te sturen.

[Belgar]

Hardware kan niet altijd een taak herkennen, tenzij je speciale instructies gebruikt die de pipeline kan herkennen. Maar dan heb je uiteindelijk hetzelfde probleem, je moet speciale instructies uitsturen die je in software moet verwerken. Voor embedded toepassingen kun je dan beter direct de kernel aansturen om gebruik te maken van de juiste cores (extra driver laag is dan niet nodig).

Dat is, vermoed ik, ook de reden dat specifiek AI en automotive als doelgroepen worden genoemd. Gebieden waar genoeg kennis en investering is om van geoptimaliseerde clusters gebruik te maken.

In mijn router voorbeeld is het veelal simpelweg veel goedkoper om er meer cores tegen aan te gooien dan een custom chip met kernel te schrijven voor een thuisproduct. Voor een professioneel ontwerp ga je dan sneller naar een CPU en FPGA design ipv een custom ARM core.

Er zijn vast niche oplossingen die baat hebben bij dit nieuwe design, maar ik denk dat voor het gros van de toepassingen alleen een paar procent extra power savings alles zal zijn wat je terugziet van de extra flexibiliteit.

[kidde]

Inderdaad, simpeler gezegd was het eerst niet mogelijk in je taak te wisselen van een 'snelle energieverslindende octacore-cluster' naar 1 enkele zuinige core als de berekening klaar was. Kan nu wel. Sommige fabrikanten, volgens mij Mediatek als 1e, hadden zelf al oplossingen buiten big.Little om gemaakt omdat het tekort schoot, bijv. NVidia Tegra (1 dacht ik) had delen op twee verschillende TSMC processen, 1 zuinige kern en 4 snelle, dus ook voor hun was big.Little 'te simpel'.

Het protocol waar op gehint wordt in verband met accelerator en de marketing blaat lijkt mee gewoon CCIX, hieraan kan bijv. een Xilinx FPGA, Mellanox netwerk accelerator, TI DSP of AMD GPU cache coherent verbonden worden. CCIX lijkt sterk op ARM's CCI500 geïnspireerd.

Zie ccixconsortium.org
Ed: Kan ook CCI550 zijn, maar die lijkt me meer specifiek voor ARM alleen, en bovendien zou dat denk ik een minder grote verbetering zijn, ik hoop echt eindelijk CCIX, naar voor de volledigheid 'het beste wat ARM nu heeft: http://www.tiriasresearch...link-cci-550-and-dmc-500/

De scheduler waar veel het hier over hebben zit vziw gewoon standaard in de Linux kernel, lijkt me dat dit onder Linaro-vlag geregeld wordt, oa EAS project: https://www.linaro.org/bl...e-scheduling-eas-project/. Dus dat kernel stukje wordt vast uitgebreid. Zie o.a. hier voor de originele big.Little Linux scheduler: https://www.linaro.org/bl...g-little-software-update/

[Reactie gewijzigd door kidde op 1 augustus 2024 21:42]

[rjberg]

Vraag me af hoe dit gaat werken met scheduling. Je moet namelijk taken specifiek aan cores toewijzen om voordeel te hebben, maar als dat ertoe leidt dat de ene core op de andere moet wachten is het weer trager.

Ook vraag ik me af of deze technologie ook in amd64(x86_64) terecht zal komen. Het zou indrukwekkend zijn om meerdere soorten cores door elkaar te gebruiken zonder dat de programmeur extra moeite moet doen om geschikte software te schrijven. Dat de chip dus in realtime instructies toewijst aan de beste cores die beschikbaar zijn in het systeem. Of zelfs cores met verschillende frequenties.

Ik vraag me af of gpu-cores dan ook op deze manier universeel zullen worden benaderd. Geen opengl of opencl, maar gewoon instructies waarvoor de cpu zelf de beste strategie en verdeling kiest.

[Little Penguin]

Ook vraag ik me af of deze technologie ook in amd64(x86_64) terecht zal komen. Het zou indrukwekkend zijn om meerdere soorten cores door elkaar te gebruiken zonder dat de programmeur extra moeite moet doen om geschikte software te schrijven.

Zoals de cores dezelfde instructieset gebruiken zou dit geen enkel probleem moeten zijn. Volgens mij is het idee van HyperThreading (wat Intel ooit gebruikt heeft) al enigszins te vergelijken met dit idee (maar was er geen sprake van cores die exact dezelfde instructieset aan konden)

Bij big.LITTLE, en naar ik aanneem DynamicIQ, kunnen de cores wel exact dezelfde instructieset aan alleen is de implementatie in de CPU anders.

Ik vraag me af of gpu-cores dan ook op deze manier universeel zullen worden benaderd. Geen opengl of opencl, maar gewoon instructies waarvoor de cpu zelf de beste strategie en verdeling kiest.

Het probleem van GPU's is dat deze een totaal andere architectuur hebben dan een x86/x64- of een ARM-processor. De kans dat dit ooit gaat werken is zo goed als nhil...

[rjberg]

Ik bedoelde niet in één keer, maar als opstapje naar nieuwe technologieën voor universeel gebruik van specialistische cores. Ik hoorde dat amd al aardig goed tussen verschillende processoren op hetzelfde moederbord kan samenwerken. Dan is dit nog wel een forse stap, maar nog steeds mogelijk.

[R3dRacer]

Zie het als de Cortex A53 die samenwerkt met de Cortex A57 in de Snapdragon 820. Die koppeling tussen deze 2 processoren wordt dan mogelijk gemaakt met de A53 en de A73