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