Ezzel indul be a telefonpiacon a MIPS?

Az Imagination Technologies korábban már nyilvánvalóvá tette, hogy hatalmas terveket szövöget a 2012-ben mindössze 100 millió dollárért felvásárolt MIPS-szel és a cég tulajdonában lévő azonos nevű utasításkészlet-architektúrával. Az Imagination komoly szereplő az alacsony fogyasztású processzorokra integrált grafikus vezérlők piacán, a cégtől licencel az Apple, a Samsung és az Intel, a MIPS-szel azonban immár a CPU-k oldalán is jelentős játékossá válna a cég.

Az Imagination az ARM Holdingshoz hasonló üzleti modellt követ, processzormagokat, grafikus vezérlőket és egyéb járulékos komponenseket tervez és licencel a processzorgyártók felé, amelyek ezeket teljes implementációvá, rendszerlapkákká gyúrják össze. A MIPS azonban eddig elsősorban a beágyazott rendszerekben, kiegészítő processzoroknál volt szereplő, az új processzormaggal azonban az okostelefonok és tabletek között is helyet találhat.

Bemutatkozik a Warrior I6400

Az Imagination/MIPS kínálatában az I6400 nagyjából hasonló pozíciót foglal majd el, mint az ARM-nál a Cortex-A53, a cég egyértelműen e magok ellen is küldi csatába. A két megoldásban sok minden közös: modern, 64 bites utasításarchitektúrát használó, azonban a csúcsmodellnél olcsóbban licencelhető, annál szerényebb fogyasztású és teljesítményű processzormagokról van szó. A MIPS-nél a csúcsot a P-sorozat jelenti, ennek legutolsó tagja a P5600 (erről itt írtunk részletesen), a legalsó szintet pedig a beágyazott rendszereket célzó M-sorozat (M5100) képezi, ezek az új modellel ellentétben 32 bites regisztereket használnak.

A MIPS kínálatában mind a P-, mind az I-család a 64 bites MIPS64 utasításkészletre épül, utóbbi azonban már annak idén kiadott legfrissebb, hatodik kiadását használja. A MIPS64 release 6 jelentős frissítésnek számít, az utasításkészletből számos, ritkán használt utasítás kikerült, valamint  azok is, amelyek az Imagination GPU-kkal funkcionális átfedést mutattak (például geometriai számításokért felelős MIPS-3D ASE). Új utasítások is bekerültek, amelyek expliciten a modern feladatok futtatását támogatják (például JavaScript), ezt a Chrome V8 motorjának MIPS-portja már ki is használja.

Az I6400 (a Cortex-A53-hoz hasonlóan) két utasítás széles, in-order típusú processzor, vagyis a beérkezett utasításokat azok sorrendjében hajtja végre. A megközelítés előnye, hogy nincs komplex és nagy fogyasztású átrendező-motorra szükség, a hátránya viszont az out-of-order lapkákhoz képest alacsonyabb teljesítmény. Az eredeti Intel Atom processzorok például in-order végrehajtást alkalmaztak, a (fogyasztásban drágább) out-of-order csak 2013-ban, a Bay Trail platformmal jelent meg.

^{A titokzatos versenytárs a Cortex-A53 lenne.}

Az in-order használata az I6400-ban logikus döntés, az energiahatékonyságra és apró méretre kihegyezett lapkánál a kompromisszum érthető. Az I6400 pedig tényleg apró, az Imagination hivatalos adatai szerint mindössze 1 négyzetmilliméter szilíciumot foglal a TSMC 28 nanométeres HPM eljárásán (ezzel összemérhető a Cortex-A53 nagysága is). Az I6400-ban az Imagination egy 9 fokozatú futószalagot implementált, szemben a Cortex-A53 8 (integer) illetve 10 (lebegőpontos) fokozatú futószalagjával. Ez azt jelenti, hogy hasonló feladatok alatt a MIPS megoldása valamivel magasabb órajelet érhet el, ahogy az egyes fokozatok komplexitása valamivel alacsonyabb.

Sokkal érdekesebb újdonság, hogy az I6400-ban az Imagination egy teljes SMT (szimultán multi-threading) rendszert implementált, ez az Intel szótárából Hyper-Threading néven lehet ismerős. Az SMT lehetővé teszi, hogy a mag egyszerre több szálat futtasson, ezzel némileg csökkentve az in-order felépítés hátrányait (épp ezért támogatta az SMT-t az eredeti Intel Atom is), az Imagination adatai szerint az SMT a méretet 10 százalékkal növeli, a végrehajtás azonban 30-50 százalékkal gyorsul egyes esetekben. Egy I6400 mag az SMT-vel egyszerre maximum négy threaden dolgozhat, amelyet a két párhuzamos futószalag és a hardveres ütemező döntései alapján hajt végre. Az SMT pontos implementációjáról a magot licencelő processzorgyártó dönthet, így 1 és 4 között tetszőlegesen választhat, az egy fizikai mag ennek megfelelő számú logikai magként jelenik meg az operációs rendszer számára.

