[bogdan]

mar hogy ne lett volna szo parhuzamositasrol? vegig arrol van szo! (a "vektorprocesszor" cimszot megtalalod barmely parhuzamos architekturaval foglalkozo konyvben pl..)

es elkepzelni boven el tudom, sot, meg irtam is: a hangsuly a "sokszor" szon volt! es vigyazz a multitask-al, mert a tobbiek neked fognak ugrani, hogy dehat ahhoz meg sokkal tobb memoria szukseges, es lesz benne nemi igazsag..

[dezz]

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 10:48

mar hogy ne lett volna szo parhuzamositasrol? vegig arrol van szo! (a "vektorprocesszor" cimszot megtalalod barmely parhuzamos architekturaval foglalkozo konyvben pl..)

Azért a SIMD feldolgozás általi (adat-)párhuzamosítás nem teljesen ugyanaz, mint a több mag általi párhuzamosítás. Ha eltérõ szálakról is van szó, akkor meg egyátalán nem. Bár már vannak compilerek, amik a megfelelõen elõkészített kódot SIMD-es kóddá tudják fordítani, ez sokszor nem ilyen egyszerû, és kézzel kell csinálni. Ezzel szemben több skalárisra írt kód több magos párhuzamos futtatása jóval egyszerûbb, még ha nem is a leghatékonyabb.

Idézet

es elkepzelni boven el tudom, sot, meg irtam is: a hangsuly a "sokszor" szon volt! es vigyazz a multitask-al, mert a tobbiek neked fognak ugrani, hogy dehat ahhoz meg sokkal tobb memoria szukseges, es lesz benne nemi igazsag..

Nem multitaskingra gondoltam, hanem multithreadingre, tehát nem arra, hogy 6-7-8 különféle applikáció fut egy idõben, pl. a PS3-on, hanem az egy applikáción belüli különféle feladatok magok közötti szétosztásáról. Vagy ne feledkezzünk meg arról az esetrõl, hogy egy feladat más-más fázisai is futhatnak az egyes magokon. (Feltételezem, a memóriát a main ramra értetted, és nem az LS-ekre - utóbbi egy másik téma lehetne.)

Elõzõbõl:

Idézet

a tobbiek allitasa ezzel szemben valami olyasmi, hogy HA nem tudunk parhuzamositani, akkor megette a fene az SPE-ket, akar vektorosan, akar nem vektorosan hasznalnank oket..

Ez hol is szerepelt így? Nekem úgy tûnt, végig arról volt szó, mennyire lehet az egyes SPE-ken skalárisan dolgozni, és ennek mi értelme van. Hogy a többi éppen mit csinál, az egy másik dolog.

[bogdan]

nem tudom idezni explicite, hogy hol szerepelt, ez az en osszefoglalom, es fenntartom a tevedes lehetoseget.

multitask vagy multithread szinte ugyanaz, ha a memoriaigenyt nezem. es igen, a fo memoriarol beszelek. a problema meg ugyanugy fennall! (egyebkent meg nem multithread, ha aplikacion belul nezed, mert az gyakrabban tobb processzre oszlik, es inkabb multiprocessz. multithredhez nem szerencses tobb processzort hasznalni!)

(es persze, hogy mas a kulonfele parhuzamositas, de ettol meg parhuzamositasi kerdes.)

[special]

bogdan, nem kevered itt a dolgokat?

az utasításszintû párhuzamosság (ILP, több utasítás egyidejû végrehajtása egy szálon belül, avagy effektíve non-stalled IPC) a szálszintû párhuzamossággal (TLP, több utasításszál futása egymás mellett, multi-threading), valamint a vektorizált végrehajtást (egy utasítás elvégzése egyszerre több adaton).

mi itt és most a vektorizálásról beszéltünk, mely esetében adatszinten beszélhetünk párhuzamosságról. viszont ezt nem szoktuk így hívni, inkább simdization, vektorizáció. ez releváns igazán egy SPE szempontjából, másodsorban az ILP, mivel az SPE 2-issue emlékeim szerint, de ez meg inkább a compiler feladata, érzésem szerint.

[bogdan]

nem hinnem, hogy kevernem. igen, ismerem a parhuzamositas kulonfele modozatait (kapnek is a fejemre d n.r-tol ha azt irnam, hogy nem!). es tudom, hogy mas megkozelites kell hozza programozastechnikailag.

