513
-
dez #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. -
dez #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. -
dez #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 [ha blokkos, de általában az]).
"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.) -
BiroAndras #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." -
BiroAndras #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. -
BiroAndras #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. -
BiroAndras #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. -
dez #346 Én meg igen. :) -
dez #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). -
dez #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. -
dez #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. -
BiroAndras #342 "A PPE-vel is hozzá lehet férni az SPE-k belső ramjához."
Ez tuti? Én nem így emlékszem. -
BiroAndras #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. -
BiroAndras #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. -
BiroAndras #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. -
dez #338 (Mármint az AI-ba kell majd valószínűleg besegíteni.) -
dez #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]](https://media.sg.hu/forum/avatars/10427091571053517846.jpg "[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 #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ó. -
dez #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. -
dez #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. -
BiroAndras #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. -
BiroAndras #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). -
dez #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. -
#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. :P -
dez #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.) -
BiroAndras #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. -
TommyVercetti #326 Halál DjDano-ra! 
-
dez #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. -
BiroAndras #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. -
dez #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. -
dez #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.) -
#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ó. -
BiroAndras #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. -
#319
Akkor en ezt rosszul tudtam. :P -
dez #318 256KB/SPE! :)
(A PPE L2-je 512KB.) -
#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 #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. -
dez #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... -
BiroAndras #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.