PlayStation 3 bemutató az E3-on

Jelentkezz be a hozzászóláshoz.

#363
"Ez nem igaz. Csak arról van szó, hogy egy 3.2GHz-es PPE nem ér fel egy 3.2GHz-es x86-tal, de az hülyeség, hogy egy átlagos, mondjuk 2GHz-es x86-nál is sokkal gyengébb."

Nem hülyeség. A feladattól függõen nagyon sokat számíthat a sokkal egyszerûbb felépítés.

"Más feladatnál a CPU is gyengébb, mert ott is SIMD-bõl jön a FLOPS nagy része."

Ezért nem a flops-ot nézzük.

"Más dolgokban sem teljesen pontosak."

Pl.?

"Talán nem kellene mindenben és kizárólag a wikire hagyatkozni."

Hol hagyatkozom kizárólag arra?
Egyébként mintha lett volna egy cikk nemrég, ami arról szólt, hogy a wiki legalább olyan megbízható, mint az Encyclopaedia Britannica.

#362
"Aha, csak épp "lassan" is megvan egytízezred mp alatt."

Az rettenetesen lassú. Az adattal végzett mûvelet nanosec nagyságrendû.

"Ne túlozz. Már-már úgy akarod beállítani, mintha L1-L2 sem lenne benne."

A cikkben leírják szépen, hogy mi a probléma. Nagyon sokat számítanak ám ezek a dolgok az ilyen típusú feladatoknál.

"PC-n az ideje nagy része másra megy el."

Igen, de az a plusz teljesítmény nagyrészt elveszik.

"Az általad leírt játékoknál régebben is voltak már "intelligensebbek", legfeljebb nem ismerted õket."

Megint személyeskedsz érvelés helyett. Nem lehettek oylan összetett játékok, mivel nem volt elég erõforrás hozzá, és egyébként is a komplexitás jelentõs része a 3D világból adódik. Az AI munkáját is drasztikusan megnehezíti a komplexebb környezet. És ott van még pl. az útkeresés. Négyzetrácsos térképen azonos (1 négyzetnyi) méretû egységekkel, nagyságrendekkel egyszerûbb, mint 3D poligonos világban különféle méretû egységekkel. Ráadásul itt a jármûvek ív mentén kanyarodnak, és ki is kell hogy kerüljék egymást.

"A mai játékok "intelligenciája" sem igazán nyûgöz le, és ami azt illeti, még nagyon is elõreprogramozottak a lépések"

Attól is függ, hogy melyik játék (pl. nézd meg a Black&White-ot). A többség sajnos tényleg elég buta (de régen még butábbak voltak).

"Ez a kvázi véletlenszerû hozzáférés esete, azaz a fennmaradó kicsi halmaza a feladatoknak, amibõl speciális feladatoknál kell olyan sokat csinálni, hogy az gondot okozzon."

Pontosan errõl beszélek. És messze nem biztos, hogy kevés ilyen lesz. Pl. a gráf algoritmusok gyakran ilyenek (AI, útkeresés).

#361
(És akkor még nem számoltuk bele a true hw smp-t. )

#360
Igen, ha kevés adatot tolunk, akkor az már csak olyan sávszél, mint pc-n a csúcs. Hát igen, az milyen kevés is...

#359
"Ami szintén sokkal egyengébb, mint egy átlag x86 CPU."

Ez nem igaz. Csak arról van szó, hogy egy 3.2GHz-es PPE nem ér fel egy 3.2GHz-es x86-tal, de az hülyeség, hogy egy átlagos, mondjuk 2GHz-es x86-nál is sokkal gyengébb.

"Elméletben, és csak SIMD mûveleteknél. Más jellegû feladatoknál sokkal egyengébb."

Más feladatnál a CPU is gyengébb, mert ott is SIMD-bõl jön a FLOPS nagy része.

"Simán elírták, elõfordul. Ez nem változtat semmin."

Más dolgokban sem teljesen pontosak. Talán nem kellene mindenben és kizárólag a wikire hagyatkozni.

#358
"Az lassú."

Aha, csak épp "lassan" is megvan egytízezred mp alatt.

"A sokkal gyengébb CPU miatt pont az arányok borulnak. Ami egy A64 3000+-on 10%, az a PPE-n könnyen lehet akár 100% is (de 30-50 biztosan)."

Ne túlozz. Már-már úgy akarod beállítani, mintha L1-L2 sem lenne benne.

"De gond, mert PC-n is az a gond, hogy nem jut neki elég teljesítmény. Ha a cell-en sem jut több, akkor gamelogic szinten nem lesznek jobbak a játékok."

PC-n az ideje nagy része másra megy el.

"Nagyságrendekkel összetettebbek."

Az általad leírt játékoknál régebben is voltak már "intelligensebbek", legfeljebb nem ismerted õket. A mai játékok "intelligenciája" sem igazán nyûgöz le, és ami azt illeti, még nagyon is elõreprogramozottak a lépések, csak már nem olyan banálisan egyszerûen, mint korábban a legtöbb esetben. Ennel jóval intelligensebbek is lehetnek majd.

"Az SPE nem fér hozzá a PPE lokális memóriájához, így abban nem tud hatékonyan másolni."
+
"Erre mondtam, hogy az ilyen másolgatásos feladatok egyébként sem a PPE-n futnak, így az SPE besegítése a PPE-nek itt nem játszik."

A PPE-nek nem lokális memóriája van, hanem a szokásos L1-L2. Ahhoz tényleg nem fér hozzá az SPE, de attól még tud másolgatni a main memóriában, illetve a main és a vram között, így be tud segíteni a PPE-nek.

"De itt max. 1 tucat byte-ról van szó egy lépésben, és az azon végzett mûvelet dönti el, hogy melyik adat kell legközelebb. GOndolj pl. nagy gráfban keresésre (arra sincs semmi garancia, hogy a szomszédok egymáshoz közel vannak a memóriában)."

