PlayStation 3-ból szuperszámítógép

Egyébként most itt pontosan milyen szoftverrõl is van szó? Végülis egy IBM Cell SDK is elég bármihez, pl. PS3-ak clusteres számoltatásához is. Csak ugye szépen kézzel le kell programozni az egészet.

A másik véglet meg az, hogy matematikai kifejezésekbõl clusteres párhuzamos vektoros kód-gyûjteményt generál. :) (Na én erre gondoltam az elõbb.)

A Mercury-s cucc mit csinál?

Ezt a mercury SDKt kellene jobban megviszgálni akkor. Nem vagyok programozó tehát azt a részét nem értem.

NEm mondtam hogy õk nem csinálták meg. Én azt mondtam, hoyg csináljuk mi is meg. Szvsz lenne rá vevõ, de csak mint kész megoldás. Nem nagyon van az egyetemeken olyan emberke aki ráér erre molyolni...

Hát errõl az üzletrõl asszem lekéstetek, mert a Mercury Computer Systems már kiadott egy ilyen progit, amivel PS3 clustereket lehet csinálni kifejezetten tudományos feladatokhoz!;)))

Amúgy ha valaki veszi a fáradtságot, akkor az egyetem cikkben szereplõ linkjén utána nézhet, hogy milyen szoftvereket használtak a rendszer felépítésénél, pl Fedora 5/6 Linuxot, IBM cell SDK-t, a message-passing technológiához, meg OpenMPI-t, szal ingyenesen hozzáférhetõ dolgokat.
Hát õk ezexerint meg tudták csinálni, de biztos csaltak!;)))

Elõször talán megpróbálok számoltatni egyet. Aztán jöhetne egy adott feladat kiterjesztése több gépre. Viszont egy ilyen univerzális rendszer létrehozására (amivel bármilyen "számoltatást" clusterezve el lehet végeztetni, ha erre gondoltál) nem igazán vállalkoznék, az már egy kicsit nagy falat. Nem is tudom, létezik-e egyátalán ilyen bármilyen clusteres rendszerre vagy szuperszámítógépre.

Az egy dolog, de ha olyan rossz lenne a Cell, mint egyesek mondják, hiába lenne minden - túl botrányos lenne a dolog.

LOL, mintha elfelejtenéd, hogy a Sony veszteséggel árulja a PS3-at, miközben az IBM magas haszonkulccsal a saját cuccait.
1/10 annyi pénzért -2 SPE, és fele ram, ez nem olyan rossz... (Oké, PS3-on Infiniband sincs, de legalább van egy gyors LAN port.)

Hahó, te azt írtad, nem is ugyanaz a Cell, és a PS3-as erõsen[/b] lebutított. Holott csak egy SPE van letiltva. (Egyet meg az alap firmware használ, többek között hang en-/dekódolásra.)

Ha raytracingre ennyire jó a Cell (és ennyivel jobb, mint a G80), akkor sokminden másra is jó.

Egyébként meg; Annyira frankó programozó vagy. Szedjél össze egykét havert csináljatok szoftvert amivel clusteres ps3-akat lehet számoltatni nagy teljesítményen. Ha életképes akkor én eladom!

"amikor rájuk esik a választás, azt csinálnak, amit akarnak. Azzal, hogy az IBM nyert, az elbírálók a Cellre is rábólintottak."

Jaaaaaj ez a naívság. Ugye nem kell elmondanom, hogy hogy zajlik egy ilyen nagyobb beszerzés eldöntése. Külföldön persze nem akkora méretekben mint magyarországon, de azért ott is jelen van. Túl sok pénz...

"Ha viszont spórolni kel..."

Olcsó húsnak...

Örülök mikor engem igazolsz végül. Jópár hozzászólással ezelõtt még lehülyéztél azért mert azt mertem mondani hogy az IBM Cell kissé erõsebb. Egyébiránt meg, a mi profilunk (cégnél) többek között tudományos számitásokra gépeket eladni. Nem fogod elhinni de sehol nem fut ray tracer program rajta...

"Erre az volt a szimpla válasz, hogy azért mert azok nem neki hoznak hasznot, nem õ gyártja õket. Ha az IBM történetesen videokártyákat gyártana akkor abból építené és nem a cellbõl."
Én meg erre válaszoltam azt, hogy akkor nem feltátlenül az IBM nyerte volna a tendert. Tudod, ez nem úgy megy, hogy "én akarom, én akarom!", és amikor rájuk esik a választás, azt csinálnak, amit akarnak. Azzal, hogy az IBM nyert, az elbírálók a Cellre is rábólintottak.

"Azonkivül szerintem a cell-el mint processzorral nem is volt itt senkinek sem baja. Legalábbis nem rémlik, hogy valaki ezt támadta volna."
Hát dehogynem, lásd amiket kvp írt. (Persze itt-ott volt benne igazság, de kicsit eltúlozta a dolgokat. Persze millió "rendes" prociból is jó gép építhetõ, csak nem túl költséghatékony a dolog.)

"Viszont a ps3 az nem maga a Cell processzor..."
Nyilván megvannak a hátrányai (pl. kevés memória), és elõnyei (ár) pl. egy IBM-es Cell blade laphoz képest.

ps. egyébként a szuperszámítógép nem egy szerver, hanem egy nagy cluster.

"Csak azt állitani, hogy azért nyert itt a cell mert az a legjobb , ez miatt dõreség."
És ki írt ilyet?

"Ráadásul ez is bizonyitja azt amirõl folyamatosan beszélek. Nem 1000db Ps3-at rendeltek, hanem egy IBM szervert!"
Még jó, hogy egy katonai szupergépet nem PS3-akból építenek fel. Ha viszont spórolni kel...

Cell vs. G80 @Raytracing

Méretek, tranzisztorszámok, és raw flops-ok:


Ehhez képest raytracing-performance:


Ugye látod ezt, kvp? ;)

Azt irtad: "Mit gondolsz, az IBM miért Cellekbõl (plusz kiegészítésnek Opteronokból) építi a köv. világelsõ szuperszámítógépét, a Roadrunnert, nem G80-akból vagy R600-asokból?"

Erre az volt a szimpla válasz, hogy azért mert azok nem neki hoznak hasznot, nem õ gyártja õket. Ha az IBM történetesen videokártyákat gyártana akkor abból építené és nem a cellbõl.
Azonkivül szerintem a cell-el mint processzorral nem is volt itt senkinek sem baja. Legalábbis nem rémlik, hogy valaki ezt támadta volna. Szerintem egy jó processzor és ezt mindenki elismeri. Viszont a ps3 az nem maga a Cell processzor...

"És, ez mit von le a dolog értékébõl?"

Természetesen semmit. Csak azt állitani, hogy azért nyert itt a cell mert az a legjobb , ez miatt dõreség. Akkor amelyik tenderen az AMD nyer akkor az a legjobb?
Ráadásul ez is bizonyitja azt amirõl folyamatosan beszélek. Nem 1000db Ps3-at rendeltek, hanem egy IBM szervert!

'sokszor utasítás-szinten keveredik a két fajta mûvelet'

Hanem mi?

És, ez mit von le a dolog értékébõl?

Miért kéne, hogy ugyanazt számolják?

Jah ráadásul nem is ez volt a kérdés...

"Csakhogy az IBM nem csak úgy magának építi a Roadrunnert, hanem katonai tenderre, ahol más cégek is indultak, mégis az IBM nyert, konkrét tervekkel természetesen. Tehát az elbírálók szerint is használható a Cell"

Meg rengeteg más helyen nyert az AMD és az Intel is, és még sorolhatnám.

Ja, a hasonlat kimaradt:

"Itt a hasonlat az, hogy cell spe eseten csak 8 kis betonkevero van amiket kezzel kell megtoltni es kiuriteni, mig a masik ceg 3 nagy betonkevero teherautot ad, amik toltik es uritik is magukat. Melyikkel lesz konnyebb a munka es kell hozza kevesebb ember???"

Sántít ez a hasonlat. Éppenhogy a 8 betonkeverõ a nagyobb, csak nem hétköznapi, amivel - mint Nexus6 is írta - Józsi bácsi is elboldogul, hanem speciális, nagyteljesítményû gépek, amikhez szakszemélyzet kell, viszont ontják is a betont.

