[dezz]

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

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!

Tehát most arra gondolsz, hogy a vektorprociban több végrehajtóegység van, és ezek az adott számítás (szerk: nem úgy értettem, hogy ugyanaz) más-más fázisánál tartanak.

Csakhogy, itt az egyes egységek SIMD-ben mûködnek. Én meg arról beszéltem, hogy az egyes egységek skalárisan számolnak, de más-más fázist. (Persze a legjobb, ha õk is SIMD-ben dolgoznak, csak ugye éppen egy olyan esetrõl van szó, amikor ez valami miatt nem megy.)

Nos, hogy is lett a többfázisú skalárból SIMD?

Szerkesztette: dezz 2007. 06. 11. 22:00 -kor

[d n . r]

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

Én meg arról beszéltem, hogy az egyes egységek skalárisan számolnak, de más-más fázist

Pontosan ez a lényeg, márpedig ha nincs ugye "same instruction", akkor lõttek a SIMD-végrehajtásnak!

[bogdan]

hat az azonos fazisok altal!!

meg egyszer:
"probald kisakkozni hogy lesz futoszallagbol vektorprocesszor, ha megvan latni fogod az ekvivalenciat!"

a futoszallag elven megvalositott vektorprocesszor egysegei egymashoz kepest ugyanis NEM SIMD modon mukodnek! ez csak eltolva igaz, eppen ugy, mint az altalad megvalositani kivant esetben.

[d n . r]

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

a futoszallag elven megvalositott vektorprocesszor egysegei egymashoz kepest ugyanis NEM SIMD modon mukodnek!

Ezt szerintem nem is állította senki.
Viszont Te _ekvivalenciát_ állítóttál a futószallag-elv és a "vektorprocesszor" között. Most akkor az utóbbin nem a SIMD végrehajtást értetted? Akkor viszont most mi ekvivalens itt mivel?

Szerkesztette: d n . r 2007. 06. 11. 22:05 -kor

[bogdan]

Idézet: d n . r - Dátum: 2007. jún. 11., hétfõ - 22:40

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?

rosszul. mondom, hogy nagyjabol ekvivalens, kulonben nem lehetne futoszallaggal megvalositani a vektorprocesszort!

es nem a Tannenbaumban kell nezni. az masrol szol, mas szinten.

*************************************************************
az a lenyeg, hogy SIMD-beli "azonos utasitas" lehetseges idoben eltolva is!

[bogdan]

Idézet: d n . r - Dátum: 2007. jún. 11., hétfõ - 23:03

Ezt szerintem nem is állította senki.

mar hogyne. mindketten. kulonben mi ertelme volna emlegetni, hogy a futoszallagban nincs SIMD? csak ugy van ertelme ennek az allitasnak, ha szemben ezzel azt allitjatok, hogy lam, lam, a vektorprocesszor viszont SIMD.

ami igaz, csak megvalositasilag (futoszallaggal) nem szigoruan. pont ugyanannyira, mint a futoszallagositott esetek tulnyomo resze.


****************************************
"a "vektorprocesszor" között. Most akkor az utóbbin nem a SIMD végrehajtást értetted?"
NEM. a "vektorprocesszor" alatt egeszen konkretan vektorprocesszort ertek. tudod, egy kis kutyu, ami bizonyos tulajdonsagokkal bir....

Szerkesztette: bogdan 2007. 06. 11. 22:34 -kor

[d n . r]

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

rosszul. mondom, hogy nagyjabol ekvivalens, kulonben nem lehetne futoszallaggal megvalositani a vektorprocesszort!

es nem a Tannenbaumban kell nezni. az masrol szol, mas szinten.

*************************************************************
az a lenyeg, hogy SIMD-beli "azonos utasitas" lehetseges idoben eltolva is!

Hm, hát én ezt nagyon nem értem... Sem azt, hogy "kulonben nem lehetne futoszallaggal megvalositani a vektorprocesszort!" (ez mitõl lenne bármiben is ekvivalencia?) és "az a lenyeg, hogy SIMD-beli "azonos utasitas" lehetseges idoben eltolva is!" (ez meg mitõl lenne SIMD?...)

[d n . r]

Húha, egyre kevésbé értem.
Én a magam részérõl futószallag-ELV-rõl és SIMD-VÉGREHAJTÁSRÓL beszéltem, mert ezekrõl a kifejezésekrõl látom, hogy van értelmük, és hogy mi is az értelmük.

[d n . r]

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

az a lenyeg, hogy SIMD-beli "azonos utasitas" lehetseges idoben eltolva is!

Megpróbálom dekódolni.
Pl. egy háromdimenziós vektort skalárszorzol. Azaz mindhárom koordinátáját szorzod X-szel. Ezt eltolhatod idõben (azaz egymás _után_ szorzod meg õket), de akkor ez ugye _nem_ SIMD (azt pont arra találták ki, hogy az ilyeneket _egyszerre_ csinálhasd), így nem értem, mitõl lenne már "lehetséges" eltolni az iõben... Akkor már nem lenne az, ami...

