Juhász Dávid 1/1/ Multiprocesszorok és szálszintű párhuzamosság.

Az előadások a következő témára: "Juhász Dávid 1/1/ Multiprocesszorok és szálszintű párhuzamosság."— Előadás másolata:

1 Juhász Dávid 1/1/ Multiprocesszorok és szálszintű párhuzamosság

2 Juhász Dávid 2/2/ Bevezetés ● Jövő technológiája – Költséghatékonyság – Korlátok az utasításszintű párhuzamosság teljesítményének növelésében – Lassú, de biztos fejlődés a szoftver területén ● Friss technológia – Különböző utak – Sok kudarc – Sok kérdés ● A mainstreamre koncentrálunk ( ≤ 128 processzor)

3 Juhász Dávid 3/3/ Nevezéktan ● SISD – Uniprocesszor ● SIMD – Vektor processzorok – Korai multiprocesszorok, '90-es években eltűntek ● MISD – Ilyen nincs is ● MIMD – Általános célú multiprocesszor – rugalmasság (flexibility) – Jó ár/teljesítmény arány ● (léteznek hibrid megoldások is)

4 Juhász Dávid 4/4/ Szálak és a párhuzamosság ● Szálak (thread) – Párhuzamos folyamatok megosztott névtérrel – A programozó vagy a fordítóprogram készíti ● Kétféle párhuzamosság – Szálszintű párhuzamosság – szoftver – Utasításszintű párhuzamosság – hardver

5 Juhász Dávid 5/5/ MIMD memóriaszervezés ● Centralized shared-memory architecture – Egy közös memória ● Symmetric (shared-memory) multiprocessors (SMPs) ● Uniform memory access (UMA) – Egy busz, esetleg néhány – Néhány tucat processzor ● Distributed memory – Nagy processzorszám – Szükséges: nagy sávszélességű kapcsolat – Lokális memória elérése gyors – Processzorok közötti kommunikáció lassabb, és komplexebb

6 Juhász Dávid 6/6/ Basic structure of a centralized shared-memory multiprocessor

7 Juhász Dávid 7/7/ Basic architecture of a distributed- memory multiprocessor

8 Juhász Dávid 8/8/ Elosztott memória kommunikációs modelljei ● Osztott címtér (shared address space) – Implicit kommunikáció – Elnevezések: ● Distributed shared memory (DSM) ● Nonuniform memory access (NUMA) ● Multicomputer – Explicit üzenetátadás ● Message-passing multicomputers – Akár egy cluster is lehet – Üzenetküldés ● Szinkron – legegyszerűbb ● Aszinkron – blokkolhat ha a fogadó puffere tele – Léteznek standard könyvtárak (pl. MPI)

9 Juhász Dávid 9/9/ Teljesítménymetrika ● Sávszélesség – Processzor, memória, csomópontok közti kapcsolat – Kommunikációs mechanizmus ● Késleltetés (latency) – Sender overhead + Time of flight + Transmission time + Receiver overhead – Hatékonyan ki kellene használni az időt ● Késleltetés elrejtése – Nem precízen mérhető jellemző, de nagyon jó dolog – Kommunikáció átlapolása ● Számítással ● Egyéb kommunikációval

10 Juhász Dávid 10 / Kommunikációs modellek előnyei ● Shared memory – Könnyű programozhatóság – Teljesítménykritikus részekre lehet koncentrálni – Kis overhead a hardveres támogatás miatt ● Message-passing – Egyszerűbb hardver – Explicit kommunikáció ● Költséghatékony megvalósítás – Szinkronizáció az üzenetküldésekhez kötött – Lehetséges küldő által kezdeményezni ● Egy kommunikációs modell megvalósítható olyan hardveren is, amely a másikat támogatja

11 Juhász Dávid 11 / Párhuzamos feldolgozás kihívásai ● Amdahl's Law – Korlátolt párhuzamosság ● 80-szoros gyorsulás 100 processzorral → 0,25% lehet szekvenciális ● Új algoritmusok kellenek ● Kommunikációs költségek – Főleg a késleltetés (100-1000 órajel) ● Hardver – cache-elés ● Szoftver – adatok átstrukturálása – Késleltetés csökkentése ● Prefetching ● Multithreading

12 Juhász Dávid 12 / Alkalmazási területek jellemzői ● Alkalmazástól függő teljesítménykritikus jellemzők – Terhelés-elosztás – Szinkronizáció – Memória-késleltetésre való érzékenység ● Computation/Communication ratio – Minél nagyobb, annál jobb – Több adat növeli, több processzor csökkenti ● Több processzornak adjunk több adatot ● Tipikus felhasználási területek – Kereskedelmi alkalmazások – Multiprogramming, OS – Mérnöki, tudományos alkalmazások