Ez a kvázi véletlenszerû hozzáférés esete, azaz a fennmaradó kicsi halmaza a feladatoknak, amibõl speciális feladatoknál kell olyan sokat csinálni, hogy az gondot okozzon.

" "És ugye közben a 2. threadben más feladat is futhat a PPE-n."
Hiába, mert itt az SPE idejével van a gond."

Az SPE idejével?? A PPE ide való besegítésére fordított idejérõl volt szó, tehát a PPE idejérõl. (Mellesleg a PPE értesülése arró, hogy az SPE adatot vár, egy db bájt kiolvasása az SPE belsõ gyors ramjából.)

#357
"Azt is nézd meg, mihez képest: max. sávszél itt 2-300 GB/s."

Pont arról van szó, hogy a gyakorlatban ez könnyen a töredékére csökkenhet, ami már összemérhetõ a PC-k sávszélességével. Abból jön ki ez a nagy szám, hogy az összes mag kommunikációját összeadják.
Az egész cell-re az a jellemzõ, hogy alapvetõen erõsnek lett szánva, de a költségek csökkentése miatt sok helyen erõs kompromisszumokra kényszerültek, amik a teljesítményt is visszafoják. Szóval nagyon jó lesz ez bizonyos típusú feladatokra, de messze nem az a csodaszer, aminek reklámozták.

#356
"Ehhez annyit, hogy miután van itt egy PPE is"

Ami szintén sokkal egyengébb, mint egy átlag x86 CPU.

"Aha, úgy nem 30x gyorsabb, csak 6x"

Elméletben, és csak SIMD mûveleteknél. Más jellegû feladatoknál sokkal egyengébb.

"At 3.2 GHz, each SPE gives a theoretical 256 GFLOPS"

Simán elírták, elõfordul. Ez nem változtat semmin.

#355
"Hát úgy, hogy kiolvassa a memóriából azt a párszáz, párezer kis adatcsomagot, és átadja valamelyik SPE-nek (egy tízezred mp alatt)."

Az lassú.

""Emiatt nem biztos, hogy sokkal több marad a gamelogic-nak, mint PC-n."
Ez egy igen elhamarkodott következtetés, lásd arányok."

A sokkal gyengébb CPU miatt pont az arányok borulnak. Ami egy A64 3000+-on 10%, az a PPE-n könnyen lehet akár 100% is (de 30-50 biztosan).

"Oké, de mivel közben alig kell mással foglalkoznia a PPE-nek (más csinálja párhuzamosan), ez nem feltétlenül gond."

De gond, mert PC-n is az a gond, hogy nem jut neki elég teljesítmény. Ha a cell-en sem jut több, akkor gamelogic szinten nem lesznek jobbak a játékok.

"Kicsit besegíthet a PPE, de a számítások nagy része mehet az SPE-ken."

Errõl nem vagyok meggyõzõdve, de elképzelhetõ.

"Na de hát ez az, hogy sok 3D grafikával kapcsolatos mûveletet (amit PC-n a CPU csinál) átvehet 1-2 SPE, így a PPE-nek több ideje marad."

Gamelogic szinten is rengeteg dolog kapcsolódik a 3D környezethez. Ezek egy része biztosan gyorsítható az SPE-kkel, de nem olyan egyszerûen, és nem mind.

"Melyik játékban van ma "igazi" AI? Szerintem ma is eléggé behatároltak és elõreprogramozottak, csak már kicsit összetettebb vezérlésûek."

Nagyságrendekkel összetettebbek. A valódi AI attól függ, hogy mit nevezel annak. A játékban szt szokás, ami nem szkriptelt, hanem programozott. Régen a stratégiai játékokban az AI nem épített, hanem megkapta a bázist, aztán a legyártott egységeket ellened küldte egyesével. Ma már az AI önállóan építi fel a bázist, optimális helyet keresve az épületeknek. Eldönti, hogy mit kell építeni, és milyen egységet gyáratni. Összeállítja a megfelelõ csapatot, és azzal támad. Képes megkeresni a te bázisod gyenge pontját, és gonosz módon ott támad. De még a játékstílusodhoz is alkalmazkodik valamennyire.

"Nem értem, milyen plusz másolgatásra gondolsz."

Az SPE nem fér hozzá a PPE lokális memóriájához, így abban nem tud hatékonyan másolni.

"Ki beszél itt a PPE-rõl és gamelogicról? Az SPE-k másolgatásban való részvételérõl van szó."

Erre mondtam, hogy az ilyen másolgatásos feladatok egyébként sem a PPE-n futnak, így az SPE besegítése a PPE-nek itt nem játszik.

"Ha párszáz, vagy párezer quadwordrõl van szó, nem hiszem, hogy különösebb problémát jelent."

De itt max. 1 tucat byte-ról van szó egy lépésben, és az azon végzett mûvelet dönti el, hogy melyik adat kell legközelebb. GOndolj pl. nagy gráfban keresésre (arra sincs semmi garancia, hogy a szomszédok egymáshoz közel vannak a memóriában).

"És ugye közben a 2. threadben más feladat is futhat a PPE-n."

Hiába, mert itt az SPE idejével van a gond.

#354
Azt is nézd meg, mihez képest: max. sávszél itt 2-300 GB/s.

#353
Ezt keresni sem kellett, csak megnézni. 😊
De amúgy is nagy bénaság lett volna, ha nem férhetne hozzájuk.

"Unlike a Cell processor, such desktop CPUs are more suited to the general purpose software usually run on personal computers."

Ehhez annyit, hogy miután van itt egy PPE is, a feladatok többségére nagyon jó a Cell is, de a kevés maradékkal (sok szétszórt adattal kevés mûvelet) is megbírkózik.