Csakhogy az IBM nem csak úgy magának építi a Roadrunnert, hanem katonai tenderre, ahol más cégek is indultak, mégis az IBM nyert, konkrét tervekkel természetesen. Tehát az elbírálók szerint is használható a Cell.

"Igy van és azt is irja, hogy ezért használják mellette a cpukat is. Az pedig van minden gépben."
Ez nem ilyen egyszerû, mert sokszor utasítás-szinten keveredik a két fajta mûvelet, miközben most a CPU és a GPU közötti kapcsolat nagyon lassú ehhez.

"A lényeg hogy az eredményeknél az jön ki hogy egy gpus gép gyorsabban számol jóval."
Csak nem ugyanazt.

"Erre irtam, ha ugyanezeket elinditom haver xps gépén az lényegesen kezesebben viselkedik ilyenkor."

Erre kérdeztem, hogy 256MB rammal? Azt kötve hiszem, hogy az XP spórolósabb lenne a memóriával, mégis el lehet lenni 256MB rammal (+ virtuális memória) - nemrég anyáméknál volt alkalmam ezt megtapasztalni.

Egyébként talán a késõbbiekben használhatóvá válik majd a VRAM is, akkor összesen 512MB lesz.

Azért ha csak üzenni akarsz valakinek, vagy más apróbb mûveletet végrehajtani, jó, ha nem kell ide-oda szaladgálni. Meg ugye nem csak magadból kellene kiindulni.

btw, korábban említettél valami olcsó touch-screen panelt (gondolom, LCD-vel együtt, mert nélküle én is tudok), írnál róla valami infót?

Na, asszem ideje válaszolnom.

"Szerintem inkabb probald ki. En is ezt tettem. Nagyon jo szorakozas... bar lehet hogy csak azert tunt konnyunek mert mar ismertem a forditot."
Mi tûnt könnyûnek? Lefordítani egy kisebb programot? Nem ez a nehéz, hanem a CUDA-t komolyabb célokra használni szándékozók szerint optimális kódot készíteni, ami nem csak fut, de értelmes sebességgel fut.

"A scatter-gather i/o pedig nagyon jol jon pl. raytrace-hez. De lehet alatta rendes grafikus/fizikai motorokat is irni, ahol minden latott polygon egy fizikai objektum resze, vagy dinamikusan valtozik a polygon-ok szama a kivant reszletesseg fuggvenyeben. (cpu beavatkozas nelkul)"
Kár, hogy ezeket még nagyon lassan viszi - lásd Geometry Shader teljesítmény a béka feneke alatt.

"Bar a local store-juk nem eppen szep, de mivel van rendes memoria i/o es smt ezert ez nem igazan szamit. (ha nem fer el az adat legfeljebb lassabb lesz a program, de mindenkeppen futni fog)"
Ja, legfeljebb 100x lassabb...

"Nem tudom neked mi az eleg, de egy gyakorlatban is hasznalt mintailleszto rendszerben 256MB volt a local store. (1 orajeles statikus ram-bol felepite) Az hozta a megfelelo teljesitmenyt, raadasul powerpc alapu rendszer volt. Egy mai jobb jatek mi vagy fizikai motor dataset-je neha nagyobb ennel, bar egy lepes soran nem dolgozodik fel az egesz. A baj az, hogy az algoritmus nem tudja elore mi fog kelleni neki."
2MB (8*256KB) már elég sok dologra elég.

"Talan mert sok cell-uk van raktaron es az nvidia bevetele nem az o hasznukat noveli?"
Hát ez nem egészen így ment, ugyanis akkor nem az IBM kapta volna a megbízást.

"A memoria fele mar nem olyan nagy a savszelesseg"
De igen, a memória felé ennyi. Az LS felé jóval gyorsabb.

"es a scatter gather i/o-t hasznalo algoritmusok igenis quadword-onkent akarnak olvasni."
Ez oké, de sokszor át lehet variálni a dolgokat. Nem emlékszel a múltkor hogy átalakítottam a példádat?

"En jatekra gondoltam elso korben. A ps3 alapvetoen jatekkonzol. Ha arra nem jo, akkor nem josolok neki tul fenyes jovot."
Majd meglátjuk néhány év múlve, jól gondoltad-e.

"Probaltad mar hasznalni az stl library-t cell spe-n? Es sikerult is?"
Még nem. De itt fordítókról volt szó, és azok vannak. (Én amúgy is mindent szeretek magam megírni.)

"Akkor ezert jobbak es van tobb linux-os jatek?"
Nem csak játékokról van itt szó.

"A cell-el az a baj, hogy az spe-k nem ugy mukodnek ahogy a vilag osszes tobbi altalanos cpu-ja teszi ezt egy ideje."
PC-s vonalon is jönnek majd a hasonló inhomogén chipek.

"Az ibm fele cucc jo resze open, tehat mashol is hasznalhato."
A kimondottan Cell-orientált dolgok nem igazán.

"Szerintem inkabb valami kesz kod jobb lett volna, mondjuk szabvanyos formaban. Hivhatnak felolem akar sony direct-opengl-nek is, csak ne techdemokbol allna."
Tudod, vannak a lusta programozók, és a nem-lusták. Az egyik összeollózik valamit kész kódokból, a másik a példákból megérti, mit hogy jó csinálni. Tudom, tudom, könnyed (multiplatform) fejlesztés, stb. Viszont ez egy konzol, nem egy Windows-box.

"Hanem hogy van? Mert kesz algoritmus meg egyelore nagyon keves van. Demok vannak, de eles project-ben ezek a kodok kapasbol buknak, mert nem szabvanyosak."
Lásd fent.

"De egy mai jatekban nagyobb az adatmennyiseg, es egy spe nem skalazodik felfele, mert a memorialimit bele van egetve az architekturaba. Legalabbis a ps3 cpu-jaba igen. Es ki akarna gpu-s shader logikat futtatni a fo processzoron? A szoftver renderelo mar kiment a divatbol."
A PS3 esetén legalább van erre kapacitás, az Xbox360-nál nem sok.

"Kb. ennyit rak az ember az otthoni barkacs hardverebe, hasonlo 1 orajeles sram formajaban. (mikrovezerlokben van kb. ennyi) Profi felhasznalasra mar tobbet szokas."
A GPU-kban még ennyi sincs, legalábbis a G80-ban az újak közül - az R600 valamivel jobban el van eresztve. Tehát még az újabb GPU-k sem többszörösen rekurzív kódokra, és más effélére vannak szánva.

"Ha meg olcson akarjuk meguszni akkor tobb lassabb egyseg es smt alapu thread valtas amig a kert adat megjon. Ezt hasznalja a gf8800-as."
Nem tudok róla, hogy az egyes egységek össze-vissza tudnának váltani a threadek között. Regiszterkészletbõl is annyi kellene.

"Meg a barkacs xbox360 is kapott 10 Mb nagyon gyors edram-ot, ami kb. az sram-ok szintjen van sebessegben, csak valojaban dram. Ilyet akar rakni az ibm az uj powerpc cpu-jaiba. A cell2-ben talan mar lesz is."
Az xbox360 esetén ennek felhasználhatóságe elég szûkös - és a nagy sávszél nem a GPU és az EDRAM között áll fenn, hanem csak az EDRAM-on belül, a ram és az ott lévõ kisméretû logika között.

"Ha lenne, akkor nem az agyhalott dma rendszert hasznalna. Epp ez a gondom az egesz cell-el, hogy ezt az egy aprosagot kihagyak, mivel az spe nem tud sem hardveres smt-t, sem prediktiv memoria i/o-t, ezert a virtualis memoria kezeles csak lock-olna a teljes feldolgozast amig a lassu rambol megjon az adat, igy inkabb nem raktak bele."
Valami azért van, mert mindegyiknek van egy MMU-ja. Mindenesetre, 32 bitesek a címek, így ha máshogy nem, szoftveresen megoldható a lapozás. Ez persze lassú hétköznapi kód esetén, de lehet optimizálni rajta.

"Kis adatkeszletnel ez igaz. Ha elfogy a 256KB (kilobyte!) akkor jonnek elo a gondok. Azert ez mar nem egy olyan nagy adatmennyiseg hogy egy fizikai modell ne tartalmazzon tobb adatot. (es meg a programnak is bele kellene fernie)"
Nyilván bonyolódnak a dolgok 256KB (vagy kooperatív munka esetén 2MB felett), de sok esetben nem túlzottan.