13 Juhász Dávid 13 / Szimmetrikus osztott memória kialakulása ● '80-as években megjelentek a cache-ek ● Processzor memória-sávszélesség igénye csökkent ● Több processzort ki tudott szolgálni egy memória – Small-scale symmetric shared memory – Költséghatékony megoldást nyújtott – Privát és osztott adatok ● Osztott adatok gyorsítótárazása – Gyorsabb elérés – Kevesebb memóriakérés – Koherencia

14 Juhász Dávid 14 / Cache koherencia ● Koherencia – mit adjon az olvasás – Aki utoljára írta, az a saját adatát olvassa – Olvasás az utoljára kiírt adatot adja, ha az igény időben megfelelően elválik az írástól – Azonos helyre történő írások sorosítottak (serialized) ● Konzisztencia – mikor látja egy processzor az új értéket

15 Juhász Dávid 15 / Koherencia kikényszerítése ● Program multiprocesszoron – Osztott adat több gyorsítótárban ● Teljesítménykritikus ● Hardveres megoldás – Migration, Replication ● Osztott adat állapotának követése – Directory based ● Megosztási állapotot központilag tárolja – Snooping ● Megosztási állapotot lokálisan tároljuk ● A közös buszt figyeli ● Mikroprocesszorokon alapuló multiprocesszoroknál népszerű

16 Juhász Dávid 16 / Snooping protocols ● Write invalidate ● Write update (write boradcast)

17 Juhász Dávid 17 / Hatékonysági különbségek ● Többszörös írás olvasás nélkül – Több update – egy invalidate ● Többszavas blokkoknál különböző szavak írása – Több update – egy invalidate ● Írás után olvasás máshol – Update esetén kis késleltetés ● Általában a busz- és memória sávszélesség a szűk keresztmetszet – Érvénytelenítő protokoll használata

18 Juhász Dávid 18 / Implementációs technikák ● Small-scale multiprocessors ● Buszt használja érvénytelenítésre – A hozzáférés szerializációja biztosítja az írásokét ● Érvényes másolat megtalálása – Write-through cache – Write-back cache ● Kevesebb memóriaigény ● Cache-tagek használata – Valid bit – Shared bit ● Busz tranzakcióknál ellenőrizni kell a jelző biteket – Interferálhat a CPU kéréseivel ● Duplikált tagek ● Többszintű cache

19 Juhász Dávid 19 / Egyszerűsített példa-protokoll

20 Juhász Dávid 20 / Szimmetrikus osztott memória teljesítménye (1) ● Változtatható faktorok – Processzorok száma – Cache-méret – Blokk-méret ● Uniprocesszorokhoz képest új a coherence miss – True és false sharing

21 Juhász Dávid 21 / Szimmetrikus osztott memória teljesítménye (2) ● Koherencia miatti forgalom – nem egyszerű eldönteni, hogy mi van jó hatással a teljesítményre.

22 Juhász Dávid 22 / Skálázható multiprocesszorok (1) ● Döntés: Foglalkozunk-e a koherenciával ● Hardveresen nem foglalkozunk a koherenciával – Egyszerű hardver ● Fókuszálhatunk a skálázható memóriára – Csak lokális adatok cache-elhetők ● Persze szoftveresen lehet, de az már nem hardver-probléma – Nem elfogadható megoldás ● Fordítók nem támogatják az implicit koherenciát – Nagy overhead, túl komplex ● Cache-elhetőség nélkül drága a blokkok elérése – DMA-szerű megoldás – Message-passing nagy üzenetmérettel ● Nincs lehetőség prefetchingre ● Távoli memóriát nagyságrendekkel nagyobb idő elérni

23 Juhász Dávid 23 / Skálázható multiprocesszorok (2) ● Cache-koherencia – Small-scale multiprocesszoroknál elvárás – Nagyobb rendszereknél kihívás ● Busz → skálázható kommunikációs hálózat ● Osztott memória – elérés skálázhatósága ● Snooping protokoll – Broadcast szükséges – drága – Központi struktúra kell → directory protocol ● Directory tárolja minden blokk állapotát – Tipikusan: blokkok száma × processzorok száma ● 200 processzorig működik, afölött skálázhatóbb megoldás kell – Csak a ténylegesen cache-elt blokkok adatai – Kevesebb bit bejegyzésenként ● Centralizáltság általában is korlát a skálázhatóságnál – Osszuk el a directory-t