mindazonaltal en ugy erzem, hogy az elsodleges kerdes inkabb a parhuzamosithatosag, az, hogy azt mivel is oldjuk meg sokszor inkabb masodrendu kerdes. azaz egy problemat vagy lehet parhuzamositani, vagy nem. hogy ezt a parhuzamositast mikeppen oldja meg az ember, az gyakran mellekes (bar nem trivialis) kerdes.

hogy ezt a compiler vagy a assembly programozo oldja meg, arrol nem irtam. elvi velemenyt probaltam adni: valami vagy parhuzamosithato elvben, vagy nem, ha nem, akkor teljesen mindegy, hogy az SPE vektorprocesszor-e, vagy sem. ha igen, akkor gyakran ki tudjuk hasznalni a vektorfunkciokat is.

[dezz]

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 12:08

multitask vagy multithread szinte ugyanaz, ha a memoriaigenyt nezem. es igen, a fo memoriarol beszelek. a problema meg ugyanugy fennall!

A multithread ugyanazon az adathalmon is dolgozhat, egymás között felosztva, vagy fázisokban (és az applikáció egyéb adatai is csak egyszer szerepelnek), miközben multitaskban a taskok jellemzõen a sajátjukkal foglalkoznak.

Idézet

(egyebkent meg nem multithread, ha aplikacion belul nezed, mert az gyakrabban tobb processzre oszlik, es inkabb multiprocessz. multithredhez nem szerencses tobb processzort hasznalni!)

Attól függ. Általánosságban egy applikáción belül lehet több thread is és több processz is.

Óvatosan kell bánni a thread fogalmával, mert 2 némileg eltérõ értelemben is használatos. HW-es megközelítésben, mint pl. SMT: itt átlalánosságban "a végrehajtás több szála"-ról van szó, ami állhat több taskból, processzbõl és processzen belüli al-szálból, azaz "thread"-bõl, ill. ezek keverékébõl. Újabb OS-eknél a "thread" egy bizonyos meghatározott struktúra, egy processz korlátozott képességû al-szála, ami az anya-process erõforrásait használja, és amit a newthread(), vagy hasonló függvény indíthat.

Nos, jelen esetben, és értelemszerûen SW-es oldalról megközelítve, valószínûleg igazad van, és a multiprocessing a helyes fogalom. (Bár ki tudja, hogy nem nevezik-e itt a Cellnél az SPE-ken futtatott kódokat mégis al-threadeknek.)

Idézet

(es persze, hogy mas a kulonfele parhuzamositas, de ettol meg parhuzamositasi kerdes.)

Na ja, de ha egy dolog egyik aspektusáról beszélünk, akkor nem feltétlenül a másikról is.

Szerkesztette: dezz 2007. 06. 11. 12:39 -kor

[bogdan]

Idézet: dezz - Dátum: 2007. jún. 11., hétfõ - 13:35

A multithread ugyanazon az adathalmon is dolgozhat, egymás között felosztva, vagy fázisokban (és az applikáció egyéb adatai is csak egyszer szerepelnek), miközben multitaskban a taskok jellemzõen a sajátjukkal foglalkoznak.

ebben 100%-ban igazad van. DE...
kulonitsunk el ket esetet. 1) egy feladat tavoli reszfeladatainak vegrehajtasa, vagy 2) egy feladat kozeli (osszetartozo) reszfeladatainak vegrehajtasa. 1) eseteben nem nyersz memoriat, mindket (mindNYOLC) reszfeladat adathalmaza a rendszermemoriaban kell, hogy legyen. mivel a Cell hatarozottan korlatozott memoriaval bir, ez igenis okozhet gondot. 2) esetben meg mar valoszinuleg parhuzamositasrol beszelhetunk, hiszen adatfuggoseg eseten a vegrehajtasi szallak egymastol nem fuggetlenek.

szoval vagy vagy adatfuggoseg, ez esetben nincs szukseg tobb memoriara, de szukseges a parhuzamositas leprogramozasa; vagy nincs adatfuggoseg, ez esetben viszont feltehetoleg sokkal tobb memoriara lesz szukseged, hiszen fuggetlen adathalmazokon kell, hogy dolgozzal.

persze ez a fenti szetvalasztas csak nagysagrendi es durva, de ugy velem az esetek nagyobbik reszere igaz.

Idézet

Na ja, de ha egy dolog egyik aspektusáról beszélünk, akkor nem feltétlenül a másikról is.

ez igy van. en hoztam be a kettot, es altalanositottam roluk valamit. az altalanositasom ervenyessege nelkul nem jogos behozni. viszont ha van benne racio, akkor hasznos felvetesnek erzem.

[dezz]