"Probald ki! A linux eredetileg M68k-ra optimalizalt valtozata tokeletesen fut barmilyen memoriavedelem nelkuli rendszeren, bar driver nem nagyon lesz hozza, de vegulis csak egy shared memory alapu driver stack kell neki (csomag i/o alapu virtualis hardverekkel, amiket a kulso cpu kezel). Last nommu-s kernel. A kod egyszalu resze nagyon lassu lesz, de a parhuzamos feldolgozas sokat nyer a 128 maggal."
Az "általános CPU" azt jelenti, hogy általános kódot értelmes sebességgel futtat. A G80 erre nem képes, csak nagyon lassan. Nagyon is specializált rendszer. A gyosítás nem egyszerû párhuzamosítás, hanem sok kötöttségre kell odafigyelni.

"Van mar devkit-ed? Ha nincs vetess a cegeddel egyet es megerted miert kap hulyet tole a legtobb fejleszto."
Jelenleg megbízásos magánzó vagyok, szal max. magam vehetek egy PS3-at, és szórakozhatok Linux alól.

"Mutass egy ceget magyarorszagon ahol ps3 exkluziv fejlesztes van es eppen van felvetel rendes fizetessel... egyszeruen a ps3 exkluzivitas nem jellemzo a mai cegekre. Mindeki csak egyszer ir es sokszor fordit. Mondjuk ez az eladasok tukreben ertheto."
M.o. kis ország - a világon máshol azonban vannak ilyen fejlesztések. És ahogy beindul a szekér, több is lesz.

"Egyebkent meg en teljesen tisztaban vagyok azzal, hogyan lehetne jo kodot irni a cell-re. Jol szegmentalhato adatmodell kell, vektoros feldolgozas, manualis memoriakezeles, es buta, de gyors cpu-t igenylo algoritmusok. Az egyetlen gond, hogy egy ilyen kod nem futna jol mas cpu-kon. Ha egy ceg valaszthat, hogy fejleszt az osszes tobbire vagy ps3 exkluziv lesz, akkor az elsore fog tenni. Es meg tobbet is adnak el az osszes tobbi gepbol (pc, xbox360, wii) tehat tobb jatekot is fognak rajuk venni."
A PS3-mal viszont különlegesebb dolgokat lehet csinálni, és ha megjelenik 1-2 ilyen, az jó hatással lesz az eladásokra is - utána megéri majd több ilyet fejleszteni.

"===Mas==="
Egyszerûbb lenne használni a "válasz erre"-t (akkor a visszakövetés is könnyebb), és személyesen válaszolni.

"Majd jopar ev mulva mar lesz rendes tamogatas, de addigra elavul a cell."
A PS3-ban lévõ igen, de közben lesznek újabb Cellek is, több+okosabb PPE-vel, SPE-vel, LS-sel.

"A hagyomanyos algoritmusok pedig cpu-tol fuggetlenul barhol jol fognak futni a jovoben is, mig a cell-re optimalizaltak csak a cell-eken."
Mint írtam, PC-s vonalon is jönnek majd a heterogén chipek (náhány sima CPU mag, és jópár SIMD-alapú mag). (Poén lenne, ha azok is DMA-sok lennének a jobb helykihasználás érdekében. :P)

Szerintem de!;)))

Legalábbis nálam ez az elsõdleges számítógép.
Az persze, hogy kinek mi a jó, elég viszonylagos. Nem tökéletes, de használható.

Nem is arról beszéltünk hogy a cellen milyen a linux, hanem hogy a ps3-mon. És mint te is elismered, nem túl jó. Lehet, hogy ez idõvel változik majd, de jelenleg nem lehet pcként használni bármit is állit dez.

"Itt a hasonlat az, hogy cell spe eseten csak 8 kis betonkevero van amiket kezzel kell megtoltni es kiuriteni, mig a masik ceg 3 nagy betonkevero teherautot ad, amik toltik es uritik is magukat. Melyikkel lesz konnyebb a munka es kell hozza kevesebb ember???

Az edge konyvtarrol meg annyit, hogy nem eri el a directx szinvonalat, pedig ebben az esetben nincs tul magasan a lec. Majd jopar ev mulva mar lesz rendes tamogatas, de addigra elavul a cell. A hagyomanyos algoritmusok pedig cpu-tol fuggetlenul barhol jol fognak futni a jovoben is, mig a cell-re optimalizaltak csak a cell-eken."

Tudom, hogy értelmetlenség egy szinten tovább vinni a hasonlatot de épp fordtva van a dolog. A hagyomágyos szimmetrikus magos architektúrák speciális "betonkeverési" feladatra éppen lassúbbak. Igaz ott van mellettük az általános célú józsibácsi, akinek nem kell a szájába rágni hogy mit csináljon, addsz neki 10-ezer forintot és elmegy cementért a kis betonkeverõjéhez, és még a cébéába is beugrik a söréért.

A cellben viszont ott van 8 db "betonkeverõs teherkocsi", ami lehet hogy csak a betongyárból tud betont hozni, és a sofõrök is EU normáknak felelnek meg, szal munkaidõben önállóan nem ugranak be sörért, és a szállítólevelüknek is teljesen rendben kell lenni, de õk nem családi házat fognak neked építeni, hanem felhõkarcolót!

Igen a Sony viszonylag elmaradásban van a könyvtárak tekíntetében, de lehet hogy sokkal több támogatást is kapsz tõlük a programozó kommandó képében, ha exkluzív progit fejlesztesz a platformra, mint amit a M$ adna. (Lásd UT3 esete).

Ha próbáltad, akkor számodra is nyilvánvaló gondolom, hogy nem a cell sebességével van gond, hanem hogy a Linuxot is úgy írják manapság, hogy ha grafikus felületet használsz, akkor végtelen mennyiségû memória sem elég. Na erre a PS3-nak van kb 200MB-ja amibõl tud gazdálkodni. Szal nem a cell a lassú!!!

Ez egy Firefox, egy egyszerûbb média lejátszó, meg mondjuk egy torrent kliens használatát jelenti egyszerre. Ha még valamit elindítasz akkor az ablakok/programok közötti váltás megismertet az örökkévalóság élményével, de az elõbbi program összetétel még teljesen OK! Szal kb 3 dolgot tudsz futtatni egyszerre.

Ja és mégegyszer, pl. a MPlayer SPU támogatása is még csak most lesz elérhetõ, szal minden a PPE-n fut.

Réadásul az nvidia a tesla supercomputerrel közvetlen vetélytárs is.

"Ez is tévedés. Mit gondolsz, az IBM miért Cellekbõl (plusz kiegészítésnek Opteronokból) építi a köv. világelsõ szuperszámítógépét, a Roadrunnert, nem G80-akból vagy R600-asokból?"

Talán azért mert a Cellt õ gyártja a többit meg a konkurencia? Nah vajon miért?

"a GPU-k egyszerûbb számításoknál nagyon gyorsak, de ha már kicsit összetettebb dolgokról van szó, erõsen visszaesik a teljesítményük! Sõt bizonyos algoritmusokra még nem is alkalmasak."

Igy van és azt is irja, hogy ezért használják mellette a cpukat is. Az pedig van minden gépben. A lényeg hogy az eredményeknél az jön ki hogy egy gpus gép gyorsabban számol jóval.

"Magam ugyan még nem próbáltam, de többen, akik normálisan fel tudtak tenni egy Linuxot"

Figyelj, mint irtam én próbáltam és ugyanarról számoltam be mint amirõl Nexus is a ps3 topicba. Megy meg minden, de ha egyszerre megy levelezés, internet, mp3, stb, akkor azért már türelem kell hozzá. Erre irtam, ha ugyanezeket elinditom haver xps gépén az lényegesen kezesebben viselkedik ilyenkor.

"És most egymás mellett fogsz tartani egy PS3-at és egy ilyen csúnya (fehér bádogdobozos ennyiért) kis PC-t a nappaliban?"