24 Juhász Dávid 24 / Elosztott directory elosztott memória esetén

25 Juhász Dávid 25 / Directory-based cache coherence protocols ● Feladatok – Read miss kezelése – Osztott adat írásának kezelése ● Blokk állapotai – Uncached – Shared – Exclusive ● Shared és exclusive blokknál tudni kell kinél van ● Busz helyett kommunikációs hálózat – Üzenetorientált kommunikáció ● explicit válaszok kellenek

26 Juhász Dávid 26 / Üzenetek a koherencia biztosításához

27 Juhász Dávid 27 / Egyszerűsített directory protokoll (cache oldal)

28 Juhász Dávid 28 / Egyszerűsített directory protokoll (directory oldal)

29 Juhász Dávid 29 / Kihívást jelentő gyakorlati problémák ● Jobb optimalizáció – Nagyobb komplexitás ● Nem-atomos műveletek ● Véges pufferek – Üzenetek elvesztése miatti holtpontok

30 Juhász Dávid 30 / Elosztott közös memóriájú multiprocesszorok teljesítménye ● Faktorok a korábbiakkal azonosak ● Adat helye függ a kezdeti helytől és a megosztás állapotától ● Helyi és távoli kérések aránya a meghatározó ● Tudományos alkalmazások – Processzorok száma – változó hatás – Cache-méret – ha a távoli kérések nem kommunikáció miattiak voltak, akkor jótékony hatás – Blokk-méret – remote miss csökken, de a memóriaforgalom növekszik

31 Juhász Dávid 31 / Szinkronizáció ● Felhasználó-szintű szoftveres megoldások hardveres támogatással ● Kis multiprocesszorok, kis verseny – Megszakíthatatlan műveletek – Lehetőség atomi szekvenciák írására ● Nagyobb multiprocesszorok, nagy verseny – Szinkronizáció rontja a teljesítményt ● Eleve nagyobb késleltetés ● Verseny növeli a blokk megszerzésének idejét

32 Juhász Dávid 32 / Alapvető hardveres primitívek ● Atomic exchange – Beállít egy értéket, a régit visszaadhatja – Zároláshoz használható ● Test-and-set – Régebbi processzorokra jellemző – pl. ha 0, akkor állítsd 1-re ● Fetch-and-increment – Kiolvassa az értéket, majd 1-gyel növeli ● Read-and-update – Olvasás és írás egy atomi műveletsorozatban – A koherencia biztosítása költséges ● Amíg be nem fejeződik a műveletsorozat zárolni kell a változót

33 Juhász Dávid 33 / Alternatív read-and-update ● Load linked (load locked) és store conditional – A második művelet eredménye, hogy sikerült-e atomosan végrehajtani a műveletsorozatot – 1 – siker; 0 – egyébként ● Link regiszterben tárolja a beolvasott címet – Ha valami történik vele, akkor törli a regiszter tartalmát – A store conditional ezt a regisztert vizsgálja ● Csak regiszter-regiszter műveletet szabad beírni – Egyébként holtpont keletkezhet ● Célszerű az utasítások mennyiségét minimalizálni – Kisebb eséllyel lesz sikertelen a műveletsorozat

34 Juhász Dávid 34 / Primitívek megvalósítása LL és SC segítségével ● Atomic exchange ● Fetch-and-increment

35 Juhász Dávid 35 / Zárolás implementálása ● Cache-koherencia nélkül – Lockot a memóriában kell tartani ● Cache-eléssel – Nem kell mindig a memóriához fordulni

36 Juhász Dávid 36 / Teljesítményproblémák ● Az előző megoldások nem skálázhatók – n processzor akarja párhuzamosan a lockot, összesen n 2 +2n busz-tranzakció ● Ideális megoldás – Alacsony kommunikációs költség – Lock hatékony újrafelhasználásának biztosítása

37 Juhász Dávid 37 / Barrier szinkronizáció (1) ● A folyamatok addig várnak, amíg mind el nem éri a határt, ezután mindenki tovább mehet

38 Juhász Dávid 38 / Barrier szinkronizáció (2) ● Előző nem jó – gyors folyamat zárolja a határt, mielőtt egy lassú átlépte volna – holtpontot okoz ● Sense-reversing barrier

39 Juhász Dávid 39 / Sense-reversing barrier teljesítménye ● Biztonságos, de nem hatékony – n processzor határátlépése O(n 2 ) busz-tranzakció – Kis verseny, ritka szinkronizáció ● A szinkronizációs primitív sebessége a döntő – Nagy verseny ● A szerializáció okoz problémát

