Az OpenGl-nek a legnagyobb elonye es egyben legnagyobb hatranya az extension-ok: -Gyorsan lehet hozzaadni plusz feature-oket -Az egyes feature-oket a kulonbozo gyartok kulonbozo keppen valosithatjak meg...(kulonbozo mukodes, kulonbozo API)
A kettõt együtt kell nézni. A központi mag egy gyors mai x86-nál lassabb (fõleg ha nem rá optimizált a kód [de ilyet csak idióták fordítanak, mivel elérhetõ 2 rá szabott fordító is, az egyik a standard GCC módosított változata]), ha mindent rá akarnak bízni, és parlagon hagyják az SPU-kat. Azaz ha a lehetõ legegyszerûbben akarnak pl. egy pc-s játékot portolni, vagy úgy írni ps3-ra, mintha pc lenne. Ami a GPU-t illeti, az végülis egy bõvített 7800GT. Nem egy 8800GTX, de egy ügyes programozó kezében azért sokmindenre képes. (Az x360 GPU-ja is kb. ez a szint, egyes dolgokban valamivel gyorsabb, más dolgokban valamivel lassabb.)
A PS3 a "pc"-s játékipart is tovább jó irányba formálhatja!
Úgy vélem több ember "merne kipróbálni" egy "másfajta" operációs rendszert, ha tudatában lenne, hogy azzal játékban is kiválthatja lehetõségekben korlátozott operációs rendszerét.
nem is igazán a használhatóság, mintsem a megszokás tarthat még vissza egyeseket hiszen ha nem "windows" szemmel nézünk például egy linuxot, akkor rájöhetünk, hogy egy sokkal egyszerûbben használható és nagyszerûbb dologról van szó (még akár beleszámítva azon problémákat is, melyek az elterjedtségének mértékébõl adódhatnak vagy amiket néhány "windows hardver" okozhat)
A PS3 lehetõség arra, hogy ne olyan problémákkal teli és olyan hosszú ideig tartó legyen egy új architektúra bevezetése, mint amilyen volt és amilyen jelenleg is a DOS -> Windows ... vonalon (pl.: 16 bites DOS-ról 32 bitre váltás mely az átlag, otthoni felhasználóknak a Windows XP-vel teljesedett be vagy említhetném a mostani 32 bitrõl 64 bitre történõ átállást és a windows bõdületes kullogását - hányan használják már otthon a 64 bites gépüket a 64 bites operációs rendszerrel 64 bites játékokat nyúzva)
Ha egy játék nem feltétlenül csak windows-ra, tehát OpenGL-re is elkészül, akkor az mûködhet bármilyen operációs rendszeren és számítógép architektúrán.
A fejlõdés lehetõsége...
Kinek és miért lehet jó, ha egyféle ("torz") architektúra létezik egyféle ("gyenge elméjû, nehezen, problémásan fejlõdõ") operációs rendszerrel?
Ja akkor félreértettük egymást, az elõzõ hsz-ed azt hittem az optikai tárolókról szól.
Hát egy biztos fiúk, lányok annyira más "rendszere" amihez a mai fejlesztés során szoktak a programkészítõk hogy tényleg "gázos" egy szerkezet. Kicsit megelõzte ezen a területen a korát. Tényleg nem mindennapi és lehet azt mondani, hogy forradalmi újjítások vannak benne és lehetõségek, de figyelembe véve a fejlesztési és átfutási idõket illetve rendszerben rejlõ mélyebb lehetõségek kiismerésének idõráfordítás igényét ez igazán majd a ps4-ben fog kamatozódni.
A valve fõmuftija csak fogja be a pofikáját, és nézzen a programozóinak a körmére, meg a saját lelkiismeretébe: szándékosan $*@rják szét a source engine-t a sok update-el, hogy vegyél új hardware-t... (Aki masszívan CSézik, az vesz jobb hardvert, hogy jobban fusson a game... új hardverrel ugyan azt a sebességet éri el, mint egy évvel ezelõtt... és nem max grafikán... :S lobbi... ááá dehogy... :S) Egy évvel ezelõtt kétszer gyorsabban futott a CS:S, mindenféle butító parancsok beirogatása nélkül... Mostmeg: jó, ha a 7-es directxel (mat_dxlevel 70) 60-80 fps-t kiköhögi magából... Ez a röhej...
"Jó, a Netburst magas órajelre optimalizálását kicsit eltúlozták, az új architektúra annyira nem lesz arra optimailizálva, mint a NB, de eléggé arra lesz."
Nem tuloztak el. A 4Ghz-s P4-es pont 8Ghz-es belso alu orajelen jar. Ez majdnem a tervezett 10Ghz-es maximum.
Egyebkent az orajel novelesen kivul vegre noveltek az alu-k szamat is. Eddig csak 2 gyors, 1 lassu alu volt. Most elmeletileg kaptunk 3 altalanos celut a core2 sorozattal. Ezt erdemes lenne felvinni 4-ig es maris gyorsulna a proci. (a ppro, p2, p3 atlag 2 utasitast tudott orajelenkent, a p4 is, a core2 3-at tud, 4-ig siman fel lehetne vinni)
Az orajel tovabbi novelesevel az a baj, hogy mar mikrohullam tartomanyban dolgozik a rendszer (2.46 Ghz a mikrosuto frekije). Ez energiafelhasznalas szempontjabol nem jo. Alternativa meg az implicit tobbszalu vegrehajtas, errol szol a tobb alu es pipeline. (azaz a core2 sorozat)
Hosszu tavon egyebkent nagyon sok feladatot lehet parhuzamositani, csak megfelelo algoritmusokkal kell dolgozni. Pl. ha a jelenlegi alap utvonalkereses helyett image pyramid alapu megoldast hasznalnanak, akkor az mi-t is tudna gyorsitani egy programozhato videokartya (nv80) vagy egy dsp (pl. cell spu). Ezeket konnyu parhuzamositani, mivel ahany mi van (azaz ahany gepi ellenfel van) annyi szal vagy proci is talalna munkat. Fizikai gyorsitasnal minden targy kaphat egy sajat procit, vagy legalabb egy sajat szalat.
"Meg hát a magok számát nem lehet a végtelenségig emelni, az órajelet viszont idõvel lehet."
Jelenleg a legtobb mag egy chipen 65536. En csak egy 16384 magos kiserleti rendszert hasznaltam, de az is nagyon gyors volt. Persze magok alatt ebben az esetben egyszeru risc magokat kell erteni. (risc pl. a ppc is, de a legismertebb es klasszikus pelda ezek kozzul az arm sorozat)
"márciusra 6 millió helyett csak 4,5 millió darabot sikerül majd leszállítani" Jó lesz az 3-4 milliónak is, pláne, hogy emeltek rajta 30 eurot, a brittek és írek örömére.
"Meg hát a magok számát nem lehet a végtelenségig emelni, az órajelet viszont idõvel lehet. "
ennek nem kicsit mond ellen az emberi agy felépitése 1 khz-el megy csak és jéé müködik, persze ahogy elnézem nem mindenkié egyformán jol
Carmacknek igaza van, az órajelet kéne már emelni, nem a magok számát. Lehet, hogy ez nem igazán volt lehetséges az utóbbi idõben, de már itt a 45nm, nem kell sok idõ, és az Intel bejelenti az új magas órajelre optimalizált architektúráját. Jó, a Netburst magas órajelre optimalizálását kicsit eltúlozták, az új architektúra annyira nem lesz arra optimalizálva, mint a NB, de eléggé arra lesz. A Core architektúra csak egy átmeneti dolog(igaz elég jól sikerült), addig is kellett valamit csinálni, amíg a technológia eléggé fejlett lesz egy magas órajelre optimalizált új architektúrához. Amúgy meg a Netburst is elég jól sikerült, ha elég nagy órajelen megy egy NB proci, akkor elég brutális teljesítményre képes. Most az én P4-em 3.8-ra van húzva, és így nagyon erõs.
És azt mondom, hogy ne várja el senki a programozóktól, hogy majd õk alkalmazkodjanak egy esetleg az õ szempontjukból rossz architektúrához. Ha a programozók magas órajelet akarnak(egyetértek velük), akkor csináljanak magas órajelû procikat a gyártók, ne pedig olyan többmagos procikat, amikre csak elméletileg lehetséges jól optimalizálni, gyakorlatilag nem. Meg hát a magok számát nem lehet a végtelenségig emelni, az órajelet viszont idõvel lehet.
48 pipline 600Mhz-en...PS3 7*3,2GHz + GPU => kb 21GHz proci teljesítmény + játékra optimalitált GPU + baxott gyors FSB. Nem érzed az erõt? :D Blue rayyel nem értem mi a gondod. Szerinted a mérnökök nem gondoltak erre? Az adatátviteli sebessége jöval nagyobb mint 1 DVD olvasási sebesség! 1mp-en belül leszedhetõ a 256 mega a rendszer memóriába, megjegyezném, hogy a 256 megát nem kell folyamatosan tölteni a lemezrõl.
A Cell procit nem vonnám kétségbe, mármint az erejét, mégiscsak 2 milliárd dollár volt a kifejlesztése! A processzorai pedig általános célokat is szolgálhatnak és sima mezei Ansi C-vel programozhatók.
"a valaki ír egy progit és úgy csinálja meg, hogy a winyóról tölt de a júzernek csak IDEs winyója van SATA-2 helyett"
Hát a gond az, hogy egy SATA-2-es vinyó nem gyorsabb mint egy ugyanolyan IDE-s, mert bár a sata-2 jó nagy adatátvitelt támogat, az IDE meg max 133 mb/sec-et, még az a 133 is sokszor sok, mert a vinyók mechanikailag nem képesek nagyobb teljesítményre, majd akkor ha már jóval nagyobb lesz az adatsûrûség, szal jelenleg a sata-nak kényelmi szempontból van elõnye (kisebb a kábel, nem kell megcsavarni, menet közben le lehet húzni, stb.).
"tök mindegy, hogy hány mega RAM-ja van, meg hány GHz-es CPU-ja van, akkor is úgy fog szaggatni, mint a nagymama a nokedlit!" elsõ pár másodpercben ja, míg betölt... aztán full folyamatos, én tudom, nekem borzasztó töredezett a vinyóm, így elég lassan mûködik, mégsem jelent gondot játéknál.
Najó, akkor egy geforce 7950 gx2 az meg 600 MHz * 48 pipeline, berakom quad sli-be, erre mit lép a ps3? A ps3 vektorprocijai nem egyenrangúak az általános célú procikkal, csak a saját célterületükön életképesek, másra nem jók. Még utasítássorrend változtatást se tudnak, hiába a nagy freki meg minden, nagyon sok az üresjárati idõ ha nem az elvárt számolásokat végzik.
Naaaa...számold csak össze! PS3 3,2 GHz * 7+1 256megás videó memó, videó procival + 256mega redszer memó olyan sebességgel ami az összes procit ki tudja szolgálni. Erre 1 PC sem képes jelenleg. Nemhogy emulálni...pfff. Nvidiának van 128 magos videó procija, de primitív, csak egyszerû utasítások végrehajtására képes CISC alapú. Ha a videókari maxon megy, a rendszerbusz nem tudja teljesen kihasználni...nem az igazi.
:) Andris! 256+256 a memója igen. PC tényleg több is lehet. Ámde: - Nagyobb az FSB a PS3 nál - Kvázi többször tölti a kevés memóriát - Nem DDR2 memória van benne
Ilyen érdekes adatokkal szolgált anno a PSX is. 4MB memó. Aztán mégis az idejében játék tekintetében megszorongatta a PC ket. Vagy a PS2 elött a DreamCast. 400Mhz proci, 64mega memó. Neki is gyors FSB jutott, optimalizált kód és RISC proci. Majdnem elérte a PS2 szintjét jóval alacsonyabb áron.
Prociban igazad van, hogy a 8800GTX messze ver mindent, de a Cell-t azért nem kell lebecsülni, a Core 2 Duo-k nagyon jók mind, az tény, de a Cell ezeknél (Core 2 Quad/Extreme-nél is talán) többre képes, csak nehezebb rá megírni a játékokat/progikat.
Egy jo pc mar most is elhuzott barmelyik konzol mellett. Egy core2 duo es egy nvidia8800-as siman veri mind az xbox360-at, mind a ps3-at. Meg egy kis ido, es akar emulatorban is tudjak majd futtatni a konzolokat. (harom sli-s nv80-assal mar most is lehetne, csak meg nehezebb 128*3 magra megirni egy emulatort, mint a cell max. 8 spu-jat felprogramozni)
A cell egyebkent _nem_ pc/konzol chip-nek keszult. Ott vannak a sony bravia tv-k. Mindegyiken linux fut egy cell magon. (a 7 jo spu-t sem tartalmazo cell-ek mennek belejuk) Az spu a skalazast, a hangfeldolgozast vegzi, mig a kozponti egyseg a menukezelest. Az operacios rendszer egyebkent ugyanaz mint a ps3 eseteben. (ugyanaz a sony-linux csak mas a grafikus shell)
Az ibm pedig vektorgyoritonak hasznalja a celleket az amugy is ppc alapu szuperszamitogepeiben. (ok kapjak a 8 jo spu-s chipeket)
Egy pc-s programozonak, aki soha nem dolgozott dsp-n, annak nehez barmit is kezdenie a cell spu-kkal. Egy telekomos vagy shader programozo pedig orul, hogy milyen sok ramja lett (256Kb ram sok egy dsp-n, bar az ujabb 64Kb ram/64Kb rom-os dsp-k mar kb. itt vannak)
Nem csoda hohgy nem megy mivel még alig van rá játék
hát ha megfog bukni akkor jó nagyot szXpott. inkább nyomjanak még ki ps2 kiegészítõket , ps2t legalább veszik....
Nagyjából egyetértek.
Viszont a konzolok részegységei maximálisan össze vannak hangolva. Pl valszeg a PS+-ban levõ BR-rõl is lehet közvetlenül tölteni az adatokat, textúrákat, de ha nem is, akkor a wincsit még mint buffert/cachet lehet használni. A PC-nél rengeteg fajta háttértátoló van elterjedve, ezért a fejlesztõk sokkal inkább támaszkodnak arra az 1-2 dologra, amit a progi specifikációjánál megkövetelnek: RAM CPU GPU+VRAM. Ha valaki ír egy progit és úgy csinálja meg, hogy a winyóról tölt de a júzernek csak IDEs winyója van SATA-2 helyett akkor tök mindegy, hogy hány mega RAM-ja van, meg hány GHz-es CPU-ja van, akkor is úgy fog szaggatni, mint a nagymama a nokedlit!
Szal a RAM hiánya lehet hogy annyira nem gond. Másrészt a buszsávszélesség viszont olyan hatalmas, ami max a PCI-E v4.0-ban már talán lesz. A PC progik optimalizáltsága, meg igen csak alacsonyszintû a konzolokéhoz képest -ezért is olyanok a PC-s eredetû multiplatform játékok konzolon amilyenek.
Az a gond, hogy közbena PC-k is komoly fejlõdés elõtt állnak. Lassan átlépjük az egymagos procikat, és onnantól már sokkal gyorsabban fog menni a 4-8-stb mag kihasználása. Ráadásul nemsoká a cell-hez hasonló magokat fognak integrálni az x86-okba is. És a GPU-k is durván fejlõdnek. Pl. a 8800GTX programozható nyers számítási teljesítménye duplája a cell-ének, és lényegesen szabadabban programozható, mint a korábbi GPU-k. Persze a PC-s játékokat meg az korlátozza, hogy nem csak csúcshardveren kell futniuk (most különösen probléma a multicore és DX10 átállások miatt). Szóval szerintem a játékok minõsége egy ideig kb. hasonlóan fog fejlõdni PC-n és konzolon, aztán pár év múlva a PC elhúz. Hasonlóan, ahogy a PS2-nél is történt.
"Ugyan már! Azt ne mond hogy a kód nem fér el a maradék 8,5GB-on"
Mirõl beszélsz? A PS3-nak 256MB video RAM-ja, és 256MB main RAM-ja van. Ezt hasonlítsd ösze egy jobb PC 2GB main RAM-jával, és 512MB-1GB video RAM-jával. Persze konzolokon egy csomó dolog egyszerûbb (pl. egyszerre csak egy progi fut), így jóval kevesebb memória kell, de azért a 256 mega elég szûknek tûnik.
Minek szóljak hozzá? Az igzesek általában sokkkal profibbak PS3 ügyben, mint akár maga a sony. Technikai, üzleti, marketingstratégiai elõrejelzõ és mindenféle szempontból. Felesleges bármit is hozzátenni az írkálásaikhoz...
Én emlékszem rá, hogy amikor a PS2 megjelent pontosan ugyanez történt. Gyártási nehézségek, nagy veszteségek, lassú kezdés és a porgramozók, panasza, miszerint hihetetlenül nehéz a PS2-re fejleszteni. Szóval semmi új. SZVSZ olyan tartalékok vannak a konzolban, ami jóval hosszabb termékciklust feltételez riválisainál. Majd kb 2 év múlva térjünk vissza a témára.
Archkoven írta:"Mindjárt jön dez és elmondja, hogy mekkora laikus ez a Gabe Newel:))) "
És lámm tényleg igaza lett! dez írta:"Ja, és különben is: akkor dumáljon Newell, ha PC-n már nem hagyják parlagon legalább a 2. CPU-magot..."
Nem pont a cell köré épített buszrendszer lett nagyon elcseszve? Mint ha olyasmit olvastam volna hogy van vagy vannak olyan pontok ahol a névleges 25Gb/s helyett max 5Gb/s-t tud produkálni a gép és az általad leírt öngerjesztõ fojamatot is megemlítik, ami annál nagyobb gondokat okoz, minél nagyobb a vas kihasználtsága.
Azéert érdekes hogy Carmack i ezt mondta ráadásul sokadikként, de hát biztos õk a hülyék, meg nemértenek hozzá. Na nem baj majd jön dzson és megmondja a frankót.
"de mit kezdesz mondjuk egy rekurziv problemaval, ami csupan lokalisan, mondjuk egy relative kis ciklus belsejeben parhuzamosithato"
Hm. Pedig rekurziv dolgokat a legegyszerubb parhuzamositani sztem. Kb a processzorok szamanak novekedesevel linearisan csokken a vegrehajtasi ido. En meg clusteren csinaltam ilyet, de tobbprocesszoros gepnel talan meg hatekonyabb a kisebb kommunikacios koltsegek miatt.
Öröm volt végigolvasgatni mindenki hozzászólását, de azért várjuk meg Dzson barátunkat, Õ majd megmondja a tutit.
Konzol=> suck... PC rulez ! :) :) :)
Most eszembe jutott az egyik hanem legjobban várt nextgen game a crysis és az egyik fejlesztõjével lévõ interjú ahol meg azért huzogatta az ispe a száját mert fain, hogy brutális a teljesítmény X360/PS3 esetén de ha a textúra összecsomagolva, össze vissza sporolva félgiga akkor hova fogják rakni az egyébkéntse kis kodot.
Az teny, hogy a mai compiler-ek mar nagyon jok. Szinte semmivel sem gyorsabb az agyonoptimalizalt asm kod, mint a leforditott C kod. Es itt jon be az SSE! Bar eleg ritkan hasznalhato, de amikor mukodik, akkor nagyon sokat gyorsit.
Amugy ugy tudom a mai procik sem rendezik at az x86 utasitasokat, hanem csak a micro-op-okat izelgetik.
az egyik vectorproci beolvassa a polygonokat, majd kisebb polygonokra bontja, pl mindegyiket 16 darabra, igy 16-szoros adatmennyiség keletkezik amit nem kell visszairni a memoriába, hanem egyszerüen még ez az spe megvizsgálja hogy látható lesz e a képen ha nem eldobja a kis polygont ha igen küldi tovább további 4 vectorprocinak, ezek mindegyike tovább bontja 16-odára a polygonokat majd megvizsgálva hogy látható e továbbküldik az adataikat további 2 vectorprocesszornak amik rendezik konvertálják az adatokat és kiküldik a GPU-nak
igy kapunk egy streamgráfot ami elöször szétnyilik majd bezárodik, és igy a memoriábol beszivott 25 GB adat másodpercenként 200 GB adatot generál a procin belül és csutkára nyomja a gpu buszt is
több mint 1 milliárd polygon framenként ennyit tud a cell , csak jol kell bánni vele
Sot, en kifejezetten elvezek MMX-et es SSE-t assembly-ben programozni. :-) Talan ez az egyetlen, amiert egyaltalan erdemes manapsag az assembly-hez nyulni.
"de ez sem olyan egyszerü , mivel ha a vectorprocesszorok egyesével dolgoznak, akkor az össz memoria sávszélességük maximuma a fömemoria 25GB/sec értéke lehet ami röhejes ha figyelembe vesszük a cellen belül levö ringbusz 200 GB/seces értékét emiatt célszerü SÖT, ajánlott ugy tervezni az algoritmusokat hogy sorba kötött vagy egymással kommunikálo vectorprocikat használjunk"
Szerintem meg a legcélszerûbb blokkonként feldolgozni az adatokat (pl. hangot nagyon egyszerûen lehet), akár úgy, hogy a köv. feldolgozandó blokkot az egyik épp szabad SPU kapja meg, kódostul (ennek betöltése elenyészõ lehet a feldolgozási idõhöz képest, így elég hatékony marad). Ki is van dolgozva az SPU-k self-multitaskingja.
Külön kell választni: a "vektorprocik"-on (valójában sokkal többek annál: mini PPC magok -> mindent tudnak, amit egy PPC proci, de SIMD megy nekik igazán jól) normál C-s kód használata a célszerû, SPE-specifikus kiterjesztésekkel; a PPU esetén jöhet a C++, ha feltétlenül muszály.
Szerinted... Valójában a következõket gondolom: a. érdek (alapvetõen PC-s fejlesztõk), b. egy PC-s fejlesztõ rinyálása, c. programozóból lett (abban már talán megcsömörlött) üzletember, d. amúgy is szeret reflektorfénybe kerülni.
Ha szerinted a C, vagy barmelyik mas alacsonyabb szintu programnyelv a jo kis POSIX/Win32/etc szinkronizacios mechanizmusokkal kiegeszitve ugy jo, ahogy van a sokszorosan tobbszalu hardver programozasahoz, akkor sok szerencset kivanok a jovohoz.
A cluster-ek programozasa merfoldekre esik egy tobbmagos processzor programozasatol, ebben egyetertunk.
Konnyu egy veges elem szimulaciot vagy egy CGI renderelest szetdarabolni tobb processzorra, de mit kezdesz mondjuk egy rekurziv problemaval, ami csupan lokalisan, mondjuk egy relative kis ciklus belsejeben parhuzamosithato? Olyakor jon elo az igazi problema, hogy a meglevo szinkronizacios infrastruktura teljesitmenye elegtelen a par mikroszekundumos feladatok osszehangolasahoz (talan a real-time OS-eket kiveve). Ilyenkor hol vannak a szukseges eszkozok? Ne felejtsuk el, ma meg "csak" 8 magot kell kezelni, de 5 ev mulva mar lehet, hogy 64-et. Neki lehet allni a 8-64 szalat "kezileg" szinkronizalgatni, de a fejlesztesi ido akkor elszall az orokkevalosagig. Sot minden feladatnal ujra kell kezdeni az egeszet. Raadasul a szinkronizalas overhead-je egyre csak no. Az egyik megodas, hogy ujratervezzuk az algoritmusokat, pl egy skalazhato pipeline architekturaba (a Cell-t erre talaltak ki). A masik meg az lenne, ha leteznenek olyan fejleszto eszkozok, amik mar a programnyelvekbe integralva tamogatnak a tobbszalusagot. Milyen szep is lenne, ha pl lenne olyan ciklus vagy elegazas, aminek a kulonbozo agai maguktol kulon threaden futnanak. Ekkor a programozo feladata csak annyi lenne, hogy eldontse, hogy mely agak hogyan futhatnak egymas mellett. Lefogadom, hogy hamarosan kijonnek a megfelelo programnyelv kiterjesztesek. Egesz biztos, hogy mar ma is sokan hasznaljak makrok tucatjait ugyanilyen celra (amolyan berhelt kiterjeszteskent).
Igenis paradigmavaltas van folyamatban. Mi masnak nevezhetnenk azt, amikor a tegnapi 1 feladat 1 szal utan holnap mar 1 feladathoz akar tobb tucat szal is tartozhat. Es a szamokon tul ez egy alapjaban eltero strukturaju programkodot jelent a hatterben.
(Jo pelda pl az ITK/VTK, ami egy thread pool-bol dinamikusan szabalyozza a filterek eroforras hozzafereset, bar ehhez persze az kellett, hogy az egeszet mar az alapoktol multithreaded-re tervezzek.)
De nem is kell bizonygatnom nekem itt semmit, hiszen a tenyek engem igazolnak. Eleg csak megnezni a jatekok skalazodasat a processzorok szamaval. Hat szanalmas! Pedig, egy jatekban a legtobb feladat elmeletben gyunyoruen parhuzamosithato lenne. Az, hogy megsem skalazodik jobban a teljesitmeny kizarolag annak koszonheto, hogy a fejlesztoknek nem eri meg annyi munkaorat beletenni a plusz optimalizacioba. Es miert kellene ennyi plusz munkaora? Mert a jelenlegi fejlesztoeszkozokkel ennyire bonyolult a parhuzamositas.
Hogy adottak-e az eszkozok a parhuzamositasra? Mindig is adottak voltak. Jok-e? Nem elegge.
"ahol a vektoregységek folyton adathiánnyla küzdenek, mert csak a fõmagon át érik el a memóriát, stb."
Ez nagy tévedés. A fõmagtól tökéletesen függetlenül dolgozhatnak (a saját kis szupergyors integrált ramjukkal), és férhetnek hozzá a main ramhoz, DMA-val.
ps2-n kb ugy volt ahogy irtad,a föcore végezte a menedzselést de mivel az ibm mérnökei belesuvasztották a vectorprocikba a dma-t, igy komplett processzoroknak tekinthetök, emiatt akár egy word is lazán futhat egy vectorprocin a föprocesszor segitése nélkül
játék alatt szabadon feloszthatjuk hány jusson zenére, AI-ra, fizikára, posteffectre ,grafikára de ez sem olyan egyszerü , mivel ha a vectorprocesszorok egyesével dolgoznak, akkor az össz memoria sávszélességük maximuma a fömemoria 25GB/sec értéke lehet ami röhejes ha figyelembe vesszük a cellen belül levö ringbusz 200 GB/seces értékét emiatt célszerü SÖT, ajánlott ugy tervezni az algoritmusokat hogy sorba kötött vagy egymással kommunikálo vectorprocikat használjunk na emiatt haldokolnak a pc-s programozok
Javíts ki ha tévedek, de az SPE-k általában egyszerû mûveleteket végeznek el (gyorsan) a 256K itt inkább adatokat tartalmaz, és relatív kis része megy el program instrukciókra, ezek az adatmanipulátor programok nagy része szerintem szabványos kód, mert ugye nem nagyon kell itt specifikus dolgokat írni, többnyire game fizika meg hasonló dolgok, a grafikát gondolom a GPU kezeli, stb. Maga a programlogika meg a PPE dolga, amelynek jóval több memóriája van. Na OK, nem okoskodok, a Cell-t nem game development oldalról tanulmányozom, de szerintem túl sok jelentõséget tulajdonítottál az SPE darabonkénti 256K local memory korlátnak. A komplex operáció többszálosítása pedig szerintem a kompiler dolga. Persze kézzel elérhetsz nagyobb optimizációt az nem kétséges, a kérdés, hogy szükséges e és, hogy mennyivel kerül több idõbe (pénzbe, bug-ba stb.)
Newelltol nem lattam egyetlen konkretumot sem ami alatamasztja az allitasat - azonkivul, hogy szar es kesz - igy meg nem erzem sehol a cikk hirerteket sem. Ezt nem feltetlenul PS3 vonatkozasban mondom, lehet az barmilyen mas termek is.
a memoria kezelés a gond, mivel kevés van 256 kilobyteba be kell férni a programnak, 2-3 memoria buffernak amit a dma ir-olvas , és ami marad azt használhatja a program dinamikus memoriának és hamar betelik , kis programoknál ez nem gond talán, de nagyobbaknál csak szopás van , igazábol fel se merült nálam hogy c++-ban kéne rajta bohockodni az assembly hive vagyok
??? általában a C,C++ memóriakezelése nem roszabb az assemblytõl, de mégis ??? egyébként mi a különbség a "sima C" és a C++ között az adott esetben, nem gondoltam most itt design patterns-ekre, osztályokra, interfacekre meg hasonló, ugyanis a C++ ebben az esetben inkább C-vel kompatibilis módban van használva, mert legtöbbször nem tudsz mit csinálni a többi erõvel, de az még nem jelenti, hogy el kell felejteni. Különben ne haragudj, de vectorprocikat assembly-ben... na az lenne az igazi tánc...
256 kilobyte memoriával ne akarj c++-t ráeröltetni a vectorprocesszorokra,persze aki szeret szopni az csinálja, én nem ajánlom , sima C,assembly a nyeröbb
nem lenne rossz, ha jelentenéd az IBM-nek, ne vacakoljon a C++ al inkább felejtse el... és persze érdekelne bennünket, hogy melyik nyelv az amit nem kell elfelejteni a Cell-en?
(dez gyere már segíteni...) :) mert bevallom én nem vagyok annyira Cell expert, de a Power architektúrát már sokkal jobban ismerem.
Lenne egy kérdésem... honnan szeded azt, hogy a programozási eszközök elégtelenné váltak, honnan szeded azt, hogy az összes tapasztalt programozónak... ha a párhuzamos dolgokra gondolsz, akkor el kell mondanom, hogy a jelenlegi eszközök igen is felvannak készülve, a fejlesztésben levõk még jobbak lesznek, a programozóknak pedig már elég régóta gondolkodniuk kell, hogy egy alkalmazás vagy komponens, hogyan kezeli a többszálas futást, meg hasonló dolgokat. Ami a párhuzamos programozás specifikus oldala, az inkább a kluszterek programozásához szükséges, ahol a memória külön CPU-kén vagy kluszter node-ként van kezelve, ennk nem sok köze van a multicore vagy többszálas programozáshoz. Nincs itt semmi féle paradigm shiftrõl. Ugyanakkor a Cell többmagos sajátosága, hogy ezek a magok valójában DSP-k (durván beszélve) és ezeknek a programozása teljesen az alkalmazástól függõ, de biztos vagyok benne, hogy a Game SDK ezt jól kezeli, ennek nem sok köze van játékok minõségéhez vagy programozásuk nehézségéhez, mert ezek az insztrukciók alapjában multimediális insztrukcuiók FP darálókról van itt szó. Nem kell félreérteni a dolgokat. Különben a PS2 "Emotion Engine"-je is gondolom legalább annyira szokatlan volt mint a Cell, mégsem jelentett problémát a programozóknak.
Meg vannak becsülve? Én eddig valahogy nem vettem észre. A nagy szakmai tudású programozónak meg igenis jár a magas fizetés. Ez nem összekverendõ a futószalagon gyártott informatikusokkal. Informatikust minden sarkon találsz egy raklapnyit, de jó programozót már kevesebbet. Ez a szakma is kezd olyan lenni, hogy minden balek elmegy egyetemre infósnak meg programozónak tanulni, mert azt hiszi majd õ is sokat fog keresni. Közbe az ilyen balfékek miatt csökken a színvonal, és megy egyre lejebb a fizetés is.
A lustaság csak illúzió, valóságban nem létezik, a kérdés, hogy egy ember mit lát értékesebbnek, ülni vagy dolgozni, és az érték itt nem csak pénzben mérhetõ dolgot jelent. Ugyanakkor a programozókkal az a baj, hogy a tényleg jó programozók alul vannak fizetve, a rosszak meg jócskán felül, úgyhogy nem kell itt sem általánosítani. De ugye amikor egy melóval sokat lehet keresni, akkor mindenki azt akarja csinálni, a végeredmény, pedig az, hogy a mindenki miatt gyengül a minõség, a mindenki miatt idõvel kevesebbet is fizetnek és akkor a valódi minõségi programozók isszák meg a levét.
Ami a PS3-at illeti, a Cell fantasztikus proci, és ugye nem kell "Cell programozási nyelvét" tanulni a programozóknak, C++ ban megy a mese tovább és SDK segítségével a PS3-ra generálódik a kód... na de gondolom ezt programozóknak nem is kell külön mondani, de az valamit mégis csak jelent, hogy az eladások nagyon alulmaradtak, a leszálított 2 millió-nak állítolag a felét sem adták el, olvastam olyant, hogy százzával álnak a polcokon. Tehát valami nincs rendben. Persze, nem tudom milyen a PS3, nekem nincs úgyhogy nem tudok itélkezni, de biztos, hogy valami nincs rendben vele.
En speciel nagyon becsulom Gabe Newell-t, mert nagyszeru programozo es manager, mint ahogy John Carmack is az, de sajnos ok nem a felhasznalok szempontjabol, sot meg csak nem is a realitasok talajarol nezik a dolgokat, hanem a programozok szempontjabol. Erre ekes bizonyitek, hogy Carmack a legutobbi interjujaban azt talalta mondani, hogy ok nagyon utaljak a tobb magos processzorokat es a processzorgyarto cegeknek inkabb az orajel emelese iranyaba kellett volna elmenniuk.
Mondja mindezt azutan, hogy legalabb 5 eve sziv a felvezetogyarto ipar az orajel emelesenek problemajaval. Persze nagyon szep lenne 10GHz-es processzorokat gyartani, mert akkor azok 5* olyan gyorsan futtatnak a meglevo kodot, mint egy 2GHz-es proci mindenfele szoftveres modositas nelkul, de sajnos nem ez a mai realitas. A felhasznaloi szoftverek programozoi az elmult 30 evben hozzaszoktak, hogy egymagos processzorokra optimaliznak es a sebesseg emelesehez csupan ki kell varniuk egy meggyorsabb processzor generaciot. Ez a folyamat egesz a legutobbi idokig mukodott, am most megakadt. A processzrogyartok megtalaltak a kiutat, meghozza a parhuzamositasban, am ez a programozokat nagyon erzekenyen erinti.
Latni kell, hogy a programozoi oldalrol hatalmas a kihivas! Gyakorlatilag egy paradigmavaltas kellos kozepen vagyunk, amikor az osszes tapasztalt programozonak ujra kell tanulnia az ipart es teljesen ujfajta gondolkodasmodra kell atallnia. Nem csak a tudas hianyzik, hanem az eszkozok is. Szinte a teljes programozoi eszkoztar elegtelenne valt. Ilyen korulmenyek kozott persze mindenki sir, aki eddig ugy gondolta, hogy tud programozni. Sirnak a 10GHz-es processzor utan. :-) Talan 10 ev mulva, amikorra leulepedett az indulat es kifejlodtek a megfelelo eszkozok, az uj programozo nemzedek gondolkodasa atallt a parhuzamos programozasra, .... na akkor talan mar nem fognak ennyit sirni.
A Sony hibaja az, hogy bedobta a programozokat a melyvizbe. Nem csak 2-3 magot (mint az XBox360-ban), hanem rogton 8-at kellene egyszerre programozni.
Sok evnek kell eltelnie, hogy normalisan megirt programok jojjenek ki a PS3-ra. Varhatoan meg 5 ev mulva is ernek majd kellemes meglepetesek minket egy-egy uj kijovo PS3-as jatek grafikaja kapcsan, mivel a fejlesztok egyre jobban ki tudjak majd hasznalni a hardvert.
A counter strike-ot tudtommal nem a valve fejlesztette, az egy ingyenes gammaként indult. HL1 motorra készült "amatõr" próbálkozásként. Csak elég jól eltalált próbálkozás lett és a valve rátette a kezét.
mindenesetre nemileg ertelmesebb hozzaszolasa volt mint neked ez a "de buszke vagyok ra hogy primitiv vagyok" tipusu hozzaszolasod.
Szerintem iszonyatosan beégette magát az ipse, azok után hogy olyan játékokkal indított a SONY mint a Motorstorm, vagy a Resistance, amelyek lehet hogy nem az évszázad játékai, de azért simán felveszik a versenyt az x360-as játékokkal.
Nem 10X jobb a PS3 mint monnyuk az x360, de legalább annyival, mint amennyivel többe kerül, és ez valszeg elég is a sikerhez.
1. az eredeti egy spot jellegû részlet, kiragadott dolgok egy interjúból, figyelemfelkeltõ, szenzációhajhász, bulváros stb. amivel el lehet adni a dolgokat. 2. az figyelemfelkeltõ, szenzációhajhász, bulváros stb. átvétel ráadásul pontatlan és kissé torzít. amivel kattintást lehet elérni. ezekkel így magában nincsen semmi gond, megszoktuk, így mûködik a világ- de: 3. aki ennek a 2-nek így együtt bedõl és relevanciaként kezeli, hozzáfûzi bivalybasznádról a maga "bölcsességeit" marketingrõl, közgazdasági összefüggésekrõl, technológiai kérdésekrõl, az már most megérdemli az év lámája díjat. nagyjából annyit ér, mintha pl. kristálygömbbõl jósolnátok meg a ps3/xbox/blúréj/hd-dvd sorsát.
Japánban az eladási mutatók valahogy mást festenek, amit te írtál: 1. Nintendo DS Lite 1157730 (igen, egymillió-százötvenhétezer...) 2. Wii 679177 3. PSP 375041 3. PS3 289495 5. PS2 174175 6. Xbox 360 69525
és a Wii-bõl ha jól tudom közel 4,5 milliót adtak el.
Informatika és tudomány
A ps3 vektorprocijai nem egyenrangúak az általános célú procikkal, csak a saját célterületükön életképesek, másra nem jók. Még utasítássorrend változtatást se tudnak, hiába a nagy freki meg minden, nagyon sok az üresjárati idõ ha nem az elvárt számolásokat végzik.
