Mentegetőzések. Hatékony CPU kód. írásához hasznos architekturális háttér, hogy miért is lassú a kódom. Valasek Gábor

Átírás

1 Mentegetőzések Hatékony CPU kód írásához hasznos architekturális háttér, hogy miért is lassú a kódom Valasek Gábor

2 Tartalom Pipeline-ing, szuperskalár architektúra A programunk a memóriában Cache-ek: I cache és D cache Néhány probléma (stalling, branch prediction, load-hit-store)

3 Tartalom Pipeline-ing, szuperskalár architektúra A programunk a memóriában Cache-ek: I cache és D cache Néhány probléma (stalling, branch prediction, load-hit-store)

4 Pipeline architektúrák

5 Pipeline architektúrák Két fontos statisztikájuk van: Latency: egy utasítás végrehajtásához szükséges teljes idő. Bandwidth vagy throughput: egységnyi idő alatt hány utasítást tud feldolgozni a rendszer. Ez a leglassabb komponenstől függ.

6 Szuperskalár architektúrák

7 Szuperskalár architektúrák A pipeline egyes fázisait megvalósító egységeknek több, redundáns példánya is van Ezáltal egyszerre több utasítás is végrehajtható párhuzamosan Például az Intel processzorok pipeline-os és szuperskalár architektúrák Érdeklődőknek további anyagok:

8 Hatékony kód régen és most Amíg az órajelek relatív alacsonyak voltak, megérte minimalizálni a számítások számát Ez ma már megfordult: a mantra az, hogy inkább végezz több munkát a CPU-val és csak akkor nyúlj a memóriához, ha feltétlenül szükséges Ennek oka az elérési idők módosulása (forrás: d_with_point_and_storageclass_memory/ )

9 Elérési idők

10 Elérési idők

11 Irodalom Egy nagyon hasznos bejegyzés erről a témáról:

12 Tartalom Pipeline-ing, szuperskalár architektúra A programunk a memóriában Cache-ek: I cache és D cache Néhány probléma (stalling, branch prediction, load-hit-store)

13 Program a memóriában A végrehajtható fájl lehet egy.ee (Windows) vagy.elf (eecutable and linking format - Uni) A lefordított és összelinkelt végrehajtható fájl tartalmazza a program eecutable image-ét Ez egy részleges képe annak, ahogyan a program memóriában ki fog nézni a dinamikus memóriafoglalásokat értelemszerűen nem tartalmazza Az image 4 szegmensből áll

14 Eecution image Code/tet segment Data segment BSS segment Read-only data segment

15 Eecution image Végrehajtható gépikód A kódban inicializált globális illetve statikus változók Inicializálatlan globális és statikus változók Csak olvasható adatok Az értékük a specifikáció szerint adott (=0), de csak a program belépési pontjának meghívása előtt nullázódik ki. Egyes esetekben (ún. manifest constant-oknál) a kódba fordul bele a konstans értéke. Ilyen pl. az int konstans.

16 Eecution image A BSS megnevezés történelmi hagyaték: a block started by symbol rövidítése A manifest konstansok trükkösek: mivel a compiler az értéküket belehelyettesíti a kódba, ezért az ő tárolásuk valójában a kódszegmensben történik

17 Endian Az egy bájtnál nagyobb foglalású változók esetén jön képbe Kétféle verziója van: Little endian: a kisebb helyiértéket reprezentáló bájtok a memória elejéhez vannak közelebb Big endian: a legnagyobb helyiérték bájtja van a kisebb memóriacímen Fontos, hogy min fejlesztünk és mire fejlesztünk: Intel processzorok: little endian-ok Wii, Xbo 360, PlayStation 3 (vagyis PowerPC hajtotta konzolok): big endian-ok

18 Program végrehajtása A belépési pont elindításával kezdődik (pl. main() ) A futtatás megkezdésekor az OS lefoglal egy memóriaterületet az alkalmazásnak, amit program stack-nek hívnak Minden egyes függvényhíváskor erre a stack-re push-olnak egy összefüggő (=folytonos) memóriafoglalást, amit stack frame-nek hívnak

19 Stack frame Háromféle adatot tárolunk itt: A függvényünket hívó függvény memóriacímét, hogy a visszatérésünk után folytatódhasson a program futtatása A CPU regisztereinek értékeit a hívás pillanatában. Visszatéréskor ezeket az értékeket visszaírjuk a regiszterekbe. A függvény visszatérési értéke viszont általában egy speciális regiszterbe kerül, amit értelemszerűen nem állítunk vissza A függvény lokális változói is itt kerülnek foglalásra. (Meg néha regiszterekbe kerülnek, de ezt most nem részletezzük)

20 Példa void c() { U32 localc1;... } F32 b() { F32 localb1; I32 localb2;... c(); return localb1; } void a() { U32 alocalsa1[5];... F32 locala2 = b();... }

21

22

23