"Also, Cell is optimized for single-precision calculations; for double-precision, as used in personal computers, Cell performance drops by an order of magnitude to levels similar to desktops."

Aha, úgy nem 30x gyorsabb, csak 6x... 😊 (Valahol volt egy összehasonlító táblázat, de most nem találom.)

Én is találtam egy "érdekességet":
"At 3.2 GHz, each SPE gives a theoretical 256 GFLOPS of single precision performance. The PPE's VMX128 (AltiVec) unit is fully pipelined for double precision floating point and can complete two double precision operations per clock cycle, which translates to 6.4 GFLOPS at 3.2 GHz; or eight single precision operations per clock cycle, which translates to 256 GFLOPS at 3.2 GHz<7>."

Nos, Ezek itt hibás adatok. Az egész Cellre vonatkozik a 256 gflops (single prec.), így érdekes azt olvasni, hogy mind a PPE, mint az SPE-k egyenként tudnak ennyit. Ez így összesen 2,3 tflops, szép is lenne. 😊
Még rosszul is számolnak, mert 3.2 x 8 = 25.6, nem pedig 256.

#352
"De akkor megint PPE idõt pazalunk."

Általában keveset.

"Igen, pont errõl beszélek."

Milyen feladat lehet ilyen? De még ha elõ is jön egy ilyen egy játékban, a 2. threadben mást is csinálhat a PPE is, plusz az SPE-k is levesznek a válláról sokmindent.

#351
"Hogyan?"

Hát úgy, hogy kiolvassa a memóriából azt a párszáz, párezer kis adatcsomagot, és átadja valamelyik SPE-nek (egy tízezred mp alatt).

"Úgy értem, hogy õ szervezi a feladatokat. Megmondja, hogy melyik SPE mit csináljon"

Ez semmibõl sem áll, pár utasítás, a többit meg már az SPE csinálja (beolvassa a programját, aztán szépen nekiáll végrehajtani, már õ olvassa be az adatokat ).

"meg elõkészíti nekik az adatokat."

Csak ha kimondottan szükséges - csak bizonyos feladatoknál.

"A tapasztalat szerint nem igazán. Nem véletlen, hogy a PC-n is rengeteg tranzisztort áldoznak erre."

Ezt gondolom az in-orderre és a branchra írod. Olvasgattam már megoldásokról. Nem tökéletesek, de a másik megoldás sem mindig az.

"Igen, de a PPE eleve sokkal gyengébb, és plusz adminisztrációs feladatokat is kap."

Azért figyeljünk oda az arányokra is...

"Emiatt nem biztos, hogy sokkal több marad a gamelogic-nak, mint PC-n."

Ez egy igen elhamarkodott következtetés, lásd arányok.

"A gamelogic tipikusan az a fajta kód, ami igényli az alacsony memória késleltetést, a rövid futószalagot, a fejlett branch-prediction-t, és a többit."

Oké, de mivel közben alig kell mással foglalkoznia a PPE-nek (más csinálja párhuzamosan), ez nem feltétlenül gond.

"Egyébként az AI-t nem is biztos, hogy át tudják venni, az nem olyan egyszerû."

Kicsit besegíthet a PPE, de a számítások nagy része mehet az SPE-ken.

"Igen, de sajnos manapság nem az az elvárás. Ha nem kéne ultra csúcs 3D grafika, akkor sokkal jobb játékokat lehetne írni, ez tény."

Na de hát ez az, hogy sok 3D grafikával kapcsolatos mûveletet (amit PC-n a CPU csinál) átvehet 1-2 SPE, így a PPE-nek több ideje marad.

"De azért nem csak ezen múlik. Azokban a játékokban pl. AI sem volt, csak egyszerû szkriptek."

Melyik játékban van ma "igazi" AI? Szerintem ma is eléggé behatároltak és elõreprogramozottak, csak már kicsit összetettebb vezérlésûek.

" "Miért lenne lassabb egy SPE másolásban?"
Mert nem fér hozzá közvetlenül a PPE memóriájához, így még plusz másolgatás is kell."

Nem értem, milyen plusz másolgatásra gondolsz.
Én blokkos másolásra gondoltam. Azt nem tudom, arra képesek-e az SPE-k, hogy egy blokkot a külsõ memórián belül átmásoljanak, de ha nem, akkor megtehetik, hogy bemásolnak maguknak egy blokkot, és aztán vissza máshova. A main és a vram között így is valószínû ez a leggyorsabb.

"A gamelogic-ban nem jellemzõ akkora másolgatás, amit érdemes külön kezelni.
Inkább olyan feladatokra jellemzõ, amiket egyébként is az SPE-k csinálnak."

Ki beszél itt a PPE-rõl és gamelogicról? Az SPE-k másolgatásban való részvételérõl van szó.

"A gamelogic még mindíg 1 szálú, és egy ideig az is marad. Egyébként a többszálúsításnak van nem kevés adminisztrációs költsége, ami nem biztos, hogy megtérül."

Na de a másik/többi szálon más feladat is futhat.

"Pl. az Intel féle HT egyes esetekben lassította a szoftvert emiatt."

A true HW SMP és a HT nem ugyanaz. Az utóbbinál nincsenek megduplázva egységek (esetleg 1-2 dolog), csak a meglévõk között osztja el a feladatokat. Két egyforma feladatnak várnia kell egymásra. Az elsõnél viszont jópár dolog meg van duplázva. (Látszik a dye-fotón.)

"Tévedsz, a PPE apránként is küldhet adatot az SPE-knek, mivel hozzáfér a ramjukhoz."

"És ennek mennyi a késleltetése? Mert ha jóval több, mint a SPE belsõ RAM-jáé, akkor szart se ér. Arról nem is beszélve, hogy ez esetben a PPE jelentõs idõt pazarol az SPE-k etetésére. És még valahogy értesülnie is kell arról, hogy az SPE adatot kér. Kizárt, hogy ez így elég gyors legyen."

