Multiprocesszorok és szálszintű párhzamosság · Kommunikációs modellek előnyei Shared memory – Könnyű programozhatóság – Teljesítménykritikus részekre lehet koncentrálni

Juhász Dávid 1/86

Multiprocesszorok ésszálszintű párhuzamosság

Juhász Dávid 2/86

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)

Juhász Dávid 3/86

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)

Juhász Dávid 4/86

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

Juhász Dávid 5/86

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

Juhász Dávid 6/86

Basic structure of a centralized shared-memory multiprocessor

Juhász Dávid 7/86

Basic architecture of a distributed-memory multiprocessor

Juhász Dávid 8/86

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)

Juhász Dávid 9/86

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

Juhász Dávid 10/86

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


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


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


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


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


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ű


Snooping protocols

●Write invalidate

● Write update (write boradcast)


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


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


Egyszerűsített példa-protokoll


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


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.

Processzorok száma cache-méret blokk-méret

Kereskedelmi Növeli a true sharinget

Uniprocesszoros hibákat csökkenti

Növeli a false sharinget

OS -Capacity miss

csökkenJó hatással van a

teljesítményre

Tudományos Változó hatás Cache missek csökkenése

Általában jó, de növeli a false sharinget


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


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


Elosztott directory elosztott memória esetén


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


Üzenetek a koherencia biztosításához


Egyszerűsített directory protokoll(cache oldal)


Egyszerűsített directory protokoll(directory oldal)


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


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


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


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


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


Primitívek megvalósításaLL és SC segítségével

●Atomic exchange

● Fetch-and-increment


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


Teljesítményproblémák

●Az előző megoldások nem skálázhatók– n processzor akarja párhuzamosan a lockot,

összesen n2+2n busz-tranzakció●Ideális megoldás

– Alacsony kommunikációs költség– Lock hatékony újrafelhasználásának biztosítása


Barrier szinkronizáció (1)

●A folyamatok addig várnak, amíg mind el nem éri a határt, ezután mindenki tovább mehet


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


Sense-reversing barrier teljesítménye

●Biztonságos, de nem hatékony– n processzor határátlépése O(n2) 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


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


Spin-lock with exponential back-off


Tree-based barrier


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


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


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


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


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


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


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


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


Szuperskalár processzor kihasználása


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


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


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


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)


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


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á


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


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


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


Wildfire architecture


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


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


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


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


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


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


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


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


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


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


Fejlődés és forradalom


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)


Az ördög a részletekben rejlik.

Koherencia protokollok implementálása


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


Snooping coherence protocol (2)


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


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


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


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


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


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


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


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


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


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

Documents

Multiprocesszorok és szálszintű párhzamosság · Kommunikációs modellek előnyei Shared memory – Könnyű programozhatóság – Teljesítménykritikus részekre lehet koncentrálni