Hát egyrészt szerintem a ps3 sem lett szebb, másrészt meg nem. A nappaliban a tévé alatt a konzolom van. A számitógép egy másik szobában van monitorral. Eszembe sem jut a tévé elõtt számítógépezni, feleségem biztos kinyirna. A "dolgozószobában" is elég nagy kupi van emiatt.

""Es a kulso memoriacimzes tamogatasa miatt meg c++-os kod is elfut rajta"
Na persze, ahogy azt pistike elképzeli. Beszélj egy CUDA programozóval."

Szerintem inkabb probald ki. En is ezt tettem. Nagyon jo szorakozas... bar lehet hogy csak azert tunt konnyunek mert mar ismertem a forditot. A scatter-gather i/o pedig nagyon jol jon pl. raytrace-hez. De lehet alatta rendes grafikus/fizikai motorokat is irni, ahol minden latott polygon egy fizikai objektum resze, vagy dinamikusan valtozik a polygon-ok szama a kivant reszletesseg fuggvenyeben. (cpu beavatkozas nelkul) Bar a local store-juk nem eppen szep, de mivel van rendes memoria i/o es smt ezert ez nem igazan szamit. (ha nem fer el az adat legfeljebb lassabb lesz a program, de mindenkeppen futni fog)

""mig a cell spe-kben erre nincs eleg kozvetlenul cimezheto memoria."
256KB/SPE épp elég kisebb programokhoz+adatokhoz. (Ezt mikrokontrolleresként tudnod kellene.) A többit meg lehet DMA-zni viszonylag nagy sávszéllel."

Nem tudom neked mi az eleg, de egy gyakorlatban is hasznalt mintailleszto rendszerben 256MB volt a local store. (1 orajeles statikus ram-bol felepite) Az hozta a megfelelo teljesitmenyt, raadasul powerpc alapu rendszer volt. Egy mai jobb jatek mi vagy fizikai motor dataset-je neha nagyobb ennel, bar egy lepes soran nem dolgozodik fel az egesz. A baj az, hogy az algoritmus nem tudja elore mi fog kelleni neki.

""A gyenge pontjuk a cimezheto memoria kis merete, ami miatt hasznalhatosagban csak a dsp chipekkel tudnak versenyezni, egy gpgpu-val mar nem."
Ez is tévedés. Mit gondolsz, az IBM miért Cellekbõl (plusz kiegészítésnek Opteronokból) építi a köv. világelsõ szuperszámítógépét, a Roadrunnert, nem G80-akból vagy R600-asokból?"

Talan mert sok cell-uk van raktaron es az nvidia bevetele nem az o hasznukat noveli?

""A dma-s ram kezeles olyan mint amikor egy videokartya a rendszer rambol probal texturazni. Mukodik, de nagyon lassu."Nem olyan nagyon lassú (hacsak nem quadwordonként akarnak olvasni), mivel itt egy ~25 GB/s-es elérésrõl beszélünk, nem a töredékérõl."

A memoria fele mar nem olyan nagy a savszelesseg es a scatter gather i/o-t hasznalo algoritmusok igenis quadword-onkent akarnak olvasni.

""A gf8800-as egyszeruen egy jobban hasznalhato architektura"
Attól függ, mire akarják használni õket. Ezt kellene legalább megértened."

En jatekra gondoltam elso korben. A ps3 alapvetoen jatekkonzol. Ha arra nem jo, akkor nem josolok neki tul fenyes jovot.

""A forditoprogramok nem boldogulnak veluk, mert nincs ilyen architekturara optimalizalt fordito."
Dehogynincs. Még a GCC-hez is van SPE támogatás, az IBM készít két saját C-fordítót is (egy egyszerûbbet és egy szuperszámítógépre optimizáltat),"

Probaltad mar hasznalni az stl library-t cell spe-n? Es sikerult is?

""es jobb szoftvertamogatassal rendelkezik mint a ps3 mivel a microsoft (dx10) es az nvidia (gpgpu) is ott all mogotte."
A Cell mögött meg az IBM, a Sony, a Toshiba, számos más cég, egyetemek, egyes katonai szervezetek, és az opensource közösség egy része is."

Akkor ezert jobbak es van tobb linux-os jatek? A cell-el az a baj, hogy az spe-k nem ugy mukodnek ahogy a vilag osszes tobbi altalanos cpu-ja teszi ezt egy ideje.

""A sony elfelejtett egy akkora szovtverkonyvtarat adni a cell-hez ajandekba mint amilyen a microsoft directx."
DirectX? Most mirõl beszélünk, játékokról, vagy tudományos+egyéb felhasználásról? Ha utóbbiról, nézd meg az IBM kínálatát, ha játékokról, akkor meg lásd a Sony fejlesztõ-csomagját."

Az ibm fele cucc jo resze open, tehat mashol is hasznalhato. A sony fele kit-ben meg nem sok dolog van a (butitott) opengl-en es mas alap library-ken kivul. A segedkonyvtarak jo resze meg mindig hianyzik, mint ahogy a stabil online felulet is csak keszul, de sajnos meg mindig nem eri el a microsoft szinvonalat. Pedig a sony minden elerheto ingyenes komponenst is beepitett.

A sony szovegebol:
"rather than an overarching engine, these teams have chosen to create specialized systems that demonstrate best practices of SPU and RSX utilization."

Szerintem inkabb valami kesz kod jobb lett volna, mondjuk szabvanyos formaban. Hivhatnak felolem akar sony direct-opengl-nek is, csak ne techdemokbol allna.

"Ha nincs ra algoritmus, nincs ra rendes fordito, akkor baromi nehez barmit is kihozni."
Csakhogy ez nem egészen így van."

Hanem hogy van? Mert kesz algoritmus meg egyelore nagyon keves van. Demok vannak, de eles project-ben ezek a kodok kapasbol buknak, mert nem szabvanyosak.

""A jatekok meg jo ideje rengeteg uzleti logikahoz hasonlo feladatot vegeznek, azaz sok felteteles elagaz van a programokban, meg a v2-nel jobb shader-ekben is."
Sokat, de nem annyit, amennyivel ne boldogulna el a PPE (vagy akár egy SPE, ha megfelelõen kicsi az adatmennyiség)."

De egy mai jatekban nagyobb az adatmennyiseg, es egy spe nem skalazodik felfele, mert a memorialimit bele van egetve az architekturaba. Legalabbis a ps3 cpu-jaba igen. Es ki akarna gpu-s shader logikat futtatni a fo processzoron? A szoftver renderelo mar kiment a divatbol.

""Nem. Tobbnyire DSP-ket es mikrovezerloket szoktam programozni, tehat ismerem a problemakat."
Valóban? Hát itt azért nem egészen egyszerû DSP-krõl és mikrokontrollerekrõl van szó.
Meg nem tudom, hogy programozol, de érdekes, hogy ehhez képest mennyire lebecsülöd azt a 256KB-ot."

Kb. ennyit rak az ember az otthoni barkacs hardverebe, hasonlo 1 orajeles sram formajaban. (mikrovezerlokben van kb. ennyi) Profi felhasznalasra mar tobbet szokas. Tudom hogy 256 _MB_ sram eleg draga, de gyors is es bele is fer a legtobb jelenlegi adat. Persze tudok mondani olyan esetet a kozeljovoben amikor meg ez is keves lesz. Ha meg olcson akarjuk meguszni akkor tobb lassabb egyseg es smt alapu thread valtas amig a kert adat megjon. Ezt hasznalja a gf8800-as. Meg a barkacs xbox360 is kapott 10 Mb nagyon gyors edram-ot, ami kb. az sram-ok szintjen van sebessegben, csak valojaban dram. Ilyet akar rakni az ibm az uj powerpc cpu-jaiba. A cell2-ben talan mar lesz is.

""Egyik sem tul gyors, es mivel az spe-ben nincs hardveres virtualis memoria kezeles"
De, tudomásom szerint van!"

Ha lenne, akkor nem az agyhalott dma rendszert hasznalna. Epp ez a gondom az egesz cell-el, hogy ezt az egy aprosagot kihagyak, mivel az spe nem tud sem hardveres smt-t, sem prediktiv memoria i/o-t, ezert a virtualis memoria kezeles csak lock-olna a teljes feldolgozast amig a lassu rambol megjon az adat, igy inkabb nem raktak bele. A full crossbart meg csak sporolasbol hagytak ki, az meg az ibm mernokeit is zavarta, bar tenyleg nem sokat javitott volna a helyzeten. (6-rol 1-re vitte volna a belso busz latency-jet es 3-szorosara a saveszelt, ami ugye igy is eleg)