Ha párszáz, vagy párezer quadwordrõl van szó, nem hiszem, hogy különösebb problémát jelent. (És ugye közben a 2. threadben más feladat is futhat a PPE-n.)

#350
Vannak még ott érdekes dolgok
pl.:
"A ring can start a new op every three cycles. Each transfer always takes eight beats. That was one of the simplifications we made, it's optimized for streaming a lot of data. If you do small ops, it doesn't work quite as well."

#349
"Én meg igen."

Az ilyen rendkívül informatív válaszok helyett lehetne pl. keresni egy egyszerû kis linkecskét. pl. : http://en.wikipedia.org/wiki/Cell_(microprocessor)#Power_Processor_Element
Ebbõl rögtön kiderül, hogy én emélkeztem rosszul, és így elkerülhetõ a felesleges vita.

Mellesleg ugyanitt írják:
Compared to a modern personal computer, the relatively high overall floating point performance of a Cell processor seemingly dwarfs the abilities of the SIMD unit in desktop CPUs like the Pentium 4 and the Athlon 64. But, comparing only floating point abilities of a system is a one-dimensional and application-specific metric. Unlike a Cell processor, such desktop CPUs are more suited to the general purpose software usually run on personal computers. Also, Cell is optimized for single-precision calculations; for double-precision, as used in personal computers, Cell performance drops by an order of magnitude to levels similar to desktops.

#348
"Azokra ott van a PPE, vagy PPE+x SPE együtt."

De akkor megint PPE idõt pazalunk.

"Csak azok maradnak fent, amiként tényleg teljesen össze-vissza kell hozzáféri nagy területhez, és egy-egy adattal csak 1-2 mûveletet kell végezni."

Igen, pont errõl beszélek.

#347
"Ott kezdõdött, hogy azt írtad, nem-blokkos adattal nem tud kezdeni semmit az SPE. Pedig tud, csak ilyenkor be kell segítenie a PPE-nek is."

Hogyan?

"Hogy érted, hogy a PPE irányít? Az SPE akkor fér hozzá a külsõ ramhoz, amikor akar."

Úgy értem, hogy õ szervezi a feladatokat. Megmondja, hogy melyik SPE mit csináljon, meg elõkészíti nekik az adatokat.

"Párhuzamosítással közömbösíthetõ a hosszabb késleltetés. Megfelelõ (fordítóra bízható) optimizáció révén az in-order végrehajtás és a gyengébb branch-prediction is, többé-kevésbé, feladattól függõen."

A tapasztalat szerint nem igazán. Nem véletlen, hogy a PC-n is rengeteg tranzisztort áldoznak erre.

"PC-n egy játékban a prociidõ többsége ugyancsak a megjelenítésre megy el, ide sorolva a fizikát is (vertex-adatok kezelése, atpumpálása a GPU-nak, stb.). Itt ezen feladatok jó részét átvállalhatják az SPE-k. Meg a lassan bejövõ fejlettebb AI-t is. Így nagyon sok prociidõ felszabadul!"

Igen, de a PPE eleve sokkal gyengébb, és plusz adminisztrációs feladatokat is kap. Emiatt nem biztos, hogy sokkal több marad a gamelogic-nak, mint PC-n.
A gamelogic tipikusan az a fajta kód, ami igényli az alacsony memória késleltetést, a rövid futószalagot, a fejlett branch-prediction-t, és a többit.
Egyébként az AI-t nem is biztos, hogy át tudják venni, az nem olyan egyszerû.

"Gondolj arra, hogy jópár éve, egy 7MHz-es, maiaknál jóval egyszerûbb procival rendelkezõ Amiga500-ra is eléggé összetett játékok is születtek."

Igen, de sajnos manapság nem az az elvárás. Ha nem kéne ultra csúcs 3D grafika, akkor sokkal jobb játékokat lehetne írni, ez tény.
De azért nem csak ezen múlik. Azokban a játékokban pl. AI sem volt, csak egyszerû szkriptek.

"Miért lenne lassabb egy SPE másolásban?"

Mert nem fér hozzá közvetlenül a PPE memóriájához, így még plusz másolgatás is kell.

"Egy programban sokszor kellhet memóriát másolni."

A gamelogic-ban nem jellemzõ akkora másolgatás, amit érdemes külön kezelni.
Inkább olyan feladatokra jellemzõ, amiket egyébként is az SPE-k csinálnak.

"Egy tread esetén talán, 2 (x360-nál 6) esetén már nem biztos."

A gamelogic még mindíg 1 szálú, és egy ideig az is marad. Egyébként a többszálúsításnak van nem kevés adminisztrációs költsége, ami nem biztos, hogy megtérül. Pl. az Intel féle HT egyes esetekben lassította a szoftvert emiatt.

"Tévedsz, a PPE apránként is küldhet adatot az SPE-knek, mivel hozzáfér a ramjukhoz."

És ennek mennyi a késleltetése? Mert ha jóval több, mint a SPE belsõ RAM-jáé, akkor szart se ér. Arról nem is beszélve, hogy ez esetben a PPE jelentõs idõt pazarol az SPE-k etetésére. És még valahogy értesülnie is kell arról, hogy az SPE adatot kér. Kizárt, hogy ez így elég gyors legyen.

#346
Én meg igen. 😊

#345
Hogy érted, hogy nem segít az SPE-ken?
Az alábbi lehetõségek közül lehet választani:
- PPE használata a belsõ VMX-szel
- SPE-k önálló munkája
- PPE szedi össze az adatot, amit SPE-k dolgoznak fel
- ezek valamilyen kombinációja

Igen, x86-on is van az SSE(x). De a VMX ütõsebb (nagyobb teljesítmény, sokkal több regiszter), és SMP-re optimializált (2 regiszter-készlet, de állítólag magából a VMX-bõl is kettõ van).

