co jsem našel nějaký info tak bsd zatím jen bootuje a víc nic, mě to připadá jako velká škoda, že není nějaký kvalitní os který by využil cell architekturu na ps3 plnohodnotně i když nikdo netuší co všechno sony časem na svém herním os povolí..
Printable View
co jsem našel nějaký info tak bsd zatím jen bootuje a víc nic, mě to připadá jako velká škoda, že není nějaký kvalitní os který by využil cell architekturu na ps3 plnohodnotně i když nikdo netuší co všechno sony časem na svém herním os povolí..
vsak linux to umi vyuzit, nevim, kde je problem ... spis pro to nejsou aplikace, protoze se pro to a) blbe programuje (prodavam jak jsem koupil)Citace:
Původně odeslal Rache
b) je to silene specifickej kus HW ...
Je to bohuzel presne tak, jak rikas, hlavni problem je, ze je to relativne dost novej kousek hw a vyzaduje trosku jinej styl programovani.. ani si nemyslim, ze pro sikovnejsiho programatora by to mel bejt nejakej extra kamen urazu, jenze kdo provozuje IBM bladecluster si potrebnej soft napise a bude si chrochtat jak to slape, ale zcela jiste to nebude sw pro bezny pouziti. A pro ostatni programatory nebude ps3 dvakrat lukrativni platforma, protoze uzivatelska zakladna je titerna a navic je desktop linux na ps3 opravdu linej diky mnozstvi operacni pameti a do budoucna s sebou tudiz dvakrat nic perspektivniho nenese, tak "proc se patlat s prepisovanim kodu pro SPE, kdyz to vlastne ani nikdo nevyuzije.." Prezentuju tady teda jenom svuj soukromej nazor, ale myslim, ze daleko od pravdy nebudu.. ps3 je uzasna masinka, ale je desiva skoda, ze sony nepritlacila na pameti, i na ukor ceny, ja bych si neskonale rad priplatil.. :) ..a btw zrovna vcera se vyjadrili i vyvojari farcry2, ze je ps3 skvelej, ale ze highend pc budou mit grafiku nepatrne lepsi, prave protoze jim chybi na ps3 pamet.. jdu chrapat, dobrou :)
lullu
ještě takovej ot dotaz, když linux používá část hdd na ps3 místo ramky bude znát výměna disku za rychlejší tzn z 5400 na 7200?
..no on na ten disk prachsprostě swapuje :) ..o výměně za 7200rpm jsem uvažoval snad stokrát, ale je to celkem drahej špás na to, že člověk ani neví, jak dostatečně velkej to bude mít v praxi přínos, drobný zlepšení tam ale podle recenzí je.. pokud máš firmware <2.10, tak díky klukům z ps2dev dostaneš v linuxu přístup k 254MB videopaměti, což taky trošku pomůže a pak už mě napadaj takový věci jako i-ram nebo swap na usb flashkách v raidu ..a v poslední řadě ssd hdd, kterej by tomu pomohl asi nejvíc, jenže je zatim neúnosně drahej :( kurnik.. :)
http://gravity.phy.umassd.edu/ps3.html
http://www.smh.com.au/news/articles/...?page=fullpage
16 x PS3 = 400 x PC :)
Na to, ze to je vlastne 486ka (podle Eagla), pro kterou se neda programovat, to neni uplne spatne, ze?
We have done tests of algorithms and Nvidia cards are four to five times faster than the Cell chip, which is 20 times faster than an ordinary high end computer.....
jenze tady tomu nikdo neupira tenhle tezce specifickej druh vykonu. ano, je to vykonny, ale ten vykon je pouzitelnej tak akorat na ty vedecky vypocty. z casti jeste na hry. na normalni pouzivani je to 486ka presne, jak to eagle tvrdil...Citace:
Původně odeslal Petrik
ale vobec nie
3,2ghz je dost vykonu
no a co ze to nema reordering instrukcii, ked pri kompilacii su uz tie instrukcie preusporiadane prave pre tento CPU...
Na bezne pouzitie ten vykon v pohode staci, na velmi specificke veci to ma SPE.
a proc teda apple od powerpc utekl k intelu, kdyz jsou to tak vykony procesory :DCitace:
Původně odeslal THX
Podle mě jedním z klíčových rozhodnutí pro migraci k intelu byla snaha o postupné sesazení microsoftu z jeho jakoby neotřesitelné pozice, protože peníze který dělá na prodeji OS microsoft jsou tak nechutně velký, že nenažranej Jobs má asi taky chuť se do budoucna přiživit, je otázka jestli současná oficiální nemožnost použití osx na jakémkoli intel/amd systému je dána pouze snahou dělat šišky na prodeji "toho správného" rozumí se u applu koupeného hw a nebo je to zapříčiněno širší nekompatabilitou a nevyladěnost systému. Těžko říct co Jobs zamýšlí, ale vzhledem k tomu jakým způsobem je u applu všechno zpoplatněno nějaká velká konkurence mrkvosoftu nehrozí..
A proto je Pentium 4/Celeron "dost výkonné" CPU, jo?Citace:
Původně odeslal THX
dobrý vtip. Touto logikou by to znamenalo, že ve všech moderních CPU je out of order naprd, akorát žere zbytečně elektřinu, produkuje teplo, a snižuje výkon úplně zbytečně, protože by stačilo "líp to zkompilovat".Citace:
Původně odeslal THX
Mimochodem, posílal jsem tuhle diskusi kamarádovi, který studuje defacto návrh procesorů, a za rok jede do německa dělat doktorát, u kterého se bude podílet na vývoji CPU pro IBM, a dost se rozčilil, že je tahle diskuse hodně mimo ;). SPE prý chybí cache a podpora multithreadingu, a random acces přístupy do paměti jsou peklo se zpožděním v řádu stovek cyklů
na beznu pracu (=filmy, browsenie, mail etc.) ano. Doma mi na to staci 1700+ athlon v pohode.Citace:
Původně odeslal Keymaster
pozri, aj novy power procesor od IBM siel cestou vyssej freq. a zjednodusenia cpuCitace:
dobrý vtip. Touto logikou by to znamenalo, že ve všech moderních CPU je out of order naprd, akorát žere zbytečně elektřinu, produkuje teplo, a snižuje výkon úplně zbytečně, protože by stačilo "líp to zkompilovat".
rozdiel vo svetoch win + x86 a linux/ine platformy je v tom, ze v x86 win svete sa robia procesory pre uz existujuce programy (ktore sa nerekompiluju - a preto robi reordering sam CPU), kdezto v lin. si mozes skompilovat program priamo na mieru konkretneho cpu a teda mozes spravit reordering (mozes presunut logiku z cpu do kompilera)
zaujimave, ale...Citace:
Mimochodem, posílal jsem tuhle diskusi kamarádovi, který studuje defacto návrh procesorů, a za rok jede do německa dělat doktorát, u kterého se bude podílet na vývoji CPU pro IBM, a dost se rozčilil, že je tahle diskuse hodně mimo ;). SPE prý chybí cache a podpora multithreadingu, a random acces přístupy do paměti jsou peklo se zpožděním v řádu stovek cyklů
SPE nema cache schvalne. pretoze u cache nevies povedat ci budes mat dane data dostupne alebo nie, preto ma kazda spe 256kilo lokalnej pamate (pozor, nie je to cache!), kde kompiler v kazdom jednom okamihu vie co presne ma v tej lokalnej on chip pamati a kolko taktov bude trvat precitanie a zapis a teda moze robit reordering instrukcii...
to uz bolo 1000x rozoberane, ale slo tam napr. aj o dostupnost, cenu HW - a ano, aj max. vykon...Citace:
Původně odeslal Fox!MURDER
Promin, ale jestli ten tvuj kamarad rika, ze SPE chybi cache, tak IMHO patrne vubec nepochopil, jak Cell funguje a co to je SPE. V IBM mu to zrejme vysvetli. Jak to chapu ja, tak SPE je jakovy maly samostatny procesor, ktery ma misto bezne pomale DRAM operacni pamet typu SRAM 256kB, takze zadnou cache nepotrebuje, protoze neni co cachovat.
Citace:
Původně odeslal Keymaster
Převod CD (22 skladeb) na C2D E4500@2,53+2GB/800 na mp3 320kBit trvalo 8m15s stejné cd nastavené na stejnou kompresi trvalo přímo v herním menu PS3 4m59s, výsledný soubor na pc měl 176MB na PS3172MB. Škoda, že nejde přímo na ps3 bez linuxu převést dvd na divx... Pro lepší porovnání použiju vícero softů a různý bitrate a postnu výsledky.
spis najit soft, co v tom linuxu vyuzije spe :) to by pak ficelo hodne hezky :)Citace:
Původně odeslal Rache
To jsou ponekud strohe informace - musel by byt pouzit stejny kodek a stejne nastaveni, aby byl vysledek porovnatelny.
Mne foobar na C2D 3,15GHz prevadi jedno hudebni CD z FLAC do MP3 Lame V0 kolem jedne minuty, quadcore by na to byl jeste vyrazne lepe, foobar totiz enkoduje tolik songu naraz, kolik jader mas.
to byl prvni nastrel ,vecer si s tim pohraju dukladne dejte navrh jaky konkretni soft pouzit.
mas na tom linux? docela by me zajimalo, jak funguje ten ibmackej octopiler :-)Citace:
Původně odeslal Rache
mám na tom ydl 6.0 ale jsem linuxová nula s žádnýma znalostma, vyloženej klikač :-) takže ti toho asi moc neprozradím leda bys měl náladu se stavit osobně a pohrát si s tím - alespoň bych něco pochytil :-D
No, ten compiler jsem nijak nestudoval, takze jsou to jenom moje domnenky, ale nerekl bych, ze compiler nejakym zpusobem spravuje tu lokalni pamet. Spis bych tipoval, ze je starosti programatora, aby se postaral o to, ze v lokalni pameti budou potrebna data.Citace:
Původně odeslal THX
No, tvrzeni "chybi mu cache" a "nema cache, protoze na typicke ulohy ji nepotrebuje" mi prijdou ekvivalentni. Obcas by na tom clovek proste rad provozoval veci, na ktere by se cache hodila.Citace:
Původně odeslal Petrik
SRAM neni o nic mene bezna nez DRAM. A jinak ta rychlost neni tim, ze je to SRAM, jako spis tim, ze je ta pamet tak mala. DRAM o stejne velikosti by mela +/- stejnou rychlost. SRAM ma hlavne tu vyhodu, ze neni potreba ji neustale refreshovat, takze se ti nemuze stat, ze se do ni zrovna chvilku nedostanes, protoze se ji kus obnovuje.
Neviem ake presne moznosti ponuka programatorovi, mozno skutocne mozes si sam nahravat data do tej pamate, ale to je programovanie na este nizsej urovni ako povedzme C, prakticky skoro v zdrojovom kode.Citace:
Původně odeslal Ryuu
Vdaka tomu ze je znama rychlost (pocet taktov na pristup, citanie, prepis atd.) do tej lokalnej pamate, tak moze kompiler robit nielen preusporiadavanie instrukcii, ale napr. aj prefetching dat. Ked pises program v C, tiez nerozhodujes na ktorej adrese presne v pamati chces mat ulozene dane data, o to sa stara kompiler. Podobne aj tu, proste napises zdrojak a ostatne nechas na kompiler.
Cim "deterministickejsi" je procesor pre ktory kompilujes, tym viac funkcionality mozes presunut z CPU do kompilera, viz. napr. uz spominany reordering, prefetching. Takto zjednodusis samotny procesor, znizis jeho cenu, mozes dosahovat vyssie freq. (viz 45nm cell ktory bezi snad na 4,5ghz - tiez viz power6 ktore su na tom podobne a tiez sli cestou "determiniziacie" a vyssich freq. - a myslim ze IBM vie velmi dobre co robi a na co sa ich procesory pouzivaju).
No, nevim jak ty, ale ja zdrojovy kody pisu naprosto bezne. Tak nejak po pravde si skoro ani nedokazu predstavit programovani bez toho :o)Citace:
Původně odeslal THX
Ale ted vazne. Nejak nechapu tu poznamku o nizsi urovni nez je C. Ccko ti umoznuje libovolne low nebo high level pristup, jak zrovna potrebujes. Rekl bych, ze zrovna tohle je jedna vec, kterou by nebylo uplne nejlepsi nechavat na prekladaci. Preci jen programator vi mnohem lip nez prekladac, ze ted se zrovna chysta pracovat s temihle daty a za chvilku bude potrebovat zase tamhleto.
Samozrejme, muze na to byt nejake higher level API, ktere se bude poloautomaticky samo starat o to, aby byla v pameti potrebna data. Spis bych to ale videl tak, ze si proste alokujes kus hlavni pameti, kus lokalni pameti a pak si budes mezi nimi presunovat data podle potreby.
At tak a nebo tak, tohle nevyresime, dokud se nekdo z nas nepodiva do dokumentace toho jejich uzasneho compileru. Jsem na to moc linej, takze to asi budu resit tim, ze se zkusim poptat par lidi, co s CELLem u nas neco delaji :o)
Ziadne higher level API, ale skor lower level. O to ci tam tie data mat budes alebo nie sa velmi starat nemusis, pretoze kompiler vidi nie na 100 instrukcii dopredu ako CPU, ale ak chce tak aj na 10000 instrukcii dopredu a tak vidi ze kedy budes potrebovat tie data a moze ich teda prefetchovat. 256k je dost mala pamat, jej zaplnenie trva pomerne malo taktov. Ak teda pozera prekladac minimalne tento pocet taktov dopredu, tak potom si moze byt isty, ze sa mu nikdy nestane ze bude cakat za plnenim lokalnej ram (samozrejme - ak dokaze preusporiadat (coho je podmienkou ze tam budu take) instrukcie tak aby mal co robit CPU kym sa mu nacitaju data). Samozrejme to sa nie vzdy da a tak verim ze programator moze tiez urcit co a kedy v tej pamati bude mat - a to je napr. dalsia vyhoda oproti cache. Teda - pri kompilacii kompilerom sa ta pamat pouzije prinajhorsom rovnako ako cache, ale je tu dost dobra moznost omnoho lepsieho vyuzitia.
btw. cim vyssie higher level funkcie v c pouzijes, tym menej vies napr. co kde kedy a kolko tie funkcie v ram citaju; higher level = napr. regexp matching a zlozitejsie
to je vsechno nadherny, az na to, ze by se ten kod nesmel vubec vetvit a vstupni data pro jedno SPU by nemohla zaviset na vystupnich datech jinych PPE/SPU ... pak vsechny tyhle vyhody jdou do haje ....Citace:
Původně odeslal THX
kompiler taky neni vsemocnej. imo by nejlepsi reseni byla kombinace obou pristupu - reordering/cache ala x86 a zaroven SRAM/compiler based optimizace ala cell ... jenze to je az moc narocny na vyvoj ...