40 Juhász Dávid 40 / Large-scale multiprocesszorok szinkronizációs mechanizmusai ● Cél – Kis késleltetés versenymentes környezetben – Kevés szerializáció verseny esetén ● Szoftveres megoldások – Spin-lock – verseny csökkentése ● Exponential back-off ● Queuing lock – Barrier – az összegyűjtésnél és az átlépésnél is verseny ● Combining tree ● Hardveres megoldások – Szerializáció csökkentése verseny esetén ● Queuing lock

41 Juhász Dávid 41 / Spin-lock with exponential back-off

42 Juhász Dávid 42 / Tree-based barrier

43 Juhász Dávid 43 / Queuing lock ● Synchronization controller – Első miss-nél eltárolja a kérőt és foglalt lockot ad neki – Amikor felszabadul a lock, a soron következőnek adja ● Fel kell készülni a lock elvételére is – Környezetváltás esetén vagy ha soha többé nem ütemeződik a folyamat arra a processzorra ● A sor directory-based esetben a sharing halmazzal azonos megvalósítású lehet ● Így n processzor párhuzamos igénye esetén, csak 3n-1 busz- tranzakció, amíg mindenki megkapja

44 Juhász Dávid 44 / Barrier teljesítményének növelése ● Queuing lock használatával javul a barrier teljesítménye ● Fetch-and-increment primitív használata – n processzor átengedése 3n busz-tranzakció – Combining tree-vel még kevesebb szerializációt eredményez minden egyes node esetén

45 Juhász Dávid 45 / Konzisztencia modellek ● Cache-koherencia – memória konzisztens képe – Mennyire legyen konzisztens? – Olvasás és írás között kikényszerítendő tulajdonság ● Példa: – Írások azonnal látszódnak – csak az egyik feltétel igaz – Érvénytelenítés késleltetett – mindkét feltétel igaz lehet ● Legkézenfekvőbb a szekvenciális konzisztencia

46 Juhász Dávid 46 / Szekvenciális konzisztencia ● Bármely végrehajtás eredménye olyan, hogy – Egy processzor memóriahozzáférései sorrendje nem változik – Különböző processzorok hozzáférései tetszőlegesen összefésülődnek ● Követelmény – Egy memóriahozzáférés addig nem sikeres, amíg az összes szükséges érvénytelenítés végre nem hajtódott ● Könnyen érthető, de nem hatékony megoldás – Sok processzor vagy lassú kommunikáció ● Megoldás a teljesítmény problémára – Latency-hiding – Kevésbé szigorú konzisztencia modell

47 Juhász Dávid 47 / A programozó nézőpontja ● A szekvenciális konzisztencia egyszerű – Hasonlóan könnyen érthető modell kell ● Szinkronizált program kell – Minden közös változóhoz való hozzáférés szinkronizációs műveletek által rendezett ● Egy művelet az írás után ● Egy művelet egy másik processzor hozzáférése előtt ● Rendezettség nélkül versenyhelyzetek alakulnak ki – data-race ● Szinkronizált program – data-race-free ● Szinkronizációs könyvtárak – Hardver megvalósíthat lazább konzisztenciát is

48 Juhász Dávid 48 / Lazább konzisztencia modellek ● Írások és olvasások bármikor végrehajtódhatnak – A rendezettséget szinkronizációs műveletek biztosítják ● Három fő csoport aszerint, hogy min enyhít – W→R – store ordering, processor consistency ● Írások közti konzisztencia megmarad – W→W – partial store ordering – R→W és R→R ● Sokféle modell: pl. gyenge konzisztencia, feloldó konzisztencia ● Nagyobb teljesítmény, de komplex feladat ● Mai multiprocesszorok – Laza konzisztencia és szinkronizációs könyvtár ● Más megközelítés – Szekvenciális vagy processzor konzisztencia és a fordító optimalizálja a hozzáféréseket – nagyobb teljesítmény

49 Juhász Dávid 49 / Multithreading – Szálszintű párhuzamosság egy processzoron ● Több szál átlapolva ugyanazon funkcionális egységen ● Tárolni kell a szálak állapotát – Gyors váltás a szálak között ● Fine-grained multithreading – Utasításonként vált – round-robin, blokkolt szál kimarad – Elrejti a rövid blokkolásokat – Futásra kész szálaknak várni kell egy kicsit ● Coarse-grained multithreading – Csak költséges blokkolásnál vált – level 2 cache miss – Szálváltásnál a csővezetéket újra kell tölteni ● Hosszú blokkolásnál elhanyagolható idő az újratöltés