""Ma mar kaphatoak 8 magos rendszerek (2x4 mag)."
Aha, csak épp túl drága átlagfelhasználásra, és igen lassan és nagy késleltetéssel éri el az egyik proci a másikat és a memóriát."

A cikkben szereplo rendszernel meg a hp 8 magos asztali gepe is jobb. (teszteltem egy ilyet linux alatt es egy specialis '4 monitoros oblivion tesztben' is, persze az utobbit nem hivatalosan munka kereteben hanem csak azert mert nem birtam ki hogy ne nezzem meg)

""Mig pc-n, xbox360-on csak ujra kell forditani a tobbszalu kodot es maris gyorsabb lesz, addig ps3-on minden ujra kell irni."
Ez így nem igaz. Sokszor csak némileg kell átírni v. kiegészíteni, és Cellen jóval gyorsabb még így is, fele SPE kihasználtsággal (fejlesztõ írta)."

Kis adatkeszletnel ez igaz. Ha elfogy a 256KB (kilobyte!) akkor jonnek elo a gondok. Azert ez mar nem egy olyan nagy adatmennyiseg hogy egy fizikai modell ne tartalmazzon tobb adatot. (es meg a programnak is bele kellene fernie)

""Meg jo, hogy az nvidia gf8800-as sorozat mar altalanos cpu-kat kapott, amik akar a linux-ot is futtathatjak, bar memoriavedelem nelkul."
Ez egy hülyeség."

Probald ki! A linux eredetileg M68k-ra optimalizalt valtozata tokeletesen fut barmilyen memoriavedelem nelkuli rendszeren, bar driver nem nagyon lesz hozza, de vegulis csak egy shared memory alapu driver stack kell neki (csomag i/o alapu virtualis hardverekkel, amiket a kulso cpu kezel). Last nommu-s kernel. A kod egyszalu resze nagyon lassu lesz, de a parhuzamos feldolgozas sokat nyer a 128 maggal.

""es olyan programozok kellenek ra mint akik annak idejen c64-es meg amiga-s demokat irtak. Mara nem sok ilyen koder maradt"
Jelen! :)"

Van mar devkit-ed? Ha nincs vetess a cegeddel egyet es megerted miert kap hulyet tole a legtobb fejleszto.

""es a jatekkeszito cegeknek meg nem eri meg rendesen megfizetni oket."
A multiplatformosoknak, akik egyszerû újrafordításdiban gondolkodnak..."

Mutass egy ceget magyarorszagon ahol ps3 exkluziv fejlesztes van es eppen van felvetel rendes fizetessel... egyszeruen a ps3 exkluzivitas nem jellemzo a mai cegekre. Mindeki csak egyszer ir es sokszor fordit. Mondjuk ez az eladasok tukreben ertheto.

Egyebkent meg en teljesen tisztaban vagyok azzal, hogyan lehetne jo kodot irni a cell-re. Jol szegmentalhato adatmodell kell, vektoros feldolgozas, manualis memoriakezeles, es buta, de gyors cpu-t igenylo algoritmusok. Az egyetlen gond, hogy egy ilyen kod nem futna jol mas cpu-kon. Ha egy ceg valaszthat, hogy fejleszt az osszes tobbire vagy ps3 exkluziv lesz, akkor az elsore fog tenni. Es meg tobbet is adnak el az osszes tobbi gepbol (pc, xbox360, wii) tehat tobb jatekot is fognak rajuk venni.

===Mas===
"Pár napja a neten fenn volt egy interjú a cell tervezõ csoportjának "fõépítészével". Rákérdeztek, hogy szerinte miért panaszkodnak a programozók az új architektúrára?
Azt válaszolta, hogy ez a bonyolultabb architektúra sokkal több elõzetes tervezést igényel. Õ különbözõ nagyságú vállalatokat hozott fel példának.
Ha csak kicsi a vállakozás akkor mindíg van lehetõség, hogy az ember elugorjon a boltba cementért, vagy akármiért ha elfogyna, mert rosszul mért fel elõzetesen valamit az ember. De egy nagy vállalat nem tud egyszercsak több tonna cementet elõteremteni, ha a szükségleteket rosszul rosszul tervezték be."

Itt a hasonlat az, hogy cell spe eseten csak 8 kis betonkevero van amiket kezzel kell megtoltni es kiuriteni, mig a masik ceg 3 nagy betonkevero teherautot ad, amik toltik es uritik is magukat. Melyikkel lesz konnyebb a munka es kell hozza kevesebb ember???

Az edge konyvtarrol meg annyit, hogy nem eri el a directx szinvonalat, pedig ebben az esetben nincs tul magasan a lec. Majd jopar ev mulva mar lesz rendes tamogatas, de addigra elavul a cell. A hagyomanyos algoritmusok pedig cpu-tol fuggetlenul barhol jol fognak futni a jovoben is, mig a cell-re optimalizaltak csak a cell-eken.

Húbameg, mi a zisten van itt?!!!
;)))

Csak 1 dolgohoz szólnék hozzá:
"A sony elfelejtett egy akkora szovtverkonyvtarat adni a cell-hez ajandekba mint amilyen a microsoft directx."
Nem egészen, nemtom hallottál-e róla, hogy a fejlesztõkészletekhez adott könytárak (OGL, miegymás) mellé a SONY egy fejlettebb könytár csomagot is ad, ennek a neve EDGE.

Aztán elég sok programozójuk járja a fejlesztõ stúdiókat és közetlenül is besegítenek a kódolásba!

Pár napja a neten fenn volt egy interjú a cell tervezõ csoportjának "fõépítészével". Rákérdeztek, hogy szerinte miért panaszkodnak a programozók az új architektúrára?
Azt válaszolta, hogy ez a bonyolultabb architektúra sokkal több elõzetes tervezést igényel. Õ különbözõ nagyságú vállalatokat hozott fel példának.
Ha csak kicsi a vállakozás akkor mindíg van lehetõség, hogy az ember elugorjon a boltba cementért, vagy akármiért ha elfogyna, mert rosszul mért fel elõzetesen valamit az ember. De egy nagy vállalat nem tud egyszercsak több tonna cementet elõteremteni, ha a szükségleteket rosszul rosszul tervezték be.

Komoly szintlépésnek vagyunk tanui, amit a programozók egy része nem nagyon akar elfogadni, tök mindegy, hogy a cell, vagy más architektúra kapcsán, de a programozóknak egy sokkal struktúráltabb stílust kell felvenni.
Ez sajnos nem olyan mint egy új utasításkészlet, a programok struktúrája lép egy teljesen új bonyolultsági fokra.

Még néhány kiegészítés.
1. Az SPE-k címregiszterei 32 bitesek, így a címtér 4GB (elõjel nélkül).
Persze fizikailag csak 256KB van. A saját MMU egységeikkel valószínû megoldható az automatikus ki-/belapozás is. Így végülis egy optimizálatlan C kód is elfuthat.
2. A saját ram L1 cache sebességû, de belõle 256KB olyan, mint L1-bõl ennek többszöröse, mert nincs szükség a széles cache-line-okra.
3. Ha a main ramhoz kell nyúlni, az persze lassít, de a nagy sávszél, és az okos memória-rendszer által kb. oda lassul a dolog, mint amikor egy sima procinak a memóriához kell férnie, legalábbis nagyságrendileg.

"Meg hardveres videogyorsitas sincs, a drm kezelo mag meg masolgatja az adatokat a framebuffer-bol a videoramba. Ez kb. egy pci-os lfb-s videokartyaval felszerelt PIII-as szintjere butitja a ps3-at."
Nem egészen, mivel a PCI 133 MB/s, itt viszont ~25 GB/s játszik.
Plusz attól, hogy a grafika nem túl gyors, kisebb programokat teljesen jól el lehet futtatni.

"(mivel az spe-kre meg nincsennek programok)"
Nemsokára lesz mindenféle.

"Ez sokmindenre jo, de otthoni hasznalatra csak annyira mint egy wii a hozza valo operaval."
Ez enyhe túlzás.