#344
"Az a pár % könnyen lesz 100, és akkor meg vagy lõve. És ha neked ilyen feladatot kell megoldani, akkor nem sokat segít az, hogy más fajta feladat is van."

Egy a PC esetén sokmindennel foglalkozó procival ellentétben mindezek nagy részével foglalkozni nem kénytelen procit nem könnyû 100%-ra terhelni apróságokkal.

"Nem írom elõ, csak becsültem."

Nem lehet becsülni a feladat ismeretének hiányában. 1k-ban is lehet érdekes dolgokat csinálni.

"Konkrétan 50K-nak becsültem a kódot. A maradék a DMA-hoz kell. Ha kis DMA blokkokkal dolgozol, akkor lehet még növelni, de akkor is nevetségesen kevés sok feladathoz."

Azokra ott van a PPE, vagy PPE+x SPE együtt.

"Amik csak vinyón annyik, és a memóriát meg a procit rendesen pazarolják."

A kód méretére utaltam.

"Feladat függõ, hogy lehet-e."

Itt alapvetõen párhuzamosításról van szó, és elég sokmindent lehet párhuzamosítani. Mellesleg van L1-L2 cache, ill. a belsõ ramok is, ezek által sok eset megoldódik. Csak azok maradnak fent, amiként tényleg teljesen össze-vissza kell hozzáféri nagy területhez, és egy-egy adattal csak 1-2 mûveletet kell végezni.

#343
"Igen ítrtad, de én nem erre válaszoltam, hanem erre : "Itt nem az SPE-krõl van szó, hanem a PPE-rõl (CPU mag), abban van a (2?) VMX egység." "

Ott kezdõdött, hogy azt írtad, nem-blokkos adattal nem tud kezdeni semmit az SPE. Pedig tud, csak ilyenkor be kell segítenie a PPE-nek is. Az egy másik dolog, hogy a PPE-ben is van VMX, így õ is tud számolni szépen.

"Egyébként meg az az alap mûködés, hogy a PPE irányít, de ez nem old meg minden problémát."

Hogy érted, hogy a PPE irányít? Az SPE akkor fér hozzá a külsõ ramhoz, amikor akar.

"Viszont nagyobb a késleltetése, hosszabb a futószalagja, sokkal gyengébb az optimalizáló logika, stb. (bõvebben a cikkben). Összességében egy több generációval régebbi proci magasabb órajelen."

Párhuzamosítással közömbösíthetõ a hosszabb késleltetés. Megfelelõ (fordítóra bízható) optimizáció révén az in-order végrehajtás és a gyengébb branch-prediction is, többé-kevésbé, feladattól függõen.

PC-n egy játékban a prociidõ többsége ugyancsak a megjelenítésre megy el, ide sorolva a fizikát is (vertex-adatok kezelése, atpumpálása a GPU-nak, stb.). Itt ezen feladatok jó részét átvállalhatják az SPE-k. Meg a lassan bejövõ fejlettebb AI-t is. Így nagyon sok prociidõ felszabadul!

Gondolj arra, hogy jópár éve, egy 7MHz-es, maiaknál jóval egyszerûbb procival rendelkezõ Amiga500-ra is eléggé összetett játékok is születtek. Az egyszerûbb grafika miatt kevesebb volt az ilyen irányú feladat is... Ehhez képest egy SMT-s 3,2GHz-es proci fergetegesen gyors.

"A memóri másolásokat meg hiába veszi át egy SPE, attól nem lesz gyorsabb (sõt, talán még lassabb is). És nem is a másolásról van szó, hanem kód futtatásról."

Miért lenne lassabb egy SPE másolásban? De nem az a lényeg, hogy esetleg lassabb-e vagy sem, hanem hogy nem a központi PPE-nek kell ezzel sem foglalkoznia.
Egy programban sokszor kellhet memóriát másolni.

"Kevesebb, mint egy közepes x86."

Egy tread esetén talán, 2 (x360-nál 6) esetén már nem biztos.

"Hiába, ha az SPE-dolgozna velük. Át kell tölteni az SPE-re a megfelelõ blokkot, és ez lassú. Ha egy-egy blokkból csak kis részletekre van szükség, akkor a másolgatásra elmegy a teljesítmény nagy része. Ha meg a PPE-re túl komplex vezérlõ logikát raksz, akkor annak a teljesítménye folyik el."

Tévedsz, a PPE apránként is küldhet adatot az SPE-knek, mivel hozzáfér a ramjukhoz.

#342
"A PPE-vel is hozzá lehet férni az SPE-k belsõ ramjához."

Ez tuti? Én nem így emlékszem.

#341
"Mellesleg, mint már korábban írtam, a PPE ben is ütõs a VMX egység"

Igen, de ez nem segít az SPE-ken. És x86-on is van SSE.

#340
"És még több olyan, ami meg igen. Ami meg nem ilyen, abba be tud segíteni a PPE, az ideje pár %-át feláldozva."

Az a pár % könnyen lesz 100, és akkor meg vagy lõve. És ha neked ilyen feladatot kell megoldani, akkor nem sokat segít az, hogy más fajta feladat is van.

"Miért írod elõ elõre, mennyi lesz a kód?"

Nem írom elõ, csak becsültem.

"Pl. egy mpeg dekóder néhány tíz k-ba belefér."

Konkrétan 50K-nak becsültem a kódot. A maradék a DMA-hoz kell. Ha kis DMA blokkokkal dolgozol, akkor lehet még növelni, de akkor is nevetségesen kevés sok feladathoz.

"Vagy lásd 4k-s, 16k-s demók..."

Amik csak vinyón annyik, és a memóriát meg a procit rendesen pazarolják.

"Viszont sokcsatornás. És vannak egyéb, programszervezési módszerek, amikkel ellensúlyozni lehet."

Feladat függõ, hogy lehet-e.