Ha a PS3-at tekintjük, és ott egy játékot, annak (egy rövidebb idõintervallumban szükséges) adatainak mindenképpen be kell férnie a memóriába, eleve úgy kell megtervezni az egészet. Tehát a keretek adottak. Utána már az, hogy pontosan hogyan vannak végrehajtva a feladatok, szép sorban, egy szálban, vagy valahogy szétosztva, a programozó ügyességén múlik.

Itt jön az, hogy ha egy részfeladat leválasztható a fõ szálról, de nem nagyon SIMD-esíthetõ, attól még kiadható egy SPE-nek.

A 2) pontban írt "klasszikus" párhuzamosítás mellett emlékeztetnélek a korábban említett 3. esetre, amikor futószallag módjára mûködnek közre az egyes SPE-k egy feladat különbözõ fázisainak egyidejû végrehajtásában.

Ha még a PS3-nál maradunk, de már nem a jétékoknál, hanem Linux alatti ténykedésrõl van szó, ott kezd érvényesülni, amit írtál. Ha meg nem is PS3-ról van szó, akkor nyilván a memiria mennyiségõtõl függõen jön elõ a kérdés. (Nem tudom, a Cell fizikailag mekkora címtartományt tud megcímezni, gondolom, nem keveset. Ha esetleg az XDR ramos változat valamilyen okból korlátozott ebben, az újabb DDR2-es változat bizonyára nem az.)

Végül, de nem utolsó sorban, a 256MB azért nem olyan kevés, hogy ne lehetne 8 részre osztani. Tehát inkább a feladat típusa és célja dönti el, mennyire memóriára van/lenne szüksége.

[Laa-Yosh]

A játékoknál alapvetõen az a párhuzamosítási probléma, hogy a gameworld és renderer részfolyamatok mind egymásra épülnek - minden képkockánál fizikázni kell, AI-zni, game kódozni, aztán ez alapján animálni, renderernek parancsokat küldeni... A pontos sorrend játékonként változó, de alapvetõen mindig érvényes az elv, hogy az egyes fázisokat csak egymás után lehet indítani, párhuzamosítani ezek között nem nagyon lehet. Marad a folyamaton belüli többszálúsítás, ami viszont már jóval kevésbé egyértelmû, fõleg az SPE-k lokális memóriájának apró de annál fontosabb sajátosságai miatt.

[SFIJ]

Idézet: dezz - Dátum: 2007. jún. 11., hétfõ - 12:35

A multithread ugyanazon az adathalmon is dolgozhat, egymás között felosztva, vagy fázisokban (és az applikáció egyéb adatai is csak egyszer szerepelnek), miközben multitaskban a taskok jellemzõen a sajátjukkal foglalkoznak.

Nos ez korantsem biztos! ha egy feladatot tobb processzel latsz el, akkor ott kommunikacio szuksegeltetik, valamifele messaging. Egy gep esetere tipikusan a shared memory-t hasznaljuk. tipikus shared memory a clipboard. bogdan jol latja, a multitask es a multithread kozott lenyeges elvi kulonbseg nincs ha a teljesitmeny-skalazodas dolgokat nezzuk, akulonbseg inkabb bitonsag specifikus. egy tobbszalu program eseten a programhiba fatalis lehet a folyamatra nezve, mig egy multitaszk eseten a hiba korulhatarolhato, jobban vedheto. cserebe a feladatvaltas egy multitask implementacioban nagyobb koltsegu mint egy mtobbszalu implementacio esetere. persze az adateleres is lasubb, dragabb. ellnebrger a taszkok *altalaban* szabadabban mozgathatoak a CPU core-ok kozott, mint a programszalak.

Idézet: dezz - Dátum: 2007. jún. 11., hétfõ - 12:35

Óvatosan kell bánni a thread fogalmával, mert 2 némileg eltérõ értelemben is használatos. HW-es megközelítésben, mint pl. SMT: itt átlalánosságban "a végrehajtás több szála"-ról van szó, ami állhat több taskból, processzbõl és processzen belüli al-szálból, azaz "thread"-bõl, ill. ezek keverékébõl. Újabb OS-eknél a "thread" egy bizonyos meghatározott struktúra, egy processz korlátozott képességû al-szála, ami az anya-process erõforrásait használja, és amit a newthread(), vagy hasonló függvény indíthat.

en nemlatok ekkora kulonbsegeket, foleg azota, hogy a modern kernelek es processzorok tamogatjak mamar nemcsak a processz, hanem a szalak utemezeset is.

Idézet: dezz - Dátum: 2007. jún. 11., hétfõ - 12:35

