Xlera8

Spekuláció a szimulációhoz. Innováció a hitelesítésben

Ez egy érdekes ötlet, amely hardverrel támogatott spekulatív párhuzamosságot használ a szimuláció felgyorsítására, egyedi hardvert igénylő csavarral. Paul Cunningham (Senior VP/GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, vállalkozó, korábbi Synopsys CTO, most Silvaco CTO) és én folytatjuk kutatási ötletekkel foglalkozó sorozatunkat. Mint mindig, szívesen fogadjuk a visszajelzéseket.

Spekuláció a szimulációhoz

Az innováció

E havi választás az Chronos: Hatékony spekulatív párhuzamosság gyorsítók számára. A szerzők a 2020-as programozási nyelvek és operációs rendszerek építészeti támogatásáról szóló konferencián mutatták be a tanulmányt, és az MIT-től származnak.

A párhuzamosság többmagos processzorokkal történő kihasználása az egyik lehetőség azon alkalmazások számára, ahol a párhuzamosság magától értetődő. Más algoritmusok nem feltétlenül particionálhatók olyan könnyen, de előnyös lehet a belső párhuzamosságot kihasználó spekulatív végrehajtás. Általában a spekulatív végrehajtás a gyorsítótár koherenciáján múlik, ami nagy többletköltséget jelent, különösen a szimulációnál. Ez a módszer megkerüli a koherencia szükségességét, és fizikailag lokalizálja a feladatvégrehajtást a csempék kiszámításához a cél olvasási-írási objektum alapján, biztosítva, hogy a konfliktusészlelés lokálisan észlelhető legyen, globális koherencia-kezelés nélkül. A feladatok párhuzamosan, spekulatív módon is végrehajthatók; minden észlelt ütközés kibontható a feladatból a gyermekfeladatokon keresztül, majd újra végrehajtható anélkül, hogy más szálakat el kellene állítani.

Még egy megjegyzés itt. Ez a módszer támogatja a késleltetés alapú szimulációt, ellentétben a legtöbb hardveres gyorsítási technikával.

Pál nézete

Hú, milyen csodálatos, magas oktánszámú papír az MIT-től! Amikor a párhuzamos számításokról kérdeznek, azonnal a szálakra, mutexekre és a memóriakoherenciára gondolok. Természetesen így tervezték a modern többmagos CPU-kat. De nem ez az egyetlen módja a hardver párhuzamosításának.

Ez a cikk egy alternatív, Chronos nevű párhuzamosítási architektúrát javasol, amely a feladatok rendezett során alapul. Futás közben a feladatok időbélyegző sorrendben hajtódnak végre, és minden feladat új részfeladatokat hozhat létre, amelyek dinamikusan hozzáadódnak a sorhoz. A végrehajtás néhány kezdeti feladat sorba helyezésével kezdődik, és akkor ér véget, amikor már nincs több feladat a sorban.

A sorban lévő feladatok párhuzamosan több feldolgozó elemre (PE) vannak kigazdálkodva – ami azt jelenti, hogy a Chronos spekulatív módon hajtja végre a jövőbeli feladatokat, mielőtt az aktuális feladat befejeződött volna. Ha az aktuális feladat érvénytelenít bármely spekulatívan végrehajtott jövőbeli feladatot, akkor a jövőbeni feladatok műveletei „visszavonódnak”, és újra sorba kerülnek. Ennek a koncepciónak a hardverben történő helyes megvalósítása nem könnyű, de a külső felhasználó számára gyönyörű: csak kódolni kell az algoritmust, mintha a feladatsor egyetlen PE-n sorosan futna. Nem kell mutexet kódolnia, és nem kell aggódnia a holtpont miatt.

A szerzők a Chronos-t a SystemVerilogban implementálják, és FPGA-ra fordítják. A cikk nagy része annak elmagyarázására irányul, hogyan valósították meg a feladatsort és a hardverben a maximális hatékonyság érdekében szükséges kibontást. A Chronos négy algoritmuson alapul, amelyek jól illeszkednek a feladatsor-alapú architektúrához. Mindegyik algoritmus kétféleképpen valósítható meg: először egy dedikált, algoritmus-specifikus PE-vel, másodszor pedig egy kész, nyílt forráskódú, 32 bites beágyazott RISC-V CPU-val PE-ként. A Chronos teljesítményét ezután összehasonlítják az Intel Xeon szerveren futó algoritmusok többszálú szoftveres implementációival, amelyek árcédulája hasonló a Chronoshoz használt FPGA-hoz. Az eredmények lenyűgözőek – a Chronos 3-15-ször jobban skálázható, mint a Xeon szerver használata. A 3. táblázat és a 14. ábra összehasonlítása azonban egy kicsit aggodalomra ad okot, hogy ezeknek az előnyöknek a többsége az algoritmus-specifikus PE-kből származott, nem pedig magából a Chronos architektúrából.

