0xDEADBEEF

[RSS]
««« »»»

EDGE, TRIPS a hon za vyšším ILP

26. 7. 2018

Tiskem pro­le­těla zpráva, že Micro­soft por­to­val Win­dows a Linux na vlastní ex­pe­ri­men­tální CPU ar­chi­tek­turu E2. Pro­četl jsem pár pu­b­li­kací o ar­chi­tek­tuře a na pohled vypadá za­jí­mavě. Tedy aspoň z tech­nic­kého po­hledu je am­bi­ci­ózní, jestli povede k re­ál­nému pro­duktu, si ne­trou­fám od­ha­do­vat.

To nej­lepší na za­čá­tek: Micro­soft se roz­hodl vy­tvo­řit da­ta­flow stroj. I když ne tak úplně, jde o ome­zený da­ta­flow v tech­nic­kém žar­gonu ozna­čo­vaný EDGEEx­pli­cit data graph execu­tion.

Článek An Eva­luation of the TRIPS Com­pu­ter System po­skytne de­taily o pr­votní EDGE ar­chi­tek­tuře TRIPS, vy­ví­jené v aka­de­mic­kém pro­středí. Její autoři se sna­žili do­sáh­nout vy­so­kého ILP (in­strukční pa­ra­le­lis­mus) v malém a úspor­ném pro­ce­soru a mít všechny výhody out-of-order bez kře­mí­kové a ener­ge­tické režie OoO.

CPU pro­vádí bloky až 128 in­strukcí bez skoků (kom­pi­lá­tor se je snaží na­hra­dit pre­di­kací). Blok com­mitne ato­micky jako celek a uvnitř se chová jako da­ta­flow. In­strukce ne­za­pi­sují vý­sledky do re­gis­trů, ale přímo je smě­řují zá­vis­lým in­struk­cím. Pokud je blok do­sta­tečně velký, může ob­sa­ho­vat velké množ­ství in­strukč­ního pa­ra­le­lismu (TRIPS jádro má 16 ALU) a díky jeho ex­pli­citní da­ta­flow povaze je pro­vá­děn jako na OoO jádře. Zá­vis­losti mezi in­struk­cemi nemusí za běhu ana­ly­zo­vat pro­ce­sor, ale jsou iden­ti­fi­ko­vány už v pro­ce­soru.

Pro před­stavu to může vy­pa­dat nějak takhle (hy­po­te­tický pseu­do­kód):

i1: READ R1 i3     // přečte z globálního registru a data nasměruje instrukci i3
i2: READ R2 i3 i4  // to samé, ale pošle je instrukcím i3 a i4 najednou
i3: ADD i4         // až obdrží data, sečte je a výsledek pošle instrukci i4

Toto uspo­řá­dání řeší pro­blémy, kte­rými trpěly obecné da­ta­flow ar­chi­tek­tury. Ale jako ob­vykle kom­pli­ko­vané vět­vení kódu se ne­ka­ma­rádí s ILP, pro­tože vede k malým blokům in­strukcí.

Paper Dy­na­mic Vec­to­ri­zation in the E2 Dy­na­mic Mul­ti­core Ar­chi­tecture před­sta­vuje další pokrok již pod tak­tov­kou Micro­softu. Jde o první ná­střel z roku 2010, ale přesto uka­zuje ně­ko­lik za­jí­ma­vých ino­vací, jako na­pří­klad dy­na­mické spo­jo­vání ně­ko­lika fy­zic­kých jader do jed­noho lo­gic­kého. Jedno fy­zické jádro v gangu pro­vádí ne­spe­ku­la­tivní kód a ty ostatní jsou po­u­žité pro spe­ku­lace. Po spo­jení jader tak vznikne agre­sivní su­per­ska­lární OoO CPU. To dodá pro­ce­soru fle­xi­bi­litu – na jedné straně v něm může běžet mnoho malých jader na druhé ně­ko­lik málo velice moc­ných jader pro jed­no­vlák­nové pro­gramy.

Další chu­ťov­kou je vek­to­rový mód, kte­rého je do­sa­ženo kom­bi­nací všech ska­lár­ních ALU v jádře. Ne­po­tře­buje tedy novou sadu re­gis­trů nebo nové funkční jed­notky, ale po­u­žívá všechny exis­tu­jící hard­wa­rové pro­středky.

Všechno tohle EDGE ší­len­ství je honem za stále ILP – TRIPS měl 16 ALU a vý­zkum­níci do­spěli k závěru, že ide­ální stroj s ne­ko­neč­ným množ­stvím funkč­ních jed­no­tek a masiv­ním in­strukč­ním blokem by do­ká­zal pro­vá­dět de­sítky až stovky in­strukcí každý takt. Jeden z pro­to­typů E2 měl údajně mít 32 ALU.

Za ILP se dříve hnalo Ita­nium a všichni víme jak to s tímto dítkem Intelu a HP do­padlo. O po­dobný kousek se snaží i ar­chi­tek­tura Mill, ale jde cestou kom­pletně sta­tic­kého VLIW. His­to­rie nedává příliš op­ti­mismu, že by to mohlo vyjít.

Jedním z mnoha pro­blémů Itania byl fakt, že po­tře­bo­valo po­kro­čilý kom­pi­lá­tor, který by do­ká­zal ohnout kód tak, aby sedl na masivně pa­ra­lelní spe­ku­la­tivní pre­di­ko­vané srdce čipu. Stejně to budou po­tře­bo­val EDGE (a Mill) pro­ce­sory. Pokud ne­bu­dou k dis­po­zici, můžou skon­čit jako pro­dukty s ne­vy­u­ži­tým po­ten­ci­á­lem.

Ale také nemusí, když končí moorův zákon, efek­ti­vita, i když v po­rov­nání s ex­po­nen­ci­ál­ními zisky mi­nu­losti jen mar­gi­nální, může hrát znač­nou roli.


K tématu:

píše k47 (@kaja47, k47)