50 Juhász Dávid 50 / Simultaneous Multithreading ● Általános célú, dinamikusan ütemezett processzorokban TLP és ILP kihasználása ● Sok párhuzamos funkcionális egység – Egy szál nem tudja hatékonyan kihasználni ● Regiszter-átnevezés és dinamikus ütemezés – Független szálak különböző utasításai egymás mellett ● Modern szuperskalár processzorok – Virtuális regiszterek nagy halmaza – Szálanként ● átnevezési tábla ● PC ● reorder buffer a kommitáláshoz

51 Juhász Dávid 51 / Szuperskalár processzor kihasználása

52 Juhász Dávid 52 / SMT tervezési kihívásai ● Hosszú csővezeték – Durva szemcsézettség nem kifizetődő – Finom szemcsézettség csökkenti egy szál teljesítményét ● Preferred thread – Prefetch a főszálon ● Még jobb kihasználás – több preferred thread ● Gyakorlatban – 4-8 thread és 2-4 preferred thread ● Több kontextus – nagyobb regiszter fájl ● Órajel ciklusokban kis overhead ● Cache-konfliktusok ne rontsák a teljesítményt

53 Juhász Dávid 53 / Kereskedelmi megvalósítások ● 2002 – Intel Pentium 4 – Hyper-Threading Technology – 2 szál – 30% sebességnövekedés ● 2004 – IBM Power5 – Dual-, quad- vagy oct-core – Minden mag 2 szálas SMT – Szálakhoz prioritások rendelhetők – Sokkal inkább finom szemcsézettség ● 2008 – Intel Atom – Hyper-Threading-ként hirdetett – Nem támogatja az utasítások újrarendezését, regiszterek átnevezését és a spekulatív végrehajtást

54 Juhász Dávid 54 / Memóriarendszer kérdései (1) ● Osztott memóriájú rendszerek tervezésének alapja – Multiprocesszorok új problémákat vetettek fel ● Tartalmazás – Többszintű cache-hierarchia ● Csökkenti a globális kommunikációt és az elérés idejét – Tartalmazási tulajdonság (inclusion or subset property) ● Kérés és érvénytelenítés “átcsorog” ● Eltérő blokkméretek – sérülhet a tartalmazás ● Nem-blokkoló cache-ek és a késleltetés elrejtése – Cache miss átlapolva más utasításokkal ● Fontos, mert nagy a késleltetés ● Gyenge konzisztencia modellekhez szükséges ● Prefetch-eléshez nélkülözhetetlen – nonbinding

55 Juhász Dávid 55 / Memóriarendszer kérdései (2) – Implementáció nehézsége – több kintlévő üzenet ● Egyes válaszokat megfelelően kezelni ● Többszörös kérés elkerülése ● Cache miss esetén a válaszra várva újabb kérések lehetnek ● Fordítási optimalizáció és a konzisztencia modell – Konzisztencia modell → elvégezhető átalakítások – Explicit párhuzamosság esetén szinkronizáció nélkül nem változtathatók meg a hozzáférések – Implicit párhuzamosság esetén a szinkronizációs pontok ismertek, nincs ilyen probléma (pl. HPF)

56 Juhász Dávid 56 / Memóriarendszer kérdései (3) ● Spekuláció a késleltetés elrejtésére szigorú konzisztencia modell esetén – Spekulatív processzorok – dinamikus ütemezés ● Késleltetett commit ● Érvénytelenítés esetén újra végrehajtódik a művelet – Mintha az utasítások sorrendben hajtódtak volna végre

57 Juhász Dávid 57 / Virtuális memória használata ● Osztott címtér egy hálózatban ● Virtuális memória OS támogatással – Distributed/shared virtual memory (D/SVM) – Másolás read-only módban ● Hardver támogatás szükséges – Írás esetén OS trap, hasonló a directory protokollhoz ● Lapokon alapul – Nagy lapok ● False sharing vagy a lapok kihasználatlansága ● Szoftveres implementáció – Nagy overhead, rossz teljesítmény ● Lazán kapcsolt üzenetküldő rendszerhez használható ● Hardveres segítség vagy fordítók fejlődése javíthatná

58 Juhász Dávid 58 / Párhuzamos processzorok teljesítményének mérése ● Egyik legvitatottabb kérdés ● Wall-clock – CPU idő félrevezető lehet ● Programok skálázhatósága – Több processzor – Nagyobb feladat ● Nonscaled (true) speedup ● Scaled speedup – Memory-constrained scaling – Time-constrained scaling