24 Változók helye a memóriában A globális és a statikus változók a futtatható fájlban vannak A lokális változók a stack-re kerülnek A dinamikus változók azonban a heap-re A probléma ezzel az, hogy az OS-től függ a foglalás Ezért váratlanul sokat állhat a programunk, amíg a new vissza nem tér (...legalábbis 4 new a 6-ból (<C++17)/8-ból(>=C++17)..)

25 Tartalom Pipeline-ing, szuperskalár architektúra A programunk a memóriában Cache-ek: I cache és D cache Néhány probléma (stalling, branch prediction, load-hit-store)

26 Cache A CPU által írható és olvasható memóriadarab, aminek kialakításánál a cél a minél kisebb késleltetés Ezt kétféleképpen érik el: A lehető leggyorsabb memóriatechnológiát használják hozzájuk A cache-ek fizikailag is közelebb vannak a CPU-hoz A cache lényegében a globális memóriában lévő változóknak egy (CPU szempontjából) lokális másolata Méghozzá azoké, amiket gyakran lekérdez a program Így ha épp cache-ben van, akkor nem kell elzarándokolni a RAM-ig (ez a cache hit) Ha nem volt a cache-ben (cache miss), elmegyünk a RAM-ig, visszahozzuk az adatot de egyúttal beírjuk a cache-be is (hátha legközelebb is kell)

27 Cache line Amikor egy új memóriádarabot érünk el cache miss miatt, nem csak az általunk kért adatok jönnek vissza, hanem egy cache line-nyi darab i7-es archiektúrákon a L1, L2, L3 cache line-ok 64 byte-osak Így ha a programunk következő utasítása az előzőleg lekért memória utáni memóriát olvasná, akkor garantált () cache hit-ünk van A cache-ek asszociatív memóriák: tudják, hogy melyik RAM-beli valódi memóriaterület van bennük (ehhez használják a translation lookaside buffer-t, azaz a TLB-t)

28 Cache

29 Cache - írási policy Amikor a programunk egy változó értékét módosítja, akkor azt vissza kell juttatni a memóriába is Ez a CPU architektúra write policy-jétől függ, hogy miképp történik Az írások bekerülnek a cache-be, aztán A write-through cache-ek az írásokat rögtön továbbítják a memóriába is A write-back policy-k pedig csak bizonyos esetekben (pl. cache miss) írnak vissza

30 Többszintű cache Probléma, hogy kisméretű cache A nagyméretű viszont Nagyon gyors De sok cache miss-t generál Fizikailag nem tud olyan közel kerülni a CPU-hoz De cserébe több cache hit lesz Ezért csinálnak többszintű cache-eket, egyre nagyobb méretben

31 Cache-ek többmagos környezetben

32 Cache-ek többmagos környezetben Többmagos környezetben előjön a cache konzisztencia problémája Vagyis hogy minden mag lokális cache-e a fizikai memóriában található valódi értéket tükrözze Két elterjedt protokoll erre a MESI (modified, eclusive, shared, invalid) és a MOESI (modified, owned, eclusive, shared, invalid):

33 A kétféle cache Instruction cache: a programunk kódját cache-eli. Elágazásokkal ezt tudjuk tönkrevágni, ezért van szükség branch prediction-re stb. Data cache: a programunk adatait cache-eli A fenti kettő független egymástól

34 D-cache-re optimalizálás Az adatainkat a memóriában folytonosan tároljuk, a lehető legkisebb méretben és szekvenciálisan dolgozzuk fel őket

35 I-cache-re optimalizálás A teljesítmény-kritikus ciklusok a lehető legrövidebbek legyenek kódméret szempontjából Ne hívjunk belőlük függvényeket Ha mégis kell és kicsi a függvény, akkor inline-oljuk Ha nem kicsi és csak igazi függvényhívással érhető el, ekkor érjük el, hogy a memóriában a függvény gépi kódja a ciklushoz a lehető legközelebb legyen

36 I-cache-re optimalizálás Az utóbbi nagyon nehéz, mert a linker és a compiler dönti el, hogy fizikailag hová kerül az eecutable image-ben a függvény törzse Viszont van néhány rule-of-thumb amit általában be szoktak tartani: Egy függvény kódja a memóriában szinte mindig folytonos, azaz a linker nem szúr bele más kódot a függvénybe (kivéve ha az a más kód egy inline-olt függvény hívása) A függvények a fordítási egységük forráskódjában (.cpp) található sorrendjüknek megfelelően kerülnek a memóriába Vagyis egyetlen fordítási egység függvényei a memóriában folytonosan helyezkednek el (általában)

37 Tartalom Pipeline-ing, szuperskalár architektúra A programunk a memóriában Cache-ek: I cache és D cache Néhány probléma (stalling, branch prediction, load-hit-store)

38 Stalling Előfordulhat, hogy egy utasítás végrehajtása csak akkor kezdődhet meg, hogy ha egy előtte lévő utasítás teljesen végigment a pipeline-on Ekkor a függő utasítás beakasztja a pipeline-t - ez a stalling

