74
-
Sir Ny #74 "Tehat gyakorlatilag a ps3 magja egy blue-ray player kore epult"
a blu-ray player magja epult a ps3 kore. (ill. a blu-ray player epult a ps3 magja kore) -
Sir Ny #73 "Mi ebben az üzlet, amikor valamit 2X-is el lehet adni?"
ugye nem hiszed, hogy valaki megveszi a játékot boxra és pcre? még ha azt írtad volna hogy letölti a játékot, akkor talán még rendben lenne, de ez nonszensz. -
Sir Ny #72 "Egy ismert jétékipari cég most jelentette be, hogy játéktermi gépeket épít Cell+RSX alapon, csak több memóriával, és játékokat is fejleszt hozzájuk, amiket utána visszaportolnak PS3-ra is."
ha már ismert az a jétékipari cég, akkor esetleg azt is elárulhatnád, hogy melyik az... -
Golodin #71 http://s3.bitefight.hu/c.php?uid=28668
-
dez #70 erm, cache :) -
dez #69 1-2 korrekció a korábbiakhoz:
- Az SPE-k nem a szabványos PowerPC instruction setet használják, bár hasonlót (és van mindenféle általános célú művelet, plusz nem csak floating-pointot tud, hanem normál integert is).
- Az SPE-k nem tudják címezni egymás lokális sramját, de attól még könnyen és gyorsan tudnak adatot cserélni egymással. (Lásd Atomic Chace Facility.) -
dez #68 (SPE = SPU + LS + DMA + MMU) -
dez #67 Ott nem az SPE-k LS-eiről (Local Storage nevű RAM, tehát címezhető, szokásos memóriaként használható tár) van szó (az a 256KB/SPE), hanem arról, hogy ezen kívül is van egy minimális cache az SPE-kben (512 byte), és egy ezzel kapcsolatos fícsörről.
Részben éppen arról vitáztunk, amit a 256KB-os (/SPE) LS-ről írsz. Csak kvp egy olyan, kissé kitekert példát hozott fel, amit nem lehet stream-szerűen feldolgozni. És ebből a példából kiindulva vonta le azt a végső következtetését, hogy a Cell használhatatlan, mindent 10x bonyibb megcsinálni vele, stb. stb. (Korábban meg azt próbálta elhinteni, hogy az SPU-k mikrokontolleres DSP-k, párszáz byte bufferrel, stb.) -
gforce9 #66 "Amúgy meg egy progi elkészítéséhez nem programozó kell sok, legfeljebb vesz egy enginet a cég."
ez pc-n működik mert van sok kiforrott engine, PS-en még kiforratlanok vannak. A kiforratlant úgy értem, hogy egy konzolnál főleg kell foglalkozni a motorral, hiszen a hadver nem lesz erősebb évek múltával, mint egy PC-nél. A PS-nek pont az az ütőkártyája, hogy vannak tartalékai, mert még nincs kihasználva, de ahhoz hogy ki legyen használva, sok hozzáértő programozó szükséges.
-
#65
Huh teccik a vita!
Még éppen értem az én csökevényes programozói tudásommal (asszem), minden esetre érdekes lehet a Cell azon "kicsiny" bár nem elhanyagolható jelentőségű fícsőre, ami az alant található linken található:
Atomic Cache Facility
Nekem mint programozó-analfabétának ez azt mondja, hogy a DMA feladatok nagyrésze megspórolható, mindegyik SPE dolgozhat a maga 256KB-os cachebe és csinálhatja az alanat említett példa feladat rá eső ciklusát. Szal 3 SPE és 3 összehangolt ciklus lefuttatásával megoldható!!! Ja és az SPE-k közben sokkal kiseb mértékben fordulnak a DMA-hoz is, így full sebességgel tudnak dolgozni, gyakorlatilag összehangolva egyetlen egységként!
kvp
Szerintem mondasz azért okosságot is, csak annyira egy dolgot akarsz bebizonyítani, hogy az okosságokból az amit mondani akarsz nem biztos hogy következik.
Pl. lehet hogy a halo népszerű progi az x platformon, de ha azt nézed, hogy más az X360-nál is népszerűbb platformokon (mer azért van ilyen is 1-2) is vannak legalább ennyire népszerű progik, nos akkor rájösz, hogy a halonak csak az Xbox fanok szempontjából van jelentősége. Azok az emberek akik haloval akartak játszani már megvették a boxot, a világ nagyobbik felét viszont hidegen hagyja!
Halo, PGR, Forza, esetleg Mass effect valójában ennyi és nem több az X exluzív listája (már ami számít is, mert a Bombastic Bomber Alien Attack from Space III c. X exkluzív cím csak 1-2 embert fog érdekelni).
Amúgy meg egy progi elkészítéséhez nem programozó kell sok, legfeljebb vesz egy enginet a cég. Hanem a médiafájlokat elkészítő grafikusokból, zenészekből, modellerekből!
Szal tök mindegy hogy az enginet min fejlesztik, Linuxon, vagy Win-en. Akit érint az úgy is ismerni fogja.
Asszem a Naughtydog egyik fejlesztője mondta, hogy arra a platformra fognak fejleszteni ami a legnagyobb bevétellel kecsegtet, ha kell mert igényes a hardwer, akkor tövig koptatják a programozók az újjukat de megcsinálják.
Nem csak lusta hozzánemértő, M$ nevelésű programozók vannak a világon, hanem olyanok is akiknek azért ez a munkájuk, mert ezt szeretik csinálni és mert értenek hozzá, pont mint a te esetedben is. Gondolom;))) -
dez #64 "Es ha nem? Akkor a programozo nem hasznalja az SPE-t? Vagy valszt egy masik architekturat? (tobbnyire ez a ket opcio van, gondolkodni valoszinuleg nem fog nagyon)"
Attól függ. Ha a feladat adott, és a platform szabadon választható, akkor elgondolkodhat, melyikkel éri meg jobban dolgozni. Ha viszont mindkettő adott, akkor kénytelen egy picit megerőltetni az agytekervényeit. És mint már írtam, ott van az az opció a Cellnél is, hogy a PPE bonyolítja a véletlenszerű hozzáféréseket (akár csak az idejének tört részében), és az SPE-k számolnak. (Pl. egy blade-nél ugye nincs játéklogika, van elég ideje a PPE-nek.)
"A vektorfeladat jelen esetben nem vektorgrafikat jelent, hanem vektorprocesszorral megoldhato feladatot. Ilyen feladat a kepfeldolgozas is, pl. a voxeltombok kezelese"
Van egy kis különbség a 2D képfeldolgozás, és a voxeles dolgok között, talán ne az utóbbit vedd elő az első tipikus példájaként. Az elsőben nagyon is jó lehet a Cell, de adott esetben az utóbbiban is.
"ami egy 3d-s tomb tehat nagyon sok ram kell hozza viszont viszonylag veletlenszeru az elerese. At lehet rendezni, mondjuk 256x256x256-os altombokre, de meg az is 16Mb/tomb."
És miért is ne lehetne adott esetben jóval kisebb blokkokban feldolgozni?
"Ebbol egy vetitosugar eleg keveset hasit ki."
Nem egészen értem itt a vetítősugár említését, jellemzően inkább metszeti képeket szoktak csinálni pl. gyógyászati alkalmazásokban.
"Egyebkent egy 100 ezer poligonos modell mar nem fer be az spe-be, mivel csucsonkent 32 byte adat szokott minimum kelleni (7 float, 1 integer), tehat 3.2Mb lenne a modell merete, ha a csucsok redundaciaja miatt 1 poligon = 1 csucs az arany."
Jó, akkor legyen 65536 poligonos, az már befér az összesen 2MB-ba. Ez sem éppen kicsi, a játékokban nem túl jellemző...
"Ha ebbol akarunk dinamikus lod-ot generalni vagy esetleg morph-olni, akkor vagy a kozponti processzor csinalja vagy a videokartya, ha tud geometry feedback-et. Az spe ehhez egyszeruen nem idealis."
1. Ekkora objektek nem igazán jellemzőek játékokban.
2. A kisebbek kényelmesen elférnek.
3. LOD-ot generálni szerintem lehet kisebb blokkokban is.
4. Legtöbbször morholásokat is.
5. Miért nem inkább a fizikát hozod fel, ahol akár az összes elem függ a többitől? De tudtommal még azt is lehet blokkosan csinálni.
"Egyszer sem erkezett ra reakcio."
Dehogynem, csak részletekben.
"Azt probaltam elmondani, hogy nem szamit mi a jobb technikailag hanem hogy mi hoz gyorsabban tobb penzt. Az eredeti cikk pont errol szol."
Valakinek a gyors, de nem túl nagy bevétel számít, másnak meg a lassabb, de nagyobb. A PS3-mal meg lehet valósítani olyan dolgokat, amit az x360-nal és főleg a Wiivel nem. A PS3 nagyobb durranásai később fognak jönni.
"Nem tudom miert veded annyira a cell-t, a tobbi processzorral szemben, de nem akkora talalmany hogy megerje ennyit foglalkozni vele."
Én nem így goldolom.
"Ha valaki fogna 1024 db egyszeru altalanos processzort es belerakna egy chipbe"
LOLLLLLLER.
1. Az "egyszerű" és az "általános" eleve ütik egymást!
2. Az "általános" esetét véve: 2 évente duplázódik a magszám, így - ha tartani tudják ezt az ütemet - elvileg 2022-ben lesz/lenne 1024 magos általános proci. Most 2007-et írunk...
3. Még csak most mutattott be az Intel egy kísérleti 80 magos procit, ami matematikai számításokra lett tervezve (tehát nem általános) - még évekbe tellik, mire termék lesz belőle, ha egyátalán működőképes a dolog.
4. A legújabb unified shaderes GPU-k egyes shader egységei nagyon messze állnak egy általános procimagtól, de még a Cell SPE-itől is. Sok, gyors, de buta multiply+add egységek halmaza, kisebb számú speciális function egységgel, alapműveleteken kívül minden másban (kevés ilyen dolog van) alacsony teljesítménnyel.
"ugy hogy minden processzort hardverbol tudna scheduler alapu smt-t kezelni a load/store wait-ek elkerulesere, akkor azt mondanam az egy jo chip."
Ébredj fel, bilibe ér a kezed! Ez itt 2007...
"Az nvidia g80-as architekturaja kozelebb all ehhez az idealis, konnyen programozhato chiphez. (es valahogy megoldottak, azt hogy az egesz ram-ot latja minden processzor)"
LOLLLLLLER. Ekkora hülyeségeket ne beszélj már!
1. Nem is állhatna messzebb, általános műveletvégzésre egyátalán nem ideális, számításokra is csak bizonyos esetekben. Lásd fenti 4-es pont!
2. Ez van aztán igazán stream feldolgozásra kialakítva.
3. Egyátalán nem könnyű programozni, tele van korlátokkal, megkötésekkel a dolog, stb.
"Szerintem erdemes lenne befejezni a vitat"
Hát valóban, mert össze-vissza beszélsz.
"ugy sem tudlak meggyozni arrol, hogy a nintendo jobban jart anyagilag amikor egy olcso es primitiv processzort valasztott"
Rövíd életű lesz ez a siker.
"es hogy meg a microsoft is inkabb a haszonra jatszik mint a technologiai uttoro szerepere."
Ezt tudjuk...
"Ez az en velemenyem, ha nem ertesz egyet akkor azt tiszteletben tartom, de a sajatomat megvaltoztatni nem fogom."
Ja, inkább ahhoz igazítod a "tényeket", ugyi...? -
kvp #63 ""Es mindez egy sima egysoros for ciklus kedveert? Mit csinalnal egy 8-szorosan egymasbaagyazott for ciklussal??? 32 for ciklust? Csak azert kerdezem, mert sajnos van olyan problema aminel szukseg van a 8 ciklusra"
Ha belefér elegendő adat egy vagy több SPE ramjába, akkor nem kell több ciklus."
Es ha nem? Akkor a programozo nem hasznalja az SPE-t? Vagy valszt egy masik architekturat? (tobbnyire ez a ket opcio van, gondolkodni valoszinuleg nem fog nagyon)
""A PPE feladata az uzleti logika (jatekszabalyok) futtatasa kellene hogy legyen, nem az SPE-k etetese tipikus vektorfeladatok adataival vagy ezek kiszamitasa."
Egyébként milyen vektorfeladatban is van szükség többmegás tömbök keresztül-kasul elérésére? Egyszerre egy objektummal szoktak számolni, ami általában pártízezer, esetleg 1-2 százezer csúcspont-számú..."
A vektorfeladat jelen esetben nem vektorgrafikat jelent, hanem vektorprocesszorral megoldhato feladatot. Ilyen feladat a kepfeldolgozas is, pl. a voxeltombok kezelese, ami egy 3d-s tomb tehat nagyon sok ram kell hozza viszont viszonylag veletlenszeru az elerese. At lehet rendezni, mondjuk 256x256x256-os altombokre, de meg az is 16Mb/tomb. Ebbol egy vetitosugar eleg keveset hasit ki. Hogy konkretan mit kodolok a fizetesemert az sajnos nem publikus...
Egyebkent egy 100 ezer poligonos modell mar nem fer be az spe-be, mivel csucsonkent 32 byte adat szokott minimum kelleni (7 float, 1 integer), tehat 3.2Mb lenne a modell merete, ha a csucsok redundaciaja miatt 1 poligon = 1 csucs az arany. Ha ebbol akarunk dinamikus lod-ot generalni vagy esetleg morph-olni, akkor vagy a kozponti processzor csinalja vagy a videokartya, ha tud geometry feedback-et. Az spe ehhez egyszeruen nem idealis.
"...
Ezt a rantingot hányszor fogod még előadni? Talán elég lenne csak pl. minden 5. hozzászólásban."
Egyszer sem erkezett ra reakcio. Azt probaltam elmondani, hogy nem szamit mi a jobb technikailag hanem hogy mi hoz gyorsabban tobb penzt. Az eredeti cikk pont errol szol. Nem tudom miert veded annyira a cell-t, a tobbi processzorral szemben, de nem akkora talalmany hogy megerje ennyit foglalkozni vele. Ha valaki fogna 1024 db egyszeru altalanos processzort es belerakna egy chipbe, ugy hogy minden processzort hardverbol tudna scheduler alapu smt-t kezelni a load/store wait-ek elkerulesere, akkor azt mondanam az egy jo chip. Az nvidia g80-as architekturaja kozelebb all ehhez az idealis, konnyen programozhato chiphez. (es valahogy megoldottak, azt hogy az egesz ram-ot latja minden processzor)
Szerintem erdemes lenne befejezni a vitat, ugy sem tudlak meggyozni arrol, hogy a nintendo jobban jart anyagilag amikor egy olcso es primitiv processzort valasztott, es hogy meg a microsoft is inkabb a haszonra jatszik mint a technologiai uttoro szerepere. Ez az en velemenyem, ha nem ertesz egyet akkor azt tiszteletben tartom, de a sajatomat megvaltoztatni nem fogom. -
dez #62 "Es mindez egy sima egysoros for ciklus kedveert? Mit csinalnal egy 8-szorosan egymasbaagyazott for ciklussal??? 32 for ciklust? Csak azert kerdezem, mert sajnos van olyan problema aminel szukseg van a 8 ciklusra"
Ha belefér elegendő adat egy vagy több SPE ramjába, akkor nem kell több ciklus.
"Szenvedtem vele eleget, legyeny annyi eleg, hogy mintaillesztesrol van szo nagy adatmennyisegre, amiben pont a cell-nek kellene jonak lennie."
És miért is ne lenne az? Hány megányi az a "minta", amit illeszteni kell?
"(ps3-ast meg nem programoztam, cell-t mar igen"
Az eddigiekre tekintettel nem hiszem el.
"Jatekokat csak hobbibol fejlesztek, azt is ritkan. Sokkal komolyabb a munkam, de van koze a jatekfejlesztesnel is szukseges algoritmusokhoz, csak ez elesben megy."
Huhuhuhúúúú. Kicsit sem vagy elszállva magadtól.
"A PPE feladata az uzleti logika (jatekszabalyok) futtatasa kellene hogy legyen, nem az SPE-k etetese tipikus vektorfeladatok adataival vagy ezek kiszamitasa."
Egyébként milyen vektorfeladatban is van szükség többmegás tömbök keresztül-kasul elérésére? Egyszerre egy objektummal szoktak számolni, ami általában pártízezer, esetleg 1-2 százezer csúcspont-számú...
"De mivel a legtobb programozo csak a PPE-re tud kapasbol jo kodot irni, ezert jobban jarunk ha egy gep kap 3 PPE-t, mintha kap 8 SPE-t. Nem a teljesitmeny miatt, hanem mert igy jobb a programozonak es jobb a programozo cegenek is. A teljesitmeny uzleti szempontbol nem fontos, boven eleg ha optimalizalas nelkul gyorsan kesz a program es a vasarlo megveszi a termeket. 3 altalanos cpu-ra jobb fejleszteni, ahol a tervezesi limitek olyan magasan vannak hogy elobb fogy el minden eroforras (pl. rendszer memoria) mint hogy tullepjuk a cimzesi es egyebb tervezesi korlatokat. Legfeljebb egy picit szaggat a program, de pillanatok alatt osszerakhato. Egy rendszer nem attol jobb, hogy technikailag jobb, hanem attol hogy tobb penzt hoz. (lasd a sony esetet a betamax-al, ami tenyleg jobb, csak hat a vhs olcsobb volt)"
Ezt a rantingot hányszor fogod még előadni? Talán elég lenne csak pl. minden 5. hozzászólásban. -
kvp #61 "2. Több oldalas program? LOL. 4 egymásba ágyazott for ciklus, néhány dma-s olvasás-hívás, és pár egyéb egyszerű művelet. Ennyi."
Es mindez egy sima egysoros for ciklus kedveert? Mit csinalnal egy 8-szorosan egymasbaagyazott for ciklussal??? 32 for ciklust? Csak azert kerdezem, mert sajnos van olyan problema aminel szukseg van a 8 ciklusra, es ha nincs eleg kozvetlen eleresu ram (vagy eppen nem eleg nagy a cache) akkor nagyon lassuva valik a dolog. Lehet particionalni a problemat, de az viszont sokkal bonyolultabb programot eredmenyez. Szenvedtem vele eleget, legyeny annyi eleg, hogy mintaillesztesrol van szo nagy adatmennyisegre, amiben pont a cell-nek kellene jonak lennie. Nem az, meg az ibm fele cell blade-ben sem, pedig csak fixpontos szamitasok vannak. (ps3-ast meg nem programoztam, cell-t mar igen, ha tobb ram lenne a ps3-ban akkor jobban megerne mint az ibm blade-ek, igy inkabb csak otthoni pc kategoria)
"3. Ha ez neked egy nagynehezen megoldható és leprogramozható feladat, akkor talán nem programozással kellene foglalkoznod. Legalábbis nem játékprogramozás (de nem is ezt csinálod szerencsére), ahol ennél sokkal bonyolultabb dolgok is vannak."
Jatekokat csak hobbibol fejlesztek, azt is ritkan. Sokkal komolyabb a munkam, de van koze a jatekfejlesztesnel is szukseges algoritmusokhoz, csak ez elesben megy.
"(4. A leírt eljárást lehetne még alaposan gyorsítani azzal, ha a DMA műveletek másik bufferekbe töltenének, mint amikben a párok keresése zajlik - egymást nem zavarva, sávszélességet nem elvéve! És ez is csak minimálisan bonyolítaná meg. Nem beszélve a következőkről.)
5. Olyan feladatot húzol elő, ami egyátalán nem az SPE-knek való, és úgy állítod be, mintha ez lenne az általános eset."
Vegul egy ennel csak egy kicsit bonyolutabb problemat sikerult egy altalanos vektorprocesszorral megoldatni, csak a memoria merete kellett hogy nagyobb legyen. Es mivel pont befert az L2 cache-be a tejes dataset (10 Mb) ezert sikerult majdnem olyan gyors memoriahozzaferest produkalni mint a cell spu-janak a belso ramjaban. (azaz 1 orajeleset) A ps3 rendszer ram-ja eleg gyors lehetne igy is, csak nem erre terveztek a processzort.
"6. Konzekvensen "megfeledkezel" a következőkről - annak ellenére, hogy direkt figyelmeztettelek rájuk:
- A Cellben van egy átalános, a memóriát szokásosan elérő proci-mag is, a PPE, amivel ugyanúgy egy sor (C-ben) ez a dolog!
- A PPE hozzáfér az SPE-k ramjához, pl. beírhatja nekik a main memóriából össze-vissza összeszedett értékeket, stb. Tehát a feladatokat szét lehet osztani a PPE és az SPE-k között úgy, hogy mindkettő a számára legjobban fekvőt csinálja.
- Az SPE-k hozzáférnek egymás memóriájához is, azaz ha szükséges, nem 256KB-tal kell gazdálkodni, hanem lehet akár 2MB-tal is! Ez már nem olyan kevés.
- Ha éppenséggel nem csak összeadni kell számokat, hanem bonyolultabb, lassabb műveletet végezni, máris fordul a kocka, és kijön a több mag és a gyors belső memória előnye."
A PPE feladata az uzleti logika (jatekszabalyok) futtatasa kellene hogy legyen, nem az SPE-k etetese tipikus vektorfeladatok adataival vagy ezek kiszamitasa. De mivel a legtobb programozo csak a PPE-re tud kapasbol jo kodot irni, ezert jobban jarunk ha egy gep kap 3 PPE-t, mintha kap 8 SPE-t. Nem a teljesitmeny miatt, hanem mert igy jobb a programozonak es jobb a programozo cegenek is. A teljesitmeny uzleti szempontbol nem fontos, boven eleg ha optimalizalas nelkul gyorsan kesz a program es a vasarlo megveszi a termeket. 3 altalanos cpu-ra jobb fejleszteni, ahol a tervezesi limitek olyan magasan vannak hogy elobb fogy el minden eroforras (pl. rendszer memoria) mint hogy tullepjuk a cimzesi es egyebb tervezesi korlatokat. Legfeljebb egy picit szaggat a program, de pillanatok alatt osszerakhato. Egy rendszer nem attol jobb, hogy technikailag jobb, hanem attol hogy tobb penzt hoz. (lasd a sony esetet a betamax-al, ami tenyleg jobb, csak hat a vhs olcsobb volt)
Kedves dez, bizonygatod hogy a cell jobb technikailag. Ez _igaz_, csak eppen nem jo _uzleti_ szempontbol, ahol az olcson-gagyit-gyorsan elv ervenyesul. A wii is pont ezert nyereseges. Nem er annyit amennyiert adjak, de megis veszik es ezzel agyonkeresi magat a nintendo, mig a sony csak veszit a minosegen. -
dez #60 1. 7 óra alatt? LOL. Gondolod, hogy nincs más dolgom, mint veled feladványosdit játszani? Nézd csak meg, mennyi idő telt el a két hozzászólásom között! Eleve csak 1,5 óra. De ebből is csak kb. negyed óra volt a "feladattal" töltött idő.
2. Több oldalas program? LOL. 4 egymásba ágyazott for ciklus, néhány dma-s olvasás-hívás, és pár egyéb egyszerű művelet. Ennyi.
3. Ha ez neked egy nagynehezen megoldható és leprogramozható feladat, akkor talán nem programozással kellene foglalkoznod. Legalábbis nem játékprogramozás (de nem is ezt csinálod szerencsére), ahol ennél sokkal bonyolultabb dolgok is vannak.
(4. A leírt eljárást lehetne még alaposan gyorsítani azzal, ha a DMA műveletek másik bufferekbe töltenének, mint amikben a párok keresése zajlik - egymást nem zavarva, sávszélességet nem elvéve! És ez is csak minimálisan bonyolítaná meg. Nem beszélve a következőkről.)
5. Olyan feladatot húzol elő, ami egyátalán nem az SPE-knek való, és úgy állítod be, mintha ez lenne az általános eset.
6. Konzekvensen "megfeledkezel" a következőkről - annak ellenére, hogy direkt figyelmeztettelek rájuk:
- A Cellben van egy átalános, a memóriát szokásosan elérő proci-mag is, a PPE, amivel ugyanúgy egy sor (C-ben) ez a dolog!
- A PPE hozzáfér az SPE-k ramjához, pl. beírhatja nekik a main memóriából össze-vissza összeszedett értékeket, stb. Tehát a feladatokat szét lehet osztani a PPE és az SPE-k között úgy, hogy mindkettő a számára legjobban fekvőt csinálja.
- Az SPE-k hozzáférnek egymás memóriájához is, azaz ha szükséges, nem 256KB-tal kell gazdálkodni, hanem lehet akár 2MB-tal is! Ez már nem olyan kevés.
- Ha éppenséggel nem csak összeadni kell számokat, hanem bonyolultabb, lassabb műveletet végezni, máris fordul a kocka, és kijön a több mag és a gyors belső memória előnye.
Mindezek nem mást mutatnak, mint hogy teljesen inkorrekt vagy...
ps. hol maradt az általam kért szám? -
kvp #59 Kedves dez, nagynehezen sikerult talalod egy talan mukodo megoldast erre a trivialis problemara. (7 ora alatt) Ha ezt most le is kellene kodolnod, akkor orokre eleged lenne a cell spe-jeibol. Par lassabb, de kozvetlen memoriahozzaferessel rendelkezo segedprocesszor sokkal jobb lenne erre a celra. Nem lett volna olyan bonyolult megcsinalni, de teves donteskent a tervezok arra jutottak hogy 256Kb mindenre eleg lesz. Meg egy trivialis egy soros feladatot is csak mindenfele trukkozessel lehet megoldani. A pelda algoritmusa egyebkent a 3d-s vektorgrafikus modellek dinamikus animaciojanal jon elo, csak bonyolultabb formaban, tehat pont ott ahol lenne ertelme segedprocesszort hasznalni. Mivel egy trvialis egysoros kodbol egy tobb oldalas processzorspecifikus, dma-val megtuzdelt kod lett, csak azert hogy mukodjon, igy teljesen ertelmetlenne valik erre az egysegre fejleszteni. A sony egyetlen eselye, ha ad egy kesz konyvtarat, olyat mint a direct-x amik kihasznaljak az spe-ket. Ebben persze a microsoft a jo. A multiplatformos jatekok keszitoi soha nem fogjak venni a faradsagot, hogy kodot irjanak ra. A ceges programozo lusta es ez igaz a jatekfejlesztokre is. A sima egysoros c kod meg fut: x86-os pc-n, xbox360-on es wii-n is. A ps2-esen sem sok jatek hasznalja ki az ee nyujtotta extra lehetosegeket, mivel nem eri meg megtanulni. (annyit nem fizet a ceg alapon) A cegvezetonek meg nem erdeke eroltetni, mivel fele annyi munkaval, olcsobb munkaerovel, hamarabb eladhatobb termeket tud kihozni a tobbi rendszerre.
"Én nem is vagyok kíváncsi a Winteles mentalitással szült játékokra..."
Ennek ellenere sok ember igen, ilyen jatek a halo, ami egymagaban kepes eladni az xbox csaladot, ilyen jatek az age of sorozat ami pc-n nepszeru. Nem kimagaslo jatekok, viszont sokan veszik oket, es ez eleg. A wow is ezert lett nepszeru es hoz rengeteg penzt, nem azert mert jobb lenne a kodja barmelyik azsiai mmo-nal. A tartalom (content) adja el, az amugy gyenge szinvonalu kodot. Viszont igy benabb programozok is kepesek voltak megirni. Egy tucat zseni kepes volt ujrairni a szerverkodot, amit tobb ezer gyenge programozo irt. A baj, hogy gyenge programozo tobb van mint cegeknek dolgozo zseni.
A sony azzal szurta el a jelenlegi strategiajat, hogy egy bonyolult processzort valasztott csak azert hogy egysegesek legyenek az alkatreszei az osszes termekeben _es_ tulsagosan eroltette a bluray lejatszo funkciot, igy a ps3 inkabb egy linuxos multimedias home pc lett, mint jatekkonzol. Altalaban nincs eleg jatek, meg minding nincs rendes huzojatek, a microsoft meg kihasznalja az olcson szemetet filozofiajat arra, hogy olcsobban rosszabb minosegu rendszert adjon el, de tobb embernek nagyobb haszonnal. A windows kompatibilitasrol pedig ne is beszeljunk. A legtobb ember meg mindig inkabb windows-t hasznal, mint linux-ot, tehat szoftveres oldalon az xbox360 nagy elonnyel indul. Az xbox360 rosszabb minosegu hardverbol, jobb megoldasokkal kepes ugyanazt kihozni. Lehet, hogy a ps3 teljesitmenye nagyobb, csak nem sok olyan ember van aki kepes ezt kihozni belole vagy fizetnenek neki annyit hogy legalabb megprobalja. Es most mar nincs 10 ev arra, hogy majd a vegere belejonnek a fejlesztok, valoszinuleg 3-4 evente generaciovaltas lesz es az olcsobb rendszer nem jobb, de uzeletileg sikeresebb. A legjobb pelda a wii, ami egy gyenge mac mini hardveret kapta de megis hatalmas hasznot hoz a gyartojanak.
ps: Ha valakinek sikerul megirnia a feladatban vart kodot, ugy hogy forduljon es fusson cell-en, akkor szivesen letesztelem. Ha kesz van, akkor erdemes osszehasonlitani a tobb oldalas kinszenvedest az egy soros eredeti koddal. Ha ezek utan azt mondja valaki, hogy jobb 6 spe-re fejlesztni mint 3 altalanos magra, akkor az illeto szvsz. fanatikus. A racionalista pedig hasznalja a 3 altalanos magot es mar reg a kovetkezo programot irja, amikor a masik meg mindig az elso problemat probalja megoldani. -
dez #58 (Ja, természetesen a1+a2 váltások közben kiírom a c buffer tartalmát.) -
dez #57 Jó vicc, ez természetesen alapvetően nem az SPE-knek való feladat, mi a csudáért kellene rájuk erőltetni? Ott van a PPE ilyesmire!
Tehát semmi értelme nem lenne ezt SPE-vel csinálni (hacsak nem valami elég bonyi művelet zajlana az a tömb elemei között, ami által arra menne el az idő nagyobb része).
Továbbá, ha már SPE-k, akkor az összeset bevetném, nem mellesleg kihasználva az összesen 2MB-nyi belső memóriát... De most maradjunk 1db-nál. Nem állok most neki igazán alaposan átgondolni, és főleg lekódolni csak a kedvedért, de pl. így lehetne csinálni:
1. 5 részre osztom a 256KB-ot. 2x64KB a1 és a2 buffer, 64KB b buffer, 32KB c buffer, a maradékban a program terpeszkedhet.
2. Főciklusban beolvasgatom az a többöt 2x64KB-os blokkokban a1 és a2 bufferbe, olyan variációkban, hogy mindegyik 64KB-os blokk "találkozzon" egymással 1x.
3. Minden ilyen variációban végigmegyek a b tömbbön 64KB-os blokkokban (b buffer), és kikeresem belőle azokat a párokat, amik éppen a1 és a2 bufferben vannak.
4. Közben a c tömbből is beolvasom a b tömbből beolvasott blokknak megfelelő blokkot (ha már írtam korábban oda), és ide írkálom a párok összegeit.
Nos, a b és c tömbökön többször kell végigmenni, de a "pároztatás" már viszonylag gyorsan megy a belső gyors ramban. Hogy pontosan hányszor kell végigmenni a b és c tömbökön blokkonként, most pontosan nem tudnám megmondani, ki kellene számolni, de pl. messze nem 64x64, mert elég, ha két a-s blokk egyszer találkozik, ennek a mintájára: 4 blokk -> 1-2, 1-3, 1-4, 2-3, 2-4, 3-4. (Cserébe számld ki nekem, hány variáció lesz a mi példánkban! :) )
ps. átlagos procin viszonylag gyorsan fut az az egy soros c kód is, de azon is lehetne optimizálni... -
dez #56 8x256KB LS van összesen, azaz tehát 2MB. És tudtommal az SPE-k látják (és írják) egymás memóriáját is (kivéve, ha ez adott SPE-re le van tiltva, DRM célokból), csak persze nagyobb latencyvel érik el. (~200 GB/s a magok közötti sávszél.) Mint ahogy a PPE is látja és írja őket.
MMU is van minden SPE-ben! Tehát valószínűleg virtuális memóriakezelés is megoldható.
Az természetesen igaz, hogy bonyolódik a helyzet, ha nem fér el az összes adat a belső memóriában, és nem nagyon lehet blokkosan kezelni. Viszont azzal nem számoltál, hogy van itt egy PPE is, amivel megoldható a teljesen véletlenszerű olvasás. De ilyen feladatok nem nagyon akadnak pl. egy játékban, de máshol sem túl sűrűn... Nem ilyen komplex adatbáziskezelésre való a Cell, na bumm.
"Azt irtam, hogy protein elemzo _VAN_, vektorgrafikus renderelo _meg_nincs_."
Úgy fogalmaztál, hogy erősen úgy lehetett érteni, az elsőből is csak algoritmus van, valós alkalmazás még abból sincs.
"A raytracer-ek eleve jobban optimalizalhatoak vektoregysegekre, tehat nalluk nem jon elo a vektorgrafikus rendszerek gather problemaja."
Te itt most tulajdonképpen mit értesz vektorgrafikus rendszer alatt?
"Kar hogy a ps3 a korabbi gyenge teljesitmenyu egyseggel jott ki, es nem lehet kicserelni csak majd esetleg a ps4-ben..."
Nem olyan nagyon nagy kár, nem hiányzik annyira, így is tud majd' annyit DP-ben is, mint egy 4-magos x86.
"Az elso eset egyszeru, a masodik szivas... ezzel szemben 3 power mag eseten mindenki lat mindent, van virtualis memoria is."
Csak épp jóval kisebb a teljesítmény. A játékokban használt rutinok többségének (meg még sokminden másnak) meg elég az a memóriamennyiség átmeneti tárnak, ami a Cellben adott.
"(legalabb eloszor ertelmezned a mondatot)"
Itt is erősen félreérthetően fogalmaztál: "siman ment az ibm az out of order execution-rol in order-re a power5 es a power6 valtaskor" --> "simán ment az IBM-nek az out-of-orderről in-orderre váltás a Power5 és Power6 között".
"A chip ram valoban unified ram volt, viszont a procinak lehetett sajat ram-ja, amit a chip ram-tol fuggetlenul (es wait mentesen) erhetett el. Viszont primitiv elso peldanak jo."
Lehetett. Lokális ramról beszéltél, ami azt jelenti, hogy egy adott egységhez kapcsolódik, és más csak valamilyen megkötéssel, stb. éri el.
"Gyakorlatilag az egyetlen bajom az spe-kel hogy nem latjak kozvetlenul a rendszer ram-ot."
Nocsak, most már csak ez? :)
"Ha megoldjak hogy dma nelkul a power mag l2 cache-en at kozvetlenul hozzaferhessenek a rendszermemoriahoz akkor sokkal egyszerubb lenne a programozok dolga."
Ez így van (viszont az esetek többségében nem bonyolódik túl nagy mértékben), de valószínű azért nem tették bele, mert túlzottan megbonyolította volna a chipet, és nem fért volna bele a megfelelő keretekbe, vagy csökkenteni kellett volna az SPE-k számát. Az LS-ekre mindenképp szükség lett volna továbbra is, és úgy kellett volna megoldani az egészet, hogy egy adott címterület az LS-ek, és egy másik a main ram, mégpedig virtualizálva. Meg az is valószínű, hogy a túl sok rövidke írás túlterhelte volna a belső buszt. (És emlékeztetnék, hogy a PPE besegíthet ebbe, tehát legalább az adott algoritmus megvalósítható - ha már ilyen algoritmus kerül elő.)
"A cell es a ps3 jo lenne, ha... lenne ra eleg program ami ki is hasznalja az spe-ket"
Mint már írtam, és egy példával is demonstráltam, nem olyan nagyon nagy ördöngősség legalább valamennyire kihasználni őket, mint el van hintve. (És ha csak 50%-osan használják ki őket, összesen mégiscsak 8-an vannak [PS3-ban csak 7 aktív, és ebből egy az OS-é].)
"lenne ra szabvanyos windows-on megszokott fejelsztoi kornyezet"
Nem mindenkinek kell ez. Pl. nekem sem. Meg szerinted pl. a PS2 fejlesztők Windowsos fejlesztő környezetet használnak?
"mert windows-os gepe szinte mindenkinek van a legtobb ember azon tanul meg programozni. (tenyleg nem linux gurubol van tobb)"
Felteszem, a mai legjobb programozók nem Wintelen tanultak meg programozni... És sokan közülök nem is azon teszik.
"Tehat a cell lehetne jobb, de mivel a legtobb fejleszto a pc-s vilagot es a windows-t szokta meg, ezert azt a gepet valasztjak ami legjobban hasonlit egy wintel pc-re."
Egészségükre. Én nem is vagyok kíváncsi a Winteles mentalitással szült játékokra...
"Ez ma boven eleg a bukashoz..."
Ugyan. Ilyen alapon a PS2 is bukás lenne, ehhez képest az van még ma is a csúcson (eladott rendszerben), és aktuális eladásokban is benne van a top 5-ben... Ennyit erről.
A PS3-nak csak az a baja, hogy túl drága, így 2x meggoldolja mindenki, hogy ezt vegye-e. Ha jobb lesz a helyzet ilyen szempontból, majd szépen elkezdenek rá jóval nagyobb arányban feljeszteni a konzolos fejlesztők is, akik a leginkább kenik-vágják a témát. (Pl. PS2/PS3 fejlesztők szerint a PS3-mal jobb dolgozni, mint a PS2-vel.) -
kvp #55 Mondok egy egyszeru peldat ahol egy spe elverzik:
-van harom tomb: a, b es c
-a feladat az a tomb elemeit paronkent osszeadni, ugy hogy a parokat a b tomb hatarozza meg
-az eredmenyt a c tombbe kell irni
Problema:
-ha a harom tomb befer az spe 256Kb-jaba programmal egyutt, akkor nincs gond
-ha nem fer el 256Kb-ban akkor kerlek keves dez, ird le hogy oldod meg kodmodositas es trukkozes nelkul a dolgot???
c-ben: (N paros)
![]()
Akkor ezt varom spe-n futo valtozatban, a, b legyen 4Mb, c 2Mb... -
kvp #54 Akkor lassuk...
""Egy altalanos algoritmust meg lehet irni ugy hogy tobb mega ram-ban ugral oda vissza es kimazsolazza az adatokat. Ezt stream processzoron csak ugy lehet megoldani, ha elore tudjuk a mi fog kelleni az algoritmusnak a memoriabol es az adatokat elore osszeszedjuk a dma buffer-be. (scatter/gather i/o)"
1. Nincs itt semmilyen (kis méretű) DMA buffer. Local Storage van, ami magonként 64KB, ami elég sokmindenre elég."
Errol beszelek, 256Kb lokalis memoria van. Minden mas csak dma-val erheto el. Ez azt jelenti, hogy random access cimzessel (ram-kent) csak ennyit lat az spe. Minden mas kulso memora, ami lehet kulso ram vagy akar diszk is, de mivel nincs virtualis memoria tamogatas egy spe-ben igy is ugy is kenytelen blokkonkent olvasni. (szavankent nagyon lassu es maceras lenne) Egy mai algoritmus siman feltetelezi hogy kozvetlenul lat tobb megabyte ram-ot. Ha ezt nem lehet megtenni, akkor gondolkozhat a programozo hogy hogy tordeli szet 256Kb-os darabokra. (es a 256Kb-ba bele kell fernie a programnak is) A programozonak ugy kell osszeraknia az adatokat a fomemoriaban hogy az spe lehetoleg 1 darab dma muvelettel be tudja huzni oket. Ez azt jelenti hogy egy N darab Mkb-os blokkba kell pakolnia mindent. Majd ezeket a blokkokat feldolgoznia. Ha M=1 szo, 32 bit azaz 4 byte, akkor olyan az spe mint egy altlanos cpu, csak nagyon lassu, mivel 4 byte-ot tolt be egy lepesben 32Kb helyett... Igy akar 100 orajel is lehet egy 32 bites dma transzfer. Ha meg blokkonkent probalja megcsinalni akkor olyan algoritmus kell neki ami nem 4 byte-onkent akar olvasni, mint egy sima c-s pointer eseten.
"Protein elemzo algoritmusbol van parhuzamositott stream alapu, scenegraph bejaro (terkep renderelo) algoritmusbol viszont csak csak par publikaciot talaltam stream processzorokra, tehat program meg nem nagyon van belole, csak kutatjak a teruletet."
LOL LOL LOL LOL LOL, akkor ez mi: http://folding.stanford.edu/FAQ-PS3.html
Azt irtam, hogy protein elemzo _VAN_, vektorgrafikus renderelo _meg_nincs_. A raytracer-ek eleve jobban optimalizalhatoak vektoregysegekre, tehat nalluk nem jon elo a vektorgrafikus rendszerek gather problemaja.
"Az első Cell verzió (nem számolva a legelső reviziót) Double Precision teljesítménye is viszonylag alacsony, pedig ez sokszor szükséges tudományos célokra, és csak a nemrég kijött második verzióban emelték ezt fel alaposan,"
Kar hogy a ps3 a korabbi gyenge teljesitmenyu egyseggel jott ki, es nem lehet kicserelni csak majd esetleg a ps4-ben...
""A microsoft sajnos azert csinalt jobb rendszert, mert a programozoknak konnyebb xbox360-ra fejleszteniuk, mivel egyszerubb a hardver."
Messze nem olyan nagy a különbség programozhatóságban, mint a FUD mondja. Pl. egy másik fórumon írta egy fejlesztő, hogy 2 napba telt átírni egy számítási rutint x360-ról PS3-ra (pontosabban úgy átírni, hogy néhány makró segítségével ugynaz a kód [lásd amit a PowerPC-s SPE-kről írtam] forduljon mindkettőn...), és az utóbbin mellesleg sokkal gyorsabban is futott."
A power magokon fog is futni, de az spe-kbe csak akkor fer bele, ha:
1: adat + program elfer 256Kb-ban
2: atirjak a kodot, kigyujtik es feldaraboljak a veletlen ram hozzaferest dma-sra (gyakorlatilag olyan mint regen dos-os szoftveres overlay-ekkel dolgozni)
Az elso eset egyszeru, a masodik szivas... ezzel szemben 3 power mag eseten mindenki lat mindent, van virtualis memoria is.
""Mig a power mag eseten siman ment az ibm az out of order execution-rol in order-re a power5 es a power6 valtaskor"
Ez is tévedés, nem in-orderes a Power5. Lásd itt: IBM Power5 Chip: A Dual-core Multithreaded Processor” (IEEE Micro March-April 2004)."
Osszekevered, a power 5 volt az out of order, a power 6 az in order, az ibm 'visszalepett', azert hogy osszesegeben egyszerubb es gyorsabb legyen az uj processzor. (legalabb eloszor ertelmezned a mondatot)
""Az egyik elso multimedias pelda ilyen egysegre az amigak copper+blitter egysege volt, ami kepes volt sajat programot futtatni a lokalis ram-bol (chip ram) viszont butabb volt a M68k-s kozponti processzornal."
Tényleg "butább" volt: 3db utasítása volt a Coppernek. A Blitter nem tudott programokat futtatni, de a Copperral is fel lehetett programozni és elindítani. A Chip RAM nem lokális ram volt, hanem unified ram, a proci is azt használta az alapgépben."
A chip ram valoban unified ram volt, viszont a procinak lehetett sajat ram-ja, amit a chip ram-tol fuggetlenul (es wait mentesen) erhetett el. Viszont primitiv elso peldanak jo. De emlithetnem az ibm elso io processzorait is.
Gyakorlatilag az egyetlen bajom az spe-kel hogy nem latjak kozvetlenul a rendszer ram-ot. Ha megoldjak hogy dma nelkul a power mag l2 cache-en at kozvetlenul hozzaferhessenek a rendszermemoriahoz akkor sokkal egyszerubb lenne a programozok dolga. Igy egy hatarig egyszeru, majd 256Kb adat + program utan beleutkoznek egy falba, amit a dsp programozok is erzekelnek. Egy sima mikrovezerlon ez a fal lehet lejjebb is. Egy altalam tervezett kis rendszeren ez 128 Kb volt. Ennyit tud a rendszer kozvetlenul kezelni, a tobbi memoria (4Gb-ig) mar csak hattertarkent erheto el. Mivel nincs virtualis memoria egyseg, sem az en vezerlomben sem az spe-ben ezert blokkonkent ki kell irni a bent levo adatokat es ujakat tolteni a helyukre. Mindezt szoftverbol, mig L2 cache eseten ezt a hardver elvegzi a programozo helyett. Egyebkent egy mikrovezerlo siman tud futtatni 8 bites mikrokoddal 32 bites utasitaskeszletet is, csak egy osszeadas is 4 orajel lesz... (lassu de mukodik, a limit nem a processzor hanem a kozvetlenul cimezheto memoria)
A fo problema az, hogy mig egy okos hardver buta programmal tobbnyire lassabb mint egy buta (egyszeru) hardver okos programmal, de mig hardvert csak par ceg gyart, addig szoftvert nagyon sokan irnak. Ha egy ceg vesz egy okos hardvert es egy csomo gyenge programozot akkor olcsobban jon ki, mint ha vesz egy gyors de buta hardvert es probal talalni okos programozokat akik ki is tudjak hasznalni. A microsoft lathatoan inkabb az okos hardver es buta de olcso programozo kombinaciojara eskuszik, meg ha ezzel teljesitmenyt is veszit. A lenyeg, hogy igy olcsobban tobb programot tudnak elkesziteni, rovidebb ido alatt. A cell es a ps3 jo lenne, ha... lenne ra eleg program ami ki is hasznalja az spe-ket, lenne ra szabvanyos windows-on megszokott fejelsztoi kornyezet, mert windows-os gepe szinte mindenkinek van a legtobb ember azon tanul meg programozni. (tenyleg nem linux gurubol van tobb)
Tehat a cell lehetne jobb, de mivel a legtobb fejleszto a pc-s vilagot es a windows-t szokta meg, ezert azt a gepet valasztjak ami legjobban hasonlit egy wintel pc-re. Az xbox360 gyakorlatilag ugyanugy nez ki, meg az oprendszer is megegyezik, tehat barmelyik indiai wintel-es programozo tudja hasznalni. A ps3 ezzel szemben egy linux-os kornyezet, a megszokott x86-tol eltero gondolkodasu hardverrel. Egyszeruen nincs eleg programozo, ezert nincs eleg program... Azokat a programokat nem szabad szamolni amik wii-n is elfutnak, azok nem hasznaljak ki egyik gepet sem, legfeljebb a videokartyakat. A sony addig eroltette az egyseges architekturat (tv+player+konzol), hogy vegul olyan lett amit az atlag programozo nem tud kapasbol x86-os tudassal programozni. Ez ma boven eleg a bukashoz... -
dez #53 "Lehet vitatkozni azon hogy mik a tenyek, de mivel mindket rendszer jol dokumentalt, ezert erdemes utannanezni."
Rajta! -
dez #52 "Mig a power mag eseten siman ment az ibm az out of order execution-rol in order-re a power5 es a power6 valtaskor"
Ez is tévedés, nem in-orderes a Power5. Lásd itt: IBM Power5 Chip: A Dual-core Multithreaded Processor” (IEEE Micro March-April 2004).
"(nem mondjuk 3 power5 magot, ahogy a microsoft is tette)"
Újabb tévedés: a Xenonban 3db PPE-variáns van, ami nem Power5 mag, hanem derivált.
"Az egyik elso multimedias pelda ilyen egysegre az amigak copper+blitter egysege volt, ami kepes volt sajat programot futtatni a lokalis ram-bol (chip ram) viszont butabb volt a M68k-s kozponti processzornal."
Tényleg "butább" volt: 3db utasítása volt a Coppernek. A Blitter nem tudott programokat futtatni, de a Copperral is fel lehetett programozni és elindítani. A Chip RAM nem lokális ram volt, hanem unified ram, a proci is azt használta az alapgépben. -
dez #51 KORREKCIÓ: "egyenként 64KB belső rammal" -> 256KB belső rammal/SPE, az összesen 2MB belső ram/Cell. -
dez #50 Na jó, válaszolok, csak úgy kedvtelésből:
"A cell annak ellenere, hogy jo otlet volt sajnos zsakutcanak tunik a jelenlegi formaban."
Talán neked, a téves információid, vagy inkább fantáziáid alapján.
"Csak akkor lenne esely a fejlesztesre ha nem lenne fixen limitalva a dsp-k es a magok szama."
1. Hülyeség, éppenhogy nincsenek fixen limitálva, a jövőben különféle variációk jelennek majd meg. Pl. 4 PPE + 16 SPE.
2. Nem DSP-k.
"A cell ezzel szemben egy sima g5-os power mag 8 dsp egyseggel."
1. Nem igaz, nem sima G5-ös Power mag, bár a G5-ön alapul. (Különben is, a G5-ös sem Power mag, hanem PowerPC mag, ami az első deriváltja.)
"Hivatjuk oket spe-nek is de attol meg is csak egy kis mikovezerlovel egybeepitett dsp egysegek maradnak, amik ugyan tudnak dma-zni es ilyen kulso memoria illesztest en is csinaltam pic mikrovezerlohoz, de nagyon keves dologra jok."
Ekkora baromságot még nem hallottam. A mikrovezérlők 8/16 bitesek, pártíz MHz órajelen járnak, 0 cache, stb. Az SPE-k PowerPC magok, egyenként 64KB belső, nagyon gyors rammal.
"Altalanos celra nem idealis"
Eddig valamennyire igaz...
"stream feldolgozashoz pedig nincs eleg hozzaerto programozo."
...de ez már nem.
1. Az SPE-kre sima PowerPC-s kódok fordíthatók, csak pl. a memóriahozzáférések a belső ramba irányulnak.
2. Te teljesen kevered a Cellt valami mással, mindjárt leírom, mivel.
"Egy altalanos algoritmust meg lehet irni ugy hogy tobb mega ram-ban ugral oda vissza es kimazsolazza az adatokat. Ezt stream processzoron csak ugy lehet megoldani, ha elore tudjuk a mi fog kelleni az algoritmusnak a memoriabol es az adatokat elore osszeszedjuk a dma buffer-be. (scatter/gather i/o)"
1. Nincs itt semmilyen (kis méretű) DMA buffer. Local Storage van, ami magonként 64KB, ami elég sokmindenre elég.
2. Kevered a Cellt a GPU-kkal, és azok (SPE-khez képest sokkalta egyszerűbb) stream processoraival, minimális belső cache-sel, stb.
"Amint belefutunk egy ilyen nem lineris problemaba (mi, scenegraph rendereles) a feladatra hasznalhatatlanna valik az osszes spe."
Ahhoz képest pl. egy elég jó ray-casting renderert írtak Cellre...
"At lehetne allni stream alapu algoritmusokra, de ezek jo reszet meg ki sem fejlesztettek, vagy ha igen, akkor csak nagyon szuk teruletekre jok."
Valóban, a GPGPU alkalmazások most kezdenek fejlődni.
"Protein elemzo algoritmusbol van parhuzamositott stream alapu, scenegraph bejaro (terkep renderelo) algoritmusbol viszont csak csak par publikaciot talaltam stream processzorokra, tehat program meg nem nagyon van belole, csak kutatjak a teruletet."
LOL LOL LOL LOL LOL, akkor ez mi:
Vethetsz egy pillantást a statokra is...
"Nem veletlen hogy a cell egy tudomanyos gyorsitoegysegnek keszult eredetileg."
Nem azt írtad, hogy csak stream-feldolgozásra jó...? De mindegy, mert egyik sem igaz ebben a formában. Egyszerűen egy többmagos PowerPC alapú chip (amiben a magok egy része belső ramba dolgozik, mert így úgy lehet gyors, hogy nincs szükség bonyolult, és sok tranzisztort igénylő elágazás-becslésre, stb.), ami többmindenre jó, és elég jó teljesítmény/méret+fogyasztás aránnyal rendelkezik.
Az első Cell verzió (nem számolva a legelső reviziót) Double Precision teljesítménye is viszonylag alacsony, pedig ez sokszor szükséges tudományos célokra, és csak a nemrég kijött második verzióban emelték ezt fel alaposan, hogy így építsék be a LoadRunner nevű szuperszámítógépbe, ami világ új leggyorsabb szuperszámítógépe lesz egy ideig. (Igaz, Cellek és Opteronok kéz a kézben fognak benne dolgozni.)
"A microsoft sajnos azert csinalt jobb rendszert, mert a programozoknak konnyebb xbox360-ra fejleszteniuk, mivel egyszerubb a hardver."
Messze nem olyan nagy a különbség programozhatóságban, mint a FUD mondja. Pl. egy másik fórumon írta egy fejlesztő, hogy 2 napba telt átírni egy számítási rutint x360-ról PS3-ra (pontosabban úgy átírni, hogy néhány makró segítségével ugynaz a kód [lásd amit a PowerPC-s SPE-kről írtam] forduljon mindkettőn...), és az utóbbin mellesleg sokkal gyorsabban is futott.
"A ps3 a sony linux-al es az opengl tamogatasaval nagyon gyengen all a dx9d-s xbox360-al szemben."
Most akkor miért is, mert "egy halom kesz fuggvenyt ad, amit opengl-nel fejbol kell tudnia a fejlesztonek"? Ugyan. Ez inkább csak a PC-s cuccok portolását, illetve a x360-ról PC-re portolást könnyíti meg. Viszont pl. az OpenGL extensionjaival sokmindent el lehet érni, amit a DX zárt függvényeivel nem.
"Viszont nekik meg a hardveruk tul bonyolult es tul draga. Jobb a ps3 minosege, de tul draga es tul bonyolult ahhoz, hogy megerje foglalkozni vele es programokat irni ra."
Bla bla bla. -
kvp #49 "Gondoltam, hogy válaszolok neked, de aztán rájöttem, hogy tök fölösleges lenne, mert te csak írsz, és sosem olvasol el semmit, amit a másik ír, akár direkt neked. Mint pl. hogy a Cell SPU-i nem DSP-k."
Szerintem probald meg programozni. Es probakeppen probalj meg programozni egy mikroverlos dsp-t. Teljesen egyforma az architektura. Mindketto egy kis risc-es processzor, nagy orajelen es determinisztikus (orajelre pontos) idozitessel. Ebbol a dsp-bol raktak 8-at a cell-be. De ha nem tetszik a dsp kifejezes, hivhatod spe-nek. A problema az, hogy a fix idozitesek miatt nem lehet szabadon valtoztatni a felepiteset. Mig a power mag eseten siman ment az ibm az out of order execution-rol in order-re a power5 es a power6 valtaskor, addig az spe-k eseten nem lehet architekturat valtani, mert rogton elcsuszik a szepen kiszamolt idozites. Ez hang vagy kep megjelenitesnel nagyon kellemetlen tud lenni. Tobbek kozott ezert tunik zsakutcanak.
A masik gond a memoria limitaltsaga, ha csak kilobyte-okban merheto a szabadon cimezheto memoria, akkor nagyon nehez olyan algoritmust megvalositani, ami ossze-vissza olvas a memoriaban. Nagyon sok jatek algoritmus ilyen. Lehet uj algoritmusokat tervezni, de jelenleg ilyenek nem nagyon vannak. Ha lennenek akkor sem ezeket tanitjak a kezdo programozoknak, tehat nagyon nehez olyan embert fogni aki ert is hozza. Mivel en szoktam mikorvezerlos dsp-ken dolgozni, ezert nekem a cell spu-ja ismeros volt, de azert ereztem hogy ez tipikusan a gyors proci, tavoli memoria esete, amikor a memoriabusz kesleltetese fogja visszafogni a rendszert. (tehat nem a savszelesseg, hanem a kesleltetes)
Hogy miert ezt valasztotta a sony es nem egy masik megoldast? (nem mondjuk 3 power5 magot, ahogy a microsoft is tette) A valasz a sony tv-kben rejlik. Minden bravia tv es sony blue ray lejatszo belsejeben van egy cell processzor, csak meg tobb hibas spe-vel. (hibatlan: ibm cluster, 1 hibas: ps3, tobb hibas: bravia tv-k) Igy egy termek, egy operacios rendszer es egy szoftver kepes kiszolgalni a teljes termekpalettat. Tehat gyakorlatilag a ps3 magja egy blue-ray player kore epult. (mondjuk ezt a sony sem tagadja) A cell a tipikusan dsp-s feladatokban jo: videodekodolas, videoskalazas, hangdekodolas, stb. Ezeket egy bravia tv-ben kulon videokartya es hangkartya nelkul meg tudja oldani, akar mindossze 5 aktiv spe-vel is. (a tv-n is sony linux fut, van hozza gpl-es licensz papir is) A konzolba persze raktak kulon videokartyat. (es nem is rosszat, a legdragabb dx9-eset) Viszont azert van kulon video es rendszermemoria, mivel a proci arra van felkeszitve hogy kulon mukodjon videokartya nelkul. Ezzel szemben az xbox360-ban a proci kepes belso ramkent hasznalni a cache-t, igy az eredeti felhasznalasban (ibm kryptobox) nem is kell neki kulso ram. Amit viszont cserebe kapott az egy gyors i/o csatorna amin at a videokartyat tudja eszaki hidkent latni, igy az L3 cache a videokartyan van, a rendszer ram pedig a videomemoria. Ez egy eltero architektura, ami nem gyorsabb viszont elegansabb es konnyebben programozhato. Nem kell pl. a rendszer es a video ram kozott adatokat toltogetni, hanem minden adat egyben textura is. Es nem kell ram-ba kiirni majd atmasolni a video parancsokat, mivel a videokartya 'elkapja' oket iras kozben es ramba iras helyett vegre is hajtja oket.
Kedves dez: ertem hogy a cell spu-i nem dsp-k, hiszen van altalanos egyseguk is, viszont az osszes ujabb mikrovezerlos dsp-nek van ilyen tehat ez nem uj otlet. Az ibm csak atemelte az egychipes cpu+dsp otletet a telekommunikacios rendszerekbol. Ezert is van az, hogy a cell tipikusan olyan helyeken kerul felhasznalasra nagyobb ibm gepek eseten ahol eddig egy power mag tobb dsp-t iranyitott. Az egyik elso multimedias pelda ilyen egysegre az amigak copper+blitter egysege volt, ami kepes volt sajat programot futtatni a lokalis ram-bol (chip ram) viszont butabb volt a M68k-s kozponti processzornal. Az otlet jo, de ha van videokartya, shaderekkel, akkor erdemesebb rajuk bizni a feladatot. Az uj g80-as sorozat nagyobb elerheto memoriaval es tobb processzorral kb. ugyanezt a teljesitmenyt hozza.
A cell spe-k akkor lennenek teljes erteku procik, ha a dma library fole irna valaki egy rendes scatter/gather library-t. (lasd: linux forras) Viszont a dma setup latency miatt ez annyira visszaveti a teljesitmenyuket, hogy akkor mar erdemesebb venni egy tobbmagos power5-ot vagy egy power6-ot. Bonuszkent arra meg programozot is talal az ember, mivel a power csalad c-ben programozva nagyon hasonlo a sima x86-osokhoz. (a programozonak nem latszik a kulonbseg, mig cell spe-k eseteben a regi dsp-s limitek jonnek elo, mint a 'hogy hogy nem tudok egy 4 Mb-os blokkon veletlenszeruen vegigmenni?' es a 'miert kell a ram-ban fizikailag egymas melle tenni az adatokat amikor nem is egyszerre keletkeznek?')
Kedves dez, lehet, hogy nem ertesz egyet azzal amit leirtam, de attol a tenyek nem valtoznak. Lehet vitatkozni azon hogy mik a tenyek, de mivel mindket rendszer jol dokumentalt, ezert erdemes utannanezni. (az ibm mindket processzor adatlapjat pubikalta, a cell-hez meg hivatalos linux tamogatas is van) Vegyel egyet, probald ki, probald meg programozni es ha mar eleged van a cell-bol akkor rajosz, hogy egy kezdo is megirta volna ha kap meg ket altalnos power magot ahol az egesz ram latszik egy nagy blokkban es lehet tobb megas c++ strukturakat dobalni. A microsoft-nal mivel ok egy szoftverceg sok olcso es alulkepzett programozoval erre jottek ra. -
dez #48 Többieknek: amit kvp írt, az sok ponton téves. -
dez #47 Gondoltam, hogy válaszolok neked, de aztán rájöttem, hogy tök fölösleges lenne, mert te csak írsz, és sosem olvasol el semmit, amit a másik ír, akár direkt neked. Mint pl. hogy a Cell SPU-i nem DSP-k. -
kvp #46 ""(cell meg inkább zsákutcának tűnik jelenleg)"
Ugyan írd már le, ezt meg mire alapozod?"
A cell annak ellenere, hogy jo otlet volt sajnos zsakutcanak tunik a jelenlegi formaban. Csak akkor lenne esely a fejlesztesre ha nem lenne fixen limitalva a dsp-k es a magok szama. Jelen formajaban nem eleg flexibilis. Az x86 architektura mar rengeteg generaciovaltast tulelt, koszonhetoen annak, hogy a pentium-ok ota a processzorok belsoleg mar csak emulaljak az eredeti x86-os architekturat. A cell ezzel szemben egy sima g5-os power mag 8 dsp egyseggel. Hivatjuk oket spe-nek is de attol meg is csak egy kis mikovezerlovel egybeepitett dsp egysegek maradnak, amik ugyan tudnak dma-zni es ilyen kulso memoria illesztest en is csinaltam pic mikrovezerlohoz, de nagyon keves dologra jok. Altalanos celra nem idealis, stream feldolgozashoz pedig nincs eleg hozzaerto programozo. Egy altalanos algoritmust meg lehet irni ugy hogy tobb mega ram-ban ugral oda vissza es kimazsolazza az adatokat. Ezt stream processzoron csak ugy lehet megoldani, ha elore tudjuk a mi fog kelleni az algoritmusnak a memoriabol es az adatokat elore osszeszedjuk a dma buffer-be. (scatter/gather i/o) Sajnos a legtobb programozo es a legtobb algoritmus erre nem alkalmas. Amint belefutunk egy ilyen nem lineris problemaba (mi, scenegraph rendereles) a feladatra hasznalhatatlanna valik az osszes spe. At lehetne allni stream alapu algoritmusokra, de ezek jo reszet meg ki sem fejlesztettek, vagy ha igen, akkor csak nagyon szuk teruletekre jok. Protein elemzo algoritmusbol van parhuzamositott stream alapu, scenegraph bejaro (terkep renderelo) algoritmusbol viszont csak csak par publikaciot talaltam stream processzorokra, tehat program meg nem nagyon van belole, csak kutatjak a teruletet. Nem veletlen hogy a cell egy tudomanyos gyorsitoegysegnek keszult eredetileg.
A microsoft sajnos azert csinalt jobb rendszert, mert a programozoknak konnyebb xbox360-ra fejleszteniuk, mivel egyszerubb a hardver. Mindemellett meg mindig egy modositott win2k fut az xbox360-akon (winnt5.x-es kernel), tehat van directx is ami ugyan benabb az opengl-nel, de a matemataikahoz nem erto programozoknak egy halom kesz fuggvenyt ad, amit opengl-nel fejbol kell tudnia a fejlesztonek. A ps3 a sony linux-al es az opengl tamogatasaval nagyon gyengen all a dx9d-s xbox360-al szemben. Az olyan aprosagokat, mint hogy az xbox360 flexibilisebb memoriakezelovel rendelkezik nem is erdemes nagyon emliteni. (lehet hogy lassabb de legalabb befer a progi a nem bovitheto ram-ba, az egyik funkcio lophat ramot a masik karara) Az amiert az xbox360 ugy nez ki mint egy gyengebb hardver az azert van mert a microsoft szemet es uzleti alapon letiltotta a tamogatott hardverek es szoftverek jo reszet. Pl. nem mukodik a billentyuzet es nem hasznalhatunk usb hub-ot. Ez azert van mert a microsoft nem rakta fel a keyboard es a nem root usb hub drivereket az oprendszerre. Persze ezt csak uzleti alapon csinalja. A sony rendesebb szoftveres tekintetben, bar a drm miatt ok is kikapcsoltak a 3d-s gyorsitast linux alatt. Viszont nekik meg a hardveruk tul bonyolult es tul draga. Jobb a ps3 minosege, de tul draga es tul bonyolult ahhoz, hogy megerje foglalkozni vele es programokat irni ra. Egy konzol eseteben pedig ez az egyetlen esely a sikerre. Az xbox360 a maga dx9d-s kartyajaval es 75%-nyi core2 duo javal jobban all es tobb eselye van a sikerre, annak ellenere hogy a pc-k mar most tulleptek a hardveren.
ps: A wii pedig a maga kis mac mini-s hardverevel tenyelg innovativra sikerult (foleg a vezerles, a visszafele kompatibilitas es az ar tekinteteben). -
#45
Na igen de akkor adjuk hozzá a ps3mat, a pspt a sonyhoz, a dst meg a wiit a nintendóhoz. Mobilnál meg bonyolultabb a helyzet, meg kell nézni hány sony-ericson telefont vettek csak játékra xD. -
#44
Öööö izé a GBA meg a GC azért nem ugyan az a kategória. Mobiltelcsit nem akarod beleszámolni, azon is lehet játszani?!
Amúgy tavaly decemberig a PS2-ből kb 115 milliót adtak el! -
#43
Mondjuk azt nem értem mikor volt előnyben a sony konzolok terén? Gba 82 millió+ gamecube 23 millió= 105 millió áll szemben a ps2 102 millióával. Csak úgy volt előnyben ha a gbat nem nézzük. -
#42
Az a baj, hogy mind az x360 hoz mind a ps3hoz hdtv kell, azért nem fogy, meg túl nagyok, meg túl drágák, meg a gamepad már elavult. A nintendó meg vehetne/bérelhetne/felkérhetne még pár gyárat hogy wiit gyártson, mert ha bírják gyártani wiit, simán megdönti a ps2 100000000ós rekordját. -
#41
Jó, hát vitatkozhatunk, de marhára nem egy dologról beszélünk.
Az hogy a M$ kiadott egy mondjuk úgy middlewaret az miért csoda (annyi multiplatformos middleware van a piacon, hogy Dunát lehet velük rekeszteni), ha olyan szolgáltatásokat nem fog mellé adni, hogy közös lemezen legyen a PC/Box verzió - ha már ajánlott egy PC is a lakásban, ha Boxot médiacenterként akarod használni- , meg hogy a két tábort közös szerverre eressze rá?
Szal marhára jó, hogy egy használható fejlesztő környezetet ad, de engem mint egyszeri játékost ez hol érdekel? Gyorsabb, olcsóbb lesz PC-ről X-re portolni? Gratula, és ettől a játék is olcsóbb lesz? Nem hiszem.
"És szerzi a tapasztalatot, és előbb utóbb olyan fokú interakció lesz ezen kütyük közt, amit ha a nép megszokik, akkor biztosított a fennmaradása..."
Na ez most a szokásos M$ fikázás lesz, de ha csak az M$-en múlik, akkor utóbb. Másrészt különböző eszközök kommunikációját nem az szabja meg, hogy ugyan az a cég gyártsa öket, hanem a kommunikációs szabványok/protokolok. Más kérdés ha egy cég megteheti csökkenti az ezekkel való kompatibilitást, erölteti a saját szabványait, hogy a termék csak a saját termékeivel tudjon kommunikálni, de ez nem egy kibaszott előremutató dolog. Ezt csinálja a Sony is, erölteti a saját szabványait egy darabig, de ha a piac nem fogadja el, akkor kénytelen nyitni.
Az hogy lesz M$ OS-es PC/Konzol/Mobil/PDA/MP3pléjer/mikró/mosógép/hajszárító az lehet, hogy előbb utóbb azt eredményezi hogy ezek majd egymással kommunikálnak, meg könnyű lesz az egyikről a másikra portolni az alkalmazásokat, de ez nem jelenti azt, hogy ezt ne lehetne ma megcsinálni, vagy hogy a M$ úgy csinálja majd meg, hogy a jelenlegi helyzetjhez képest ez a júzer szempontjából előrelépés lenne.
A lényeg, hogy a lehetőség ma is adott, az egy gyártóttól mindent elvnek pedig legalább annyi buktatója van, mint előnye. -
Yv@n #40 "Egy közös SDK az egy dolog, az meg egy másik, hogy a végeredményt min tudod majd futtatni. Márpedig eléggé elkerekedne a szemem, ha a M$ olyan kiadványokat csinálna, amit Boxon meg PC-n is el tudnál indítani."
Nyilván nem közös futtatható binárist kapsz, de ha a fejlesztő környezetben a terméked legyártása a két totál eltérő eszközre kb annyi erőt vesz igénybe, hogy egy radio button-t arrébb kattintassz compile előtt, akkor azért az lehet fejlesztőként nem mindegy.
"Mi ebben az üzlet, amikor valamit 2X-is el lehet adni?"
Az üzlet szerintem ebben az egészben, az hogy két platformot teljes körű megoldással lefed. Ott van a mobilokon mint OS, ott van a szervereken mint OS, ott van a munkagépeken, mint domináns OS, ott van a játék pc-ken, és a box révén ott van a nappaliban is. És szerzi a tapasztalatot, és előbb utóbb olyan fokú interakció lesz ezen kütyük közt, amit ha a nép megszokik, akkor biztosított a fennmaradása... -
vax #39 Ez is igaz, de az is igaz más kor volt. Más elvárásokkal, igényekkel, más lehetőségekkel más piaci viszonyokkal stb.
-
#38
Igaz. Az európai indulás fél évvel el volt tolva, de elég jól sikerült. Pár hét alatt 1 milliót eladtak, a boxnak ehhez európában legalább legalább 6-8 hónapra volt szüksége.
Szal a különbség valszeg megvan csak kb 1 millióval eltolva.
-
#37
Mit kell itt látni. Én ezen azt látom, hogy nem sokkal jobban fogy, és a fogyás mértéke, szép lassan egyre kisebb. Míg a másik kettőé stagnál, vagy emelkedik. És ebben csak a japán meg az amcsi eladások szerepelnek :( -
#36
Nincs itt semmi összeesküvés, ha az adatok nagyságrendileg helyesek, akkor a PS3 sokkal jobban fogy mint pl az X360 az indulás napjától számítva! Legalább félmilliós forban van.
Lásd itt.
Ha összesküvés van, akkor az abban nyilvánul meg amikor valaki ilyen eredmények mellett a PS3 csődjéről huhog.
-
#35
Valószínűleg az átlagos eladásokat veszi figyelembe frissítésenként. Érdekes módon mindenhol hasonló adatok vannak. Gondolom ez is csak a ps3 elleni összeesküvés része :D
