2017. december 15., péntek

ARM Big.Little

  • (p)
Írta: Abu85 | Utoljára frissítve: 2015-01-05 10:18

H​i​r​de​t​és​

Az ARM által kifejlesztett processzordizájn elsősorban a fogyasztás csökkentésére kihegyezve. A koncepció lényegében lehetővé teszi, két eltérő MPCore tömb alkalmazását egy lapkán belül, az összeköttetést pedig a CoreLink busz biztosítja.

Mint ismeretes az ARM a jövőben minden generációban kétféle processzormagot fejleszt. Ezek közül az egyik rendszert az alacsony fogyasztásra, míg a másikat a relatíve magas teljesítményre optimalizálják. Így alakulhatnak ki a Big.Little párosítások, ahol mindkét mag helyet kap a lapkában, ezzel biztosítva az energiahatékony működést és a nagy teljesítményt. Az ARM saját fejlesztésű firmware-je felméri az adott munkafolyamat igényeit, és a két beállított teljesítménystátusz közül az egyiket engedélyezi. A magas teljesítményt kínáló státusszal a több energiát igénylő, de gyorsabb, míg az alacsony fogyasztáshoz igazított beállítás aktiválásával az energiatakarékosabb kisebbik tömb dolgozik. Ez a váltás lényegében bármikor, akár egy program futtatása közben is megtörténhet, továbbá az egész teljesen automatikus, vagyis a felhasználó ebből nem érez majd semmit. Az adott munkafolyamat átadásáról a CoreLink összeköttetés gondoskodik, és a váltás hozzávetőleg 20 mikroszekundumba kerül. Ez az időtartam egyébként elsősorban a tömbökbe helyezett magok számától függ. Természetesen az ARM partnerei egyénileg módosíthatják a firmware-t, így akár az is megoldható, hogy az összes mag látszódjon, de ehhez az operációs rendszer oldaláról is szükségesek fejlesztések.

A Big.Little koncepcióval jelenleg a Cortex-A7 és a Cortex-A15 jelzésű mag párosítható, de a jövőben az érkező Cortex-A53 és Cortex-A57 is megfelel majd a célnak.

A működés szempontjából háromféle Big.Little koncepció építhető. Ezek különbségeit lentebb részletezzük:

  • Klaszter-alapú migráció: Ez a Big.Little koncepciójának alapértelmezett és legegyszerűbb megvalósítása. Két eltérő MPCore tömb kerül a lapkába, de fontos, hogy mindkét tömb ugyanannyi processzormagot tartalmazzon. A váltás nagyon egyszerűen kivitelezhető, hiszen a két tömb funkcionálisan megegyezik, csak a teljesítményük és a fogyasztásuk eltérő.
  • Magalapú migráció: Ez a megoldás annyiban különbözik az előző opciótól, hogy a MPCore tömböknek nem szükséges megegyező számú processzormagot tartalmazni. Ilyenkor lényegében négy processzormag építhető a lapkába, és az egyik tömbbe kell helyezni hármat, míg a másikba értelemszerűen egy mag kerül. Utóbbi ezzel nem is lesz tömb, de logikai szinten annak tekinti a firmware. Az opcionálisan eldönthető, hogy a nagyobbik, vagy a kisebbik processzormag árválkodik egymagában a mellé helyezett hárommagos tömb mellett, amibe értelemszerűen pont az ellentétes képességű magok kerülnek. Ez a Big.Little dizájn nem igazán kedvelt, mivel manapság általános igény, hogy egy lapkának jó teljesítménye legyen, így az igen olcsó rendszerchipek esetében is a nagyobbik processzormagokra építenek a cégek, míg a kisebb magok annyira pici kiterjedésűek, hogy abszolút indokolt többet beépíteni az adott chipbe.
  • Heterogén többmagos dizájn: Ez a Big.Little koncepció legnehezebben kivitelezhető formája. Elsősorban azért, mert a módosítani kell hozzá az alap ARM firmware-t, illetve az operációs rendszer oldalán is komoly támogatás szükséges a jó működés biztosítása érdekében. Az operációs rendszer felé logikai értelemben az összes mag látszódik, de a kernelnek tudnia kell, hogy ezek nem egyenlő képességű magok a teljesítmény és a fogyasztás szempontjából. Erre jelenleg (2013-ban) az Android és a Linux sem képes, így egységesként kezelik az összes magot, ami rendkívül kellemetlen, mivel egy nem éppen megterhelő feladathoz felesleges a többet fogyasztó gyorsabb magokat használni, illetve ennek a fordítottja is igaz, hiszen a kisebb magok teljesítménye nem biztos, hogy elegendő a komolyabb számítási teljesítményt igénylő programokhoz.

Ha pontatlanságot találsz a cikkben, kérjük, írd meg a szerzőnek!
A bejegyzés utolsó frissítésének időpontja: 2015-01-05 10:18

Hir​d​e​té​s​

Hi​rd​eté​s

Copyright © 2000-2017 PROHARDVER Informatikai Kft.