[dezz]

szerk: ez RE: bogdan 22:59

Te most egy olyan futószallagra gondolsz, ami az eredetileg SIMD utasítást elemenként idõben eltolva dolgozza fel? Ennek mi értelme lenne? Miért nem tudja egyszerre (azonos elem -> azonos fázis)? Nem tudom, volt-e ilyen vektorproci, de a maiak nem ilyenek: egy-egy egység az összes elemen dolgozik egyszerre, és ezen belül pipe-olva.

Másrészt, nem feledkeztél meg véletlenül arról, hogy az említett esetben az SPE-k nem 1-1 utasítást végeznek el, aztán már adják is tovább az adatot a másiknak, hanem egy egész kódsort - SPE-nként mást... Plusz az egyes SPE-k nem 1 utasításnyival vannak más fázisban, hanem az egyik ott folytatja a mûveletet, ahol a másik befejezte.

Szerkesztette: dezz 2007. 06. 11. 22:14 -kor

[bogdan]

sok a zavar.. lassunk egy kis szakirodalmat:
http://www.renyi.hu/~bogdan/foto/5-Special...chitekturak.pdf

[SFIJ]

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

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

dehogynincs van egy a mûveleted, legyen a végrehajtási ideje T, legyen egy B mûveleted, aminek a végrehajtási ideje 3T. Legyenek ezek mondjuk atomi SQL tranzakciók. Nézzük az A+B mûveletet. lehet egy olyan megoldás, hogy egyben lemagy az A+B , megjön az eredmény, és beütemezem utána a köv inputot. Ez azt jelenti, hogy 4T idõközönként indíthatsz új mûveletet. Most csináljuk azt, hogy fogunk egy procit ami csak A mûveleteket végez és vegyünk 3 db másik procit, ami csak B mûveleteket. fûzzük fel szépen õket úgy hogy:

                   + - B - +
in - A -szelektor- + - B - + - MUX - out
                   + - B - +

Namost egy ilyen sémában ugya T idõközönként indíthatsz mûveletet, aminek az ideje kicsit több lesz mint 4T de a hatékonyságod 4x-ezõdött!

[dezz]

Mondom én... Ez az irodalom a vektorprocik igen korai megvalósítását tárgyalja. Ma már a 128 bites operandusú mûveletek számára 128 bites adatsín és regiszterek állnak rendelkezésre, ezért utasításon belül, tehát elemenként már nincs átlapolás.

[SFIJ]

Idézet: d n . r - Dátum: 2007. jún. 11., hétfõ - 21:48

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 )

ha ezt a nevet még1x elírod, a véredet veszem! :Ð

[Laa-Yosh]

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

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.

WTF?
A két kártya simán dolgozhat két különbözõ képkockán, vagy a game kód által már befejezett adatokon... ez marhára nem kapcsolódik ahhoz, amit írtam...

Idézet

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.

Ergo marad a szekvenciális feldolgozás, plusz buknak pár miliszekundumot. Össze tud ám adódni...

Idézet

De talán 1-1 fõfeladat többé-kevésbé párhuzamosítása sem akkora ördöngõsség.

De igen, ez a baj - nagy ördöngõsség. Évtizednyi szoftverfejlesztés mehet a kukába, lehet a jól bevált algoritmusokat kidobni, újakat kitalálni. Még nem érett meg rá az ipar, nincs elég akadémiai kutatás a témában, beledobták a game ipart a mélyvízbe.

És ismétlem, a párhuzamosítás másik akadálya a local store, ami 256k - de ha jót akar a kóder, akkor 128k-t használ, a másik 128k-ból meg vagy az elõzõ taszk eredményeit írogatja ki, vagy a következõ adatait olvassa be oda. Namost 128k-ba elég kevés dolog fér bele, lehet bitvadászni...


Az SPE-k sorbakötése meg megint más tészta, ilyenkor az egyik SPE kimenõ adatai mennek a másikba további feldolgozásra, és így tovább. Nem úgy számít futószalagnak, ahogy a mûveletvégzõ egységeken belüli feldolgozás...

[SFIJ]

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

szerk: ez RE: bogdan 22:59

Te most egy olyan futószallagra gondolsz, ami az eredetileg SIMD utasítást elemenként idõben eltolva dolgozza fel? Ennek mi értelme lenne? Miért nem tudja egyszerre (azonos elem -> azonos fázis)? Nem tudom, volt-e ilyen vektorproci, de a maiak nem ilyenek: egy-egy egység az összes elemen dolgozik egyszerre, és ezen belül pipe-olva.

hát attól fúgg mit nevezel mainak. a pentium4 pl a szorzást 16 bites egségekkel, kaszkádosítva, idõben eltólva végezte. a prescott már 32 biteseket használt

