Hirdetés

Új hozzászólás Aktív témák

  • korner83

    tag

    Örvendetes hír :C

    Ezen az oldalon egy olyan kliens programot tudtok letölteni, aminek a segítségével számos kuatási projectbe tudtok bekapcsolódni:
    link1

    További infó:
    link2

    Ja és van kapcsolódó topikunk is:
    link3

    [ Szerkesztve ]

  • masterful87

    senior tag

    Lassan már megdolgoztatják a hangkarit, meg a hálókarit is, meg mindent, ami csak a gépben van. :DDD

  • #95904256

    törölt tag

    Van még egy kapcsolódó topikunk: Seti@Home / Einstein@Home
    Az Einstein már szintén fut PS3-on, de még nincs hivatalosan verzió...

  • Thrawn

    félisten

    Szinte hihetetlen mire képesek ezek a Cell procik :)

    korner83:
    A Rosetta az ugyanaz mint a Folding@Home?

    szerk: na akkor én is teszek be linket egy kapcsolódó topikról: World Community Grid :D

    [ Szerkesztve ]

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł

  • Dr. Romano

    veterán

    válasz masterful87 #3 üzenetére

    Hát ja! Nemsokára egy ilyen kutatásba való bekapcsolódás jobb lesz a stabilitás vizsgálatára mint az Orthos vagy a 3DMarkok :DDD

    Ez....e...ee...ez egy.... ez egy FOTEL???

  • hardzsi2

    aktív tag

    Nem vagyok ellenére a fölös számítási kapacitások hasznosításának, mindenkinek lelke és villanyszámlája rajta, de szerintem bármely műszaki vagy főleg orvosi számítás többet érne/nagyobb hasznot hajtana, mint a Seti@home. Én mondjuk egyikben sem veszek részt, de ha megtenném, sci-fi rajongó létemre valószínűleg inkább egy orvosi kutatáshoz kapcsolódnék.

    flood-resistant mirror driller (cuccok: Skylake NUC és Xbox One X)

  • Thrawn

    félisten

    válasz Dr. Romano #6 üzenetére

    Procitesztre már most is kiválóak, sőt a Folding@Home-ra létezik ATI kliens X16xx és újabb kártyákra, amikből akár kettő is számolhat :K Link

    hardzsi2: Nálunk a helyed! Link egy fentebbi postomban, orvosi kutatással foglalkozik a projekt (AIDS, rák, Dengi-láz és fehérjekutatás) :D

    [ Szerkesztve ]

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł

  • jodován

    tag

    Nincs vmi összefoglaló ezekről? Melyik akció mivel foglalkozik és kik csinálják?

    sanszos -> van rá esély, hogy ez a szó ne használódjon többé?

  • djyuri

    őstag

    Régen én is kitöltöttem egy jelentkezést annak a teleszkóp cuccainak az elemzésére:)....de sajna akkor még minimum XENON gépek kellettek:D...vajon miért:D
    Ma szintén szívesebben hagynám itthon a gépemet tölteni netről,ha közben dolgozik a drága:)

    Szép eredmény amúgy:) Szeretnék egy ilyen összkapacitásu gépen egyszer FULL-HD-ben játszani legalább T-HTX(valami mozi,csak felül is vannak hangszórók) hangminőségben:D:D:D :R :R

  • Stalker-2572

    veterán

    Globális felmelegedés ellen kéne kiszámolni valamit :U

    ps.: hol lehet megnézni, hogy találtak-e BÁRMIT is? Ilyen jó álca alatt akár hacker progit is lehetne futtatni :Y

    [ Szerkesztve ]

    All Black...

  • #95904256

    törölt tag

    válasz Stalker-2572 #11 üzenetére

    Gyere, helyezzük másik pályára a bolygót. :)

    Vannak "hacker"-kedő DC projektek is...

    [ Szerkesztve ]

  • Probiotikus

    csendes tag

    sztem mar lassan folosleges lessz, mivel ugy volt, hogy kereskedelmi forgalomba kerulnek, a qvantumszamitogepek. pontos adatot nem tok mit teljestitett a d-wave gape, de regen azzal peldaloztak, hogy ami a bluegene-nek evekbe tellene, azt egy qvantumszamitogep percek alatt kiszamolja. akkr most johet vki a pontos adatokkal

  • Thrawn

    félisten

    válasz Probiotikus #14 üzenetére

    Legyen igazad, de kötve hiszem hogy megfizethető lesz a projektek 'tulajdonosainak'. Bár ki tudja, talán akad egy pár akinek telik rá.

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł

  • SLYM

    veterán

    válasz Probiotikus #14 üzenetére

    én már nem is tudom hány éve hallottam erről, azt mégsincs semmi qvantum a boltokba, úgyhogy ne arra alapozz, hogy mi lesz majd ha

    [ Szerkesztve ]

  • R.Zoli

    őstag

    válasz Probiotikus #14 üzenetére

    A legjobb quantumszámítógép jelenleg 16 bites... Évek telnek el még addig mire 32 bites változat is lesz és egy ilyen tudományos számításhoz 64 bit az igazi,ezt kb. 15-20 évre taksálják amire lesz...

  • R.Zoli

    őstag

    válasz R.Zoli #18 üzenetére

    na már kicsit meg vagyok zakkanva...Olyan 1024 bit környékére gondoltam ahol kezd okés lenni a dolog...

  • dezz

    nagyúr

    válasz Probiotikus #14 üzenetére

    A D-Wave "gépe" egy pár qubites proci-féleség - inkább csak érdekesség, illetve egyetemi demonstrációs eszköznek jó egyelőre.

    (#11) Stalker-2572 Lásd itt az eredményeket.

    [ Szerkesztve ]

  • dezz

    nagyúr

    Egyébként a cikkben írt arányok nem egészen egyeznek a hivatalos statokból kiolvashatókkal:

    OS Type ------- Current TFLOPS -- Active CPUs -- Total CPUs
    -----------------------------------------------------------------------------------------
    Windows ----------------- 171 -------------- 179894 -------- 1836617
    Mac OS X/PowerPC ---- 7 ------------------ 9264 --------- 107528
    Mac OS X/Intel ---------- 14 ------------------ 4464 ----------- 27624
    Linux ------------------------ 38 ---------------- 22545 --------- 252485
    GPU ------------------------- 39 ------------------- 662 ------------- 4527
    PLAYSTATION®3 -- 1033 ---------------- 41664 --------- 310385
    ----------------------------------------------------------------------------------------
    Total --------------------- 1302 --------------- 258493 ------- 2539166

    [ Szerkesztve ]

  • Kampone

    tag

    valaki legyszives irja mar meg hogy mirol is van szo?mert en a cikkbol nem vagok semmit.a mai pcm nagyobb teljesitmenyre kepes?vagy mi?pls.thx :R

    nem irok ala

  • dezz

    nagyúr

    válasz Kampone #22 üzenetére

    Distributed computing - sok kisgépre elosztott számítási feladat-végrehajtás. Sok kicsi sokra megy alapon. A te géped egy a sok közül, aminek teljesítményét beadhatod a közösbe, napi x órára. A hír meg arról szól, hogy mivel PS3-on is elérhető az egyik ilyen projektben való részvétel szoftvere, és a tulajok elég szorgosan futtatják is (plusz elég gyorsan is számol a gépecske), az összteljesítmény igencsak megugrott.

  • Drizzt

    nagyúr

    válasz dezz #21 üzenetére

    G80-hoz gondolom még nincsen támogatás??

    I am having fun staying poor.

  • dezz

    nagyúr

    válasz Drizzt #24 üzenetére

    Nincs, Radeonra vannak ráállva. De még az R6xx-asokat sem támogatják (külön?). Azt írják, a legbonyibb és hosszadalmasabb a GPU-s kliens fejlesztése.

    [ Szerkesztve ]

  • R.Zoli

    őstag

    válasz dezz #25 üzenetére

    Pedig a legtöbbet ez hozná...Egy R600-as GPU olyan 4-5-ször gyorsabban futtatná ezeket a számításokat szerintük mint egy PS3-ban a cell...

  • dezz

    nagyúr

    válasz R.Zoli #26 üzenetére

    "Pedig a legtöbbet ez hozná..."
    Hozná, ha többszázezer embernél lenne R600-as... ;)

    "Egy R600-as GPU olyan 4-5-ször gyorsabban futtatná ezeket a számításokat szerintük mint egy PS3-ban a cell..."
    Ezt hol írják? A GPU-s kliensük egyébként egyszerűbb számításokat végez. Összetettebbnél fordul a kocka. (Lásd pl. ezt.)

  • Hebry

    senior tag

    Azért engem eléggé meglepett, hogy tipikusan játékra kitalált gépeket erre használnak az emberek.
    De ennek csak örülök.

  • Steven

    addikt

    NV-re miért nicsen ennyire szar a 8 as széria???

    Valami okosat kéne ide írni ááá : OKOS :D just smile

  • orbano

    félisten

    válasz dezz #27 üzenetére

    már az is jó lenne, ha a GPU-k bevonásával átlagban a duplájára rúgna a kapacitás. de mivel célirányosan tudják osztani a feladatokat, ezért várható (az összes népszerű gpura portolás után), hogy a lényegi összkapacitás tényleg megtöbbszöröződik.

    már csak azt kéne elérni, hogy a sok kis gagyi grid helyett egy nagy közös legyen...

    meg rendesen kéne ezeket reklámozni, az is durván megsokszorozná a teljesítményt. teszem azt a csatlakozott gépek még a számítógépes vírusok és spamek ellen is tudna ezek mellett segíteni.

    bár az is kérdés, hogy a jövőben milyen támadási felületeket hagynak a gépeken az efféle programok...

    A vér nem válik VAZZE!™

  • ]Phobos[

    senior tag

    válasz R.Zoli #19 üzenetére

    Egyébiránt én úgy hallottam, h már a 16bit-es is képes lenne bármilyen védelmi rendszert feltörni mp-ek alatt... -> kereskedelmi forgalom???

    A SETI rula, de igaz, a rák meg az aids ellen IS kellene használni a számítási kapacitást!

    [ Szerkesztve ]

    Semmi sem lehetetlen, csak nem túl valószínű!

  • dezz

    nagyúr

    válasz Hebry #28 üzenetére

    A Cell procit nem csak játékra találták ki. (Sőt, egyesek szerint elsősorban nem is erre lett kitalálva - de nem biztos, hogy ez nem csak FUD.) Az IBM szerverekben, munkaállomásokban, sőt szuperszámítógépekben is alkalmazza. A Roadrunner lesz a következő "világ leggyorsabb szuperszámítógépe", és 16000 Cellt fog tartalmazni, ugyanennyi Opteron mellett.

    #30: A 7-es szériáról azt írták, valami miatt lassúak voltak a számukra. De a 8-as széria már éppen elég jó. Csak kicsit megakadtak a GPU-s kliens fejlesztésével, még az újabb ATI kártyákat sem támogatják rendesen.

    ]Phobos[: Úgy érted, 16 qubites? Nem tudom, de szerintem egyszerre kell meglennie annak a qubit szélességnek, ahány bites a kulcs.

  • Thrawn

    félisten

    válasz dezz #27 üzenetére

    R600-al nincsenek ilyen eredmények?

    ]Phobos[: A SETI rula, de igaz, a rák meg az aids ellen IS kellene használni a számítási kapacitást!
    A World Community Grid erről szól :K

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł

  • orbano

    félisten

    válasz #95561216 #33 üzenetére

    mire gondolsz? az egységesített gridre? mondjuk azért lenne jó, mert lenne egy elképesztően nagy teljesítményű gép, ami hosszú távú feladatokra jobban ütemezhető, mint sok kicsi, valamint szükség esetén igénybevehető lenne egyszerre a nagy számítási kapacitás (pl. sürgős orvosi számítások, diagnózis, stb).

    A vér nem válik VAZZE!™

  • MZsoltee

    veterán

    Lehet picit önző vagyok, de ezért lehet kapni valami ellenszolgáltatás (konpenzálandón a megemelkedett villanyszámlát) esetleg 1-2 G90es vagy G92es vga karit hogy majd azzal is tudjunk számolgatni picit...

    Jah és találtam 1 térképecskét, nem is avgyunk oylan rosszak :D

    [ Szerkesztve ]

    A tökéletes nő süketnéma, nimfomániás, és az apjának kocsmája van.

  • Thrawn

    félisten

    válasz orbano #36 üzenetére

    Ezesetben elveszne az emberek számára a választás lehetősége. Én például nem szívesen kutatnék földönkívüliek után, van a Földön is épp elég probléma. (Valaki ezt egyszer szépen megfogalmazta, az aláírásában is benne volt/van)

    MZsoltee: ellenszolgáltatás nincs, neked kell eldöntened áldozol e gépkapacitást és pénzt ezeknek a projekteknek a megsegítésére

    [ Szerkesztve ]

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł

  • ]Phobos[

    senior tag

    dezz:
    Ahammm, ezt nem ma hallottam, és ennyire nem mentek bele, de biztos igazad van :R

    Thrawn:
    Biztos, még most melóból netelek, most várom a Tré-onlányos szerelőmukit, h hívjon, oszt majd rásasolok, mert( ha otthon vagyok ) úgyis egész nap / este megy a mac :))

    [ Szerkesztve ]

    Semmi sem lehetetlen, csak nem túl valószínű!

  • kvp777

    tag

    Azért engem eléggé meglepett, hogy tipikusan játékra kitalált gépeket erre használnak az emberek.

    Ez inkabb baleset. A sony egy tipikusan szuperszamitogepekhez kitalalt cpu-t rakott a jatekkonzolba. Tobbek kozott ez az oka, hogy ilyen szamitasokban jobb, es hogy lassan tobb hasonlo kliens lesz mint jatek. Programozni egyebkent naggyabol ugyanugy kell, mint egy mai gpu-t. (pl. az gf8800-asok 8 maggal, magonkent 16 egyseggel es 1.5Ghz-es orajellel rendelkeznek, mig a ps3-as cellek 6 szabad spe maggal, magonkent 2 egyseggel es 3.2Ghz-es orajellel rendelkeznek)

    Egyebkent akkor fogjak a cell-ek spe-jeit kihasznalni, amikor a programozok vegre megtanuljak hogyan lehet a teljes jatekot shader-ekbol megirni, mivel a programozasi kornyezet nagyon hasonlo. (vagy valaki vegre kijon egy c++ -> cuda vagy c++ -> cell spe c forditoval)

  • -zolee-

    tag

    Az egyik szakmai fórumon volt egy nagyon komoly HSZ ezzel a hírrel kapcsolatban. Az egyik csaj írta, hogy az ő PS3 -as prociidejét max vibr@'tortervezéshez adná kölcsön. :DD Mindenesetre elég érdekes, hogy lassan a PS3 mindenféle felhasználási területéről ömlenek a hírek csak valahogy az a játékos rész marad ki.

    ''Könnyű fizikai munka --> Ólomlapátolás'' by Hypo!

  • dezz

    nagyúr

    válasz kvp777 #40 üzenetére

    "A sony egy tipikusan szuperszamitogepekhez kitalalt cpu-t rakott a jatekkonzolba."
    Hát nem egészen, mivel ott nem a performance/watt, performance/transistor arányok a legfontosabbak. A Cellt egy univerzális chipnek szánták, ami jó oda is, de munkaállomásokba, médiacenterekbe, és pl. játékkonzolokba is.

    "Tobbek kozott ez az oka, hogy ilyen szamitasokban jobb, es hogy lassan tobb hasonlo kliens lesz mint jatek."
    Nem éppen. Egy játék fejlesztése kicsit hosszadalmasabb, mint egy ilyen kliens portolása, némi optimalizációval. A másik persze, hogy ez egy többmagos, ráadásul inhomogén proci. De ez másféle alkalmazások fejlesztését is nehezíti (cserébe viszont igen nagy teljesítményt lehet belőle kihozni).

    "Programozni egyebkent naggyabol ugyanugy kell, mint egy mai gpu-t. (pl. az gf8800-asok 8 maggal, magonkent 16 egyseggel es 1.5Ghz-es orajellel rendelkeznek, mig a ps3-as cellek 6 szabad spe maggal, magonkent 2 egyseggel es 3.2Ghz-es orajellel rendelkeznek)"
    Mint ahogy már többen megmondtuk neked különféle fórumokon, nem kellene blokkvázlatok vagy előadásokon nagy vonalakban elhangzottak alapján ilyen kijelentéseket tenned, talán kevesebbet tévednél. :U

    "Egyebkent akkor fogjak a cell-ek spe-jeit kihasznalni"
    Mint azt is megmondták már neked, jópár játék használja már őket (több-kevesebb optimizációval). Más területekről nem beszélve.

    "amikor a programozok vegre megtanuljak hogyan lehet a teljes jatekot shader-ekbol megirni"
    Minek is, amikor ott van egy PPE (Power Processor Element) mag is a game motornak? :U

    "mivel a programozasi kornyezet nagyon hasonlo."
    Aha, 10km magasból nézve. (Attól, hogy némileg jobban hasonlítanak egymásra, mint egy hétköznapi CPU-ra, még nem lesznek hasonlók.)

    "(vagy valaki vegre kijon egy c++ -> cuda vagy c++ -> cell spe c forditoval)"
    Mire lenne ez jó? A C++-os kód fusson csak a PPE-n, az SPE-ken meg jó kis párhuzamosított vektoros kód. Nos ilyen vektorizáló fordítója van az IBM-nek.

    [ Szerkesztve ]

  • R.Zoli

    őstag

    válasz dezz #27 üzenetére

    Nem kellene több százezer... Elég lenne 1-2 ezer is és iszonyat erőt képviselne, nyílván egyszerűbb feladatokat végezne de akkor is hatalmas ugrás lenne mert a komplex feladatok más kliensre lennének kiosztva... A fórumban a foldingon le van írva több adat is... A korábbi x1900-as szériához képest az R600 bonyolultabb feladatokkal is megbírkózik és 2-4-szer gyorsabb mint mint az x1900-as széria és eddig ők 2-szeres gyorsulást realizáltak ebből,de ez fejlődni fog... A mostani adatokat ha megnézed már a mostani GPU-k is sokkal nagyobb számítási teljesítménnyel rendelkeznek mint a PS3...

    Egyébként Ray tracing-ben naná ,hogy kikap a G80 a celltől... A G80 egy hulladék ilyen feladatokra(miután rasztelizálás a fő erőssége és egy oldboy e tekintetben) , a foldingosok elmodása szerint össze sem lehet hasonlítani tiszta számítási teljesítményben az R600-at a G80-nal... Vannak számítások amiket az R600 10-15-ször gyorsabban hajt végre... Nincs is ezen semmi csodálkoznivaló, az R600 a jövő alapjait hordozza magában ami a ray tracinghez kell majd (és GPGPU-s felhasználáshoz) és ebben egyetértek Abu85-tel ,hogy az NV-nek köze sincsen a ray tracing-höz és a jövőben emiatt hullhatnak ki a versenyből... Jah és ha még jön Larabee... Nagyot fog változni a GPU-k világa az Intel beszálltával és én sem érzem felkészültnek az NV-t erre... Nagyot eshetnek pofára ha már nem most ott vannak a lemaradásaik tekintetében...

  • dezz

    nagyúr

    válasz R.Zoli #44 üzenetére

    Nos akkor nézzük a számokat: Current TFLOPS vs. Active CPUs tekintetében kb. 2x több FLOPS esik egy GPU-ra, mint PS3-ra. Ha az R600-asok is bekapcsolódnak, ez valamennyivel feljebb megy majd, lesz mondjuk 4x-es az arány.

    Most nézzük meg, 1 PFLOPS-hoz mennyi adott időben aktív PS3 kell: kb. 40000. (Mindez összesen ~300000-ből, mert ugye nem futtat minden [napi szinten bekapcsolódó] tag mindig foldingot.)

    Akkor most a fenti arányszámmal oszd el ezeket a számokat... ;) Kellene kb. 10000 egy időben aktív GPU, hogy egy szinten legyenek a PS3-as csapattal. Ahhoz most kb. 9400 hiányzik... Plusz a nagyjából 7x-es arányt nézve az éppen aktív/passzív gépek között, kb. 70000 napi szinten aktív GPU-s tag kellene. Talán összesen van a világon ennyi high-end GPU gamereknél.

    "Vannak számítások amiket az R600 10-15-ször gyorsabban hajt végre..."
    Ez azért extrém példa lehet. Sqr-t (amit a G80 a lassú spec.funct. egységeivel végez) is tartalmazó raw teljesítmény-tesztekben kb. 4x-es különbség jött ki. Átlagos pixel shader tesztekben viszont igencsak legyőzi a G80. Igaz, vertex- és geometry shaderekben fordított a helyzet, de itt talán relevánsabb a másik.

    Mindenesetre megnéznék már valami nem-raw-teszt programot, ami sokkal gyorsabb R600-ason, mint G80-on. :)

    [ Szerkesztve ]

  • R.Zoli

    őstag

    válasz dezz #45 üzenetére

    Mindenesetre megnéznék már valami nem-raw-teszt programot, ami sokkal gyorsabb R600-ason, mint G80-on.

    A folding ilyen... Sokkal gyorsabb R600-on mint G80-on :) Régen olvasgattam már de azt írta talán az egyik fejlesztő ,hogy az x1900-as szériánál kicsivel gyorsabb csak a G80, mert sokkal kevéssé alkalmas ilyen feladatokra mint az R600... Igazából nekik nem is az a legnagyobb bajuk a G80-nal ,hogy lassabb mint az R600 hanem sokkal kevesebb dolgot tud megoldani és nehezebb is megírni rá a GPU klienst, az R600-ról szinte úgy beszéltek mint a messiásról ám annyira új még a design számukra és a tudását fel akarják térképezni ,hogy maximálisan kihasználják ezért megy ilyen lassan a GPU kliens fejlesztése...Ezt írta a fejlesztő, van róla a fórumban sok oldalas leírás amikor megjelent az R600 ők akkor írták ezeket...

    Ettől függetlenül én a jövőben úgyis ki akartam próbálni az RV670-et, szerintem crossfire-ben bedobok ilyet a gépbe mert nem lesz túl drága és megnézem mit tud folding alatt... Elméletileg egy nagyobb renderfarm teljesítményét fogja hozni ilyen tudományos számításokban 2 ilyen GPU...De addig egy Yorkfield-et is kell vennem mert sajna a Qaudom 3,6-on (1,38 volton) lezabálja a gatyámat is...Ezt csak azért mondom mert a GPU klienshez kell GPU-nként 1-1 NAGYON ERŐS CPU mag is!!! Sokan erről feledkeznek meg ,hogy a GPU magában semmit sem tud megoldani, a CPU-n is sok múlik... A foldingon azt írták egy Quad magos géppel és 4 darab R600-zal amit lehetne művelni az elképesztő... Ők is tervezik 4-5 ilyen gép összerakását a laborjukban :) Nekem ehhez nincs keretem villyanszámlában :D

    [ Szerkesztve ]

  • Brae

    őstag

    válasz Thrawn #5 üzenetére

    "A Rosetta az ugyanaz mint a Folding@Home?"
    Nem

    Akkormár énis linkelek :DD Rosetta@home

  • Dr_Syrex

    senior tag

    [link]

    én már egy ideje ezt a projektet tolom, bár az utóbbi időben szoftveres és hardveres :D problémák miatt nem voltam aktív.

    Nézzétek meg melyik csapat a legaktívabb (én is abban vagyok), szerintem elég érdekes :)

    [ Szerkesztve ]

    Rosetta@home, lépj be Te is a PH! csapatába! *** WoT: Blitzking 43M TURAN - Hungarian Armored Brigade

  • Probiotikus

    csendes tag

    ne okoskodasnak nezzetek, inkabb csak erdekesseg keppen
    "A qubitek induló állapotát illetően nem csak bináris 1 és 0 tárolására képesek, hanem egyfajta szuperpozícióban is tarthatóak a két állapot között. Ahogy a qubitek száma nő, úgy növekszik a különböző állapotok száma, amelyeket megtestesíthetnek az összekapcsolt kvantum bitek. Két qubit 4 különböző állapotra képes, amelyeket szimultán fel lehet dolgozni, míg három qubit már 8-ra, és így tovább, exponenciálisan növekvően. Így egy gép, amely csak 10 qubitet tartalmaz, már 1024 műveletre képes szimultán, mintha egy hatalmas párhuzamosan feldolgozó egység lenne. Egy 40-qubites 1 trillió műveletre, sőt, egy 100-qubites rendszer már szinte elképzelhetetlenül nagy mennyiségű, egyidejű művelet végrehajtására képes.

    Ez a hatalmas teljesítmény például triviálissá tenne olyan számításokat, mint például a prímszámok faktoriálisának keresése, amely a mai leggyorsabb számítógépet is elég rendesen megdolgoztatja. Példaként Tsai a következőt hozta fel. Vegyünk egy 256 bites bináris számot, és Shor algoritmussal próbáljuk meg kiszámítani a faktoriálisát. Ez a feladat az IBM Blue Gene szuperszámítógépének 10 millió évébe kerülne, míg egy kvantum számítógépnek mindössze 10 másodpercre van szüksége a számítás elvégzéséhez."

    a mikor nyaron sikerult a nyilvanos bemutato a d-wave nek, azt mondtak, hogy 2008-tol 64 es 128qubites gepeket kereskedelmi forgalomban fognak arusitani.

  • #95561216

    törölt tag

    válasz orbano #36 üzenetére

    Diagnózisra? Arra ott van House :) Na de most komolyan, Bush egyet büfizik, és elkészítik rajta a diagnózisát? Na meg ki dönti el, hogy mi fusson rajta? Speciel engem csak a Seti/Einstein@home érdekel, a biológiát meghagyom másnak. Esetleg majd az LHC.

  • kvp777

    tag

    "Programozni egyebkent naggyabol ugyanugy kell, mint egy mai gpu-t. (pl. az gf8800-asok 8 maggal, magonkent 16 egyseggel es 1.5Ghz-es orajellel rendelkeznek, mig a ps3-as cellek 6 szabad spe maggal, magonkent 2 egyseggel es 3.2Ghz-es orajellel rendelkeznek)"
    Mint ahogy már többen megmondtuk neked különféle fórumokon, nem kellene blokkvázlatok vagy előadásokon nagy vonalakban elhangzottak alapján ilyen kijelentéseket tenned, talán kevesebbet tévednél.

    Ha nem tevedek ott voltal Peter Hofstee elodasan. (legalabbis egy angolul nem igazan tudo ember probalt a te stilusodban beszelni, vegul masok forditottak le a kerdeseit) Ha a cell tervezoje hasonlitja ossze a sajat processzorat a gf8800-as szeriaval, akkor neki erdemes hinni. Egyebkent en is az 1 cpu, 8 spe-s cell-t hasonlitottam ossze a 8 magos gf8800-assal. Mint az elhangzott lesz jobb valtozat is, bar ez a ps3-as embereknek szereny vigasz. (de majd a ps4 ha a sony tuleli a jelenlegi veszteseget) Latszott a tervezon hogy mennyire megtisztelonek erzi hogy rabiztak a feladatot es teljes erobol probalja a csapataval teljesiteni.

    "amikor a programozok vegre megtanuljak hogyan lehet a teljes jatekot shader-ekbol megirni"
    Minek is, amikor ott van egy PPE (Power Processor Element) mag is a game motornak?

    Mivel aki tud gpgpu-ra tisztan shader-bol jatekmotort futtato kodot irni, az a hasonlo architektura miatt fog tudni a cell-re is. Csak egy kulonleges cpu miatt nem tanul meg senki egy uj kornyezetet, de a gpu-k elterjedsege miatt elobb utobb minden ezen a teruleten dolgozo programozo meg fogja tanulni. Sokkal tobb gpu van a vilagban mint ps3-as konzol. (a regebbi dx9-eseket is beleszamolva)

    "(vagy valaki vegre kijon egy c++ -> cuda vagy c++ -> cell spe c forditoval)"
    Mire lenne ez jó? A C++-os kód fusson csak a PPE-n, az SPE-ken meg jó kis párhuzamosított vektoros kód. Nos ilyen vektorizáló fordítója van az IBM-nek.

    A hetfoi eloadas anyaga szerint ilyen lesz, de az is csak sima c-hez. Ez meg annyira nem elerheto technika, hogy az eloadas utan feltett egyik kerdesre az volt a valsz, hogy a gcc kodja szabad, arra megirhatja barki a hianyzo feature-t, majd atveszi az ibm ha tenyleg megeri. (jo van fortran is, de azt mar csak nehany oskovulet tudos hasznalja es az meg annyit sem tud mint a c)

    Jelenelg a fordito csak overlay-eket tud kezelni, ami a dos-os turbo c-re volt jellemzo. Mivel a memoriamodell hasonlo, csak itt nem 4*64 Kb hanem 1*256 Kb az egyszerre cimezheto limit. Az overlay-ek legnagyobb atka, hogy a programozonak oda kell figyelnie, hogy eppen mi elerheto es mi nem. Ha a teljes dataset working set-je nagyobb mint a lokalis ram, akkor bonyolult lapozo algoritmusokat kell irni, csak arra, hogy hozzaferjen a program az adatokhoz. Ilyen algoritmusbol csak a bemutatott raytracing demo-hoz 7 kulonbozo kellett (+az ibm altal adott felkesz overlay kezelo a kodnak). Mindezt egy hagyomanyos processzor hardverbol tudja, ezert nem kell megirni minden egyes programhoz kulon-kulon. A devkit-nek jelenleg ugyanis nem resze, meg az ibm fele forditohoz sem adjak oket. (majd talan par ev mulva jo penzert... de most meg nem)

    Szerintem erdemes lenne kb. a teljesitmeny felet feladva kesziteni egy altalanos interpretert, ami valamilyen virtualis cpu-t emulalna. (pl. .net kornyezetet) Igy a hianyzo hardvert a szoftveres emulator potolna, es jit-et hasznalva ez csak a teljesitmeny felet vinne el, viszont a virtualis kornyezet megegyezne az altalanos cpu-kkal. (a virtualis memoriat ugy lehetne emulalni, mint a mai szoftveres x86 emulatorok, ami lassu de konnyu programozni)

    mas...

    A cell egy spe-je magonkent ket egyseges vliw. Az itaniumok magonkent 4-6 egyseges vliw-ek. Az nvidia gf8800-asa magonkent 16 egyseges vliw. A legnagyobb ilyen rendszer magonkent (afaik) 16384 egyseges (egy CNND chip, ennel tobbmagosat meg nem lattam eloben). Az ilyen architekturak nagyon jok linearis vegrehajtasban, es nagyon rosszak elagazasban. Minel tobb alu van parhuzamosan annal nagyobb a veszteseg egy ugraskor. Az gf8800-as es az itanium ezt ugy kezeli, hogy van bennuk felteteles vegrehajtas. Ez azt jelenti, hogy egy if/else ugy fut le parhuzamosan ugras nelkul, hogy eloszor lefut az if ag, de csak azok az alu-k akitvak amikre evenyes a feltetel, majd lefut az else ag, a maradekkal. Egy bonyolult tobbszorosen egymasba agyazott if fat is at lehet alakitani egy bitmap-pe, ami akkor engedi a vegrehajtast ha az adott alura minden bit eppen 1 (az osszes feltetel igaz). Ezzel a megkozelitessel harom gond van, az egyik hogy bonyolut a fordito feladata, a masik hogy ciklusokat nem lehet vele rendesen kezelni, a harmadik pedig hogy egy if/else ag ketszer annyi ido alatt fut le mintha kulonallo vezerloegyseg lenne minden alu-hoz. (lasd x86-os pipeline-ok)

    A gf8800-as nagyon jo minden olyan kodban amit ki lehet hajtogatni feltetelekre, viszont legrosszabb esetben 16-odara esik a teljesitmeny minden olyan esetben ahol eltero szamu ciklus kell, hogy lefusson, mivel ilyenkor a cuda fordito feladja es serializalja a kodot. Shader-ek eseten a jelenlegi directx architektura nem engedi meg egy polygon-on belul pixelenkent eltero shader programok hasznalatat, tehat ez a problema nem jon elo. Raytracing kozben viszont ez az alapeset, ilyenkor a gf8800-as jelenleg 128 magbol csak 8-at tud aktivan hasznalni. (blokkonkent 1-et) Ha 16 szalat osszefognanak egy kooperativ szuperszalla, akkor visszaterne a teljesitmeny, de ilyen forditoja jelenleg nincs az nvidia-nak. (a transmetanak volt, de az most az ibm tulajdona es nekik nem kell, mert egy cell spe csak 2 egyeges, amilyen a pentium I-es volt meg annak idejen, arra viszont meg a gcc is jo valamennyire)

    Roviden szolva a jovo eleg nyitottnak latszik es nincs egyertelmu gyoztes. Ha az intel osszeszedi magat es kihoz egy 128 magos valosan fuggetlen cpu tombot, akkor letarolhatja a teljes piacot. (gyakorlatilag a gf8800-as teljesitmenyet hozna, viszont nem kellene optimalizalni a kodot, mert teljesen fuggetlen magokat hasznalna) Legjobb tudomasom szerint eppen dolgoznak egy ilyen megoldason. Az egyetlen nagyobb akadaly a memoria savszelessege lenne, de ha minden fuggetlen mag kaphatna egy sajat csatolot akkor ez is eltunne. A kerdes az, hogy ki foglalkozik jelenleg memoria es cpu szendvicsszeru osszeillesztesevel? (a valasz: a samsung es az intel, de vajon miert...)

    ps: Mar keszulnek az optikai processzorok es halad a kvantumszamitogep is. Egyebkent en az optikai interferenciat hasznalo kvantumszamitogepeket tartom a jovonek (a feny is csak elektromagneses hullam), mivel ezek kepesek lehetnek szobahomersekleten is mukodni. Az elmeleti maximum egy skalar (1 'magos') optikai gep eseten tobb terahertz. (kb. a felhasznalt feny frekvenciajanak a fele) Egy hologramban tarolt rainbow table olvasasi ideje 1 orajel, mivel a feny parhuzamosan olvassa a teljes hologramot. Ilyen rendszeket mar most is tudunk kesziteni, csak a kiolvasott jel feldolgozasara (elektromos jelle torteno visszalakitasara) nincs jelenleg gyakorlatban is hasznalhato megoldas, bar egy lezer tartomanyban dolgozo felveteto cmos fototranzisztor feltalalasa megoldhatna a dolgot.

  • dezz

    nagyúr

    válasz kvp777 #52 üzenetére

    Na most vagy hazudsz, vagy magad nem tudsz eléggé angolul.
    1. Az összes kérdésemet magam mondtam el, Hofstee meg is értette, és szépen válaszolt is rájuk. Érdekes nem? :U
    2. Utána még akartam egy apróságot mondani lezárásként, és egyetlen szó (elhivatottság) nem jutott eszembe. Az előttem lévő sráctól kérdeztem meg, viszont úgy tűnt, neki sem jutott eszébe, ezért megpróbálta a saját szavaival elmondani (nem nagyon sikerült azt mondania, amit én akartam, de mindegy).
    3. Az előadás után váltottam még Hofstee-vel néhány szót, megkérdeztem, értette-e, amit a végén mondani akartam, és mondta, hogy tökéletesen. Meg is köszönte a kommentjeimet.

    Tudod mit, ezek után kurvára nincs kedvem tovább olvasni az irományodat.

  • dezz

    nagyúr

    Jut eszembe, az előadás után közvetlenül, az ajtó előtt szúrósan rámnézett egy gonosz és féltékeny tekintetű srác, csak nem te voltál? :P

  • dezz

    nagyúr

    válasz dezz #53 üzenetére

    A sráccal kapcsolatban: tehát ott egyetlen, utolsó mondatról volt szó. Több kérdés-felelet váltás után. Aki egyátalán nem tud angolul, ennyit az is felfoghatott az egészből - tahát mégis nyilvánvalóan és szándékosan hazudtál alább.

  • Raymond

    félisten

    Basszus ne egyetek mar egymast. Inkabb irjon valamelyikotok a logout-ra milyen volt az eloadas :)

    Privat velemeny - keretik nem megkovezni...

  • tomazin

    veterán

    válasz Stalker-2572 #11 üzenetére

    [link]

    Probiotikus : A grid ereje több,mint egy számítógépé.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz Raymond #56 üzenetére

    Először, az idő nagyobb részében végülis egy 2005-ös IBM-es powerpoint prezentációs anyagon haladt végig. Letölthető tőlük (linket most nem tudok). Utána volt még néhány újabb slide, pl. az Nvidia Tesla-járól és az AMD Fusionjáról (bemutatva, hogy a Cell "nincs egyedül", illetve hogy az egyszerű többmagosítás sok területen nem elég hatékony). Nem utolsó sorban mutatott egy kis ray-tracing animációt, amit egy QS20-as real-time számol egy bizonyos iRT ray-tracerrel (a program változtatás nélkül fut PS3-on is): [link]

  • Raymond

    félisten

    válasz dezz #58 üzenetére

    Szoval semmi uj. Ezeket mar linkeltem a CELL-es topicban. Az animaciot nem hiszem de valahol megvan mar nagyfelbontasban. Meg akkor toltottem le amikor eloszor mutattak be (jo)pas honapja.

    Privat velemeny - keretik nem megkovezni...

  • tomazin

    veterán

    válasz orbano #36 üzenetére

    Rengeteg grid van,és még sokféle is(desktop/szolgáltató/vegyes) akkor környezet szerint is(condor,a másik nem jut eszembe),és ezek a "sok kicsi" is darabonként hihetetlenül erős.(használják katasztrófavédelemnél(pl paks pár éve),mikor sok számítás kell,hirtelen)
    Ennyi a jóvan így ahogy van részről.
    De meg se lehetne csinálni amit Te akarsz:Más a middleware,iszonyatos nagy központosítás nem tudná kezelni azt a sok usert/vo etc.
    So lehetetlen és felesleges lenne amit te szeretnél.

  • dezz

    nagyúr

    válasz kvp777 #52 üzenetére

    Na asszem mégis kénytelen vagyok válaszolni.

    "Ha a cell tervezoje hasonlitja ossze a sajat processzorat a gf8800-as szeriaval, akkor neki erdemes hinni."
    Éppen arról beszélt, hogy a GPU-k sok számítási feladatra sem optimálisak, ellentétben a Cellel. Te meg úgy akarod itt beállítani, hogy szinte egyformák... Nem érzel itt egy kis különbséget?

    "Mivel aki tud gpgpu-ra tisztan shader-bol jatekmotort futtato kodot irni, az a hasonlo architektura miatt fog tudni a cell-re is."
    De mi a fenének kellene egy teljes játékmotort shaderekre írni? Vagy kizárólag SPE-kre?
    Nem véletlenül van ott az a PPE sem.

    "A hetfoi eloadas anyaga szerint ilyen lesz, de az is csak sima c-hez. Ez meg annyira nem elerheto technika, hogy az eloadas utan feltett egyik kerdesre az volt a valsz, hogy a gcc kodja szabad, arra megirhatja barki a hianyzo feature-t, majd atveszi az ibm ha tenyleg megeri. (jo van fortran is, de azt mar csak nehany oskovulet tudos hasznalja es az meg annyit sem tud mint a c)"
    Te most miről beszélsz? IBM XL C/C++ for Multicore Acceleration for Linux
    A high-performance IBM XL C and C++ compiler for the Cell Broadband Engine Processor.

    A Cell SDK része, bár beta verziós.
    A gcc is C++ compiler. Bár oo kódot tudtommal csak a PPE-re tud fordítani, na de SPE-kre ki akar ilyet fordítani?
    (Továbbá ott van még az IBM Octopiler nevű fordítója, ami automatikus párhuzamosító és vektorizáló. Bővebben.)

    "Jelenelg a fordito csak overlay-eket tud kezelni, ami a dos-os turbo c-re volt jellemzo. Mivel a memoriamodell hasonlo, csak itt nem 4*64 Kb hanem 1*256 Kb az egyszerre cimezheto limit. Az overlay-ek legnagyobb atka, hogy a programozonak oda kell figyelnie, hogy eppen mi elerheto es mi nem. Ha a teljes dataset working set-je nagyobb mint a lokalis ram, akkor bonyolult lapozo algoritmusokat kell irni, csak arra, hogy hozzaferjen a program az adatokhoz. Ilyen algoritmusbol csak a bemutatott raytracing demo-hoz 7 kulonbozo kellett (+az ibm altal adott felkesz overlay kezelo a kodnak). Mindezt egy hagyomanyos processzor hardverbol tudja, ezert nem kell megirni minden egyes programhoz kulon-kulon. A devkit-nek jelenleg ugyanis nem resze, meg az ibm fele forditohoz sem adjak oket. (majd talan par ev mulva jo penzert... de most meg nem)"
    Azt nem tudom, mikor mit fognak adni, de az iRT-ről ezt írták valahol:
    The iRT now uses automatic code overlay support to switch shaders and read/write software caches to spill, sort, bundle, and evaluate secondary rays. These two coding features allowed the programming team to ignore the SPE's 256KB local store size for both code and data fetch and eliminated the need for programmer directed DMAs.".)

    "Szerintem erdemes lenne kb. a teljesitmeny felet feladva kesziteni egy altalanos interpretert, ami valamilyen virtualis cpu-t emulalna. (pl. .net kornyezetet) Igy a hianyzo hardvert a szoftveres emulator potolna, es jit-et hasznalva ez csak a teljesitmeny felet vinne el, viszont a virtualis kornyezet megegyezne az altalanos cpu-kkal. (a virtualis memoriat ugy lehetne emulalni, mint a mai szoftveres x86 emulatorok, ami lassu de konnyu programozni)"
    Rajta... :D De mégis, hogy gondolod pl. a memóriakezelést ezzel?

    "Az nvidia gf8800-asa magonkent 16 egyseges vliw."
    Az R600-as a vliw alapú.
    The G80 shader core is a little different from the R600. It is built on eight SIMD units each containing 16 SPs. The SIMD instructions are not VLIW, but single scalar instructions, and each SP within a SIMD unit executes that instruction on a different thread. While groups of 16 SPs share resources, NVIDIA's compiler doesn't need to build VLIW instructions to schedule out any of these SPs and it would be quite difficult to create dependencies between SPs because they are running different threads. [link]

    "Az gf8800-as es az itanium ezt ugy kezeli, hogy van bennuk felteteles vegrehajtas. Ez azt jelenti, hogy egy if/else ugy fut le parhuzamosan ugras nelkul, hogy eloszor lefut az if ag, de csak azok az alu-k akitvak amikre evenyes a feltetel, majd lefut az else ag, a maradekkal."
    Izé, ez itt a Static Flow Control, ami már DX9.0-ban is volt, vagy még előbb. DX9.0c óra van Dynamic Flow Control is, ami ugrásokat is kezel. Kicsit frissítsd az ismereteidet.

    "Shader-ek eseten a jelenlegi directx architektura nem engedi meg egy polygon-on belul pixelenkent eltero shader programok hasznalatat"
    És szerinted Linux alatt DX-eznek?

    "Roviden szolva a jovo eleg nyitottnak latszik es nincs egyertelmu gyoztes. Ha az intel osszeszedi magat es kihoz egy 128 magos valosan fuggetlen cpu tombot, akkor letarolhatja a teljes piacot. (gyakorlatilag a gf8800-as teljesitmenyet hozna, viszont nem kellene optimalizalni a kodot, mert teljesen fuggetlen magokat hasznalna)"
    Azt már a 80-magos TeraScale-jével is alaposan lenyomná. De még talán a 16-24 magos Larrabee-vel is. Tudod, mag és mag között lehetnek nem kis különbségek.

    "Egyebkent en az optikai interferenciat hasznalo kvantumszamitogepeket tartom a jovonek"
    Hát nem tudom, tudod-e, hogy működnek a kvantumszámítógépek, de az interferencia általában az ősellenségük. De lehet, hogy te felfedeztél valami sokkal jobbat, ki tudja. ;)

  • dezz

    nagyúr

    válasz Raymond #59 üzenetére

    A linkelt iRT-s oldalról is letölthető egy hasonló, 560p-ben.

  • dezz

    nagyúr

    válasz dezz #61 üzenetére

    Izé, kicsit figyelmesebben elolvasva azt a static flow controlos részt, már látom, miért írtad, bocs. Bár nem egészen értem ezt, mert akkor a G80 emiatt nem is tudhatna dynamicot, ami érdekes lenne.

    Mindenesetre úgy tűnik, ez egy dologgal több, amiben az R600-as superscalar blokkos végrehajtási mechanizmusa hatékonyabb.

    [ Szerkesztve ]

  • dezz

    nagyúr

    válasz dezz #63 üzenetére

    Pontosabban ott nem tudhatna, ahol a pixel/vertex aktuális értékétől függ az ugrás. Ahol ettől független változótól v. ciklusváltozótól függ, ott persze igen.

  • dezz

    nagyúr

    válasz dezz #64 üzenetére

    Mondjuk feldolgozott adat függő ugrásnál az R600 is gondban lehet, hiszen ott sem mehet minden stream proc. unit (5-way superscalar egység) össze-vissza a saját feje (PC-je) után, hanem 8-asával egy-egy szálat hajtanak végre, mindegyikük másik pixelre/vertexre vonatkozóan (pontosabban 16-osával 1-1 szál-párt).

    Na itt meg a Cell előnye jön ki, hogy nem ennyire széles a párhuzamosítás egy SPE-ben, hanem csak 4 elem széles a feldolgozás 32 bites adatnál - és azok is összefüggő adatok.

  • R.Zoli

    őstag

    válasz kvp777 #52 üzenetére

    remélem azt nem gondolod ,komolyan ,hogy a samsung lesz az Intel fő ellenfele ray tracing terén...Ott kő keményen Ati/AMD lesz az ellenfél...

  • kvp777

    tag

    Jut eszembe, az előadás után közvetlenül, az ajtó előtt szúrósan rámnézett egy gonosz és féltékeny tekintetű srác, csak nem te voltál?

    Nem. En rossz szokasom szerint eppen dumaltam. Egyebkent az itteni avatarom tokeletesen reprezentalja a hozzaallasomat a dolgokhoz. Nem kell versenyezni senkivel. A helyeztrol egy mondas jut eszembe: Az interneten vitatkozni olyan mint resztvenni a specialis olimpian, ha nyersz, akkor is bena vagy. :)

    A gcc is C++ compiler. Bár oo kódot tudtommal csak a PPE-re tud fordítani, na de SPE-kre ki akar ilyet fordítani?

    Az az oo kod a c++. A tobbi csak a sima c. Es szemely szerint en szeretnek standard template library-t hasznalni az spe-ken is. Ha egy texas dsp-n lehet es erdemes, akkor egy cell spe-en miert ne?

    De mi a fenének kellene egy teljes játékmotort shaderekre írni? Vagy kizárólag SPE-kre?

    Mert akkor lehetne pc-n (ahol nincs cell) egysegesitett grafikai es fizikai gyorsitas. Igy egy helyen lenne a grafikai adat es a fizikai rendszer. A physix legnagyobb baja, hogy lassan tud kommunikalni a gpu-val mert csak a cpu-n keresztul eri el, ezert sokaig tart amire a kiszamolt fizika kirajzolhatova valik. Ezzel szembe ha minden a gpu-n fut, akkor minden egy helyen van.

    Azt nem tudom, mikor mit fognak adni, de az iRT-ről ezt írták valahol: The iRT now uses automatic code overlay support to switch shaders and read/write software caches to spill, sort, bundle, and evaluate secondary rays. These two coding features allowed the programming team to ignore the SPE's 256KB local store size for both code and data fetch and eliminated the need for programmer directed DMAs.".)

    Leirtad ugyanazt amit en is mondam, csak most a google-t hasznalva. Az automatikus code overlay az az altalam is emlitett dos stilusu overlay kezeles. A read/write software cache pedig a 7 kulonbozo szoftveres adatlapozo konyvtarat jelenti, amit valakinek meg kellett irnia. Es az architektura miatt minden egyes adattipushoz kulon-kulon meg kell irni ujra es ujra. Az, hogy ok buszkek ra, hogy megirtak egy kulon konyvtarba nem jelenti azt, hogy ezt a hardver kezeli vagy hogy a fordito kepes lenne megirni a programozo helyett.

    Rajta... De mégis, hogy gondolod pl. a memóriakezelést ezzel?

    Lassuk csak... mondjuk szoftveres read/write cache-ekkel, amik automatikusan kezelik a virtualis lapok irasat, olvasasat es feldolgozasat. :)

    És szerinted Linux alatt DX-eznek?

    Nem, tobbek kozott ezert is szivas bizonyos dolgokat cuda vagy opengl alatt megirni. A gf8800-as nem szereti a dinamikus adatvezerelt elagazasokat. Kezeli oket, de 1/16-od teljesitmennyel. Gyakorlatilag csak 1 branch unit van blokkonkent.

    Pontosabban ott nem tudhatna, ahol a pixel/vertex aktuális értékétől függ az ugrás. Ahol ettől független változótól v. ciklusváltozótól függ, ott persze igen.

    Sajnos a tudomanyos felhasznalasban ez gyakori. A kozos, de eltero lepesszamu ciklusokat meg turkkozessel meg lehet csinalni, es ekkor a leglassabb vegrehajtasi ideje lesz az osszes ideje, de pl. az adatvezerelt felteteles ugras utani ciklusokkal mar nem boldogul, es nekiall egyesevel vegrehajtani.

    remélem azt nem gondolod ,komolyan ,hogy a samsung lesz az Intel fő ellenfele ray tracing terén...Ott kő keményen Ati/AMD lesz az ellenfél...

    Nem, a samsung az intellel egyutt szokott dolgozni, az egyik cpu-kat gyart a masik memoriat. Alapvetoen egyik sem er sokat a masik nelkul.

    Na itt meg a Cell előnye jön ki, hogy nem ennyire széles a párhuzamosítás egy SPE-ben, hanem csak 4 elem széles a feldolgozás 32 bites adatnál - és azok is összefüggő adatok.

    Igen, a cell-ek jobban hasonlitanak a hagyomanyos cpu-kra, leginkabb a 60-as evekbol szarmazo pic architekturara, annak is az eredeti formajara. (kis linearis cimter, fix orajeles utasitasok, relativ nagy sebesseg, interleave vegrehajtas, a kulonbseg hogy a cell nem harvard-os, bar az szerintem jobb lenne) A cell spe-k egyetlen hatranya, hogy altalanos cpu-nak hianyzik beloluk a virtualis memoria kezelese, vliw-es dsp-nek viszont nem eleg szeles az alu-juk. Valahol az intel fele altalanos cpu-k es az nvidia fele brute force-os buta vektoregysegek kozott vannak. Sem egyik, sem masik. Altalanos logikara jobb a cpu, vektorfeladatokhoz jobb a gpu. A cell-nek pedig maradnak a tudomanyos munkak, legalabbis amig valaki meg nem irja a szukseges virtualizalo forditot (lasd pl. compiled java) ugyanis jatekok eseten jelenleg minden programozonak fel kell talalnia a spanyol viaszt. Ahogy az eloadasban elhangzott, jelenleg sok mindent nem tud a fordito, de a gcc kodja nyilt, megirhatja barki. Ha egy jatekkeszito ceg embereit azzal biztatja az architektura kitalaloja, hogy eloszor irnia kellene egy hasznalhato forditot mielott elkezdene jatekot irni, akkor ez eleg hamar elveszi a kedvet az egesztol. Ilyenkor marad a pc, az xbox360 es a wii. Vagy alternativakent csak a power magot hasznalja. Ha egy multiplatform jatekot nem lehet egy altalanos cpu-ra irt koddal megcsinalni, akkor nem eri meg vacakolni egy amugy sem tul nepszeru konzollal. Meg az oskovulet wii-n vagy a ps2-esen is tobbet lehet eladni egy-egy jatekbol. Ha ma valaki jatekot akar irni sony-s konzolra, akkor a ps3 helyett erdemesebb a ps2-re dolgoznia, mert azt legalabb veszik.

  • dezz

    nagyúr

    válasz kvp777 #67 üzenetére

    "Egyebkent az itteni avatarom tokeletesen reprezentalja a hozzaallasomat a dolgokhoz. Nem kell versenyezni senkivel. A helyeztrol egy mondas jut eszembe: Az interneten vitatkozni olyan mint resztvenni a specialis olimpian, ha nyersz, akkor is bena vagy."
    Az a baj, hogy ezzel a "beszéljünk jó sokat össze-vissza, a fele csak igaz lesz" filozófiával jópár embert felidegelsz, akik nem igazán örülnek, ha valaki téves információkat terjeszt, helyessel keverve, így megbízhatónak tűnően. Mivel ezt a PS3-mal kapcsolatban is csinálod, ezt már konkrétan FUD-nak nevezhetjük. És ez ellen kénytelen az ember fellépni.

    "Az az oo kod a c++. A tobbi csak a sima c."
    Igen - ki írt mást?

    "Es szemely szerint en szeretnek standard template library-t hasznalni az spe-ken is. Ha egy texas dsp-n lehet es erdemes, akkor egy cell spe-en miert ne?"
    Nem tudom, most valójában lehet-e vagy sem, mindenestre ez nem egy létszükséglet tudományos és game területen. Javat nem akarsz rajtuk futtatni?

    "Mert akkor lehetne pc-n (ahol nincs cell) egysegesitett grafikai es fizikai gyorsitas. Igy egy helyen lenne a grafikai adat es a fizikai rendszer."
    A teljes játékmotorról volt szó, amibe beletartozik a játék-logika is, és az lett volna a lényeg. Az meg a procin érzi jól magát, és nem is akarja senki elmozdítani onnan.

    Az persze természetes kívánság, hogy a grafika, fizika, AI (nagyrészt) a GPU-n, ill. PS3-nál részben azon, részben az SPE-ken fusson. Azonban ez perpill PC-n nem igazán kivitelezhető, mert 1. GPU limitesek a játékok, tehát nincs fölös GPU-kapacitás. 2. A többmagos procik meg többnyire kihasználatlanok. Mondjuk valószínű a későbbiekben egyszerűen kénytelenek lesznek GPU kapacitást áldozni erre (mármint fizikára, AI-ra), mert egy kis GPU idő sok-sok CPU idővel ér fel, azaz egy fél GPU többet tud fizikázni, mint több CPU mag. De egyelőre nincs is ennyi fizika a játékokban. Azonban, láthatóan a dolgok affelé haladnak, ami a PS3-nak is kedvez. Erre te csak kántálod tovább, hogy nincs jövője, bla bla bla.

    "Leirtad ugyanazt amit en is mondam, csak most a google-t hasznalva."
    Nem kellett használnom a google-t, mivel hetekkel ezelőtt olvastam azt a szöveget, amiből az idézet származott. (Más okból már máshová is betettem.)

    "Az automatikus code overlay az az altalam is emlitett dos stilusu overlay kezeles. A read/write software cache pedig a 7 kulonbozo szoftveres adatlapozo konyvtarat jelenti, amit valakinek meg kellett irnia. Es az architektura miatt minden egyes adattipushoz kulon-kulon meg kell irni ujra es ujra. Az, hogy ok buszkek ra, hogy megirtak egy kulon konyvtarba nem jelenti azt, hogy ezt a hardver kezeli vagy hogy a fordito kepes lenne megirni a programozo helyett."
    Valamit valamiért: 10x-es teljesítmény némi pluszmunkáért cserébe. Ezt a dolgot nem sikerült megértened az előadáson?

    "Lassuk csak... mondjuk szoftveres read/write cache-ekkel, amik automatikusan kezelik a virtualis lapok irasat, olvasasat es feldolgozasat."
    Ehhez még nem kell virtuális proci.

    "Nem, tobbek kozott ezert is szivas bizonyos dolgokat cuda vagy opengl alatt megirni. A gf8800-as nem szereti a dinamikus adatvezerelt elagazasokat. Kezeli oket, de 1/16-od teljesitmennyel. Gyakorlatilag csak 1 branch unit van blokkonkent."
    1. Épp az imént írtad le, hogy a statikus flow controlnál sem jobb a helyzet, szóval azt sem szereti.
    2. Lényegében vehetjük úgy, hogy az R600-nál meg 8 blokkonként van 1, mert úgyis egyszerre működnek (ugyanannak a szálnak az utasításait hajtják végre, 1-5-ösével).

    "Igen, a cell-ek jobban hasonlitanak a hagyomanyos cpu-kra, leginkabb a 60-as evekbol szarmazo pic architekturara, annak is az eredeti formajara. (kis linearis cimter, fix orajeles utasitasok, relativ nagy sebesseg, interleave vegrehajtas, a kulonbseg hogy a cell nem harvard-os, bar az szerintem jobb lenne)"
    Már úgy érted, az SPE-k? Nem tudom, hogy jön ide a PIC (jah, némi távoli hasonlóság van), az SPE-k leginkább SIMD procikra hasonlítanak (illetve x. generációs vektorprocikra).

    "A cell spe-k egyetlen hatranya, hogy altalanos cpu-nak hianyzik beloluk a virtualis memoria kezelese"
    Nem azért hiányzik, mert elfelejtették beletenni. Tudod, valamit valamiért. Az előadáson erről is volt szó. Túl sok tranyóba kerülne (ez is többek között), és akkor szó sem lenne 8db SPE-ről.

    "vliw-es dsp-nek viszont nem eleg szeles az alu-juk."
    Ez miért olyan nagy baj?

    "Valahol az intel fele altalanos cpu-k es az nvidia fele brute force-os buta vektoregysegek kozott vannak."
    Nalátod. Akkor miért állítod be úgy, hogy szinte nem is különböznek az utóbbiaktól?

    "Sem egyik, sem masik. Altalanos logikara jobb a cpu"
    Arra ott van a Cellben a PPE. (De ha szükséges, SPE-n is futhat, scalar adatoknál kb. 1/4 teljesítményen, ami azért még mindig nem olyan rossz.)

    "vektorfeladatokhoz jobb a gpu."
    Ha leginkább csak nyers erő kell, akkor persze jobb a GPU. Más feladatnál nem feltétlenül.

    "A cell-nek pedig maradnak a tudomanyos munkak, legalabbis amig valaki meg nem irja a szukseges virtualizalo forditot"
    Nem igaz, mert már ma is úgy fejlesztik a legtöbb játékot rá, hogy többé-kevésbé igénybe veszik az SPE-ket is! Ezt már aktuális játékfejlesztő is mondta neked, szóval vedd végre tudomásul.

    "(lasd pl. compiled java)"
    Ugh, szóval mégiscsak javát akarsz rá... :DDD Ez az, tizedeljük csak meg a teljesítményét, legalább nem lesz gyorsabb, mint egy sima proci. :P

    "ugyanis jatekok eseten jelenleg minden programozonak fel kell talalnia a spanyol viaszt."
    Ez időről időre amúgy is megtörténik!

    "Ahogy az eloadasban elhangzott, jelenleg sok mindent nem tud a fordito, de a gcc kodja nyilt, megirhatja barki."
    Melyik fordító? A gcc-n kívül még van 2 c(++) fordító Cellre.

    "Ha egy jatekkeszito ceg embereit azzal biztatja az architektura kitalaloja, hogy eloszor irnia kellene egy hasznalhato forditot mielott elkezdene jatekot irni, akkor ez eleg hamar elveszi a kedvet az egesztol."
    Ezek a dolgok könnyítik a munkát, de nem feltételei.

    "Ilyenkor marad a pc, az xbox360 es a wii. Vagy alternativakent csak a power magot hasznalja. Ha egy multiplatform jatekot nem lehet egy altalanos cpu-ra irt koddal megcsinalni, akkor nem eri meg vacakolni egy amugy sem tul nepszeru konzollal. Meg az oskovulet wii-n vagy a ps2-esen is tobbet lehet eladni egy-egy jatekbol. Ha ma valaki jatekot akar irni sony-s konzolra, akkor a ps3 helyett erdemesebb a ps2-re dolgoznia, mert azt legalabb veszik."
    Na, ez meg a már tőled megszokott PS3-bashing bla-bla. :U
    1. Csak a legprimitívebb fejlesztők használják csak a PPE-t. Úgy kell nekik, ki kíváncsi rájuk.
    2. Sok kisebb adatcsomagokkal dolgozó rutin c kódja fordítható minden további nélkül SPE-re.
    3. Nagyobbaknál is sokszor elég egy egyszerű DMA kezeléssel kiegészíteni.
    4. Butaság, hogy népszerűtlen: heti szinten átlagosan ugyanannyit adnak el belőle, mint Xbox360-ból. Csak az utóbbinak van 1 év előnye.
    5. A Wii egy más kategória, nem egyforma a törzsközönsége, mint a másik kettőnek.

    ps. valamiről még megfeledkeztél.

    [ Szerkesztve ]

  • kvp777

    tag

    válasz dezz #68 üzenetére

    Mivel ezt a PS3-mal kapcsolatban is csinálod, ezt már konkrétan FUD-nak nevezhetjük.

    En probalok kedves lenni mindkivel, meg akkor is ha idegesito az illeto. Ez sok embernek sajnos nem sikerul. Egyebkent erdekes, hogy csak a PS3-al kapcsolatban veszed rossz neven a kritikat. Egyebkent amit irok az tobbnyire igaz. Ha esetleg tevednek, akkor korrigalast varnek el nem sardobalast. Ez az alap illem egyik fontos pontja fuggetlenul attol hogy ki mennyire ideges. (egyebkent en pl. miert lennek ideges? nem koltottem a penzem olyan hardverre amit nem tudok hasznalni es minden jatek fut a pcmen amivel jelenleg jatszani akarok)

    "Es szemely szerint en szeretnek standard template library-t hasznalni az spe-ken is. Ha egy texas dsp-n lehet es erdemes, akkor egy cell spe-en miert ne?"
    Nem tudom, most valójában lehet-e vagy sem, mindenestre ez nem egy létszükséglet tudományos és game területen. Javat nem akarsz rajtuk futtatni?

    Az stl keszitoi es elso felhasznaloi a tudomanyos teruletrol jottek. A jatekokat pedig ma mar tobbnyire c++-ban irjak, erosen megtuzdelve objektumorientalt script-ekkel. Mindkettonek feltetele a c++ tamogatasa. (egyebkent a java, a .net es a smalltalk nagyon kenyelmes nyelvek ha konnyen akarunk stabil programot irni)

    Valamit valamiért: 10x-es teljesítmény némi pluszmunkáért cserébe. Ezt a dolgot nem sikerült megértened az előadáson?

    Generacionkent 2x-ezodik a teljesitmeny. Ma a 4 magos cpu-knal jarunk, ez mar eleve 4x-es teljesitmeny. Egy mai x86-os munkaallomas 8 maggal dolgozik. (2x4) A leggyorsabb mai gyarhato hagyomanyos cpu 10Ghz-es, ez az ibm power magos processzora. Kb. ket even belul el elehet erni a mai cell teljesitmenyet, akar igazi technologiai valtas nelkul is, tehat ha ket evnel tovabb tart a program fejlesztese, akkor erdemesebb a jovobeni gyors x86-os cpu-kra dolgozni. (es meg optimalizalni sem kell semmit) Az uj 2 ppe-s, 32 spe-s power gyorsabb lesz es jobb (es vegre rendes ddr-es), de nem lesz annyival jobb, mint mondjuk egy 80 magos intel.

    "Lassuk csak... mondjuk szoftveres read/write cache-ekkel, amik automatikusan kezelik a virtualis lapok irasat, olvasasat es feldolgozasat." Ehhez még nem kell virtuális proci.

    Nem kell, de ha azt hasznalunk, akkor lehet ra irni jit-et es a mai forditoprogramok is tudnak ra dolgozni, arrol nem beszelve hogy a meglevo szoftverek ujraforditas nelkul is futnanak rajta. Keves munka -> sok haszon.

    "A cell spe-k egyetlen hatranya, hogy altalanos cpu-nak hianyzik beloluk a virtualis memoria kezelese"
    Nem azért hiányzik, mert elfelejtették beletenni. Tudod, valamit valamiért. Az előadáson erről is volt szó. Túl sok tranyóba kerülne (ez is többek között), és akkor szó sem lenne 8db SPE-ről.

    Kb. 64 huzalozott komparator regiszter es es par logikai kapu lenne az egesz. (4 KB-os lapok, 64 lapos L1 working set, exception driven software filled tlb) Ez jo esetben is csak par ezer tranzisztor, azaz kb. 500 byte-nyi local store. A 256 KB-hoz kepest nem jelentos. Persze a programozasi stilus nagyon megvaltozna, az spe leginkabb a sun niagara sorozatara hasonlitana.

    "Valahol az intel fele altalanos cpu-k es az nvidia fele brute force-os buta vektoregysegek kozott vannak."
    Nalátod. Akkor miért állítod be úgy, hogy szinte nem is különböznek az utóbbiaktól?

    Programozni ugyanolyan nehez oket.

    "Sem egyik, sem masik. Altalanos logikara jobb a cpu"
    Arra ott van a Cellben a PPE. (De ha szükséges, SPE-n is futhat, scalar adatoknál kb. 1/4 teljesítményen, ami azért még mindig nem olyan rossz.)

    A gf8800-asnal 1/16, ati-n 1/8-ad. Amennyivel jobb egy proci vektorfeladatokra, annyival benabb elagazasos logikanal. Programmed dynamic alu mapping pedig meg nem nagyon van. Azaz van, ha egy xilinx-be ezt tolti az ember. Lehet kapni viszonylag olcson 1 darab power maggal felszerelt, xilinx chipeket. Ezekben ki lehet alakitani annyi es olyan spe-t amilyet az ember megalmodik. Erdekes eredmenyeket lehet kapni vele. 4 ilyen, darabonkent 15 millios fejlesztoi kartyaval mar egesz szep gepet lehet osszehozni. Ha gyartasba kerulne, akkor persze sokkal olcsobban elo lehetne allitani, de ma magyarorszagon inkabb vesznek 100 kartyat 1.5 milliardert, mint hogy egy gyartosoron legyartassak, mert ez meg mindig olcsobb. (a lenyeg hogy szokott mukodni amit a cegnel hazilag osszerakunk) Lehet jobb cpu-kat is kesziteni, mint a cell. En szemely szerint az intel megoldasaban latok nagy jovot, felteve hogy ossze tudjak hozni. De otthon is osszedobtam mar egy-ket cpu-t, alacsony integritasu alkatreszekbol. (lomex-bol vett 20 eve porosodo chipek, prototipus panelen, kezzel forrasztva) A legjobb egy 20 Mhz-es 16 bites skalar cpu lett, bar sajnos nagyon bena az ugyancsak altalam tervezett videokartyaja. (de legalabb van benne linear frame buffer) Viszont szoveges konzol, debugger es 1 azaz egy darab grafikus demo van hozza. :)

    "ugyanis jatekok eseten jelenleg minden programozonak fel kell talalnia a spanyol viaszt." Ez időről időre amúgy is megtörténik!

    A mai nagy cegekre nem jellemzo az innovacio. Az oblivonban pl. csak a script-eket irta a keszito ceg. A terep, a novenyzet, a fizika, az animaciok es az arcmimika is mind keszen vasarolt modulokbol epultek fel. (ezert volt a legtobb bug a script-ekben)

    A wow a legnepszerubb es egyben legkevesbe innovativ mmorpg. A jatekmotor alapja egy mud volt. Csakugy mint ahogy a diablo az open source nethack kodjat kapta, sajnos bugokkal egyutt. (a grafikus motor sajat gyartasu mindket esetben)

    "Ahogy az eloadasban elhangzott, jelenleg sok mindent nem tud a fordito, de a gcc kodja nyilt, megirhatja barki."
    Melyik fordító? A gcc-n kívül még van 2 c(++) fordító Cellre.

    Az ibm forditoja sem tudja a szoftveres smt-t, ami lehetove tenne a kooperativ multitasking-ot spe-n, ami lehetove tenne az external load/store rendszer (dma) rendes kihasznalasat. Igy a legtobb dma muvelet blokkolja az spe-t, a helyett hogy az masik task-ra valtana. A valsz az volt, hogy ha valaki megirja a gcc-hez, akkor berakjak a tobbi forditoba is. Mondjuk en fordito tamogatasa nelkul is meg tudnam irni assembly-ben, de a legtobb jatekot es tudomanyos programot ma mar nem assembly-ben irjak. Egyszeruen nincs ra ido.

    "Ha egy jatekkeszito ceg embereit azzal biztatja az architektura kitalaloja, hogy eloszor irnia kellene egy hasznalhato forditot mielott elkezdene jatekot irni, akkor ez eleg hamar elveszi a kedvet az egesztol."
    Ezek a dolgok könnyítik a munkát, de nem feltételei.

    A mukodo c++ fordito manapsag az egyik alapfeltetele a jatekfejlesztesnek. Sok ceg megtudja, hogy az spe-ken nem lehet objektumorientalt kodot futtatni virtualis memoriaban es inkabb elvetik az spe hasznalatat. (ezert van olyan keves ps3 exkluziv jatek) Ahol hasznaljak ott is tobbnyire az ibm vagy a sony kolcsonadott mernokei kodolnak az spe-kre.

    1. Csak a legprimitívebb fejlesztők használják csak a PPE-t. Úgy kell nekik, ki kíváncsi rájuk.

    Aki jatszani akar, es csak xbox360-ra meg vista-ra jon ki a kedvenc jateka. Az egyikben a hardver, a masikban a szoftver rossz. De mas valasztas nem nagyon van.

    2. Sok kisebb adatcsomagokkal dolgozó rutin c kódja fordítható minden további nélkül SPE-re.

    Igen, vegulis minden el kell hogy ferjen 256Kbyte-ban. Egy mai atlagos 1024x1024-es terkep pedig 1 Mbyte. :-)

    3. Nagyobbaknál is sokszor elég egy egyszerű DMA kezeléssel kiegészíteni.

    Kiveve ha 1 tombben van minden. Ekkor lehet nekiallni atirni mindent. A mai jatekok jo resze nagy tombokben tarolja az adatokat. (lasd terkepek, modellek, texturak, compiled vertex array-k, stb)

    4. Butaság, hogy népszerűtlen: heti szinten átlagosan ugyanannyit adnak el belőle, mint Xbox360-ból. Csak az utóbbinak van 1 év előnye.

    A wii-bol meg tobbet mint a masik kettobol, pedig nem sok elonye van.

    5. A Wii egy más kategória, nem egyforma a törzsközönsége, mint a másik kettőnek.

    Igen, wii-t meg talan en is vennek, bar inkabb halozati medialejatszonak es webbongeszonek. (olcsobb es jobb mint az apple tv) Jatszani inkabb pc-n szoktam. (keves a konzolos mmorpg, strategia es a szabadon moddolhato szerepjatek, pedig en ezeket szeretem)

    ps: Roviden en nem a cell teljesitmenyet vitatom, csak az a velemenyem, hogy nem eri meg faradni azzal, hogy megtanuljuk programozni, mert a ps3 nem akkora piac. Mashol meg nem talalkozik az ember tul gyakran cell-lel. Persze szorakozasbol barki megtanulhatja, vagy azert mert penzt kap erte. Viszont a cegek jo reszenek nem eri meg a faradtsagot es a penzbeli befektetest. Esetleg majd a jovoben, ha mar jobb lesz a tamogatottsaga... de az jelenleg meg messze van.

  • dezz

    nagyúr

    válasz kvp777 #69 üzenetére

    "En probalok kedves lenni mindkivel, meg akkor is ha idegesito az illeto. Ez sok embernek sajnos nem sikerul."
    Nézd, most elsősorban te idegesítesz fel másokat a féligazságok tényként előadásával. Műszaki körökben a féligazság egy kalap alá tartozik a hazugsággal. (Bár máshol is így lenne...)

    "Egyebkent erdekes, hogy csak a PS3-al kapcsolatban veszed rossz neven a kritikat."
    Nem, a kritikát nem. A FUD-ot már igen.

    "Egyebkent amit irok az tobbnyire igaz."
    Hát ez az, hogy ez műszaki fórumokon nem túl nyerő. Amiről nem tudsz pontos infót, arról inkább ne beszélj, találgatásokat ne írj le tényként, stb.

    "Ha esetleg tevednek, akkor korrigalast varnek el nem sardobalast."
    Láttam a HW-n a vitátokat, nem úgy tűnt, hogy nagyon hallgatsz másokra... (Legyenek azok akár játékfejlesztők pl.) Az SG-n sem igazán foglalkoztál a reagálásokkal (nevezetesen ott az enyémeimmel), csak leírtál pár dolgot, aminek kb. a fele volt igaz, aztán szépen továbbálltál - aztán újra.

    "Ez az alap illem egyik fontos pontja fuggetlenul attol hogy ki mennyire ideges."
    Talán nem neked kellene előírni a netes viselkedési szabályokat, hanem a meglévőkhöz kellene alkalmazkodni.

    "(egyebkent en pl. miert lennek ideges? nem koltottem a penzem olyan hardverre amit nem tudok hasznalni es minden jatek fut a pcmen amivel jelenleg jatszani akarok)"
    Akkor miért nem hagyod békén a PS3-at? És miért propagálod állandóan az Xbox360-at? Minek avatkozol bele az egészbe?

    "Az stl keszitoi es elso felhasznaloi a tudomanyos teruletrol jottek."
    És? Matekos munkaállomásokon és szuperszámítógépeken nem éppen az oo-s kódolás dívik, hanem a vektoros.

    "A jatekokat pedig ma mar tobbnyire c++-ban irjak, erosen megtuzdelve objektumorientalt script-ekkel. Mindkettonek feltetele a c++ tamogatasa."
    Ha nem tévedek, ez leginkább a játék-logikára igaz, és azt Cellnél is lehet c++-ban írni, és a PPE-n futtatni.

    "Generacionkent 2x-ezodik a teljesitmeny. Ma a 4 magos cpu-knal jarunk, ez mar eleve 4x-es teljesitmeny."
    Csakhogy ez még koránt sem mainstream, így pl. a játékfejlesztők nem építhetnek erre. Majd még 1-2 év múlva.

    "Egy mai x86-os munkaallomas 8 maggal dolgozik. (2x4)"
    Egy Celles meg 2 Cellel (2 PPE + 16 SPE), ami mat. szám. telj.-ben 6-8x gyorsabb, mint a te 8-magosod. Vagy ott van az IBM QS20-asa, 24db Cellel.

    "A leggyorsabb mai gyarhato hagyomanyos cpu 10Ghz-es, ez az ibm power magos processzora."
    Ez egy igen drága szerver proci, és az egyszerűbb felépítése miatt nem annyival gyorsabb a korábbi Powereknél, amennyivel magasabb az órajele.

    "Kb. ket even belul el elehet erni a mai cell teljesitmenyet, akar igazi technologiai valtas nelkul is, tehat ha ket evnel tovabb tart a program fejlesztese, akkor erdemesebb a jovobeni gyors x86-os cpu-kra dolgozni."
    Nem olyan biztos, mert akkor sem feltétlenül lesz ez mainstream. PS3-ból viszont elég sok lesz addigra. Más területeket illetően, a Cellt is fejlesztik. Adott tranzisztorszámból a Cell mindig jóval többet fog kihozni.

    "(es meg optimalizalni sem kell semmit) Az uj 2 ppe-s, 32 spe-s power gyorsabb lesz es jobb (es vegre rendes ddr-es), de nem lesz annyival jobb, mint mondjuk egy 80 magos intel."
    Viszont a 80-magos Intel sem feltétlenül a lustább programozók álma lesz.
    szerk: ja, és miért is (lenne) jobb a "rendes ddr", mint az XDR? (Nem keversz egyébként valamit? Jelenleg az SCC-ben lehet DDR memvezérlő, másodlagos ramnak, és framebuffernek.)

    "Nem kell, de ha azt hasznalunk, akkor lehet ra irni jit-et es a mai forditoprogramok is tudnak ra dolgozni, arrol nem beszelve hogy a meglevo szoftverek ujraforditas nelkul is futnanak rajta. Keves munka -> sok haszon."
    Futnának, de nem valami gyorsan. Hatékonyabb maradna rendesen az SPE-nek megfelelően kódolni.

    "Kb. 64 huzalozott komparator regiszter es es par logikai kapu lenne az egesz. (4 KB-os lapok, 64 lapos L1 working set, exception driven software filled tlb) Ez jo esetben is csak par ezer tranzisztor, azaz kb. 500 byte-nyi local store. A 256 KB-hoz kepest nem jelentos."
    Nem egészen, mert manapság már alap a memóriavédelem és a virtualizált memóriakezelés.

    "Persze a programozasi stilus nagyon megvaltozna, az spe leginkabb a sun niagara sorozatara hasonlitana."
    Ahhoz egyéb dolgokat is meg kellene változtatni.

    "Programozni ugyanolyan nehez oket."
    Szerintem nem. Úgy tűnik, nem veszel figyelembe jópár megkötést és bonyolítást a GPU-k esetén.

    "A gf8800-asnal 1/16, ati-n 1/8-ad."
    Nem egészen: a scalar adatokkal való műveletvégzés önmagában nem jelent gondot. Abból van gond, ha ezt nem tudod megtenni 8/16 szállal egyszerre.

    "Amennyivel jobb egy proci vektorfeladatokra, annyival benabb elagazasos logikanal."
    Ezért arany középút a 4-way SIMD megoldás, amit pl. az x86-os procik SSE-je is használ, vagy a Powerek VMX-e.

    "Programmed dynamic alu mapping pedig meg nem nagyon van. Azaz van, ha egy xilinx-be ezt tolti az ember. Lehet kapni viszonylag olcson 1 darab power maggal felszerelt, xilinx chipeket. Ezekben ki lehet alakitani annyi es olyan spe-t amilyet az ember megalmodik."
    Hát azért ennek sem végtelen a kapu-száma (és tudtommal nincs kapu szintű fejlett energiagazdálkodás). Kapcsolási sebességben is lassabb.

    "Lehet jobb cpu-kat is kesziteni, mint a cell."
    Rajta.

    "En szemely szerint az intel megoldasaban latok nagy jovot, felteve hogy ossze tudjak hozni."
    Hát igen, az még a jövő zenéje, a Cell meg évek óta létezik.

    "De otthon is osszedobtam mar egy-ket cpu-t, alacsony integritasu alkatreszekbol. (lomex-bol vett 20 eve porosodo chipek, prototipus panelen, kezzel forrasztva) A legjobb egy 20 Mhz-es 16 bites skalar cpu lett, bar sajnos nagyon bena az ugyancsak altalam tervezett videokartyaja. (de legalabb van benne linear frame buffer) Viszont szoveges konzol, debugger es 1 azaz egy darab grafikus demo van hozza."
    Ez dícséretes, de most minek is írtad le? Tudod, aki dolgozik, pl. valamilyen fejlesztő, az az évek alatt összehoz ezt-azt.

    "A mai nagy cegekre nem jellemzo az innovacio. Az oblivonban pl. csak a script-eket irta a keszito ceg. A terep, a novenyzet, a fizika, az animaciok es az arcmimika is mind keszen vasarolt modulokbol epultek fel. (ezert volt a legtobb bug a script-ekben)"
    És ez most hogy jön ide? PS3-on is megteheti (majd) egy cég, hogy kész motort vesz. Viszont a motorfejlesztőknek el kellett sajátítani jópár újdonságot eddig is.

    "Az ibm forditoja sem tudja a szoftveres smt-t, ami lehetove tenne a kooperativ multitasking-ot spe-n, ami lehetove tenne az external load/store rendszer (dma) rendes kihasznalasat."
    Ha így is van, némi asm keretrendszert kell elkészíteni, a többi már mehet sima c-ben.

    "Igy a legtobb dma muvelet blokkolja az spe-t, a helyett hogy az masik task-ra valtana."
    A másik taszk csak az egyik lehetőség, a másik - sűrűn alkalmazott - a dual-buffering.

    "Mondjuk en fordito tamogatasa nelkul is meg tudnam irni assembly-ben"
    Nem vagy egyedül.

    "de a legtobb jatekot es tudomanyos programot ma mar nem assembly-ben irjak. Egyszeruen nincs ra ido."
    Nem is kell az egész kódot asm-ben írni.

    "A mukodo c++ fordito manapsag az egyik alapfeltetele a jatekfejlesztesnek. Sok ceg megtudja, hogy az spe-ken nem lehet objektumorientalt kodot futtatni virtualis memoriaban es inkabb elvetik az spe hasznalatat."
    Sorolnád őket?

    "(ezert van olyan keves ps3 exkluziv jatek)"
    Elsősorban nem ezért.

    "Ahol hasznaljak ott is tobbnyire az ibm vagy a sony kolcsonadott mernokei kodolnak az spe-kre."
    A többség vacak játékokat készít úgyis. Akik normálisabbakat akarnak, azok meg tudják ezt maguk is.

    "Aki jatszani akar, es csak xbox360-ra meg vista-ra jon ki a kedvenc jateka. Az egyikben a hardver, a masikban a szoftver rossz. De mas valasztas nem nagyon van."
    Csúsztatás. A legtöbb multiplatform játék kijön PS3-on is.

    "Igen, vegulis minden el kell hogy ferjen 256Kbyte-ban. Egy mai atlagos 1024x1024-es terkep pedig 1 Mbyte. :-)"
    Az a 3. esetbe tartozik, de van sok 2. eset is.
    Egyébként meg nem feltétlenül 256KB-ban, ha több SPE is dolgozik rajta, akkor annyiszor 256KB.

    "Kiveve ha 1 tombben van minden. Ekkor lehet nekiallni atirni mindent. A mai jatekok jo resze nagy tombokben tarolja az adatokat. (lasd terkepek, modellek, texturak, compiled vertex array-k, stb)"
    Régebbi kódok portolásánál jelentkezik ez a probléma (ami azért többé-kevésbé áthidalható), az új kódokat meg eleve ezt beleszámolva fejlesztik.

    "A wii-bol meg tobbet mint a masik kettobol, pedig nem sok elonye van."
    Ezzel most azt akarod mondani, hogy az Xbox360 is népszerűtlen?

    "Igen, wii-t meg talan en is vennek, bar inkabb halozati medialejatszonak es webbongeszonek. (olcsobb es jobb mint az apple tv) Jatszani inkabb pc-n szoktam. (keves a konzolos mmorpg, strategia es a szabadon moddolhato szerepjatek, pedig en ezeket szeretem)"
    És most itt szerinted milyen relevanciával bír ez?

    "ps: Roviden en nem a cell teljesitmenyet vitatom, csak az a velemenyem, hogy nem eri meg faradni azzal, hogy megtanuljuk programozni, mert a ps3 nem akkora piac."
    1. A PS3 a Cell piacának csak egy része.
    2. Te egy jétékfejlesztői csapat főnöke vagy? Nem? Akkor miért is akarod előírni, hogy mások mivel foglalkozzanak, és mivel ne? Majd mindenki szépen eldönti magának.

    "Mashol meg nem talalkozik az ember tul gyakran cell-lel. Persze szorakozasbol barki megtanulhatja, vagy azert mert penzt kap erte. Viszont a cegek jo reszenek nem eri meg a faradtsagot es a penzbeli befektetest. Esetleg majd a jovoben, ha mar jobb lesz a tamogatottsaga... de az jelenleg meg messze van."
    Hát akkor te ne foglalkozz vele...

    [ Szerkesztve ]

  • kvp777

    tag

    Akkor miért nem hagyod békén a PS3-at? És miért propagálod állandóan az Xbox360-at? Minek avatkozol bele az egészbe?

    Nem propagalom. A velemenyem az, hogy az xbox360 egy jo otlet amit nagyon rosszul rakak ossze. Egy egyszeru es olcso konzol lenne, ami a leheto legjobban hasonlit egy atlag windowsos pc-re, de sajnos annyira olcsora akartak csinalni, hogy kisporoltak belole a rendes hutest. Nem vennek xbox360-at mert rossz a hardvere es zart platform, de ps3-ast sem mert nincsen ra olyan jatek ami miatt nekem szemelyesen megerne, linux alatt meg le van tiltva a 3d gyorsitas. Viszont azt el kell ismerni, hogy az xbox360-as unified memory architecture-je sokkal kenyelmesebb es jobban skalazhato mint a ps3-as 3 fele elkulonitett memoriaja. (local stores, system ram, graphics ram) Nem jobb, hanem kenyelmesebb es konnyebben programozhato. Kevesebb ido alatt tobb jatek irhato ra.

    "Az stl keszitoi es elso felhasznaloi a tudomanyos teruletrol jottek."
    És? Matekos munkaállomásokon és szuperszámítógépeken nem éppen az oo-s kódolás dívik, hanem a vektoros.

    Az stl alapvetoen nem objektumorientalt, a c++-ra azert van szuksege hogy leforduljon, de mivel template gyujtemenyrol van szo, ezert barmilyen adattipusra jo. Egyik kedvenc stl-es komponensem a vector. Ennek hasznalata megfelelo implementacio mellett automatikusan optimalizalt vektoros/simd kodot eredmenyezne a template altal tamogatott muveletekre. Mindezek mellett kellemes dinamikus tomboket biztosit, ami az alap c-ben csak pointer-eken keresztul lehetseges, amik raadasul nem kepesek takaritast vegezni fuggvenybol valo vissztereskor.

    "A jatekokat pedig ma mar tobbnyire c++-ban irjak, erosen megtuzdelve objektumorientalt script-ekkel. Mindkettonek feltetele a c++ tamogatasa."
    Ha nem tévedek, ez leginkább a játék-logikára igaz, és azt Cellnél is lehet c++-ban írni, és a PPE-n futtatni.

    A c++ inkabb a grafikus motorra igaz. Pl. directx-et nem is nagyon erdemes mashogy programozni, mert az api c++-os. Egyszerueb konnyebb directx-re programokat irni, mint opengl-re. Ennek ellenere szerintem az opengl jobb, csak annyival bonyolultabb, hogy a legtobb programozo egyszeruen nem tudja hasznalni.

    ja, és miért is (lenne) jobb a "rendes ddr", mint az XDR?

    Sokkal olcsobb. Az eloadason is ez volt az egyetlen pozitivuma. En szemely szerint inkabb gddr-t raknek a cpu ala is. (mondjuk az xbox360 ezt is teszi, mar amikor eppen nem olvad ki a gpu a nyakbol)

    "Kb. 64 huzalozott komparator regiszter es es par logikai kapu lenne az egesz. (4 KB-os lapok, 64 lapos L1 working set, exception driven software filled tlb) Ez jo esetben is csak par ezer tranzisztor, azaz kb. 500 byte-nyi local store. A 256 KB-hoz kepest nem jelentos."
    Nem egészen, mert manapság már alap a memóriavédelem és a virtualizált memóriakezelés.

    Tehat fogjuk a 256KB lokalis ram-ot. Feldaraboljuk 4KB-os darabokra, minden blokknak adunk egy dedikalt asszociativ regisztert (egy komparatort). Ezutan a cimzes folso nem hasznalt bitjeit rakotjuk a regiszterekre, amiknek a kimeno jelei az adott blokkok enable jeleihez mennek. Ha nincs talalat akkor egy plusz nor kapu trap-et general egy fix cimre az elso blokkban. Igy a 256KB-os local store-t atalakitottuk 64 utas parhuzamos L1 cache-e, aminek 4KB-os a cache line-ja. Egyszerre 64 lap lehet a local store-ban. A lapok tolteset/menteset es a tlb kitolteset az elso blokkban futo kernel vegzi szoftveresen. Indulaskor a lapok a boot blokkra allnak be, mint most a digitalis alairas ellenorzesekor. (tehat ez nem igenyelne ujabb aramkort) Az egesz lehetove tenne, hogy minden cell kaphasson egy 4GB-os virtualis cimteret. Az spe cimtere es a rendszermemoria kozott tovabbra is szoftveresen menne a valtas, de a cimek helyenek ellenorzeset hardveresen oldanank meg. Ez az egyetlen muvelet amit minden cimzeskor el kell vegezni, tehat megeri hardveresen gyorsitani. Minden masra ott lenne a lokalis kernel az egyik blokkban. A vedelem es a strukuralt laptablak jelenleg is szoftveresen futnak pl. a sparc rendszereken. (ok is csak ez a sima tlb-t tettek be, csak mas a cache kiosztasa) A megoldasom masik elonye, hogy ha kesobb kijon egy 512KB-os local store-okkal felszerelt cell, akkor nem kell a kodot ujrairni, mert a blokk kezeles transzparens a kod szamara.

    Ha így is van, némi asm keretrendszert kell elkészíteni, a többi már mehet sima c-ben.

    Sajnos nem, mert a jelenlegi fordito nem tud relocatable kodot gyartani. Hiaba van keretrendszer ha a modulok agyonutik egymas regisztereit es memoriacimeit. Opcio meg nincs hogy megadjuk mettol meddig mehet egy modul. Ez konkretan kereskent elhangzott hetfon. (lasd: feature request)

    Csúsztatás. A legtöbb multiplatform játék kijön PS3-on is.

    Sot meg wii-re is, de jopar olyan van ami csak microsoft rendszerek alatt lesz. (xbox360 es vista) Van egy olyan fogalom is hogy directx exkluziv, amitol meg multiplatform de nem lesz ps3-as verzioja.

    És most itt szerinted milyen relevanciával bír ez?

    Annyival, hogy a kedvenc jatek kategoriaimbol 1 darab jatek sincs ps3 ala. Igy egyszeruen nem lenne mivel jatszani ha vennek egyet. Az emberek nem azert nem veszik mert draga, hanem mert nincs ra eleg jatek.

    Hát akkor te ne foglalkozz vele...

    Csak erdekelnek az uj architekturak, legyenek azok jok vagy rosszak. Eleg sok rendszerre fejlesztek egyszerre, erdemes latni mibol lehet valogatni. Pl. kepfeldolgozashoz a cell nem rossz, de azert ezen a teruleten siman veri a 8 magot egy 16384 alus digitalis cellular neural network processzor. (es azt is lehet kapni)

    Egyebkent azt hiszem ezt a forumtemat magam reszerol lezarom, elegge elment a parbeszed fele, es szvsz. egy forumban nem ket embernek kellene leveleznie.

  • dezz

    nagyúr

    válasz kvp777 #71 üzenetére

    Hát, "lezárod" vagy sem, azért én válaszolok, mert megint elhangzott néhány "érdekes" állítás. Egyébként meg annyian beszélgetnek egy topikban, ahánynak van hozzáfűznivalója.

    "Egy egyszeru es olcso konzol lenne, ami a leheto legjobban hasonlit egy atlag windowsos pc-re"
    Huh, hát ez meg a lehető legtávolabb áll a valóságtól! Ha így lenne, akkor egyfajta HTPC lenne, x86 procival, PC-s architektúrával. Ehhez képest:
    1. x86 proci helyett 3-magos spéci PowerPC, fordított endianess-szel.
    2. Semmi köze a PC-s architektúrához (cpu+ddr main ram+NB[+SB] - AGP/PCIe busz - gpu+vram): unified ram, vram alapon (nagy latency); proci és gpu között nem szabványos busz, stb.
    3. GPU mellett EDRAM.
    4. GPU senem szabványos DX9, senem szabványos DX10, hanem a kettő között.

    Annyi közük van egymáshoz, hogy portoltak rá egy Windows kernelt, és egy DirectX-et. Meg gondolom egy Visual Studiot.

    "de sajnos annyira olcsora akartak csinalni, hogy kisporoltak belole a rendes hutest."
    Nyilván nem szándékos volt, hanem méretezési hiba. Egy kicsivel nagyobb borda semmiség lett volna.

    "de ps3-ast sem mert nincsen ra olyan jatek ami miatt nekem szemelyesen megerne, linux alatt meg le van tiltva a 3d gyorsitas."
    Ez változóban van... A második is. Ugyanis nincs letiltva, csak nincs hozzá API szolgáltatva. [link]

    "Viszont azt el kell ismerni, hogy az xbox360-as unified memory architecture-je sokkal kenyelmesebb es jobban skalazhato mint a ps3-as 3 fele elkulonitett memoriaja. (local stores, system ram, graphics ram) Nem jobb, hanem kenyelmesebb es konnyebben programozhato. Kevesebb ido alatt tobb jatek irhato ra."
    Ez kb. az utolsó szempont etekintetben. A vram alapú unified memory nem fejlesztéskönnyítési megoldás volt, hanem olcsósítási. (Főleg, hogy így a proci magasabb latencyjű memóriával kénytelen dolgozni.) Ráadásul a PC-s fejlesztők is éppenhogy az osztott memóriához vannak szokva.

    "Ennek hasznalata megfelelo implementacio mellett automatikusan optimalizalt vektoros/simd kodot eredmenyezne a template altal tamogatott muveletekre."
    Az IBM Octopiler compilere is képes erre.

    "Mindezek mellett kellemes dinamikus tomboket biztosit, ami az alap c-ben csak pointer-eken keresztul lehetseges, amik raadasul nem kepesek takaritast vegezni fuggvenybol valo vissztereskor."
    Semmiből sem áll megírni, akár makrókkal.

    "A c++ inkabb a grafikus motorra igaz. Pl. directx-et nem is nagyon erdemes mashogy programozni, mert az api c++-os."
    Érdekes logikai bukfenc van itt. Tehát azért kellene Cellre (ill. PS3-ra) c++-os SPE fordító, mert az Xbox360-on DirectX van!?

    "Egyszerueb konnyebb directx-re programokat irni, mint opengl-re. Ennek ellenere szerintem az opengl jobb, csak annyival bonyolultabb, hogy a legtobb programozo egyszeruen nem tudja hasznalni."
    Akik nem tudják használni, normális játékprogramot (ill. motort) sem képesek írni...
    Mellesleg PS3-on egy egyszerűsített, játékorientált OpenGL van.

    "Sokkal olcsobb. Az eloadason is ez volt az egyetlen pozitivuma."
    Akkor meg? Ez csak PC-nél fő szempont, munkaállomásoknál, mini- és szuperszámítógépeknél, és konzoloknál nem. (Utóbbi esetben a megfelelő gyorsaság, tehát a Cell rendes kiszolgálása sokkal fontosabb, mint az ár. DDR2-ből persze 2x annyi lehetne a PS3-ban, de a teljesítményt meg megfelezné.)

    "En szemely szerint inkabb gddr-t raknek a cpu ala is."
    Jó nagy butaság lenne...

    "Tehat fogjuk a 256KB lokalis ram-ot. [...]"
    A leírt megoldás kényelmesebbé tenné a dolgokat, de a teljesítménynek enyhén szólva nem tenne jót.
    "Sajnos nem, mert a jelenlegi fordito nem tud relocatable kodot gyartani. Hiaba van keretrendszer ha a modulok agyonutik egymas regisztereit es memoriacimeit."
    Nem is kell, taszkváltásnál cserélődik az LS tartalom. Vagy te 256KB-on belül akarsz taszkot váltani? Eddig arról beszéltél, hogy egy rutin számára is túl kicsi.

    "(lasd: feature request)"
    Hol?

    "Sot meg wii-re is, de jopar olyan van ami csak microsoft rendszerek alatt lesz. (xbox360 es vista) Van egy olyan fogalom is hogy directx exkluziv, amitol meg multiplatform de nem lesz ps3-as verzioja."
    Jópár meg PS3-exkluzív lesz. És van egy olyan érzésem, hogy ezek jobbak lesznek.

    "Annyival, hogy a kedvenc jatek kategoriaimbol 1 darab jatek sincs ps3 ala. Igy egyszeruen nem lenne mivel jatszani ha vennek egyet."
    Ez a te egyéni szoc. problémád.

    "Az emberek nem azert nem veszik mert draga, hanem mert nincs ra eleg jatek."
    Még1x mondom: átlagosan annyi fogy belőle, mint az Xbox360-ból (bár az utóbbi hetekben megtolta az eladásokat a Halo 3, viszont PS3-ból most jött ki az olcsóbb változat, és még idén jön néhány várt játék). Akkor tehát az Xbox360-at sem veszik?

    "Csak erdekelnek az uj architekturak, legyenek azok jok vagy rosszak. Eleg sok rendszerre fejlesztek egyszerre, erdemes latni mibol lehet valogatni."
    Ezen kicsit túlmutatni látszik az aktivitásod és viselkedésed. Konkrétan mintha fizetett FUD-ügynök lennél. Jelen hsz-ed is csak ezt erősíti.

    [ Szerkesztve ]

Új hozzászólás Aktív témák

Hirdetés