59 Juhász Dávid 59 / SMP és DSM ● SMP – centralizált azonos elérési idejű memória – Miss rate fontos, az adatok elhelyezése nem ● DSM – nem egységes memória architektúra – Adatok elhelyezése fontos, de jobban skálázható ● Jó lenne a kettő előnyeit egyesíteni – Kompromisszumot kell hozni – Gyakorlati példa: Sun's Wildfire

60 Juhász Dávid 60 / Sun's Wildfire Prototype ● Cél: az SMP előnyei mellett skálázható megoldás ● DSM architektúra, ahol minden csomópont egy SMP – Csomópontokban 28 processzor ● Wildfire Interface (WFI) – 3 másik WFI-hez tud kapcsolódni ● Összesen 4 × 28 = 112 processzor – Egy koherens címtér a 4 csomópont között ● Cache-coherent non-uniform memory access architecture (cc-NUMA) – Egyszerű directory séma ● Akár 4-5 busz-tranzakció is szükséges

61 Juhász Dávid 61 / Wildfire architecture

62 Juhász Dávid 62 / Page replication and migration ● NUMA hatásának csökkentése – Coherent memory replication (CMR) ● Inspiráció – Cache-only memory architecture (COMA) ● Kissé bonyolult – Simple COMA (S-COMA) ● Lapszintű migráció és replikáció ● Cache-blokk szintű koherencia ● Lényegében egy csomópont használja → migráció – Lap-számláló – távoli lapra vonatkozó missek ● Több csomópont közösen használja → replikáció – Extra memória-igény – nagy node-ok esetén használható – Az eredeti és aktuális címek megfeleltetése

63 Juhász Dávid 63 / Wildfire teljesítménye ● Kis csomópontok és/vagy rossz adat elhelyezés – Igen rossz lehet az eredmény ● Túl nagy csomópontok – Leterheli a buszt ● Migráció és replikáció használata – Kezdetben mindent egy node-ra lehet tenni – Stabilitás elérése ● Migráció és migráció+replikáció azonos idő ● Pusztán replikáció sokkal gyorsabb stabilizálódás – Migráció olcsóbban implementálható ● Nem kell reverse-mapping

64 Juhász Dávid 64 / Multithreading kereskedelmi szerverekben ● Dinamikus ütemezés – pl. Pentium III ● Szálak közötti dinamikus ütemezés – IBM Pulsar ● Pulsarral szembeni követelmények – Northstar processzoron alapul – statikus ütemezés – Kis overhead – szilikon és órajel – Single-thread teljesítmény nem romolhat ● Megoldás – Pontosan 2 szál durva szemcsézettséggel ● Maximális single-thread teljesítmény ● Használható a statikusan ütemezett csővezeték – 2 példány a regisztrerekből – <10% overhead a lapkán ● Kiéheztetés megakadályozása – speciális regiszter az órajelek számlálására

65 Juhász Dávid 65 / Beágyazott multiprocesszorok ● Multiprocesszorok szerverek és asztali gépek esetén mindennaposak ● Beágyazott rendszerekben – Első – általános célú mikroprocesszorokból, high-end telekommunikációs célra – Manapság – különleges célú egyedi multiprocesszorok ● Számítógépes játékok, média feldolgozás, telekommunikáció – Processzorok közti kommunikáció egyszerű és nagyon szabályozott ● Terjedés okai – Nem kell a programok kompatibilitásával foglalkozni – Természetes párhuzamosság a feladatokban

66 Juhász Dávid 66 / Félreértések és buktatók (1) ● Multiprocesszorok teljesítményének meghatározása végrehajtási idő alapján – Relative vs. true speedup ● Párhuzamos program uniprocesszoron lassabb lehet, mint a szekvenciális program ● Lineáris gyorsulás kell a költséghatékonysághoz – A költség a processzorok számának lineáris függvénye ● Nem igaz – memória, IO – pl. 8-processzor esetén a lineáris gyorsulás már 3-szor nagyobb költséghatékonyságot eredményez – Nagy memóriaigényű alkalmazásoknál a MP-ok sokkal költséghatékonyabbak lehetnek

67 Juhász Dávid 67 / Félreértések és buktatók (2) ● A multiprocesszorok “ingyen” vannak – Modern processzorok támogatják a snooping cache-eket ● Könnyen összeállítható egy multiprocesszor architektúra ● A komponensek könnyen cserélhetők – Még kicsiben sem egyszerű összerakni ● Koherencia-vezérlő kell ● Memória elérése lassul – Komponensek cseréje inkompatibilitást okozhat a szoftverekkel ● Skálázhatóság majdnem “ingyen” van – Ha van egy multiprocesszor, akkor könnyen akárhány processzor beleépíthető (1980-as évek) – Large-scale esetben komoly kihívás ● Kommunikáció, OS támogatás kellhet, megbízhatóság romolhat – Szoftver oldalról is drága – nagy odafigyelést kíván