#339
"Mint írtam, meg lehet tenni, hogy a PPE-vel szedjük össze az adatokat (ez nem nagy terhelés), de azt egy SPE dolgozza fel."

Igen ítrtad, de én nem erre válaszoltam, hanem erre : "Itt nem az SPE-krõl van szó, hanem a PPE-rõl (CPU mag), abban van a (2?) VMX egység."
Egyébként meg az az alap mûködés, hogy a PPE irányít, de ez nem old meg minden problémát.

"Bizonyos szempontból gyengébb, más szempontból meg erõsebb. Pl. ebben igazi hw SMP van (jobb, mint az Intel féle HT), és nagyobb sávszél is áll rendelkezésre."

Viszont nagyobb a késleltetése, hosszabb a futószalagja, sokkal gyengébb az optimalizáló logika, stb. (bõvebben a cikkben). Összességében egy több generációval régebbi proci magasabb órajelen.

"A matematikai számítások többségét nem neki kell végeznie, és memória-másolásokat is át tud vállalni egy SPE."

Pedig õ is inkább matekból erõs. A memóri másolásokat meg hiába veszi át egy SPE, attól nem lesz gyorsabb (sõt, talán még lassabb is). És nem is a másolásról van szó, hanem kód futtatásról.

"Így a dual-thread-es 3.2GHz azért nem olyan kevés."

Kevesebb, mint egy közepes x86.

"De mondom, hogy a PPE-rõl van szó, az szedi össze az adatokat."

Hiába, ha az SPE-dolgozna velük. Át kell tölteni az SPE-re a megfelelõ blokkot, és ez lassú. Ha egy-egy blokkból csak kis részletekre van szükség, akkor a másolgatásra elmegy a teljesítmény nagy része. Ha meg a PPE-re túl komplex vezérlõ logikát raksz, akkor annak a teljesítménye folyik el.

#338
(Mármint az AI-ba kell majd valószínûleg besegíteni.)

#337
Nem egészen értem, amit az SPE-krõl írsz. A belsõ DMA-val lehet írni-olvasni, valószínû akkora csomagot (kerekítve pl. 1k-ra), amekkorát akarsz. A PPE-vel is hozzá lehet férni az SPE-k belsõ ramjához. Tehát, azt csak a belsõ ramban lévõ program helyfoglalása határozza meg, mekkora blokkokkal tudsz dolgozni. BiroAndras abból indult ki, hogy egy ilyen program minimum 150-200k, de ez alaptalan. Lehet az pártíz k is.
Az egy dolog, hogy a 4-16k-s demókban nincs AI, de attól még sokmindent csinálnak. Persze, egy AI többet foglalna az egyik SPE ramjából, miközben egy másik meg mindenféle mást csinál egy párkás programmal. 😊
(Valószínû a PPE-nek is be kell majd segíteni, de a számításokat csinálhatja egy<-két> SPE.)
Egyébként a kkrieger nevû 64k-s FPS-ben "AI" is van, de persze nyilván ugyanolyan scriptes, mint a többiben. És itt jön a PS3 új lehetõsége: a számítási kapacitás révén igazibb AI valósítható meg, a scriptes megoldások helyett...

[Jakuza]
#336
Na azert nem csak etetni kell a VPEket, hanem ki is kell olvasni belolluk az adatot, tehat egyszerre nem lehet valosagosan felhasznalni a 256k-t egy muveletre.
Tehat Biro Andrisnak igaza van akkor amikor azt mondja, hogy mekkora adatcsomagokkal dolgothatsz egyszerre.
A 4k-s meg 16k-s demokat meg ne hasonlitunk mar ossze egy jatekprogrammal.
Ott nincs AI, nincs periferiakezeles es sorolhatnam.

Dez: Inkompatibilitas definicioja jatekoknal: amikor fut,de csak pl. 1 fps-sel,vagy össze-vissza akadozva,irányíthatatlanul 2. K8-nál alapból mindig 200MHz az FSB. Csak tuning által lesz magasabb.

#335
Mellesleg, mint már korábban írtam, a PPE ben is ütõs a VMX egység (azt hiszem, 128 bites - x86-on csak a Conroe-val lett 128 bites, plusz brutálisan sok regiszter van hozzá, abból is rögtön 2 készlet a dual-thread-hez), ráadásul valószínû 2db van belõle. Tehát nem-blokkos számítási mûveletekhez is nagyon jó.

#334
"Ez csak akkor ér valamit, ha az adatot sorban lehet feldolgozni, és nem kell össze-vissza ugrálni rajta. Sok olyan feladat van, ami ezt a feltételt nem teljesíti."

És még több olyan, ami meg igen. Ami meg nem ilyen, abba be tud segíteni a PPE, az ideje pár %-át feláldozva.

"És azt se felejtsd el, hogy a 256K RAM van összesen, tehát ebbe bele kell férnie a kódnak, és a DMA által írt/olvasott buffereknek. Tehát kb. 50-100K adatcsomagokkal dolgozhatsz."

Miért írod elõ elõre, mennyi lesz a kód? Ez esetre válogatja. Pl. egy mpeg dekóder néhány tíz k-ba belefér. (Ne egy full codec+demux párost vegyél alapul, amiben enkóder is van, és minden formátumot ismerõ demux, stb.) Vagy lásd 4k-s, 16k-s demók...

"Igen, de a késleltetése sokkal rosszabb."

Viszont sokcsatornás. És vannak egyéb, programszervezési módszerek, amikkel ellensúlyozni lehet.

#333
"Pont arrõl van szó, hogy így nem az SPE-ket használjuk, hanem a PPE-t terheljük még jobban"

Mint írtam, meg lehet tenni, hogy a PPE-vel szedjük össze az adatokat (ez nem nagy terhelés), de azt egy SPE dolgozza fel.

"ami egy x86 procinál jóval gyengébb (a cikkben benne van, hogy miért, de máshol is olvastam már)."