"Jo lenne ha reszletezned. A gf8800-as mukodese hasonlo csak tobb, de lassabb mag van benne."
Sajnos ez egy akkora tévedés, hogy nem is tudom, hol kezdjem magyarázni, miért nem így van. Láthatóan mindkettõt nagyon-nagyon felületesen ismered.

"Es a kulso memoriacimzes tamogatasa miatt meg c++-os kod is elfut rajta"
Na persze, ahogy azt pistike elképzeli. Beszélj egy CUDA programozóval.

"mig a cell spe-kben erre nincs eleg kozvetlenul cimezheto memoria."
256KB/SPE épp elég kisebb programokhoz+adatokhoz. (Ezt mikrokontrolleresként tudnod kellene.) A többit meg lehet DMA-zni viszonylag nagy sávszéllel.

"A cell spe-k alapvetoen gyors skalar magok"
Nem skalar.

"memoriakezelo egyseg nelkul, par kilobyte-os cimterrel."
Az a pár az 256KB.

"A gyenge pontjuk a cimezheto memoria kis merete, ami miatt hasznalhatosagban csak a dsp chipekkel tudnak versenyezni, egy gpgpu-val mar nem."
Ez is tévedés. Mit gondolsz, az IBM miért Cellekbõl (plusz kiegészítésnek Opteronokból) építi a köv. világelsõ szuperszámítógépét, a Roadrunnert, nem G80-akból vagy R600-asokból?

"A dma-s ram kezeles olyan mint amikor egy videokartya a rendszer rambol probal texturazni. Mukodik, de nagyon lassu."
Nem olyan nagyon lassú (hacsak nem quadwordonként akarnak olvasni), mivel itt egy ~25 GB/s-es elérésrõl beszélünk, nem a töredékérõl.

"Ezzel szemben a 256Kb nagyon keves."
256 kilobit tényleg nagyon kevés - 256KB azért nem annyira.

"Ennel joval tobb belso memoria jut egy gf8800-as regiszter terere is, es mindkettonek 1 orajel az eleresi ideje."
Nem tudom, mirõl beszélsz, a G80-ban éppenhogy túlságosan is kevés a belsõ buffer, ez hátrányt jelent számára az R600-zal szemben. Pedig még abban sincs éppenséggel 2MB (8*256KB).

"A gf8800-as egyszeruen egy jobban hasznalhato architektura"
Attól függ, mire akarják használni õket. Ezt kellene legalább megértened.

"es jobb szoftvertamogatassal rendelkezik mint a ps3 mivel a microsoft (dx10) es az nvidia (gpgpu) is ott all mogotte."
A Cell mögött meg az IBM, a Sony, a Toshiba, számos más cég, egyetemek, egyes katonai szervezetek, és az opensource közösség egy része is.

"es ajandek tudomanyos celu fejlesztoi keszletet is ad hozza az nvidia)"
Az IBM is sokmindent ad a Cellhez, ingyen.

"A forditoprogramok nem boldogulnak veluk, mert nincs ilyen architekturara optimalizalt fordito."
Dehogynincs. Még a GCC-hez is van SPE támogatás, az IBM készít két saját C-fordítót is (egy egyszerûbbet és egy szuperszámítógépre optimizáltat), és egy-két cég készít tudományos felhasználást igencsak segítõ fejlesztõi környezezet, amivel komoly programozói tudás nélkül is ki lehet használni a chipet, pl. egy matematikusnak vagy egy fizikusnak.

"Ha valaki assembly-ben all neki, akkor boldogul, bar a scatter-gather memoriamodelles algoritmusok itt nem hasznalhatoak, mivel csak block io van a dma egysegben. Az utobbi idokben a gpu-k es az x86-osok miatt az osszes haszalhato nem vektoros algoritmus random memoria i/o-ra alapoz, mert az osszes mai gep ilyen. (kiveve a dsp-ket es regi vektoros szuperszamitogepeket, amik mara kihaltak) Ha nincs ra algoritmus, nincs ra rendes fordito, akkor baromi nehez barmit is kihozni."
Csakhogy ez nem egészen így van.

"A sony elfelejtett egy akkora szovtverkonyvtarat adni a cell-hez ajandekba mint amilyen a microsoft directx."
DirectX? Most mirõl beszélünk, játékokról, vagy tudományos+egyéb felhasználásról? Ha utóbbiról, nézd meg az IBM kínálatát, ha játékokról, akkor meg lásd a Sony fejlesztõ-csomagját.

"Minden programozo talalhatja fel a sajat algoritmusait, mint regen a c64-es assembly-s idokben. Oke hogy gyors lesz, de tobb evvel tovabb tart megirni. Megeri?"
1. csak bizonyos esetekben van erre szükség, és 2. adott esetben megéri.

"Nem. Tobbnyire DSP-ket es mikrovezerloket szoktam programozni, tehat ismerem a problemakat."
Valóban? Hát itt azért nem egészen egyszerû DSP-krõl és mikrokontrollerekrõl van szó.
Meg nem tudom, hogy programozol, de érdekes, hogy ehhez képest mennyire lebecsülöd azt a 256KB-ot.
Én egyébként ugyanezzel foglalkozom többnyire, kb. 10 éve, elõtte (és néha mellette) C és 68k asm játszott be nem amatõr szinten.

"Sajnos a cell meg az intel itaniumoknal is agyhalottabb architektura. Azok is gyors cpu-k lennenek, csak nincs hozzajuk szoftver es uzleti logikahoz teljesen alkalmatlanok. A cell pont ilyen."
Ez így nem igaz. Egész más okból nem sikeres az Itanium (amellett persze, hogy tényleg nincs rá szoftver).
Mellesleg a G80 sem alkalmas üzleti logikára.

"A jatekok meg jo ideje rengeteg uzleti logikahoz hasonlo feladatot vegeznek, azaz sok felteteles elagaz van a programokban, meg a v2-nel jobb shader-ekben is."
Sokat, de nem annyit, amennyivel ne boldogulna el a PPE (vagy akár egy SPE, ha megfelelõen kicsi az adatmennyiség).

"(pl. tudasbazis alapu mesterseges intelligencia, ray tracing alapu arnyekolas, dinamikusan szamolt texturak vagy eppen fizika, stb.)"
Ray-tracing? Na nézzük: egy eredetileg GF7800-asra írt ray-tracert átírtak Cellre - kapásból 2x gyorsabban futott rajta, optimizálva meg 5x gyorsabban... (Dokumentálta a program készítõje, keresd meg, ha érdekel.) Pedig FLOPS alapján a másiknak kellett volna gyorsabbnak lennie...

"Ha az adatok es a program befernek 256Kb-ba, akkor a cell spe gyors. E folott olyan sebessegeket hoz, mint amikor egy rendszer elkezd swap-elni."
Jaj, ne beszélj már ilyen ökörségeket.

"Csak itt nem diszkre hanem rendszer ram-ba swap-el."
Aha, mindössze 1000x-es a különbség.

"Egyik sem tul gyors, es mivel az spe-ben nincs hardveres virtualis memoria kezeles"
De, tudomásom szerint van!

"Egyebkent en adatokat es algoritmusokat irok, a valasz pedig az hogy baromsag... Dez, szerintem erdemes lenne annyit tanulnod, hogy legalabb ervelni tudj."
LOL, te téves adatokat írsz, mégpedig túl sokat.

"Ma mar kaphatoak 8 magos rendszerek (2x4 mag)."
Aha, csak épp túl drága átlagfelhasználásra, és igen lassan és nagy késleltetéssel éri el az egyik proci a másikat és a memóriát. teszt

"Tehat kb. 1 generaciora vagyunk attol, hogy egy pc nyers eroben is lenyomja cell-t."
LOL, egy 8 procis szerver most is lenyomhatja, legalábbis elvileg. Csak ugye mennyiért is...?
Plusz 1-2 év múlva a Cellbõl is lesz gyorsabb, nagyobb, jobb.

"Viszont mig a pc-n az osszes eddig megirt algoritmus gyorsul, addig cell eseten arra az egy egyedulallo hardverre kell optimalizalni mindent."
Bla-bla. A többmagosítástól nem gyorsulnak az egymagos kódok, mégpedig abból van a legtöbb.
Ha a többszálas alkalmazásokat nézzük, a Cell esetén több PPE+SPE esetén lineárisabb a gyorsulás üteme, és meredekebb is.

