98
-
Malbeth #58 Szerintem is katasztrófa a ps3! teljesen igaza van a Valve főnökének! 
-
muerte2 #57 Ugyan már! Azt ne mond hogy a kód nem fér el a maradék 8,5GB-on
-
muerte2 #56 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.
-
muerte2 #55 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. -
Anotino #54 "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. -
bry #53 Öröm volt végigolvasgatni mindenki hozzászólását, de azért várjuk meg
Dzson barátunkat, Ő majd megmondja a tutit.
-
HUmanEmber41st #52 Konzol=> suck...
PC rulez ! :) :) :) -
fade2black #51 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. -
#50
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. -
Vers #49 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
-
dez #48 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ő). -
Vers #47 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
-
#46
Sot, en kifejezetten elvezek MMX-et es SSE-t assembly-ben programozni. :-) Talan ez az egyetlen, amiert egyaltalan erdemes manapsag az assembly-hez nyulni. -
dez #45 "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. -
dez #44 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... -
dez #43 (Na persze asm-ben is neki lehet állni, a PowerPC-k asm-je nagyon jól használható, átlátható, stb.) -
dez #42 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. -
dez #41 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. -
#40
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. -
dez #39 "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. -
Vers #38 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
-
BlackRose #37 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.) -
#36
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. -
Vers #35 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 -
BlackRose #34 ??? á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... -
Vers #33 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 -
BlackRose #32 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. -
Zsoldos #31 for your information:
http://www.alphaworks.ibm.com/tech/cellcompiler -
BlackRose #30 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. -
#29
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. -
Vers #28 a cellen a c++-t el lehet felejteni -
BlackRose #27 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. -
#26
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. -
gforce9 #25 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. -
Anotino #24 mindenesetre nemileg ertelmesebb hozzaszolasa volt mint neked ez a "de buszke vagyok ra hogy primitiv vagyok" tipusu hozzaszolasod. -
#23
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. -
avman #22 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. -
#21
"inkább halgass :D" ezt te is megteheted. -
#20
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. -
klastrom #19 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...