Mivel ez egy ellenőrző blog, természetesen ráközelítettem a kapuszintű szimulációs benchmarkra. Az EDA iparága jelentős összegeket fektetett be a logikai szimulációk párhuzamosításába, és nehéznek bizonyult néhány konkrét felhasználási eseten túlmenően nagy nyereséget elérni. Ez főként annak köszönhető, hogy a legtöbb valós szimuláció teljesítményét az L3-gyorsítótárból hiányzó betöltési/tárolási utasítások uralják, és a DRAM-ra mennek ki. Ebben a cikkben csak egy teszteset szerepel benchmarkként, és ez egy apró, 32 bites átviteli mentési összeadó. Ha olvassa ezt a blogot, és szeretne alaposabb benchmarkingot végezni, kérem, tudassa velem – ha a Chronos valóban jól skálázható a valós szimulációkon, annak óriási kereskedelmi értéke lenne!

Raúl nézete

Ennek a tanulmánynak a fő hozzájárulása az Térben elhelyezett rendezett feladatok (SLOT) végrehajtási modell amely hatékony a párhuzamosságot és a spekulációt kihasználó hardvergyorsítóknál, valamint azoknál az alkalmazásoknál, amelyek futás közben dinamikusan generálnak feladatokat. A dinamikus párhuzamosság támogatása elkerülhetetlen a szimulációhoz, és a spekulatív szinkronizálás vonzó lehetőség, de a koherencia túl magas.

A SLOT elkerüli a koherencia szükségességét azáltal, hogy korlátozza az egyes feladatok egyetlen objektumon történő működését (írását), és támogatja a rendezett feladatokat a több objektum atomossága érdekében. A SLOT alkalmazások rendezett, dinamikusan létrehozott feladatok, amelyeket időbélyeg és objektumazonosító jellemez. Az időbélyegek rendelési megkötéseket határoznak meg; Az objektumazonosítók meghatározzák az adatfüggőségeket, azaz a feladatok akkor és csak akkor adatfüggőek, ha azonos objektumazonosítóval rendelkeznek. (Ha van olvasási függőség, a feladat spekulatívan végrehajtható). Az ütközésészlelés helyivé válik (bonyolult nyomkövetési struktúrák nélkül), ha az objektumazonosítókat magokhoz vagy csempékhez rendeli, és minden egyes feladatot oda küld, ahol az objektumazonosító le van képezve.

A Chronos rendszert az AWS FPGA keretrendszerben valósítottuk meg 16 csempével, egyenként 4 alkalmazásspecifikus feldolgozó elemmel (PE), 125 MHz-en. Ezt a rendszert egy 20 magos/40 szálas, 2.4 GHz-es Intel Xeon E5-2676v3-ból álló alapvonalhoz hasonlítják, amelyet kifejezetten azért választottak, mert az ára összehasonlítható az FPGA-val (kb. 2 USD/óra). Ha egyetlen feladatot futtat egyetlen PE-n, a Chronos 2.45-ször gyorsabb, mint az alapvonal. Az egyidejű feladatok számának növekedésével a Chronos megvalósítás 44.9-szeres önrelatív sebességre skálázódik 8 csempén, ami 15.3-szoros gyorsulásnak felel meg a CPU-megvalósításhoz képest. Összehasonlították továbbá az általános célú RISC-V-n alapuló megvalósítást, nem pedig az alkalmazás-specifikus PE-ken; A PE-k ötször gyorsabbak voltak, mint a RISC-V.

Lenyűgözőnek találtam a cikket, mert mindent lefed a koncepciótól a SLOT végrehajtási modell meghatározásán át a hardver megvalósításáig és a hagyományos Xeon CPU-val való részletes összehasonlításig 4 alkalmazáshoz. Az erőfeszítés jelentős, a Chronos több mint 20,000 5.4 SystemVerilog-sorral rendelkezik. Az eredmény 4-szeres átlagos gyorsulás (a XNUMX alkalmazásból) a szoftverrel párhuzamos verziókhoz képest, a nagyobb párhuzamosság és a spekulatív végrehajtás gyakoribb használata miatt. A dolgozatot a nem szimulációs feladatokra való alkalmazáshoz is érdemes elolvasni; a cikk három példát tartalmaz.

Oszd meg ezt a bejegyzést ezen keresztül:

Beszélj velünk

Szia! Miben segíthetek?