"Mig pc-n, xbox360-on csak ujra kell forditani a tobbszalu kodot es maris gyorsabb lesz, addig ps3-on minden ujra kell irni."
Ez így nem igaz. Sokszor csak némileg kell átírni v. kiegészíteni, és Cellen jóval gyorsabb még így is, fele SPE kihasználtsággal (fejlesztõ írta).

"Meg az nvidia mernokei is megoldottak, hogy a c++-os kod modositas nelkul fusson egy gf8800-ason"
Ezt honnan szeded?

"mig a cell spe-kbe egyszeruen nem lehet beletenni annyi kodot es adatot mert nincs hova. Abban a pillanatban hogy elkezd swap-elni, lassu lesz."
Ha okosan van megoldva, akkor nem különösebben. (Persze bizonyos esetekben igen.) Fõleg, hogy dual-bufferesen párhuzamosan mehet tovább a számolás a pakolás alatt!

"Kb. annyira mint amikor egy x86-os ps2-ot probal emulalni."
Ez aztán az értelmes összehasonlítás...

"A masik gond, hogy az spe-k osztoznak a cpu-val a memoria buszon"
Úgysem kell az PPE-nek 25 GB/s.

"ami csak egy sima ddr3-as dual channel megoldasnak felel meg."
Nem éppen. Az XDR memóriavezérlõ és memóriák sokkal intelligensebben kezelik a hozzáféréseket, és a késleltetés is alacsonyabb. Plusz ezt a sávszélt hozó DDR3 még kurva drága.

"Ha keves a belso gyors ram, lassu a memoriabusz es sokan versenyeznek erte (idealis esetben minden 6-odik orajelre ferhet csak hozza egy spe a fo ramhoz, rossz esetben csak minden 10-edikre), akkor hiaba gyors az spe, nincs eleg adata amit feldolgozhatna."
1. Közben is dolgozhat.
2. Egymásnak is továbbadhatják az adatokat további feldolgozásra, ~200 GB/s sávszéllel.

"Meg jo, hogy az nvidia gf8800-as sorozat mar altalanos cpu-kat kapott, amik akar a linux-ot is futtathatjak, bar memoriavedelem nelkul."
Ez egy hülyeség.

" "Olyan szempontból, hogy számítási teljesítménye megeggyezik a konzollal.Azt meg nem tudom, hogy pc-n milyen hw egyezik meg a ps3 tudásával. Valahogy csak össze tudják õket mérni, ha már pc-n írják rá a játékokat is." "
Ezt nem én írtam, légyszi ne keverd a válaszokat.

"A pc-n irt jatekok csak a fo magot hasznaljak ki, es a gf7900-es videokartyat. Ez egy dx9-es kartyaju PIII-asnak felel meg."
Na ja, egy egyszerû újrafordításnál.

"A cell-t kihasznalo jatekokat assembly-ben vagy ansi c-ben lehet csak megirni"
Ezt honnan szedted? Lásd fentebb, amit a Cellhez való fordítókról írtam.

"es olyan programozok kellenek ra mint akik annak idejen c64-es meg amiga-s demokat irtak. Mara nem sok ilyen koder maradt"
Jelen! :)

"es a jatekkeszito cegeknek meg nem eri meg rendesen megfizetni oket."
A multiplatformosoknak, akik egyszerû újrafordításdiban gondolkodnak...

"(pl. engem sem fizetnek meg elegge a jelenlegi cegemnel)"
Amiket összeírsz itt, ezen valahogy nem csodálkozom.

"Külsõ OS módban meg tudtommal a 8. is szabad."

Nem, ilyenkor is csak 6+1 mag van, mivel egy eleve hibas (ezert van letiltva), a drm rendszert meg nem engedik kikapcsolni linux alatt sem (azon fut a hypervisor). 'Kulso' os modban csak a cpu fo magja es 6 spe van. Meg hardveres videogyorsitas sincs, a drm kezelo mag meg masolgatja az adatokat a framebuffer-bol a videoramba. Ez kb. egy pci-os lfb-s videokartyaval felszerelt PIII-as szintjere butitja a ps3-at. (mivel az spe-kre meg nincsennek programok) Ez sokmindenre jo, de otthoni hasznalatra csak annyira mint egy wii a hozza valo operaval.

"A teljesitmennyel az igazi gond, hogy a cell spe-jei leginkabb a videokartyak alu-ira hasonlitanak" Baromság. Részletezzem"

Jo lenne ha reszletezned. A gf8800-as mukodese hasonlo csak tobb, de lassabb mag van benne. Es a kulso memoriacimzes tamogatasa miatt meg c++-os kod is elfut rajta, mig a cell spe-kben erre nincs eleg kozvetlenul cimezheto memoria. A cell spe-k alapvetoen gyors skalar magok, memoriakezelo egyseg nelkul, par kilobyte-os cimterrel. A gyenge pontjuk a cimezheto memoria kis merete, ami miatt hasznalhatosagban csak a dsp chipekkel tudnak versenyezni, egy gpgpu-val mar nem.

"Az SPE-k is elérik a ramot DMA-val. Plusz saját, különbejáratú, szupergyors belsõ ramjuk is van, igaz, nem túl sok, de nem is olyan kevés (egyenként 256KB)"

A dma-s ram kezeles olyan mint amikor egy videokartya a rendszer rambol probal texturazni. Mukodik, de nagyon lassu. Ezzel szemben a 256Kb nagyon keves. Ennel joval tobb belso memoria jut egy gf8800-as regiszter terere is, es mindkettonek 1 orajel az eleresi ideje. A gf8800-as egyszeruen egy jobban hasznalhato architektura, es jobb szoftvertamogatassal rendelkezik mint a ps3 mivel a microsoft (dx10) es az nvidia (gpgpu) is ott all mogotte. (arban meg kb. ugyanott van a ket hardver, kutatashoz a gf8800-as jobban megeri, keszreszerelve 4-es vagy 8-assaval lehet oket dobozban megvenni, es ajandek tudomanyos celu fejlesztoi keszletet is ad hozza az nvidia)

""de dma alapu memoriahozzaferes miatt meg programozni is nehez az spe-ket."
Lamereknek."

A forditoprogramok nem boldogulnak veluk, mert nincs ilyen architekturara optimalizalt fordito. Ha valaki assembly-ben all neki, akkor boldogul, bar a scatter-gather memoriamodelles algoritmusok itt nem hasznalhatoak, mivel csak block io van a dma egysegben. Az utobbi idokben a gpu-k es az x86-osok miatt az osszes haszalhato nem vektoros algoritmus random memoria i/o-ra alapoz, mert az osszes mai gep ilyen. (kiveve a dsp-ket es regi vektoros szuperszamitogepeket, amik mara kihaltak) Ha nincs ra algoritmus, nincs ra rendes fordito, akkor baromi nehez barmit is kihozni. A sony elfelejtett egy akkora szovtverkonyvtarat adni a cell-hez ajandekba mint amilyen a microsoft directx. Minden programozo talalhatja fel a sajat algoritmusait, mint regen a c64-es assembly-s idokben. Oke hogy gyors lesz, de tobb evvel tovabb tart megirni. Megeri?

"A többire egy szóban: hülyeség. Basszus, te teljesen idióta vagy, csak FUD-olsz 1000-rel?"

Nem. Tobbnyire DSP-ket es mikrovezerloket szoktam programozni, tehat ismerem a problemakat. Sajnos a cell meg az intel itaniumoknal is agyhalottabb architektura. Azok is gyors cpu-k lennenek, csak nincs hozzajuk szoftver es uzleti logikahoz teljesen alkalmatlanok. A cell pont ilyen. A jatekok meg jo ideje rengeteg uzleti logikahoz hasonlo feladatot vegeznek, azaz sok felteteles elagaz van a programokban, meg a v2-nel jobb shader-ekben is. (pl. tudasbazis alapu mesterseges intelligencia, ray tracing alapu arnyekolas, dinamikusan szamolt texturak vagy eppen fizika, stb.) Ezeket egy lassu de sok cpu-t, es veletlen memoriahozzaferest kezelo architekturaval lehet jol megoldani. Ha az adatok es a program befernek 256Kb-ba, akkor a cell spe gyors. E folott olyan sebessegeket hoz, mint amikor egy rendszer elkezd swap-elni. Csak itt nem diszkre hanem rendszer ram-ba swap-el. Egyik sem tul gyors, es mivel az spe-ben nincs hardveres virtualis memoria kezeles ezert a dosos idok borldanos overlay algoritmusaival lehet csak lapozgatni az eppen hasznalt adatokat ki es be a 256 Kb-ba.