68 Juhász Dávid 68 / Félreértések és buktatók (3) ● A programokat nem kell a multiprocesszor architektúrákhoz igazítani – Alapvetően nagy a lemaradás a hardver mögött – Meglévő szoftverek nem képesek kezelni, vagy legalábbis kihasználni az új technológiát ● pl. laptábla egy lock-kal – hiába a sok mag, a zárolás szerializálja a végrehajtást ● Ne foglalkozzunk az adatok elhelyezésével az elosztott közös memóriájú multiprocesszoroknál – Remote miss sokat ronthat a sebességen – A verseny szintén rosszul befolyásolja a teljesítményt

69 Juhász Dávid 69 / A multiprocesszorok jelene ● Hosszú és küzdelmes múlt, de biztató jövő ● Elfogadott a multiprocesszorok költséghatékonysága ● Bizonyított nagy hatékonyságú multiprogramozott alkalmazásoknál – Tudományos, mérnöki számítások, tranzakció feldolgozás – Azért néhány helyen a clusterek költséghatékonyabbak ● On-chip multiprocessing jelentősége egyre nől – Még költséghatékonyabb irány ● Kérdések/kihívások is vannak – Nagy méretű adattároló rendszerek – Massively parallel processors (MPPs) – Hosszú távon milyen alternatívát jelentenek a nagy hatékonyságú uniprocesszorokkal szemben? ● Ma már látszik, hogy erre tart a fejlődés

70 Juhász Dávid 70 / A multiprocesszorok jövője ● Kicsiben már jól működik ● Nagy méretekben még kihívás – Költséghatékonyság növelése a cél – Teljesen egyedi multiprocesszor ● Kicsiben nem éri meg ● Egyedi programozást kíván – Közepes multiprocesszorok standard összekapcsolással ● Költséghatékonyabb ● Osztott memóriát üzenetküldésre kell cserélni – Mikroprocesszorok egyedi összekapcsolással ● Olcsó processzorok ● Kicsiben is üzenetküldés kell – Mindent bolti alkatrészekből összerakni ● Legolcsóbb ● Üzenetküldés, lassú memóriaelérés

71 Juhász Dávid 71 / A mikroprocesszorok jövője ● Lassuló fejlődés – Szilikonban rejlő korlátok elérése – Persze bármikor lehet áttörés ● Irány a nagyobb lapkán több processzor – Nagyobb teljesítmény a hardver bonyolítása nélkül – A szoftveres oldal a kihívás

72 Juhász Dávid 72 / Fejlődés és forradalom

73 Juhász Dávid 73 / Paradigmaváltások kihívásai ● Forradalmi újítások izgalmasabbak, de sokkal drágább a bevezetésük – Cache megjelenése – 5 év alatt mindenki bevezette – RISC szemlélet – több, mint 8 év volt, mire a legtöbben bevezették, de akadt aki 15 évig kitartott ● Multiprocesszorok a spektrum forradalmi oldalán állnak – A régi szoftvereket nem akarják kidobni – Átállás megkönnyítése ● Egyetlen lehetőség a teljesítmény növelésére ● Hardveres vagy szoftveres megoldás, mellyel egyszerűen át lehet lépni – legalább kis processzorszám esetén (fejlődésszerű lenne)

74 Juhász Dávid 74 / Az ördög a részletekben rejlik. Koherencia protokollok implementálása

75 Juhász Dávid 75 / Snooping coherence protocol (1) ● Write miss-t nem lehet atomian kiszolgálni – Várni kell a buszra ● A busztranzakciók atomiak – Ha már megszerezte a buszt, akkor atomi a válasz – Split-transaction busz másik probléma ● Átmeneti lépés bevezetése – Write miss és kérés kiküldése – Busz megszerzése és az új érték beírása a cache-be

76 Juhász Dávid 76 / Snooping coherence protocol (2)

77 Juhász Dávid 77 / A protokoll helyessége ● Minden cache-blokkhoz külön vezérlő ● Ekkor meggondolandó – Busz művelet és másik blokk pendingje nem interferál – Busz művelet és ugyanazon blokk pendingje nem okoz problémát ● A vezérlő jól működik és holtpontmentes ● Busz pártatlan (fairness) → kiéheztetés sincs