^{Az Imagination által elképzelt ideális rendszerlapka.}

Az új, "középkategóriás" MIPS-mag 1-6 magos konfigurációban köthető össze, az elsőszintű gyorsítótár mérete választható (mind az adat, mind az utasításcache lehet 32 vagy 64 kilobájt, tervezett felhasználástól függően). A cache-koherenciáért egy központi címtár (directory) felel, amely figyeli az elsőszintű gyorsítótárak írásait. Ha egy mag olyan címre ír, ami egy másik magnál gyorsítótárazva van, akkor a központi egység kéri az utóbbinál az adat érvénytelenítését (az inkonzisztencia elkerülése végett).

Ez a megoldás lényegesen egyszerűbb implementációt ígér mint a többi mag cache-hozzáféréseit folyamatosan monitorozó snooping, amely négymagos felépítésnél 3x3 mag-mag kapcsolatot igényel, 6 magnál pedig 5x5 kapcsolatra van szükség - a központi címtárral azonban négyzetes skálázódás helyett lineáris van, minden mag egy címtárhoz kapcsolódik. A megoldás hátránya nyilván a viszonylagos lassúság, ahogy a pont-pont kapcsolat helyett közvetett irányítás lép. A másodszintű gyorsítótár egyébként fél megabájttól 8 megabájtig terjedhet, ez jól mutatja, hogy az Imagination nagyon széles skálájú számítási feladatokra kínálja a magot - konzumer termékektől hálózati eszközökig.

Konzumer eszközökhöz is?

Kevéssé ismert tény, de az Android régóta fut MIPS processzorokon. Az Android a 4.0-s kiadással vette fel a hivatalosan támogatott architektúrák listájára a MIPS és az x86 processzorokat, a piacon meg is jelentek az ARM-os gépek mellett az Intel processzoros és MIPS-es eszközök is (például az indiai Karbonn Mobiles terméke, a Smart Tab 1). Az Android L újdonsága a 64 bites architektúrák támogatása lesz, amely egyszerre jelenti az ARMv8-at, az AMD64-et (x64) és a MIPS64-et is - így az új I6400 képességeit is maximálisan ki tudja használni.

Az Androidon jellemzően kétféle alkalmazás futtatható: a Javában írt, Android SDK-t használó appok, amelyek működéséért a Dalvik futtatókörnyezet (illetve Android L-től az ART) felel. Ezek az appok minden olyan hardverplatformon elfutnak, amelyeket a Dalvik támogat, a hardverspecifikus gépi kódot ugyanis ez a köztesréteg állítja elő. A másik csoportban a natív kódot futtató alkalmazások (jellemzően játékok) találhatóak, ezen C/C++-ban íródnak, fordításuk-optimalizálásuk pedig a fejlesztő dolga.

A Gitlab mint DevSecOps platform (x) Gyere el Radovan Baćović (Gitlab, Data Engineer) előadására a november 7-i DevOps Natives meetupon.

Az első csoportban tartozó appok tehát minden további lépés nélkül futtathatóak MIPS-es hardveren is, a fejlesztőnek csupán annyi dolga van, hogy ne zárja ki a támogatott eszközök közül ezeket. A második csoport jóval nagyobb problémát okoz a nem-ARM platformok számára, ezt az Intel például egy saját fejlesztésű, az Android részévé tehető fordítóréteggel hidalta át. A MIPS elterjedéséhez is szükség lehet egy ilyen, kompatibilitást a teljesítmény rovására is biztosító szoftverrétegre - egyelőre azonban ilyennel az Imagination nem állt még elő.

Ne feledkezzünk el azért a Microsoftról sem, a szoftvercég ugyan egyelőre nem támogatja a MIPS utasításarchitektúrát, a WinRT felépítése révén azonban ugyanúgy képes köztesréteget biztosítani a hardver és az alkalmazás között, mint az Android, így elvben nem kizárt, hogy a Windows-ökoszisztémában is meg tud kapaszkodni a MIPS - persze csak ha a Microsoft portolja magát az operációs rendszert.