Egyebkent en adatokat es algoritmusokat irok, a valasz pedig az hogy baromsag... Dez, szerintem erdemes lenne annyit tanulnod, hogy legalabb ervelni tudj.

"Az x86-osok meg ~10 Gflops per mag. Szal kb. egy 16 magos lesz egy szinten mat. szám. telj.-ben a Cellel"

Ma mar kaphatoak 8 magos rendszerek (2x4 mag). Tehat kb. 1 generaciora vagyunk attol, hogy egy pc nyers eroben is lenyomja cell-t. Viszont mig a pc-n az osszes eddig megirt algoritmus gyorsul, addig cell eseten arra az egy egyedulallo hardverre kell optimalizalni mindent. Mig pc-n, xbox360-on csak ujra kell forditani a tobbszalu kodot es maris gyorsabb lesz, addig ps3-on minden ujra kell irni. Meg az nvidia mernokei is megoldottak, hogy a c++-os kod modositas nelkul fusson egy gf8800-ason, mig a cell spe-kbe egyszeruen nem lehet beletenni annyi kodot es adatot mert nincs hova. Abban a pillanatban hogy elkezd swap-elni, lassu lesz. Kb. annyira mint amikor egy x86-os ps2-ot probal emulalni. Mukodik, de a teljesitmeny nagy resze a hianyzo hardverek emulaciojara megy el, nem a tenyleges szamitasokra. (ha 10 orajelbol 1 a szamitas, 9 meg a hianyzo random access memoriazeles emulalasa, akkor az effektiv orajel a tizede lesz annak ami lehetne)

A masik gond, hogy az spe-k osztoznak a cpu-val a memoria buszon, ami csak egy sima ddr3-as dual channel megoldasnak felel meg. Ha keves a belso gyors ram, lassu a memoriabusz es sokan versenyeznek erte (idealis esetben minden 6-odik orajelre ferhet csak hozza egy spe a fo ramhoz, rossz esetben csak minden 10-edikre), akkor hiaba gyors az spe, nincs eleg adata amit feldolgozhatna.

"a GPU-k egyszerûbb számításoknál nagyon gyorsak, de ha már kicsit összetettebb dolgokról van szó, erõsen visszaesik a teljesítményük! Sõt bizonyos algoritmusokra még nem is alkalmasak."

Meg jo, hogy az nvidia gf8800-as sorozat mar altalanos cpu-kat kapott, amik akar a linux-ot is futtathatjak, bar memoriavedelem nelkul. (mindenki latja mindenkinek a ram-jat, ez nagyon gyors memoria i/o tesz lehetove, bar programhiba eseten fagy minden)

"Olyan szempontból, hogy számítási teljesítménye megeggyezik a konzollal.Azt meg nem tudom, hogy pc-n milyen hw egyezik meg a ps3 tudásával. Valahogy csak össze tudják õket mérni, ha már pc-n írják rá a játékokat is."

A pc-n irt jatekok csak a fo magot hasznaljak ki, es a gf7900-es videokartyat. Ez egy dx9-es kartyaju PIII-asnak felel meg. A cell-es linux lenyege, hogy a jatekokat is cell-en fejlesszek, csak a devkiteken nincs letiltva linux alatt a 3d, es a sony fele linux fut rajtuk. (ha nem hiszed vegyel egyett par millioert, sot egy par lopott devkit elunt annak idejen itt europaban, azok sokkal olcsobbak voltak) A cell-t kihasznalo jatekokat assembly-ben vagy ansi c-ben lehet csak megirni es olyan programozok kellenek ra mint akik annak idejen c64-es meg amiga-s demokat irtak. Mara nem sok ilyen koder maradt, es a jatekkeszito cegeknek meg nem eri meg rendesen megfizetni oket. (pl. engem sem fizetnek meg elegge a jelenlegi cegemnel)

Te meg mit helyeselsz, amikor baromságokat írkál?

"Az ibm cell blade-ek es a ps3 kozott a legnagyobb kulonbseg, hogy az ibm gepeiben mind a 9 mag jo. A ps3-ban csak 8, de ebbol 1 a drm rendszert futtatja, tehat csak 6+1 hasznalhato mag marad."
Nem egészen.
1. Alap (game) módban sem csak DRM, hanem jópár egyéb funkció (pl. hang [])
2. Külsõ OS módban meg tudtommal a 8. is szabad.

"A teljesitmennyel az igazi gond, hogy a cell spe-jei leginkabb a videokartyak alu-ira hasonlitanak"
Baromság. Részletezzem? Áh, minek, el sem olvasod, csak állandóan nyomod ezeket a hülyeségeket.

"annyi megkotessel, hogy mig a videokartyak kepes a texturazoegysegen keresztul kulso ram-ot hasznalni, addig az spe-k nem."
Az SPE-k is elérik a ramot DMA-val. Plusz saját, különbejáratú, szupergyors belsõ ramjuk is van, igaz, nem túl sok, de nem is olyan kevés (egyenként 256KB).

"Az, hogy legjobb esetben is csak 8 mag van, mig a gf8800-ban 128 mar eleve elavultta teszi a cell-t"
Baromság. Részletezzem? Fenti okból megintcsak inkább nem.

"de dma alapu memoriahozzaferes miatt meg programozni is nehez az spe-ket."
Lamereknek.

A többire egy szóban: hülyeség. Basszus, te teljesen idióta vagy, csak FUD-olsz 1000-rel?

Azt felejtik el sokan, hogy PC-n jóval kevésbé kényszerülnek rá a programozók a hw fullosabb kihasználására, mert a piac folyamatosan áll át a gyorsabb gépekre. Konzolon viszont versenyelõnyt jelent a dolog.

Ma is elõfordul, hogy egyes részeket asm-ben írnak, fõleg konzolon. De egyébként ez nem feltétele az igazán optimális kódnak - C-ben is nagyon el lehet szúrni a dolgokat, ha nem úgy állítják össze a dolgokat, ahogy a hw-nek fekszik. Az persze igaz, hogy sok a láma programozó - de egy konzolos játékfejlesztõ csapatban nincs helye az ilyennek - jobb helyeken.

"Nem kurvára mindegy, hogy 10 vagy 25 Gflops, ha öt év múlva százas nagyságrendekrõl fogunk beszélni? Meg nem 8 prociról, hanem 16-32-rõl."

Nem figyeltél. Magonként ennyi. Szal most is 100-as (pontosabban 200-as) nagyságrendrõl beszélünk a Cell esetén. Az x86-osok meg ~10 Gflops per mag. Szal kb. egy 16 magos lesz egy szinten mat. szám. telj.-ben a Cellel (annak mai formájával, mert a Cellt is továbbfejlesztik közben, persze a PS3-ban ugyanaz marad teljesítmény szempontból a kompatibilitás miatt).

"Még jó hogy számoláshoz ezek kellenek. A cikkben is Folding@home-ról van szó. Nézd meg a videokártyák teljesitményét. Asszem 4x gyorsabb mint egy ps3?"

Ha már a Folding@Home-ot emlegeted, nézd meg jobban, mit írnak errõl õk maguk... Ezt: a GPU-k egyszerûbb számításoknál nagyon gyorsak, de ha már kicsit összetettebb dolgokról van szó, erõsen visszaesik a teljesítményük! Sõt bizonyos algoritmusokra még nem is alkalmasak. Ezért a foldingos feladatok közül csak az egyszerûbbeket viszik, bár azokat gyorsabban. A Cell a GPU-k és a szokványos CPU-k között van. Összetettebb feladatokat is tud a CPU-knál 10x gyorsabban futtatni. (És a legösszetettebbeket is, de azokat már nem annyival gyorsabban, amennyit a több mag indokolna.)