78 Juhász Dávid 78 / A memória viselkedése ● Memória nem tud a megosztási állapotról ● Exclusive blokkra érkezik kérés – A memóriának nem szabad válaszolni ● Shared line hozzáadása a buszhoz – Exclusive másolat esetén jelez a cache – A memória nem válaszol ● Meddig várjon a memória? – A cache-eknek idő kell az ellenőrzésre – Wired-AND ● Amikor minden cache engedi, akkor válaszol a memória

79 Juhász Dávid 79 / Split-transaction busz esetén ● Válasz felismerése – Tranzakciók azonosítása szükséges ● Versenyhelyzetek kezelése – Két kérés is kint lehet ugyanarra a blokkra ● Pl. két kizárólagos kérés egymás után, és válasz csak később – cache-ek nem blokkolják a memóriát, mert még nincs náluk a blokk – Mindkettő megkapja, és változtatja – Busz broadcast tulajdonságának kihasználása ● Minden cache figyel minden kérést – akkor küld ki egy kérést, ha nincs arra a blokkra megválaszolatlan kérés ● Minden cache a saját kéréseit jegyzi meg – ha ugyanarra a blokkra egy másik választ észlel, akkor újra küldi a kérését

80 Juhász Dávid 80 / Distributed directory protocol ● Nincs atomi tranzakció ● Atomos stílus holtponthoz vezethet – Minden blokkhoz külön vezérlő – Ugyanarra a blokkra vonatkozó kérések ütközhetnek

81 Juhász Dávid 81 / Az összekötő hálózat ● Pont-pont, sorrendben történő továbbítás – Általában igaz ● Végtelen puffer – Természetesen nem igaz – Gyakorlatban lehet felső korlátot adni a szükséges méretre – nehezen kivitelezhető ● Minden üzenet véges időn belül megérkezik

82 Juhász Dávid 82 / Végtelen pufferek ● Cache-oldal – Minden blokkhoz külön vezérlő ● Különböző blokkokat párhuzamosan ki tud szolgálni – Állapotátmenet végrehajtása, amikor megérkezett a válasz ● Közben érkező kérések egyszerűen eldobja – ez jó ● Directory-oldal – Cache-ek csak a saját kéréseikről tudnak ● Directory-nál sorosítani kell a kéréseket – Állapotátmenet csak akkor hajtódik végre, ha minden érintett cache válaszolt ● Versenyhelyzetek elkerülése ● Így az eredeti protokoll helyes

83 Juhász Dávid 83 / Véges pufferek (1) ● Üzenetek elveszhetnek → holtpont ● Holtpont – bármely jellemzőjét megtörve elkerülhető – Nincs globális rendezés az erőforrások lefoglalására ● Korábban a busz volt, most nem megoldható – Erőforrások fogvatartása, amíg egy nem-atomi művelet végrehajtódik ● Tranzakció vége előtti felszabadítás körülményes lenne – Több erőforrás szükséges a tranzakcióhoz ● Enyhítsük – szükségesek, de mindig elérhetők

84 Juhász Dávid 84 / Véges pufferek (2) ● Tranzakciót csak akkor indítjuk, ha rendelkezésre állnak a szükséges erőforrások – Külön hálózat a kérések és a válaszok számára ● Válasz – amire a vezérlő várhat az állapotátmenet végrehajtásához ● Új kérés nem akadályozhatja meg a válasz megérkezését – Minden kérés, ami válaszra vár, előre lefoglalja a helyet a válasznak – Vezérlő bármikor elutasíthat egy kérést ● Negative acknowledge (NAK) – Ha egy kérésre NAK válasz érkezik, újra kell próbálni ● Tárolhat adatot a kérésről – meg tudja ismételni ● Cache-vezérlők kérései mindig kiszolgálásra kerülnek → nem lehet holtpont

85 Juhász Dávid 85 / Directory vezérlők implementálása ● Többszörözés fizikai replikálás nélkül – Cache-oldal ● Válaszra várva a processzor áll ● Snooping protokollhoz hasonló átmeneti állapotok bevezetése – Directory-oldal ● Fetch és fetch/invalidate esetén állapot mentése és visszaállítása ● Meghatározott számú végrehajható tranzakció – Elutasítandó, amihez ennek túllépése szükséges ● Fetch/invalidate-kor visszaírás mellett válasz közvetlenül a kérelmező vezérlőnek is – Directory vezérlőben csak egy tranzakció – Gyorsabb válasz – De versenyhelyzetet okozhat

86 Juhász Dávid 86 / Felhasznált irodalom ● John L. Hennessy, David A. Patterson – Computer architecture: a quantitative approach – Multiprocesszorok és szálszintű párhuzamosság – 6. fejezet – Koherencia protokollok implementálása – I függelék