Bizonyos szempontból gyengébb, más szempontból meg erõsebb. Pl. ebben igazi hw SMP van (jobb, mint az Intel féle HT), és nagyobb sávszél is áll rendelkezésre. A matematikai számítások többségét nem neki kell végeznie, és memória-másolásokat is át tud vállalni egy SPE. Így a dual-thread-es 3.2GHz azért nem olyan kevés.

"Úgy egyszerre, hogy nincs idõ közben a lokális memória tartalmát cserélgetni.
Pl. ha egy több megás tömb tartalmára nem sorban van szükség (pl. gráf)."

De mondom, hogy a PPE-rõl van szó, az szedi össze az adatokat.

#332
"De ha az SPE-ket vesszük: egyrészt mindegyikhez van 256KB local ram, ami elég ahhoz, hogy blokkonként olvashasson, és aztán magában dolgozhasson."

Ez csak akkor ér valamit, ha az adatot sorban lehet feldolgozni, és nem kell össze-vissza ugrálni rajta. Sok olyan feladat van, ami ezt a feltételt nem teljesíti.
És azt se felejtsd el, hogy a 256K RAM van összesen, tehát ebbe bele kell férnie a kódnak, és a DMA által írt/olvasott buffereknek. Tehát kb. 50-100K adatcsomagokkal dolgozhatsz.

"Harmadrészt jóval nagyobb sávszél áll rendelkezésre, mint PC-n megszokott."

Igen, de a késleltetése sokkal rosszabb.

#331
"Itt nem az SPE-krõl van szó, hanem a PPE-rõl (CPU mag), abban van a (2?) VMX egység."

Pont arrõl van szó, hogy így nem az SPE-ket használjuk, hanem a PPE-t terheljük még jobban, ami egy x86 procinál jóval gyengébb (a cikkben benne van, hogy miért, de máshol is olvastam már).

"Mi az, hogy egyszerre? Egy proci csak szép sorjában tud hozzáférni az adatokhoz."

Úgy egyszerre, hogy nincs idõ közben a lokális memória tartalmát cserélgetni.
Pl. ha egy több megás tömb tartalmára nem sorban van szükség (pl. gráf).

#330
A BiroAndras által írt útkereséshez, és más efféléhez épp elég. (A PPE-n futó kódról van szó, nem az SPE-krõl.)

De ha az SPE-ket vesszük: egyrészt mindegyikhez van 256KB local ram, ami elég ahhoz, hogy blokkonként olvashasson, és aztán magában dolgozhasson. Másrészt speciális memória-rendszer van, ami több párhuzamos hozzáférést tud optimálisan lekezelni. Végülis többcsatornás a memória-rendszer. Harmadrészt jóval nagyobb sávszél áll rendelkezésre, mint PC-n megszokott.

[Jakuza]
#329
Hiaba a 7 vagy 8 mag ha a savszelesseg nem eleg.
Kb olyan effektus johet letre, mint egy telthazas koncert amikor veget er es az emberek csak az egy kinyitott kijaraton tudnak tavozni. 😛

Dez: Inkompatibilitas definicioja jatekoknal: amikor fut,de csak pl. 1 fps-sel,vagy össze-vissza akadozva,irányíthatatlanul 2. K8-nál alapból mindig 200MHz az FSB. Csak tuning által lesz magasabb.

#328
"Lehet, de pl. az útkeresés nem igazán neki való feladat. És akkor ott hevernek parlagon az SPE-k."

Itt nem az SPE-krõl van szó, hanem a PPE-rõl (CPU mag), abban van a (2?) VMX egység. Ez kb. az SSE1-2-3 egységnek felel meg. Tehát normál kódba ágyazott SIMD számításokról.

"Ez nem segít azon, hogy egyszerre kell elérni az adatot."

Mi az, hogy egyszerre? Egy proci csak szép sorjában tud hozzáférni az adatokhoz. (Dualcore is csak kettesével.)

#327
"A PPE-ben lévõ (duplázott?) VMX is szép teljesítményt ad, azzal is lehet számolni (ha a sima FPU nem elég)."

Lehet, de pl. az útkeresés nem igazán neki való feladat. És akkor ott hevernek parlagon az SPE-k.

"Vagy meg lehet tenni, hogy a PPE-vel szedjük össze az adatokat, és átadjuk az egyik SPE-nek."

Ez nem segít azon, hogy egyszerre kell elérni az adatot.

#326
Halál DjDano-ra!<#mf1><#boxer><#violent>
#325
A PPE-ben lévõ (duplázott?) VMX is szép teljesítményt ad, azzal is lehet számolni (ha a sima FPU nem elég). Vagy meg lehet tenni, hogy a PPE-vel szedjük össze az adatokat, és átadjuk az egyik SPE-nek.

#324
"Nem inkább a szimuláció élethûségére goldolsz?"

Nem, mivel nem szimuláció, hanem RTS. De valami hasonlóról van szó. A lényeg, hogy a megjelenített világ lehetõleg úgy nézzen ki, és úgy viselkedjen, mint az igazi.

"Ja, hogy be lehet menni közéjük. De azért ezekbõl sincs több párzezernél, és azt a kevéske számolást, amit egy ilyen "collosion" jelent, a fõprocimag is secperc alatt ledarálja, nem nagyon kell ide SPE."

Nem is a proci a gond, hanem a memória. Arra írtam példának.

"De ha van szabad SPE-kapacitás, megoldható, hogy a fák adatai, és az egységek (ide vonatkozó) adatai blokkosan beolvashatók legyenek."

Ezt csak arra írtam, hogy a gamelogic mennyi mindennel összefügg.
Ami igényelné az SPE-ket, és szerintem problémás a kevés memória miatt, az pl. az útkeresés. Elég számításigényes, és nem igazán lehet blokkosan olvasni hozzá az adatot.

