Hirdetés

A Scorpio kódnevű 36-magos CPU alapvető problémára kínál megoldást

A MIT kutatócsoportja, Li-Shiuan Peh professzor vezetésével előállt egy Scorpio kódnevű 36-magos processzorral, mely egy rendkívül lényeges problémára kínál megoldást. Mint ismeretes a processzoroknál egy ideje a többmagos koncepciók fejlesztése zajlik, de a homogén többmagos megoldások esetében a fejlődés jórészt megállt 4-10 magnál. Vannak persze ennél több maggal rendelkező lapkák is, de a nagy átlagot tekintve láthatóan a 2-8 magot tartják a cégek optimálisnak. Ez igazából nem véletlen, és nem is gazdasági oka van, hanem szimplán a mai rendszereknek van egy skálázási maximum értékük, így a magok ugyan marékszámra építhetők be a lapkába, de ezek a gyakorlatban csak részben használhatók ki.

A probléma többszintű és főleg ez az oka, amiért még senki sem állt elő valami univerzális megoldással. Többek között gondot jelent a fogyasztás, de talán még ennek kezelése messze a legegyszerűbb. Az utasításarchitektúra rugalmassága is nagyban befolyásolja a skálázhatóságot, hiszen nem mindegy, hogy ha az egyik mag kiír egy adatot a memóriába, akkor azt a következő ciklusban egy másik magnak látnia kell-e, vagy esetleg speciálisan is működhet a rendszer a belső kommunikációra vonatkozóan. Ez az egyik leglényegesebb tényező a tervezés során, hiszen az alkalmazott utasításarchitektúra memóriamodellje döntően meghatározza a skálázhatóságot. Mindemellett a cache-koherencia biztosítása is lényeges szempont, ami a központi processzoroknál, annál nehezebb lesz, minél több mag van a lapkában.

Ha a mai processzorokat nézzük, akkor a magok jellemzően egy buszra vannak felfűzve. Ez azt jelenti, hogy ha az egyik mag kommunikálni akar egy másikkal, akkor exkluzívan ki kell sajátítaniuk azt a buszt. Könnyen kitalálható, hogy a magok számának növelésével nő a kommunikációra az igény, miközben ugyanazt a buszt terhelik. Minél több mag van az adott lapkában a buszra felfűzve, annál többet fognak egymásra várni, hiszen a munkát kommunikáció nélkül nem képesek folytatni. Ebből érthető az is, hogy az Intel a Knights Corner lapkát használó Xeon Phi termékcsalád esetében miért ajánlja a programozók számára az ideális párhuzamosítás megkeresését. Bizonyos esetekben nem az a jó, ha az összes mag ki van használva, mivel a magok közötti kommunikáció könnyen lecsökkentheti a teljesítményt. A Xeon Phi esetében tehát azt a paraméterezést kell keresni, amikor a magok közötti kommunikáció még nem megy a sebesség rovására. Ez jelentheti akár 40, vagy akár csak 20 mag befoghatóságát, de jelen esetben a kommunikáció többet árt, mint használ, így az optimálisnál több mag igénybevétele csak rontja a teljesítményt.

A MIT kutatása alapján a jelenlegi hardvereknél nagyjából 10 mag az a határ, ahol még a belső kommunikáció nem megy az összesített sebesség rovására, de felette már lehet olyan algoritmusokat találni, mely inkább csak lassul több processzormag befogásával. A Scorpio processzor elsődlegesen a ma használt összeköttetéshez nyúl hozzá. A magok a koncepcióban nem egyetlen buszon vannak, hanem egyfajta lápkára tervezett hálózat biztosítja a kommunikációt (NoC, azaz Networks-on-Chip). Ilyet már korábban láthattunk különböző termékekben, de a NoC rendszerek szempontjából a magok közötti cache-koherencia megoldása nem éppen kedvező.

A két legelterjedtebb módszer a koherencia biztosítására a snoopy és a könyvtáralapú protokoll (a jelentőségükről bővebben az alábbi oldalon lehet olvasni). Mindkettőnek megvannak az előnyei, illetve a hátrányai. A snoopy tekinthető az egyszerűbb és célravezetőbb megvalósításnak, a könyvtáralapú protokoll azonban jobban skálázódik, így például nem véletlen, hogy a Knights Corner lapkát használó Xeon Phi termékcsalád az utóbbit használja. A snoopy protokoll viszont sebességben kedvezőbb bárminél, tehát ha lehetőség van rá, akkor ezt érdemes használni. A MIT a Scorpio processzort pont úgy tervezte, hogy a snoopy protokollt használja, és eközben a skálázhatóságot is biztosítsa 36 magig, vagy akár még tovább. Ez bizonyos tekintetben egy áttörés, hiszen extrém mennyiségű processzormaggal rendelkező, snoopy protokollt használó, gyakorlatban is skálázódó processzort még senki sem tett le az asztalra. Többen elméletben is lehetetlennek tartották a megvalósítást, de úgy néz ki, hogy a MIT koncepciója működik.

A Scorpio processzorban a magok közötti összeköttetés a siker kulcsa. Minden processzormagban található egy belső kommunikációért felelős NoC egység és mellette egy router. Fizikailag minden processzormag össze van kötve a másikkal, de valójában a tényleges kommunikáció során csak az a kapcsolat él, amely a tetszőleges két mag közötti összeköttetést biztosítja. Ezzel elkerülhető, hogy két mag exkluzív módon lefoglalja a teljes buszrendszert, amivel a többi magot várakozó állásba helyezi. Persze itt is előfordulhat olyan szituáció, amikor egy magnak várnia kell a kommunikációra, de ez nagyságrendekkel ritkább a manapság alkalmazott buszrendszerekhez képest. Utóbbi egyébként főleg annak köszönhető, hogy két mag többféle úton is elérheti egymást, tehát a belső kommunikációs csatornákat a teljes lapka aktuális igényeit figyelembe véve is ki lehet alakítani. Emellett a rendszer meg van spékelve egy prioritásra vonatkozó technológiával is, így ha egy processzormaggal két másik egyszerre szeretne kapcsolatot létesíteni, akkor a fontosabbik feladat élvez elsőbbséget.

A Scorpio processzor prototípusa már működik, és egy módosított Linux operációs rendszert futtat, ahol tesztelhető a rendszer skálázódása. Az eddigi adatok szerint a koncepció hozza azt, amit elvártak tőle és ez tulajdonképpen csak jót jelent, hiszen esélyt ad arra, hogy a jövőben 10 processzormagnál több is kerüljön egy-egy lapkába. Ráadásul a kutatócsoport később nyílt forrásúvá teszi a lapka leírását méghozzá Verilog nyelven.

A Scorpio processzor egyébként módosított Power utasításarchitektúrát használ, tehát nem tudni, hogy a dizájn mennyire működne jól az elterjedt utasításarchitektúrákkal. Elméletben a hatékonyság egy része átmenthető, de a gyakorlati megvalósítás mindig problémásabb.

Azóta történt

Előzmények

Hirdetés