 Hozzászólások  A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
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.)
|
Most mint ha több kritika érné a hardert konkrétan, de lehet hogy csak nekem tűnik így.
|
Most is azt mondják. Akkor lesz "szar", ha meg sem próbálják rendesen használni.
|
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.
|
Annyi a diferencia hogy akkor arra panaszkodtak hogy nehéz fejleszteni rá és nem arra hogy szar a vas.
|
"Nem tuloztak el. A 4Ghz-s P4-es pont 8Ghz-es belso alu orajelen jar. Ez majdnem a tervezett 10Ghz-es maximum."
Mondhatom, sok értelme volt, tekintve hogy az Athlon64 2.5-3 GHz-en, nem-dupla alu órajellel hozta azt a MIPS-et.
|
Nagyon téves következtetésre jutsz, ha csak a FLOPS értéket hasonlítod össze. Ajánlom figyelmedbe: GPUs vs. Cell
|
Rosszul emlékszel. A videomemória olvasása a Cell által a lassú. De erre amúgy is ritkán lenne szükség, és ha mégis, áthidalható a GPU-val.
|
Jól egymásra találtatok Archkovennel, kb. egy színvonalon vagytok.
|
ja és 8.5gb ram van a ps3ban mi? orbitális hülyeségeket azért nebeszéljünk.
|
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...
"Az ember végtére is a vágyait szereti, nem azt amire vágyik."
Nietzsche: Túl Jón és Rosszon. IV. rész: Mondások és Közjátékok 175.
|
ez mekkora marhaság má
:DDDDDDDD
|
"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
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
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. |
Fúha, lehet számolni a pi közelítő értékét több ezer tizedes jegyig, másodpercek alatt :O Én meg nyugodtan multizok a szar ócska PC-men :)
- De ezzel saját magad lejáratását folytatod, ezt nem érted meg? Magadat égeted tovább. Ami a legszomorúbb hogy magyar színekben. Tapló.
- nem is szines a nevem
|
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.
Szar játék az élet de qwa jó a grafikja!
|
"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.
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.!
SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
|
sztem is szar a ps3(a 2 az jó volt)
az Xbox360,na az már jó!talán a ps is tudja hozni azta szintet...:)
|
És ha kifogy a 2*256 MB, honnan szedi be az adatokat, a 10000000000000000x lassabb bluray-ről? Naugye.
IBM T61 ND218HL *** Core2 Quad Q6600, Gigabyte 8800 GTX, 4 GB Kingmaxx, 1.6 TB SATA, TT Big Typhoon, SB X-Fi Fatal1ty Platinum Champion, CM Stacker, Dell 2007 WFP, Vista Ultimate BOX, Office 2007 BOX
|
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.
IBM T61 ND218HL *** Core2 Quad Q6600, Gigabyte 8800 GTX, 4 GB Kingmaxx, 1.6 TB SATA, TT Big Typhoon, SB X-Fi Fatal1ty Platinum Champion, CM Stacker, Dell 2007 WFP, Vista Ultimate BOX, Office 2007 BOX
|
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.
Szar játék az élet de qwa jó a grafikja!
|
béna a PS3 ezwan...
Apple iPhone, HP-Compaq 6715b Notebook, Google termékek - csak lazán ;)
|
:) 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.
Szar játék az élet de qwa jó a grafikja!
|
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.
Abit IC7, P4 2,8GHz Northwood HT, 2x1 GB DDR400 RAM, Gainward GF7600GT 256MB AGP
Sony PSP
|
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....
P4 2,6 GHz | 768 DDR2 ram | LeadTek 6800 Ultra 256 DRR3
|
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.
PS3 ID: NEXUS0001 Aevum est crudus, sed non satis.
CS.N.T.K.K! & A.M.É! A hétfő bűn!
Avagy: "Az ördög a részletekben van elásva!";)))
|
"Majd kb 2 év múlva térjünk vissza a témára."
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.
|
É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.
¤¤¤¤o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤o,¸¸o¤o,¸¸,o¤o°`°o¤o,¸¸,o¤o°`°o¤O3>
|
Szerintem is katasztrófa a ps3! teljesen igaza van a Valve főnökének! 
|
Ugyan már! Azt ne mond hogy a kód nem fér el a maradék 8,5GB-on
|
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 ! :) :) :)
A bölcsek nem tudósok - a tudósok nem bölcsek
Lao-Ce
|
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.
|
mondok egy példát ugy könnyebb megérteni:
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
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
Jó neked, én butácska mikrokontrollerekkel b@szakodom (bár lehetne C-ben is, de már úgy megszoktam, és mondjuk nincs is pazarolni való prociidő).
|
pc-s procin nem hatékony és nem is érdemes assemblyben progizni mivel ugyis sorbarendezi az utasitásokat, mondjuk ettöl még lehet szeretni :D
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
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.
|
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...
|
(Na persze asm-ben is neki lehet állni, a PowerPC-k asm-je nagyon jól használható, átlátható, stb.)
|
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
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
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.)
Intel.DH67BL.Core.i7-2600K.16GB.RAM.4TB.RAID.GTS450.2TB.Storage.Dual.EIZO.Windows.7.Ultimate.SP1
|
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
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
??? á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...
Intel.DH67BL.Core.i7-2600K.16GB.RAM.4TB.RAID.GTS450.2TB.Storage.Dual.EIZO.Windows.7.Ultimate.SP1
|
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
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
Ahhoz kčpest, hogy már kb. 1 éve játszadozok a Cell SDK-val, ez elégé meglep :)
http://www.alphaworks.ibm.com/tech/cellcompiler
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.
Intel.DH67BL.Core.i7-2600K.16GB.RAM.4TB.RAID.GTS450.2TB.Storage.Dual.EIZO.Windows.7.Ultimate.SP1
|
for your information:
http://www.alphaworks.ibm.com/tech/cellcompiler
|
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.
Intel.DH67BL.Core.i7-2600K.16GB.RAM.4TB.RAID.GTS450.2TB.Storage.Dual.EIZO.Windows.7.Ultimate.SP1
|
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.
- De ezzel saját magad lejáratását folytatod, ezt nem érted meg? Magadat égeted tovább. Ami a legszomorúbb hogy magyar színekben. Tapló.
- nem is szines a nevem
|
a cellen a c++-t el lehet felejteni
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
|
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.
Intel.DH67BL.Core.i7-2600K.16GB.RAM.4TB.RAID.GTS450.2TB.Storage.Dual.EIZO.Windows.7.Ultimate.SP1
|
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.
PS3 ID: NEXUS0001 Aevum est crudus, sed non satis.
CS.N.T.K.K! & A.M.É! A hétfő bűn!
Avagy: "Az ördög a részletekben van elásva!";)))
|
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.
|
"inkább halgass :D" ezt te is megteheted.
Vain ei kuulu terroristien käsiin! CS. N. T. K. K.!
SG az a hely ahol sunyi módon csöndben törölgetik a hozzászólásokat, indok nélkül. ;)
|
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.
"Ha valami elromolhat,akkor az el is romlik"
ASUS M2N4 SLI ,X2 4600+, I3D8800GTS ,2GB DDR800, 300GB Samsung,DVDRW és Combo,LogitechMX518
ami sajna már nincs: A1200 030/50 1,2GB winyó 14"Multisync
|
Ezt a versenyt még megnyerheti a szotyi.De ha nem kapja össze magát akkor a PS4 megjelenésekor tutkóra el fogja veszteni a csatát...
|
|
Nyomtatás
Elküldés e-mailben
A Valve szerint katasztrófa a PS3
Az EU vádemelést sürget az Intel ellen
Európai fellépés a YouTube és a MySpace ellen
Új nevet kapott a Skype webtévé-programja
A CES-nél is jobban sikerült a Macworld