Nos, jelen esetben, és értelemszerûen SW-es oldalról megközelítve, valószínûleg igazad van, és a multiprocessing a helyes fogalom. (Bár ki tudja, hogy nem nevezik-e itt a Cellnél az SPE-ken futtatott kódokat mégis al-threadeknek.)

az SPE-k tekinteteben a zsargon un. APUlet-ekrol beszel, amik egyszaluak es ezek kerulnek ki/be/atutemezesre az SPEk relaciojaban.

[SFIJ]

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 13:07

ebben 100%-ban igazad van. DE...

szeretem az ilyen fordulatokat

[bogdan]

Idézet: dezz - Dátum: 2007. jún. 11., hétfõ - 18:58

A 2) pontban írt "klasszikus" párhuzamosítás mellett emlékeztetnélek a korábban említett 3. esetre, amikor futószallag módjára mûködnek közre az egyes SPE-k egy feladat különbözõ fázisainak egyidejû végrehajtásában.

valojaban ez esetben ez pont ekvivalens azzal, mintha vektorprocesszort hasznalnal!!
tessek atgondolni..

(nem veletlen am, hogy valojaban a vektorprocesszorokat futoszallaggal oldjak meg...)

[bogdan]

Idézet: SFIJ - Dátum: 2007. jún. 11., hétfõ - 19:47

szeretem az ilyen fordulatokat

hiaba, a bolcsesz tud, ha akar!

[SFIJ]

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 19:01

valojaban ez esetben ez pont ekvivalens azzal, mintha vektorprocesszort hasznalnal!!
tessek atgondolni..

(nem veletlen am, hogy valojaban a vektorprocesszorokat futoszallaggal oldjak meg...)

minden modern processzor futoszalag elvu. ha egy komplex folyamatot egyszerubb reszekre bonthatsz es a muveleteket idoben at tudod lapolni akkor az egyseg kihasznaltsaga, atbocsato kepessege novekszik, mikozben persze a teljes folyamat szamitasi ideje nem, sot esetenket kismertekben nohet is!

[bogdan]

a lenyeg a vektorprocesszor es a futoszallag ekvivalenciajan volt!

(gy.k.: nincs olyan, hogy vektorizalni nem tudom, de futoszallagositani igen..)

[dezz]

Idézet: Laa-Yosh - Dátum: 2007. jún. 11., hétfõ - 19:43

A játékoknál alapvetõen az a párhuzamosítási probléma, hogy a gameworld és renderer részfolyamatok mind egymásra épülnek - minden képkockánál fizikázni kell, AI-zni, game kódozni, aztán ez alapján animálni, renderernek parancsokat küldeni... A pontos sorrend játékonként változó, de alapvetõen mindig érvényes az elv, hogy az egyes fázisokat csak egymás után lehet indítani, párhuzamosítani ezek között nem nagyon lehet. Marad a folyamaton belüli többszálúsítás, ami viszont már jóval kevésbé egyértelmû, fõleg az SPE-k lokális memóriájának apró de annál fontosabb sajátosságai miatt.

Igen, sokminden egymásra épül. De vannak kivételek. 1. Lásd pl. 2nd gen. CrossFire: az egyik kártya fizikára használható. Ha csak egymás után mehetne a dolog, nem lenne sok értelme külön egy kártyán csak fizikára használni. (Igaz, itt spec. nem az egész fizikáról van szó, hanem "effekt-fizikáról" (Havok FX) - bár ez inkább azért van, mert PS3.0 alapú egyelõre a dolog. De ha mást nem, legalább ez mehet párhuzamosan.) 2. Nemrég olvastam egy interjút egy PC-s fejlesztõvel; úgy tervezik kihasználni a többmagos procikat, hogy a 2. mag a fizikát és az AI-t számolja, ill. ha van még mag, akkor az AI arra kerül át. Ennek is csak akkor van értelme, ha párhuzamosan mûködhet. A kulcs talán az, hogy a rendering közben már a köv. frame "fizikáját" számolják.

De talán 1-1 fõfeladat többé-kevésbé párhuzamosítása sem akkora ördöngõsség. A fizika párhuzamosítására vannak már módszerek. A geometria átszámolásánál objektenként lehet párhuzamosítani (1-1 szál - 1-1 objekt). AI: esettõl függõen karakter-csoportonként, vagy épp csoporton belül lehet párhuzamosítani.

Intelligensebb AI-nél (tehát nem igazán script alapú, bár ilyen még nem nagyon van ugye) amúgy sem frémenként megy majd a dolog.

Idézet: SFIJ - Dátum: 2007. jún. 11., hétfõ - 19:47