39 Stalling - adatfüggőség miatt

40 Stalling A fenti példában az add utasításnak be kellett várni a mul befejeződését Az ilyenek elkerülése érdekében a compilerek megpróbálják automatikusan átrendezni az utasításaink sorrendjét, hogy a függés miatt várakozó utasítás helyett független utasítások futhassanak

41 Branch prediction Amikor a végrehajtás elágazáshoz ér, akkor a pipeline-nak döntenie kell, hogy az then vagy az else ág kódját kezdi végrehajtani Ha rosszul tippelt, akkor a pipeline-t flush-olni kell (az eddigi műveleteket érvényteleníteni) és újratölteni a helyes elágazási irány kódjával A legegyszerűbb (statikus) stratégia a CPU részéről hogy a backward branch-et tekinti valószínűbbnek (azaz azt az ágát az elágazásnak, aminek a gépi kód memóriacíme kisebb, mint az aktuális cím - ilyen például az az eset, amikor a ciklusunk még folytatja a futását) Következmény: if-nél, többfelé ágazó if-nél, switch-case-nél először a leggyakoribb eseteket rakjátok

42 Stalling + branching megoldások + O(e) => meltdown

43 Load-Hit-Store A probléma lényege, hogy egy változóba történő írás után közvetlenül próbáljuk újra olvasni a változó értékét A klasszikus példa: az oris-en stallol: stfs fr3,0(r3) ;Store the float lwz r9,0(r3) ;Read it back into an integer register oris r9,r9,08000 ;Force to negative

44 Load-Hit-Store int CauseLHS( int ptra ) { Nem lehetett ptra értékét regiszterben/cache-ben tartani, mert nem tudja a compiler, hogy nem módosította-e a ptra területét egy másik pointer a függvényben, ami ugyanoda mutat! int a,b; } int ptrb = ptra; // B and A point to the same direction ptra = 5; // Write data to address prta b = ptrb; // Read that data back again (won't be available for 40/80 cycles) a = b + 10;// Stall! The data b isn't available yet

45 Load-Hit-Store int slow( int a, int b) { a = 5; b = 7; return a + b;// Stall! The compiler doesn't know whether // a==b, so it has to reload both // before the add }

46 Irodalom és javasolt néznivalók Jason Gregory: Game Engine Architecture (az ábrák forrása is ez) Kitekintésnek C++ HPC workshop: uropdmdomhb6lzcwl

47 Polinomok kiértékelése Forrás: A probléma: hogyan lehet kiértékelni egy polinomot hatékonyan? Most: a sin() hatványsoros közelítését, elvágva az ^15-edikenes tagnál

48 Polinomok kiértékelése static static static static static static static static double double double double double double double double a0 a1 a2 a3 a4 a5 a6 a7 = = = = = = = = +1.0; e-1; e-3; e-4; e-6; e-8; e-10; e-13; double sin1(double ) { return a0 + a1 + a2 + a3 + a4 + a5 + a6 + a7 } 64 szorzás + 7 összeadás ;

49 Polinomok kiértékelése double sin2(double { double ret, y =, 2 = ret = a0 y; ret += a1 y; ret += a2 y; ret += a3 y; ret += a4 y; ret += a5 y; ret += a6 y; ret += a7 y; return ret; } ) y y y y y y y ; = = = = = = = 2; 2; 2; 2; 2; 2; 2; 16 szorzás + 7 összeadás

50 Polinomok kiértékelése double sin3(double ) // Horner { double 2 = ; return (a0 + 2 (a1 + 2 (a2 + 2 (a3 + 2 (a4 + 2 (a5 + 2 (a6 + 2 a7))))))); } 9 szorzás + 7 összeadás

51 Mérések Intel Core i7-2620m CPU at 2.70GHz. The functions were compiled using -O3 -ffast-math: function nanoseconds per call sin sin sin sin

52 Polinomok kiértékelése double sin3(double ) // Horner { double 2 = ; return (a0 + 2 (a1 + 2 (a2 + 2 (a3 + 2 (a4 + 2 (a5 + 2 (a6 + 2 a7))))))); }

53 Polinomok kiértékelése double sin2(double { double ret, y =, 2 = ret = a0 y; ret += a1 y; ret += a2 y; ret += a3 y; ret += a4 y; ret += a5 y; ret += a6 y; ret += a7 y; return ret; } ) y y y y y y y ; = = = = = = = 2; 2; 2; 2; 2; 2; 2;

54 Polinomok kiértékelése Kézzel optimalizálni: function sin sin1 sin2 sin3 sin4 sin5 sin6 sin7 nanoseconds per call Persze nem árt a compiler flag-ekkel is kicsit foglalkozni (csak -O3): function nanoseconds per call sin sin sin sin sin De akár használhatsz irodalmat is: Estrin séma sin sin sin