[SFIJ]

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

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

ez oltárinagy tévedés. a mai modern videogame-ek is sok processzbõl állnak.

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

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".

szerintem olvasd el a POSIX szabványt te erõsen kevered a hw és a sw thread fogalmát, ami mondjuk nem meglepõ, mert a modren OSek és processzorok is kezdik ezt a határt elmosni.

[Laa-Yosh]

A nagy ereszdeleahajamot megszakítva talán érdemes lenne visszakanyarodni az alaptémához... mi a Cell?

Elsõ körben van egy rakás vektoros egység, amik a brutál számítási kapacitást adják. Kompromisszum pl. a csak 32 bites IEEE adat kezelése, meg sok fotnos elem kihagyása (mindenbõl 8 kerülne a lapkára). Ezekre a funkciókra van a PPE, ami többé-kevésbé koordinálja is az SPE-ket, meg kiegészíti õket.

A sok ALU mit sem ér sávszélesség nélkül, de itt jön be a többi kompromisszum. Kicsi a cache, mert kell a lapkán a hely az SPE-knek; kicsi és borzasztó késleltetésû a memóriabusz, mert nem fér el a PS3 nyákon szélesebb vezeték meg több IC. Megoldás: az SPE-ket gyors belsõ busz köti össze és mindnek gyors lokális memóriája van, így minimalizálható a RAM elérés. Megint kompromisszum: local store tranzisztorok vs. SPE tranzisztorok -> kicsi a lokális memória is.

Az egész designról süt a konzolos filozófia. Ami a lapkára kerül, azon nem kell spórolni, mert pár process shrink után úgyis olcsó lesz; az alaplap és a RAM viszont nem szerveres hightech környezet, hanem baromi szûk keresztmetszet, mert azt nehezebb ócsítani és amúgy se gyártható saját üzemben.

Erre jön még a video alrendszer a maga hasonló trükkjeivel...

SZVSZ egyértelmû, hogy ez egy végletekig specializált rendszer, ahol a költség vs feature döntéseket a konzol piac sajátosságai határozták meg. Minden általános felhasználási kísérlet elsõsorban PR és költségcsökkentés miatt indul, a rendszer alkalmassága ezen a fronton lényegtelen.

[dezz]

Idézet: Laa-Yosh - Dátum: 2007. jún. 12., kedd - 0:03

WTF?

Ez nagyon kellett...

Idézet

A két kártya simán dolgozhat két különbözõ képkockán, vagy a game kód által már befejezett adatokon... ez marhára nem kapcsolódik ahhoz, amit írtam...

Dehogynem. Ez is egy lehetõség a feladatok egyidejû végzésére. Az most tök mindegy, hogy az egyik már a köv. frémen dolgozik. Mellesleg magam is írtam, hogy valószínû így megy a dolog.

Idézet

Ergo marad a szekvenciális feldolgozás, plusz buknak pár miliszekundumot. Össze tud ám adódni...

Szekvenciális, de nem úgy, hogy ugyanaz az egység végzi egymás után.

Idézet

De igen, ez a baj - nagy ördöngõsség. Évtizednyi szoftverfejlesztés mehet a kukába, lehet a jól bevált algoritmusokat kidobni, újakat kitalálni.

Néha jót tesz egy kis forradalom.

Idézet

Még nem érett meg rá az ipar, nincs elég akadémiai kutatás a témában, beledobták a game ipart a mélyvízbe.

Ez van, ezt kell szeretni. Sajna a 10GHz-es proci egyelõre nem jött össze... És amúgy is rég kevés lenne.

Idézet

És ismétlem, a párhuzamosítás másik akadálya a local store, ami 256k

Magam is írtam már ezt.

Idézet

- de ha jót akar a kóder, akkor 128k-t használ, a másik 128k-ból meg vagy az elõzõ taszk eredményeit írogatja ki, vagy a következõ adatait olvassa be oda. Namost 128k-ba elég kevés dolog fér bele, lehet bitvadászni...

Ez szerintem nem jó ötlet - max. akkor, ha egy-egy taszk futási ideje igen rövidke.

Idézet

Az SPE-k sorbakötése meg megint más tészta, ilyenkor az egyik SPE kimenõ adatai mennek a másikba további feldolgozásra, és így tovább.

Már én is írtam ezt.

Idézet

Nem úgy számít futószalagnak, ahogy a mûveletvégzõ egységeken belüli feldolgozás...

ÉS??? Talán én jöttem ezzel? Akkor légyszi címezd neki. KÖSZ.

[SFIJ]

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

Mondom én... Ez az irodalom a vektorprocik igen korai megvalósítását tárgyalja. Ma már a 128 bites operandusú mûveletek számára 128 bites adatsín és regiszterek állnak rendelkezésre, ezért utasításon belül, tehát elemenként már nincs átlapolás.

szerintem félreértetted a jegyzetben írottakat.