Nos ez korantsem biztos!

Azért írtam, hogy jellemzõen.

Idézet

ha egy feladatot tobb processzel latsz el, akkor ott kommunikacio szuksegeltetik, valamifele messaging. ...

Multitaskingról volt szó, tehát jellemzõen 1 task = 1 process, különféle feladatokkal.

Idézet

en nemlatok ekkora kulonbsegeket, foleg azota, hogy a modern kernelek es processzorok tamogatjak mamar nemcsak a processz, hanem a szalak utemezeset is.

Akkor még1x: 1 process is a végrehajtás egy threadje, azaz szála, de a newthread() (stb.) egy konkrétan threadnek nevezett al-szálat indít el, ami osztozik a hozzá tartozó process összes erõforrásán. De a "multithreading" nem ilyen "thread"-ek egyidejû futtatását jelenti, hanem bármilyen szálakét, lehet az egy másik process is. Ez kb. olyan, mint "a Nap is egy nap, de nem minden nap a Nap".

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 20:01

valojaban ez esetben ez pont ekvivalens azzal, mintha vektorprocesszort hasznalnal!!
tessek atgondolni..

Hát, bármennyire is próbálom átgondolni, csak arra jutok, hogy nem így van. A vektorprocik alapvetõen SIMD-ben mûködnek, a MIMD meg egy másik kategória - márpedig a különféle fázisok egyidejû végrehajtása (miközben az adat szépen streamelõdik) esetleg MIMD-nek fogható fel.

Idézet

(nem veletlen am, hogy valojaban a vektorprocesszorokat futoszallaggal oldjak meg...)

Nem egészen értem, ezt most hogy is érted, de ha úgy, ahogy gondolom, akkor ez a válaszom: ma már kb. minden futószallagos a procikban.

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 20:02

hiaba, a bolcsesz tud, ha akar!

Na mi van, itt már mindenki bölcsész? (Kivéve én, talán ez a baj.)

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 21:56

a lenyeg a vektorprocesszor es a futoszallag ekvivalenciajan volt!
(gy.k.: nincs olyan, hogy vektorizalni nem tudom, de futoszallagositani igen..)

Hát... Lásd, amit a SIMD vs. MIMD-rõl írtam.

Szerkesztette: dezz 2007. 06. 11. 21:13 -kor

[bogdan]

idoben told el, es talan meglatod az ekvivalenciat..

de kezdheted a masik oldalrol is: probald kisakkozni hogy lesz futoszallagbol vektorprocesszor, ha megvan latni fogod az ekvivalenciat!

[d n . r]

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 21:56

a lenyeg a vektorprocesszor es a futoszallag ekvivalenciajan volt!

(gy.k.: nincs olyan, hogy vektorizalni nem tudom, de futoszallagositani igen..)

Húha, ezt nem értem.

A futószalag elv nálam azt jelenti, hogy egy összetett mûveletet lebontok egyszerûbb al-mûveletekre
(pl. nagyon durva esetben ez csak annyi, hogy 1. lépcsõ: betölt, 2. lépcsõ az ALU, stb)
(ennek pl. kiugró jelentõsége van az órajel növelésében. Persze mellékhatásként "büntetés" is van, stb)

A vektorizálás meg az, hogyha mondjuk egy 3D-s pontot reprezentáló vektor mindegyik komponensén ugyanazt a mûveletet kell elvégeznem, akkor némi szilícium-többlet árán ezeket a számításokat _egyszerre_ is elvégezhetem.

Egy modern vektorprocesszorban (pl. GPU) a futószallag-elv és a SIMD _egyszerre_ van jelen. Értem én, milyen hasonlóságot akarsz látni/láttatni, de az SZVSZ semmiképpen sem ekvivalencia!

Aztán persze lehet, hogy rosszul értem....

Szerkesztette: d n . r 2007. 06. 11. 21:43 -kor

[d n . r]

Idézet: bogdan - Dátum: 2007. jún. 11., hétfõ - 21:56

(gy.k.: nincs olyan, hogy vektorizalni nem tudom, de futoszallagositani igen..)

Ezt mondjuk egyébként kételm, hiszen pl. ha csak skalár mûveletere szánod a processzorodat, akkor ott vektorizálni nem tudsz, ellenben futószallagosítani meg igen.
Vagy rosszul gondolnám?

[d n . r]

Most nincs nálam sajna a Tanenbaum: Számítógép-architektúrák könyv, de pl. emlékeim szerint abban ez tök jól le van írva (meg nyilván még 1000 másik könyvben, amiket nem ismerek )