#323
"Nem a sávszélesség a gáz, hanem a késleltetés."

A belsõ busz késleltetése is elég jó. (Egyébként jópár bájtokat egyidõben visz át.)

"Azért volt pár eléggé összetett játék már akkor is."

"élethûvé teszik a megjelenítést."

Nem inkább a szimuláció élethûségére goldolsz? 😉

"Rengeteg apróság összeadódik."

Akkor is igen soknak tûnik.

"Messze nem csak grafika. Pl. az egységeknek ki kell kerülniük, vagy épp ki kell dönteniük."

Ja, hogy be lehet menni közéjük. De azért ezekbõl sincs több párzezernél, és azt a kevéske számolást, amit egy ilyen "collosion" jelent, a fõprocimag is secperc alatt ledarálja, nem nagyon kell ide SPE. De ha van szabad SPE-kapacitás, megoldható, hogy a fák adatai, és az egységek (ide vonatkozó) adatai blokkosan beolvashatók legyenek.

#322
Nekem (is) leesett kicsit az állam. A "sok" mag mellett még össz. 2,5MB belsõ ram... (Persze késõbb ez már nem lesz nagy cucc, de ma még nem semmi.)

NEXUS6
#321
Hát nemtom.
Én is tervezgetek magamnak egy valósidejû zûrstratégiát. 20 lakható bolygó kb 30 naprencer, valós fizika, rengeteg NPC. A teljes adatbázis 20 megára saccolom, a kód 10-20 mega. Természetesen a 3D nyalánkságokat nem tudom megsaccolni, hogy hány giga lenne (ha valakit tudnék ilyen dologra találni).

De a fapados játék szerintem 40 megából összehozható.

Histeria est magistra vitae. Ez nem trollkodás, ez online graffiti! ;) https://suno.com/@nexus65ongs

#320
"Lassab, de semmiképpen sem lassú, mert egy belsõ, nagy sávszélû buszon történik."

Nem a sávszélesség a gáz, hanem a késleltetés.

"Azért volt pár eléggé összetett játék már akkor is."

Sokféle értelemben lehet összetett a játék. Pl. a játékmenet simán lehet komplex anélkül, hogy komolyn hardvert igényelne. Én viszont nem erre gondoltam, hanem arra a sok kis részletre, amik a nagy poligonszám, és az effektek mellett élethûvé teszik a megjelenítést. Pl. körökre osztott helyett valósidejû játék. Meg négyzetrácsos helyett vektoros pálya, és azonos méretû helyett méretarányos egységek (ezek elég durván megnehezítik az útkeresõ dolgát). Primitív szkriptek helyett AI.

"Huh, az rohadt sok. Nem vigyáztok eléggé. 😊 Mire megy el ennyi?"

Rengeteg apróság összeadódik.

"Na de a fák a grafikához tartoznak, nem a lényegi game-logic-hoz..."

Messze nem csak grafika. Pl. az egységeknek ki kell kerülniük, vagy épp ki kell dönteniük.

[Jakuza]
#319
Akkor en ezt rosszul tudtam. 😛

Dez: Inkompatibilitas definicioja jatekoknal: amikor fut,de csak pl. 1 fps-sel,vagy össze-vissza akadozva,irányíthatatlanul 2. K8-nál alapból mindig 200MHz az FSB. Csak tuning által lesz magasabb.

#318
256KB/SPE! 😊
(A PPE L2-je 512KB.)

[Jakuza]
#317
Erre mondtam, hogy amikor fetcheled az osszes SPEnek az adatot az gaz, ha az osszes szamara kell 256K-bol dolgozni.
Szerintem a mai rendelkezesre allo technologia mellett nem artott volna, ha 1MBs cacheval keszitettek volna a Cellt.

Dez: Inkompatibilitas definicioja jatekoknal: amikor fut,de csak pl. 1 fps-sel,vagy össze-vissza akadozva,irányíthatatlanul 2. K8-nál alapból mindig 200MHz az FSB. Csak tuning által lesz magasabb.

#316
De ez nem jelent áthidalhatatlan akadályt. Nem nagy dolog szegmentálni a kódot, blokkosan kezelni az adatokat. Az mondjuk érdekes helyzet, ha teljesen véletlenszerûen kell hozzáférni sok mega adathoz. De ez sem reménytelen: össze lehet gyûjteni az adatokat, és utána egyben kezelni.

#315
"Igen. Azt jelenti, hogy írhatok és olvashatok blokkokat, de mûveleteket végezni nem tudok."

Nem, nem feltétlenül csak blokkos hozzáférést jelent. Csak annyit jelent, hogy a procitól független memóriahozzáférés. Lehet az akár bájtos(/wordös/longwordös/stb.) is. (Ismerek ilyen rendszereket.)

"Az úgy már elég lassú szerintem."

Lassab, de semmiképpen sem lassú, mert egy belsõ, nagy sávszélû buszon történik.

"Igen, csak fícsörben sehol nem volt a maiakhoz képest (és nem csak grafikára gondolok)."

Hát... Azért volt pár eléggé összetett játék már akkor is.

"Dehogynem. Nálunk pl. van vagy 300 mega. NAgyon el tud ám szaporodni, ha nem vigyáz az ember."

Huh, az rohadt sok. Nem vigyáztok eléggé. 😊 Mire megy el ennyi?

"Az nagyon jó lenne, de sajnos ennél sokkal több. Plusz gyakran hozzá kell férni a modelekhez is, ami pláne sok."

Oké, ez a jétéktól függ.

"Láttam olyan pályát, amin csak fából volt ennyi..."

Na de a fák a grafikához tartoznak, nem a lényegi game-logic-hoz...

#314
Egybként még nem tudom, mennyire gázos. Majd ha lesz PS3 devkit a cégnél, és lesz idõm játszani vele, akkor kiderül.