Az Intel fejleszti a PlayStation 4 chipjét?
Oldal 1 / 2Következő →
Jelentkezz be a hozzászóláshoz.
#80
(És a te szemszögedbõl jogosan.)
#79
Ha egy program összetett számításokat végez a memóriában lévõ adatokkal, akkor azokat általában nem szépen sorban egymás után olvassa be és írja ki, hanem külsõ, a program mûködését nem ismerõ szemlélõ számára rendszertelenül, látszólag véletlenszerûen.
Innen származik a RAM, azaz a Random Access Memory neve is: véletlenszerûen is írható/olvasható.
ps. nem téged nevettelek ki, hanem hogy milyen õszinte csodálkozással kérdeztél rá. 😊
Innen származik a RAM, azaz a Random Access Memory neve is: véletlenszerûen is írható/olvasható.
ps. nem téged nevettelek ki, hanem hogy milyen õszinte csodálkozással kérdeztél rá. 😊
#78
kifejtenéd egy kicsit bõvebben?
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
#77
<#hehe>
Véletlenszerû. Itt úgy mint: nem pl. sorban jövõ.
Véletlenszerû. Itt úgy mint: nem pl. sorban jövõ.
#76
"-rendszerszo alapu veletlen memoria eleres a teljes rendszermemoriara"
mire jó, ha valami véletlen történik? nem az lenne a dolga, hogy azt csinálja amit a programozók akarnak? ki akarna egy olyanra programozni, ami véletlen csinálja a dolgokat?
mire jó, ha valami véletlen történik? nem az lenne a dolga, hogy azt csinálja amit a programozók akarnak? ki akarna egy olyanra programozni, ami véletlen csinálja a dolgokat?
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
#75
Azért annyit írnék, hogy szerintem x86 asm-ben kevés lenne 47 byte. Szerintem inkább valamilyen 8-bites gépre készült (ahol 1 byte 1 utasítás).
#74
Na jó, ezt elhamarkodtam. Vedd úgy, hogy nem szóltam.
#73
Húúú és hááá... Tök jó, hogy ismersz néhány C-s függvényt. Csak tudod, 512 bájtban kicsit összetettebb dolgokat is össze lehet hozni egy hello worldnél.
#72
No offense, de jobb is, mert ha a #68-asból nem értettél, akkor semmibõl.
#71
"De most itt nem is ez a lényeg, hanem hogy igenis lehetséges 47 bájton megírni egy kezdetleges snake-szerûséget."
Vegiggondoltam es igen lehetseges es valoszinuleg dos-os com file lesz assembly-ben irva. Anno en is csinaltam 512 byte-ban (egy bootsector merete) operacios rendszer szeruseget egy versenyre. (realtime multitaszk kezeles, szoveges konzol, szabvany fuggvenykonyvtar /fork(), exit(), getc(), putc(), stb./, minimalista shell, egy hello world program, stb.) Megnyertem. :-) Eleg regen volt, azota neha ujra meg-meg rendezik a versenyt, hatha valakinek eszebe jut valami uj dolog es evrol evre eleg erdekes eredmenyek szuletnek.
Vegiggondoltam es igen lehetseges es valoszinuleg dos-os com file lesz assembly-ben irva. Anno en is csinaltam 512 byte-ban (egy bootsector merete) operacios rendszer szeruseget egy versenyre. (realtime multitaszk kezeles, szoveges konzol, szabvany fuggvenykonyvtar /fork(), exit(), getc(), putc(), stb./, minimalista shell, egy hello world program, stb.) Megnyertem. :-) Eleg regen volt, azota neha ujra meg-meg rendezik a versenyt, hatha valakinek eszebe jut valami uj dolog es evrol evre eleg erdekes eredmenyek szuletnek.
Ja, az ilyet én is szeretem 😄
#69
Most írtam egy hosszú választ neked, képpel, erre azt írja, hogy képfeltöltésrõl nem engedélyezett képet feltölteni, de nem ám valami kis nyamvadt JavaScripttel figyelmeztetne, nem, hanem megvárja amíg elküldöm, hogy a hsz-m tartalma odavesszen!
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
De mint mondtam, ezek nem videók, hanem animációk. A videó tényleg 2d-s képek halmaza, viszont az animáció (legalábbis amire én most használom ezt a szót) egy vagy 2d-s, vagy 3d-s térben mozgó virtuális kamera által adott kép, amit a gép valós idõben renderel. (ezért a készülõ képkockák sora soha nem lesz teljesen azonos, mivel nem mindig ugyanakkor készülnek.)
A gép számára 3d-s dolgot azért vettem bele, mert itt kekeckedtél ezzel a "gyakorlatilag minden 2d, mivel a képernyõn jelenik meg"-dologgal. Ebbõl a szempontból számunkra tényleg 2d-s a monitor miatt, viszont az imént említett "virtuális kamera" egy 3d-s virtuális térben mozog, tehát a gép szempontjából 3d-s a cucc. Ennyi erõvel a világ is lehetne 2d-s, mivel mi annak látjuk, ha nem mozog a szemünk...
És azért nem mindegy a gép és a program mérete szempontjából, hogy 2, vagy 3d-s-e a program, mert a 3d nem csak abból a pixelhalmazból áll, ami a monitoron megjelenik, hanem hanem a falakat és a tárgyakat formáló testekbõl, amiknek le kell írni 3d-ben a kiterjedését, illetve az õket borító textúrákból, amik összmérete nagyobb, mint 2d-ben, mivel a teljes felület mérete is nagyobb. Amúgy ha videó lenne, nagyobb lenne az egész.
De most itt nem is ez a lényeg, hanem hogy igenis lehetséges 47 bájton megírni egy kezdetleges snake-szerûséget.
A Free rider pedig a gépnek 2d-s marad, mivel tök más eljárással éri el a 3d hatást, de ez bonyolultabb és lusta vagyok kiwikipédiázni, fejbõl meg csak úgy nagyon kábé tudom. A lényeg kb. hogy nem áll össze a gépnek egy elõtöltött 3d-s virtuális tér, hanem csak 2d-s képeket számolgat tök máshogy, ezzel az eljárással ennél komolyabb grafika nem is lenne elérhetõ. De pl. egy mai 3d-s FPS a gép számára is 3d-s, mert ott van ilyen tér, de hagyjuk, mert kezdek szerintem belekavarodni, meg különben se szeretem az ilyen okoskodást, fõleg ha nekem kell...
Bocs, ha bonyolult voltam, ha nem érted, kérj meg valami nálam okosabbat, hogy elmagyarázza, én ennél értelmesebben nem tudom sajnos.
A gép számára 3d-s dolgot azért vettem bele, mert itt kekeckedtél ezzel a "gyakorlatilag minden 2d, mivel a képernyõn jelenik meg"-dologgal. Ebbõl a szempontból számunkra tényleg 2d-s a monitor miatt, viszont az imént említett "virtuális kamera" egy 3d-s virtuális térben mozog, tehát a gép szempontjából 3d-s a cucc. Ennyi erõvel a világ is lehetne 2d-s, mivel mi annak látjuk, ha nem mozog a szemünk...
És azért nem mindegy a gép és a program mérete szempontjából, hogy 2, vagy 3d-s-e a program, mert a 3d nem csak abból a pixelhalmazból áll, ami a monitoron megjelenik, hanem hanem a falakat és a tárgyakat formáló testekbõl, amiknek le kell írni 3d-ben a kiterjedését, illetve az õket borító textúrákból, amik összmérete nagyobb, mint 2d-ben, mivel a teljes felület mérete is nagyobb. Amúgy ha videó lenne, nagyobb lenne az egész.
De most itt nem is ez a lényeg, hanem hogy igenis lehetséges 47 bájton megírni egy kezdetleges snake-szerûséget.
A Free rider pedig a gépnek 2d-s marad, mivel tök más eljárással éri el a 3d hatást, de ez bonyolultabb és lusta vagyok kiwikipédiázni, fejbõl meg csak úgy nagyon kábé tudom. A lényeg kb. hogy nem áll össze a gépnek egy elõtöltött 3d-s virtuális tér, hanem csak 2d-s képeket számolgat tök máshogy, ezzel az eljárással ennél komolyabb grafika nem is lenne elérhetõ. De pl. egy mai 3d-s FPS a gép számára is 3d-s, mert ott van ilyen tér, de hagyjuk, mert kezdek szerintem belekavarodni, meg különben se szeretem az ilyen okoskodást, fõleg ha nekem kell...
Bocs, ha bonyolult voltam, ha nem érted, kérj meg valami nálam okosabbat, hogy elmagyarázza, én ennél értelmesebben nem tudom sajnos.
#67
Naszóval. Egy video az sok kép halmaza. Egy (azaz 1 darab) kép az lehet 3D? Ha igen, akkor honnantól számít annak, ha nem, akkor miért nem? Vagy 3D-nek, legalább két két számít, amiknek van olyan részük, amik fedik egymást? (pl.: szem)
És mi az, hogy nem nekem számít 3D -nek, hanem a gépnek? Hogyhogy a gépnek? A gép az egy csomó fém meg mûanyag cuccos, amiben áram, meg nem áram váltakozik. Hol van ebben a 3D?
Meg biztos ismered a Free Rider (1) nevû Flash játékot. Ott rá lehet kapcsolni a kockára, és akkor ilyen szép lesz, na, az 3D, vagy nem?
Kérlek definiáld nekem egy kicsit a 3D-t, hogy mit jelent számodra!
És mi az, hogy nem nekem számít 3D -nek, hanem a gépnek? Hogyhogy a gépnek? A gép az egy csomó fém meg mûanyag cuccos, amiben áram, meg nem áram váltakozik. Hol van ebben a 3D?
Meg biztos ismered a Free Rider (1) nevû Flash játékot. Ott rá lehet kapcsolni a kockára, és akkor ilyen szép lesz, na, az 3D, vagy nem?
Kérlek definiáld nekem egy kicsit a 3D-t, hogy mit jelent számodra!
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
http://www.strille.net/works/snake_game_1Kb.php - ez egy 746 byteos snake játék flashben (=qrva sok fölösleges információval dúsítottan) megírva, és lehet benne almákat is gyûjteni, nõni és meghalni, illetve a pontjaidat is számolja. (A 47 byteos, gépi kódban (fölösleges infók nélkül) megírt progiban csak menni lehet)
Úgy hogy ezek nem igazi videók, hanem olyanok mint pl. a 3dmark, tehát egy valós idõben renderelt animáció, tehát olyan mint egy játék, csak nem te irányítod, hanem magától megy. És nem a Te szempontodból kell nézni a 2d-3d-t, hanem a gép szempontjából, azaz, hogy a megjelenített virtuális tér 2, vagy 3 dimenziós-e. És itt pl. a 66-os "searchlight" és a 99-es neon station is 3d-sek. Hogy ha ez így nem érthetõ, akkor nem tudok mit csinálni...
#64
Királyi többes.
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
#63
Ja, és egyébként ki az a "mi"? "Én és a kisöcsém"?
#62
LOL2.
#61
kérlek fejtsd ki nekem, hogyan lehet egy video 3d.
gyakorlatilag minden 2d, mivel a képernyõn jelenik meg. azokat a játékokat szoktuk 3d-nek hívni, amelyekben 4 - nél több irányba mozoghatunk.
gyakorlatilag minden 2d, mivel a képernyõn jelenik meg. azokat a játékokat szoktuk 3d-nek hívni, amelyekben 4 - nél több irányba mozoghatunk.
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
Ja, viszont ezek a "sima videók" színes-szagos-zenés-háromdések, textúrával, az a "játék" (ha lehet annak nevezni, mert célja nincs, csak menni lehet) meg monokróm programozott brushos kétdés hangtalan. Ráadásul ezeknél a vidiknél csak a 256 bájtos célméretet kell betartani, ott meg minél kisebbre kellett, szóval lehet hogy ezeket a vidiket még kisebbre is lehetne.
Attól, hogy a mai stúdiók elfelejtették hogyan kell optimalizálni és nem férnek fel egy játékkal a dupla rétegû blue-ray lemezre (végülis csak 50 gigás), lehet kis méretben is durva dolgokat írni...
Attól, hogy a mai stúdiók elfelejtették hogyan kell optimalizálni és nem férnek fel egy játékkal a dupla rétegû blue-ray lemezre (végülis csak 50 gigás), lehet kis méretben is durva dolgokat írni...
#59
#58
LOL.
#57
szerintem egy interaktív játék sokkal komolyabb mint egy sima videó...
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
Az a Te dolgod 😉
De ha hitetlenkedsz, nézd meg csak az 53-mas kommentet, azok sokkal komolyabb progik. Ez csak annyi volt, hogy egy kígyóval lehet menni körbe-körbe...
De ha hitetlenkedsz, nézd meg csak az 53-mas kommentet, azok sokkal komolyabb progik. Ez csak annyi volt, hogy egy kígyóval lehet menni körbe-körbe...
#55
"Ezt látszik megerõsíteni a Sony részérõl elhangzott nyilatkozat: a Sony Europe egyik reprezentánsa a TechRadar magazinnak adott interjúban kijelentette, hogy ez színtiszta fikció, mégpedig az eddigi legjobb a Gyûrûk Ura megjelenése óta."
Nem is, a Gyûrûk Ura sokkal jobb fikció, mint ez!
Nem is, a Gyûrûk Ura sokkal jobb fikció, mint ez!
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
#54
nem hiszek neked!
,,Boldogok, akik üldözést szenvednek az igazságért, mert övék a mennyek országa.\" //INRI
#53
van egy muveszeti szubkultura, amit demoscenenek hivnak. ezen belul van 1 agazat, amiben 256 bytenal nem nagyobb programok szerepelnek. itt is lehet latni erdekes dolgokat:11, 22, 33, 44, 55ez magyar, 66, 77, 88, 99, 00. (par kedvenc, download, kitomorites utan kapjuk meg a foleg 256 bytos futtathato comokat, kilepes esc). ezek a programozok is nagy altalanossagban a jatekfejlesztes kornyeken dolgoznak. egy magyar vonatkozasu link, function. itt pl. tobbek kozott ps3-ra irt ilyen muveszeti iranyu alkotassal ill. a keszitoikkel is lehetett talalkozni, sot a bufeben a szoni juropnal dolgozo programozoval is lehetett szidni v. dicserni (nemi sor mellett) a ps3 adottsagait.
hopp, el..sztam a linket, a végén az a #cite_note-os rész nem kell😊 (a historynál van ez amúgy, ha vkit érdekel)
"An early patent version of the Broadband Engine was shown to be a chip package comprising four "Processing Elements," which was the patent's description for what is now known as the Power Processing Element. Each Processing Element contained 8 APUs, which are now referred to as SPEs on the current Broadband Engine chip. Said chip package was widely regarded to run at a clock speed of 4 GHz and with 32 APUs providing 32 GFLOPS each, the Broadband Engine was shown to have 1 teraflop of raw computing power. This design was fabricated using a 90 nm SOI process." - http://en.wikipedia.org/wiki/Cell_(microprocessor)#cite_note-xbit-65-12
OK, ez csak elvi és csak valami béta verzió, de ott van az 1TFLOPs 😉 (amúgy eléggé pletyis forrásból szedtem azt az értéket, de ezt asszem mondtam is)
OK, ez csak elvi és csak valami béta verzió, de ott van az 1TFLOPs 😉 (amúgy eléggé pletyis forrásból szedtem azt az értéket, de ezt asszem mondtam is)
Szegedi egyetemen volt olyan, hogyha az addigi rekordnál kisebb méretben megírtad a snake-t (az a nokiás játék ugye), akkor 5-ös lett a féléved és nem kellett vizsgáznod. (Infótanárom mesélte)
Ezt a szokást akkor szüntették be, mikor valaki megírta 47 bájton (igen), és a tanár kijelentette, hogy ennél kisebbe nem lehet. Szóval van még hova optimalizálni... 😛
Ezt a szokást akkor szüntették be, mikor valaki megírta 47 bájton (igen), és a tanár kijelentette, hogy ennél kisebbe nem lehet. Szóval van még hova optimalizálni... 😛
#49
"Joval tobb mint 2-3 SD-s ablakot es pakolgatas nelkul. A pakolgatos demo egy masik volt. A HD video akkoriban meg nem volt tul ismert."
persze, mert akkoriban nem is volt hd video ugyanis azt 1998ban kezdték kidolgozni 😄
a beboxot meg 1996ban fejezték be😄
persze, mert akkoriban nem is volt hd video ugyanis azt 1998ban kezdték kidolgozni 😄
a beboxot meg 1996ban fejezték be😄
Just avoid to falling into the hands of terrorists.
#48
"Itt senki nem a potencialis teljesitmenyt vonja ketsegbe, hanem azt hogy valaha is lesz valakinek annyi felesleges penze, hogy olyan jatekok keszuljenek, amik rendesen kihasznaljak a konzolt. Ennel mar az is jobban megeri, ha inkabb a masik 3 elterjedt platformra dolgozik a fejlesztocsapat. (xbox360, wii, pc) Hamarabb keszen lesznek, tobb peldanyt tudnak eladni es sokkal olcsobb programozokat kell csak felvenni. A jelenleg megtalalhato hatalmas meretu ingyenes algoritmus konyvtarakrol nem is beszelve, amik szinte kivetel nelkul a hagyomanyos Neumann architekturara keszultek, ezert a cell spe-jein csak modositasok vagy ujrairas utan hasznalhatoak."
Momentán a Sony-nak van 20-25 fejlesztõ stúdiója, folyamatosan toborozza a kis kreatív, kezdõ, de ambíciózus csapatokat (lásd MediaMolecule), szal nem kell attól félni, hogy a PS3 progik nélkül marad.
A generációs siklus elején tökéletesen igazad volt, csakhogy a konzolmûfaj nem arról szól, hogy 2-3 évenként új technológia jön, aminél követelmény a könnyû programozhatóság, mert ez alatt az idõ alatt úgy sem ismeri ki magát rajta a kóder igazán, ergo felesleges is bele mélyednie.
Amit érdemnek tartasz, az a hajszolt technológiai fejlesztés következtében általánosan fellépõ a programozói kultúrában megmutatkozó hanyatlás. Szerencsére ettõl a konzolok zárt architektúrájuk lévén többé kevésbé mentesek.
Max a multiplatform játékok viszonylag silány minõségén tettenérhetõk.
Momentán a Sony-nak van 20-25 fejlesztõ stúdiója, folyamatosan toborozza a kis kreatív, kezdõ, de ambíciózus csapatokat (lásd MediaMolecule), szal nem kell attól félni, hogy a PS3 progik nélkül marad.
A generációs siklus elején tökéletesen igazad volt, csakhogy a konzolmûfaj nem arról szól, hogy 2-3 évenként új technológia jön, aminél követelmény a könnyû programozhatóság, mert ez alatt az idõ alatt úgy sem ismeri ki magát rajta a kóder igazán, ergo felesleges is bele mélyednie.
Amit érdemnek tartasz, az a hajszolt technológiai fejlesztés következtében általánosan fellépõ a programozói kultúrában megmutatkozó hanyatlás. Szerencsére ettõl a konzolok zárt architektúrájuk lévén többé kevésbé mentesek.
Max a multiplatform játékok viszonylag silány minõségén tettenérhetõk.
Histeria est magistra vitae. Ez nem trollkodás, ez online graffiti! ;) https://suno.com/@nexus65ongs
#47
"Active GPUs are defined as those which have returned WUs within 10 days (due to the shorter deadlines on GPU WUs). Active PS3's are defined as those which have returned WUs within 15 days."
Ezen kívül erõsen valószínûsíthetõ, hogy a PC-k sokkal többet vannak bekapcsolva, és a kliens akkor is futhat, ha a user netezik, stb. A PS3-akat viszont nem járatják egész nap, de ha 15 napon belül egyszer is futhat 5 percet a kliens, akkor máris aktívnak számít.
Ezen kívül erõsen valószínûsíthetõ, hogy a PC-k sokkal többet vannak bekapcsolva, és a kliens akkor is futhat, ha a user netezik, stb. A PS3-akat viszont nem járatják egész nap, de ha 15 napon belül egyszer is futhat 5 percet a kliens, akkor máris aktívnak számít.
#46
"How should the FLOPS per client be interpreted?
We stress that one should not divide "current TFLOPS" by "active clients" to estimate the performance of that hardware running without interruption. Note that if donors suspend the FAH client (e.g. to play a game, watch a movie, etc) they enlarge the time between getting the WU and delivering the result. This in turn reduces the FLOPS value, as more time was needed to deliver the result."
1 TFLOPS-t tényleg nem fogunk látni a Celltõl (csak a Cell2-tõl), de a 200 GFLOPS peak-et megközelítõ értékeket már láthattunk a gyakorlatban is.
We stress that one should not divide "current TFLOPS" by "active clients" to estimate the performance of that hardware running without interruption. Note that if donors suspend the FAH client (e.g. to play a game, watch a movie, etc) they enlarge the time between getting the WU and delivering the result. This in turn reduces the FLOPS value, as more time was needed to deliver the result."
1 TFLOPS-t tényleg nem fogunk látni a Celltõl (csak a Cell2-tõl), de a 200 GFLOPS peak-et megközelítõ értékeket már láthattunk a gyakorlatban is.
#45
Hát a netnek a semmi köze a számoláshoz ugyebár, másrészt ameddig senki nem bizonyitja, hogy annyi amennyi akkor addig csak fikció nem? Mint ahogy irtam is, hogy elméletben lehet, gyakorlatban meg még nem láttuk.-
Hülyékkel vitázni olyan, mint egy galambbal sakkozni. Ledönti a bábukat, rászarik a táblára, aztán boldogan ugrál, hogy ? nyert. http://www.vinylnirvana.hu
#44
Ja, és az 1 hsz egyszerre/user rendszert sokkal pörgõsebb fórumokra találták ki. Itt viszont nem okoz gondot (hacsak nincs valami fóbiád), hogy az az "egy hsz" egy nagy blokkból áll, vagy több kisebbõl, amik legalább egyenként meg vannak címezve, és egy kattintással visszakövethetõ minden... Az sokkal idegesítõbb, hogy te mindenféle jelzés nélkül idézgetsz mindenhonnan, nem gondolod?
#43
"Joval tobb mint 2-3 SD-s ablakot es pakolgatas nelkul. A pakolgatos demo egy masik volt. A HD video akkoriban meg nem volt tul ismert."
Errõl egy linket dobnál, mert szerintem megcsal az emlékezeted (nem elõször).
A túlzott bonyolultságról szóló elmélkedésed többek között ott bukik meg, hogy egyre jobban jönnek befelé a GPGPU alkalmazások (a GPU general-purpose számításokra használata), pedig az még bonyolultabb (a kötöttségek miatt sokkal nehezebb optimalizálni, amire viszont itt még nagyobb szükség van).
De a Cell jobb kihasználásához nem is kell feltétlenül tier 1-2 programozónak lenni, ugyanis rendelkezésre állnak SPE alapú libek különféle feladatokra. Pl. a Physix és a Havok fizikai csomagok is.
"Kb. olyan hatekonysaggal, mint amikor blokkmeret helyett byte-onkent probal meg valaki lemezrol olvasni. Mukodik, de rendes cache nelkul lassu, mint a csiga."
Mint írtam, a memóriahozzáférés a sima CPU-k számára is lassú dolog. Jóval több idõ, mint a DMA elindítása. Az idõ csak azzal a pár ciklussal hosszabbodik meg, ami az utóbbihoz kell. Ez jelentõsebb gondot csak akkor okoz, ha az egész program másból sem áll, mint véletlenszerû memóriahozzáférésekbõl, ami nem túl gyakori, és ott van rá a PPE.
Van a Cellben erre szolgáló cache is, még ha nem is túl sok; az XDR rendszer 16 külön streamen kezeli le a memóriahozzáféréseket.
Errõl egy linket dobnál, mert szerintem megcsal az emlékezeted (nem elõször).
A túlzott bonyolultságról szóló elmélkedésed többek között ott bukik meg, hogy egyre jobban jönnek befelé a GPGPU alkalmazások (a GPU general-purpose számításokra használata), pedig az még bonyolultabb (a kötöttségek miatt sokkal nehezebb optimalizálni, amire viszont itt még nagyobb szükség van).
De a Cell jobb kihasználásához nem is kell feltétlenül tier 1-2 programozónak lenni, ugyanis rendelkezésre állnak SPE alapú libek különféle feladatokra. Pl. a Physix és a Havok fizikai csomagok is.
"Kb. olyan hatekonysaggal, mint amikor blokkmeret helyett byte-onkent probal meg valaki lemezrol olvasni. Mukodik, de rendes cache nelkul lassu, mint a csiga."
Mint írtam, a memóriahozzáférés a sima CPU-k számára is lassú dolog. Jóval több idõ, mint a DMA elindítása. Az idõ csak azzal a pár ciklussal hosszabbodik meg, ami az utóbbihoz kell. Ez jelentõsebb gondot csak akkor okoz, ha az egész program másból sem áll, mint véletlenszerû memóriahozzáférésekbõl, ami nem túl gyakori, és ott van rá a PPE.
Van a Cellben erre szolgáló cache is, még ha nem is túl sok; az XDR rendszer 16 külön streamen kezeli le a memóriahozzáféréseket.
#42
"A BeOS-esek gondolom azt demonstrálták, hogy 2-3 SD video ablakot úgy lehetett ide-oda pakolgatni, hogy nem akadoztak, mint jellemzõen Windowson."
Joval tobb mint 2-3 SD-s ablakot es pakolgatas nelkul. A pakolgatos demo egy masik volt. A HD video akkoriban meg nem volt tul ismert.
""Igen, pl. azt hogy az osszes mag latja a teljes memoriat.
Köszi, hogy most ilyen bõ lére eresztve fejtetted ki újra ugyanazt. Csak kár, hogy az általam írottakat nem akaródzott felfognod."
Felfogtam, de en azt irtam le, hogy a cell pont azt nem tudja amit a programozok akarnak. Innentol nem erdekes, hogy mit tud, ha nem ugy mukodik ahogy a kodot keszitok szeretnek. A fejlesztokhoz kell igazodni vagy anyagi bukas lesz a vege. Ezt a pc-s ipar mar megtanulta, a sony meg majd belejon.
"Az errõl szóló Celles anyagokban szépen le van írva a várakozást kiküszöbölõ double-buffering módszer."
Ami a buffer meretevel tovabb csokkenti az amugy is kis meretu hasznalhato memoria meretet. Ez igy alapvetoen ertelmetlenul bonyolult. A cell lehet hogy ugyanakkora chipmeret eseten jobb hatasfokot er el, de ez az atlag fejlesztot nem erdekli. Az uzetlembereket is csak akkor ha ezzel egyutt tobb hardvert tudnak eladni. Marpedig a tulzott bonyolultsag eloszor a fejlesztoket idegeniti el, majd szoftverek hianyaban visszaesik a hardver eladasa is. Alapvetoen ezt az architekturat a sony bebukta. Hdtv-kbe meg jo bar ahhoz meg draga, de konzolnak valami sokkal egyszerubb es olcsobb kell, nem baj ha sokkal benabb csak olcso legyen es sok jatek fusson rajta.
"A DMA egységeket akár "rendszerszó" hosszon is lehet használni."
Kb. olyan hatekonysaggal, mint amikor blokkmeret helyett byte-onkent probal meg valaki lemezrol olvasni. Mukodik, de rendes cache nelkul lassu, mint a csiga.
"ps. és jó lenne, ha végre megtanulnál címezni ("válasz erre"). Tudod, kicsit jobban árt az áttekinthetõségnek, ha össze-vissza idézel mindenkitõl forrásmegjelölés nélkül, mint az, hogy én adott esetben 2-3-4 egymás utáni, külön címzett hsz-ben válaszolok..."
Szerintem az sokkal idegesitobb, mint ha valaki csak egyszer szol hozza. Ezert is lenne jobb, ha egy ember csak egy hozzaszolast irhatna, mielott valaki mas is hozzaszol, vagy letelik egy bizonyos (jo hosszu) ido. Igy az utolso N hozzaszolas nem mindig ugyannak az embernek a velemenye lenne. (tovabba jobb lenne ha a valaszokhoz bemasolt idezetek eseten legalabb a mondatok nem lennenek elvagva, mivel akkor nehezebb lenne masra valaszolni)
"A Cell felépítése visszaszoktatja a programozókat, hogy ne pazarlóan bánjanak a memóriával, hanem optimálisan használják ki az SPE-k rendelkezésére álló (egyenként) 256 KB sramot. Ha ez megvan (márpedig az IBM-es programozók már bizonyították, hogy ez nem akkora ördöngõsség, csak nem frissdiplomás amatõrökre kell bízni), akkor egy eddig elképzelhetetlen teljesítmény-sûrûséget produkál a cucc."
Ilyen fejlesztokbol nincs eleg. Az a hardver ami nem adhato oda egy atlag fejlesztonek, mert nem erti, az egyszeruen nem tamogathato gazdasagosan. A jatekprogramozok a webprogramozok utan a legrosszabbul fizetett csapat a fejlesztok kozott. Ezek utan olyan hardvert fejleszteni, amihez mikrovezerlos tapasztalat es tudas kell egyenesen uzetli ongyilkossag. Aki tudna rajta jo programokat irni, az nem hajlando annyi penzert amennyit fizetnek neki. A profi programozok pedig csak az eladashoz szukseges demokat es a tudomanyos feladatokat valositjak meg, mert a jatekokhoz tul draga lenne az oraberuk. Innentol van egy hardver ami sokat tudna, de senki nem hajlando ra jo minosegu kodot fejleszteni. Ez igy anyagi bukas.
Itt senki nem a potencialis teljesitmenyt vonja ketsegbe, hanem azt hogy valaha is lesz valakinek annyi felesleges penze, hogy olyan jatekok keszuljenek, amik rendesen kihasznaljak a konzolt. Ennel mar az is jobban megeri, ha inkabb a masik 3 elterjedt platformra dolgozik a fejlesztocsapat. (xbox360, wii, pc) Hamarabb keszen lesznek, tobb peldanyt tudnak eladni es sokkal olcsobb programozokat kell csak felvenni. A jelenleg megtalalhato hatalmas meretu ingyenes algoritmus konyvtarakrol nem is beszelve, amik szinte kivetel nelkul a hagyomanyos Neumann architekturara keszultek, ezert a cell spe-jein csak modositasok vagy ujrairas utan hasznalhatoak.
Szerintem lenne a tisztan technikai szempontok melett az emberi szempontokat figyelembe venni. Ha senkinek nem eri meg anyagilag egy konzol tamogatasa, akkor az a konzol halott. A sony is hagyna mar bekeben, ha nem ezen mulna a blueray es a ceg anyagi sikere. Anno a brunel fele szelesnyomtavu vasut hatarozottan jobb volt mint az stephenson fele, megis az utobbi terjedt el. Az oka inkabb uzleti volt mint mernoki, egyszeruen az elterjedtebb valt szabvannya es kesobb ahhoz igazodtak. Ezert valt a pc es a windows is kvazi szabvannya. Innentol aki penzt is szeretne keresni vele es szeretne ha elterjedne a termeke, akkor az nem megy szembe a vilag elvarasaival. Raadasul a legtobb ember szerint is sokkal biztosabb az egyszerubb megoldast valasztani, mert akkor kevesebb nem vart gond merulhet fel.
"Úgy kell felvenni a programozókat, hogy a Pong (az elsõ asztaliteniszkonzol) játékot írd meg assemblyben 1K-ba!"
Igen, es akkor minden cegnel lenne 1000 programozo aki ert az osszes tobbi platformhoz es 1 aki tud cell spe-t programozni. Melyik csapat keszulne el hamarabb egy jatekkal? <#vigyor3><#vigyor3><#vigyor3><#vigyor3>
Joval tobb mint 2-3 SD-s ablakot es pakolgatas nelkul. A pakolgatos demo egy masik volt. A HD video akkoriban meg nem volt tul ismert.
""Igen, pl. azt hogy az osszes mag latja a teljes memoriat.
Köszi, hogy most ilyen bõ lére eresztve fejtetted ki újra ugyanazt. Csak kár, hogy az általam írottakat nem akaródzott felfognod."
Felfogtam, de en azt irtam le, hogy a cell pont azt nem tudja amit a programozok akarnak. Innentol nem erdekes, hogy mit tud, ha nem ugy mukodik ahogy a kodot keszitok szeretnek. A fejlesztokhoz kell igazodni vagy anyagi bukas lesz a vege. Ezt a pc-s ipar mar megtanulta, a sony meg majd belejon.
"Az errõl szóló Celles anyagokban szépen le van írva a várakozást kiküszöbölõ double-buffering módszer."
Ami a buffer meretevel tovabb csokkenti az amugy is kis meretu hasznalhato memoria meretet. Ez igy alapvetoen ertelmetlenul bonyolult. A cell lehet hogy ugyanakkora chipmeret eseten jobb hatasfokot er el, de ez az atlag fejlesztot nem erdekli. Az uzetlembereket is csak akkor ha ezzel egyutt tobb hardvert tudnak eladni. Marpedig a tulzott bonyolultsag eloszor a fejlesztoket idegeniti el, majd szoftverek hianyaban visszaesik a hardver eladasa is. Alapvetoen ezt az architekturat a sony bebukta. Hdtv-kbe meg jo bar ahhoz meg draga, de konzolnak valami sokkal egyszerubb es olcsobb kell, nem baj ha sokkal benabb csak olcso legyen es sok jatek fusson rajta.
"A DMA egységeket akár "rendszerszó" hosszon is lehet használni."
Kb. olyan hatekonysaggal, mint amikor blokkmeret helyett byte-onkent probal meg valaki lemezrol olvasni. Mukodik, de rendes cache nelkul lassu, mint a csiga.
"ps. és jó lenne, ha végre megtanulnál címezni ("válasz erre"). Tudod, kicsit jobban árt az áttekinthetõségnek, ha össze-vissza idézel mindenkitõl forrásmegjelölés nélkül, mint az, hogy én adott esetben 2-3-4 egymás utáni, külön címzett hsz-ben válaszolok..."
Szerintem az sokkal idegesitobb, mint ha valaki csak egyszer szol hozza. Ezert is lenne jobb, ha egy ember csak egy hozzaszolast irhatna, mielott valaki mas is hozzaszol, vagy letelik egy bizonyos (jo hosszu) ido. Igy az utolso N hozzaszolas nem mindig ugyannak az embernek a velemenye lenne. (tovabba jobb lenne ha a valaszokhoz bemasolt idezetek eseten legalabb a mondatok nem lennenek elvagva, mivel akkor nehezebb lenne masra valaszolni)
"A Cell felépítése visszaszoktatja a programozókat, hogy ne pazarlóan bánjanak a memóriával, hanem optimálisan használják ki az SPE-k rendelkezésére álló (egyenként) 256 KB sramot. Ha ez megvan (márpedig az IBM-es programozók már bizonyították, hogy ez nem akkora ördöngõsség, csak nem frissdiplomás amatõrökre kell bízni), akkor egy eddig elképzelhetetlen teljesítmény-sûrûséget produkál a cucc."
Ilyen fejlesztokbol nincs eleg. Az a hardver ami nem adhato oda egy atlag fejlesztonek, mert nem erti, az egyszeruen nem tamogathato gazdasagosan. A jatekprogramozok a webprogramozok utan a legrosszabbul fizetett csapat a fejlesztok kozott. Ezek utan olyan hardvert fejleszteni, amihez mikrovezerlos tapasztalat es tudas kell egyenesen uzetli ongyilkossag. Aki tudna rajta jo programokat irni, az nem hajlando annyi penzert amennyit fizetnek neki. A profi programozok pedig csak az eladashoz szukseges demokat es a tudomanyos feladatokat valositjak meg, mert a jatekokhoz tul draga lenne az oraberuk. Innentol van egy hardver ami sokat tudna, de senki nem hajlando ra jo minosegu kodot fejleszteni. Ez igy anyagi bukas.
Itt senki nem a potencialis teljesitmenyt vonja ketsegbe, hanem azt hogy valaha is lesz valakinek annyi felesleges penze, hogy olyan jatekok keszuljenek, amik rendesen kihasznaljak a konzolt. Ennel mar az is jobban megeri, ha inkabb a masik 3 elterjedt platformra dolgozik a fejlesztocsapat. (xbox360, wii, pc) Hamarabb keszen lesznek, tobb peldanyt tudnak eladni es sokkal olcsobb programozokat kell csak felvenni. A jelenleg megtalalhato hatalmas meretu ingyenes algoritmus konyvtarakrol nem is beszelve, amik szinte kivetel nelkul a hagyomanyos Neumann architekturara keszultek, ezert a cell spe-jein csak modositasok vagy ujrairas utan hasznalhatoak.
Szerintem lenne a tisztan technikai szempontok melett az emberi szempontokat figyelembe venni. Ha senkinek nem eri meg anyagilag egy konzol tamogatasa, akkor az a konzol halott. A sony is hagyna mar bekeben, ha nem ezen mulna a blueray es a ceg anyagi sikere. Anno a brunel fele szelesnyomtavu vasut hatarozottan jobb volt mint az stephenson fele, megis az utobbi terjedt el. Az oka inkabb uzleti volt mint mernoki, egyszeruen az elterjedtebb valt szabvannya es kesobb ahhoz igazodtak. Ezert valt a pc es a windows is kvazi szabvannya. Innentol aki penzt is szeretne keresni vele es szeretne ha elterjedne a termeke, akkor az nem megy szembe a vilag elvarasaival. Raadasul a legtobb ember szerint is sokkal biztosabb az egyszerubb megoldast valasztani, mert akkor kevesebb nem vart gond merulhet fel.
"Úgy kell felvenni a programozókat, hogy a Pong (az elsõ asztaliteniszkonzol) játékot írd meg assemblyben 1K-ba!"
Igen, es akkor minden cegnel lenne 1000 programozo aki ert az osszes tobbi platformhoz es 1 aki tud cell spe-t programozni. Melyik csapat keszulne el hamarabb egy jatekkal? <#vigyor3><#vigyor3><#vigyor3><#vigyor3>
OK, köszi 😊
#40
Azt az 1 Tflops-t felejtsd el. Marketing-anyagokban volt, nem 1, hanem 2 Tflops, és nem a Cellre, hanem az egész PS3-ra vonatkozott, a GPU fixfunkciós egységeit is beleszámolva.
A mai csúcs GPU-k peak (elméleti max.) FLOPS értéke a Cellé többszöröse. Azonban, ezt csak a legegyszerûbb számítások sokasága esetén tudják elérni. Összetettebb számítások sokkal jobban megfektetik õket, így kiegyenlítõdik, vagy épp meg is fordul a dolog. Miközben a mai 65nm-es Cell fogyasztása és mérete sokkal kisebb, mint az említett GPU-ké. És most jön csak a 45nm-es. Aztán ~1 év múlva a megtöbbszörözött magszámmal rendelkezõ változat, ami már tényleg 1 TFLOPS-os lesz (ami felér 4-5-6 GPU-s TFLOPS-szal).
A mai csúcs GPU-k peak (elméleti max.) FLOPS értéke a Cellé többszöröse. Azonban, ezt csak a legegyszerûbb számítások sokasága esetén tudják elérni. Összetettebb számítások sokkal jobban megfektetik õket, így kiegyenlítõdik, vagy épp meg is fordul a dolog. Miközben a mai 65nm-es Cell fogyasztása és mérete sokkal kisebb, mint az említett GPU-ké. És most jön csak a 45nm-es. Aztán ~1 év múlva a megtöbbszörözött magszámmal rendelkezõ változat, ami már tényleg 1 TFLOPS-os lesz (ami felér 4-5-6 GPU-s TFLOPS-szal).
#39
"Igen, ezen nagyon elamultam anno amikor PII-es procikon hardveres gyorsitas nelkul ugyanezt demoztak a BeOS fejlesztoi."
A fantáziálásod elérte a sci-fi-t, gratulálok. 😛
Figyelmedbe ajánlanám, hogy 48 full-HD streamrõl van szó. Egy PII-es valószínûleg 1db-ot sem tud real-time dekódolni. A BeOS-esek gondolom azt demonstrálták, hogy 2-3 SD video ablakot úgy lehetett ide-oda pakolgatni, hogy nem akadoztak, mint jellemzõen Windowson.
"Aztan rajottem, hogy ez a legjobban optimalizalhato batch feladatok egyike, mivel nincs benne emberi interakcio."
Ha csak ettõl függene... Egyébként nem is talált, mert volt interaktivitás: különféle elredezésekben lehetett megjeleníteni a video-ablakokat.
"Igen, pl. azt hogy az osszes mag latja a teljes memoriat.
Köszi, hogy most ilyen bõ lére eresztve fejtetted ki újra ugyanazt. Csak kár, hogy az általam írottakat nem akaródzott felfognod.
"Ezzel szemben egy hagyomanyos processzor vagy egy mai programozhato shader 1 utasitasban es atlag 1 orajel alatt megoldja azt, ami egy cell spe-nek a dma egysegre torteno varasbol fog allni aminek a beallitasa mar eleve sok ezer utasitast igenyelt."
Ez több szempontból hülyeség (az utolsó egyenesen marhaság, nem únod még?):
1. A memória-hozzáférés akármilyen procinak sok-sok órajel-ciklus.
2. A DMA mûvelet elindítása néhány utasítás. Így az utóbbinál az ebbõl fakadó óverhead többtíz KB-os blokk esetén néhány százalék.
"Ha meg feldaraboljuk oket, akkor az spe az ido jo reszeben varni fog a blokkok betoltesere. (ugyanis meg multithreading sincs bennuk)"
Újabb fantáziálás. Jó szórakozás mindenféle hülyeséget tényként leírkálni? Az errõl szóló Celles anyagokban szépen le van írva a várakozást kiküszöbölõ double-buffering módszer.
A DMA egységeket akár "rendszerszó" hosszon is lehet használni.
ps. és jó lenne, ha végre megtanulnál címezni ("válasz erre"). Tudod, kicsit jobban árt az áttekinthetõségnek, ha össze-vissza idézel mindenkitõl forrásmegjelölés nélkül, mint az, hogy én adott esetben 2-3-4 egymás utáni, külön címzett hsz-ben válaszolok...
A fantáziálásod elérte a sci-fi-t, gratulálok. 😛
Figyelmedbe ajánlanám, hogy 48 full-HD streamrõl van szó. Egy PII-es valószínûleg 1db-ot sem tud real-time dekódolni. A BeOS-esek gondolom azt demonstrálták, hogy 2-3 SD video ablakot úgy lehetett ide-oda pakolgatni, hogy nem akadoztak, mint jellemzõen Windowson.
"Aztan rajottem, hogy ez a legjobban optimalizalhato batch feladatok egyike, mivel nincs benne emberi interakcio."
Ha csak ettõl függene... Egyébként nem is talált, mert volt interaktivitás: különféle elredezésekben lehetett megjeleníteni a video-ablakokat.
"Igen, pl. azt hogy az osszes mag latja a teljes memoriat.
Köszi, hogy most ilyen bõ lére eresztve fejtetted ki újra ugyanazt. Csak kár, hogy az általam írottakat nem akaródzott felfognod.
"Ezzel szemben egy hagyomanyos processzor vagy egy mai programozhato shader 1 utasitasban es atlag 1 orajel alatt megoldja azt, ami egy cell spe-nek a dma egysegre torteno varasbol fog allni aminek a beallitasa mar eleve sok ezer utasitast igenyelt."
Ez több szempontból hülyeség (az utolsó egyenesen marhaság, nem únod még?):
1. A memória-hozzáférés akármilyen procinak sok-sok órajel-ciklus.
2. A DMA mûvelet elindítása néhány utasítás. Így az utóbbinál az ebbõl fakadó óverhead többtíz KB-os blokk esetén néhány százalék.
"Ha meg feldaraboljuk oket, akkor az spe az ido jo reszeben varni fog a blokkok betoltesere. (ugyanis meg multithreading sincs bennuk)"
Újabb fantáziálás. Jó szórakozás mindenféle hülyeséget tényként leírkálni? Az errõl szóló Celles anyagokban szépen le van írva a várakozást kiküszöbölõ double-buffering módszer.
A DMA egységeket akár "rendszerszó" hosszon is lehet használni.
ps. és jó lenne, ha végre megtanulnál címezni ("válasz erre"). Tudod, kicsit jobban árt az áttekinthetõségnek, ha össze-vissza idézel mindenkitõl forrásmegjelölés nélkül, mint az, hogy én adott esetben 2-3-4 egymás utáni, külön címzett hsz-ben válaszolok...
Az 1 TFLOPs-ot valami cikkekben láttam, több helyen, többször (igaz, nem kifejezetten szaklapokban 😄) És attól, hogy egy viszonylag friss és emmiatt nem szanaszét optimalizált "fehérjeszámolgató" progi sok db, az egész Földön szanaszét szórt és különbözõ sebességû, nagyrészt csak 1-2 megabites, magas pinges, ingadozó sebességû nettel összekötött JÁTÉKKONZOLon ilyen sz.rul teljesít, még nem jelenti azt hogy a cell ilyen gyenge. Egyébként valahol olvastam hogy ez a progi is csak valami 25-35%-ban bírja a cellt kihasználni...
#37
1. Nem TFLOP, hanem TFLOPS. Az az "s" a per second, és nem a többesszám jele (1-nél nagyobb értéknél)! Mint ahogy nem 80 km a sebességhatár, hanem 80 km/h. 1 Tflop az 1 milliárd fp mûvelet, akármennyi idõ alatt.
2. A Cell peak FLOPS értéke ~230 GFLOPS. (De ez a rugalmasabb felépítés miatt felér 1 TFLOPS-szal GPU-knál. De már többször bizonyítást nyert.)
3. Már egyszer megbeszéltük, és ki is másoltam neked a fejlesztõk errõl szóló felhívását, hogy értelmetlen így számolni.
2. A Cell peak FLOPS értéke ~230 GFLOPS. (De ez a rugalmasabb felépítés miatt felér 1 TFLOPS-szal GPU-knál. De már többször bizonyítást nyert.)
3. Már egyszer megbeszéltük, és ki is másoltam neked a fejlesztõk errõl szóló felhívását, hogy értelmetlen így számolni.
"A Cell felépítése visszaszoktatja a programozókat, hogy ne pazarlóan bánjanak a memóriával, hanem optimálisan használják ki az SPE-k rendelkezésére álló (egyenként) 256 KB sramot. Ha ez megvan (márpedig az IBM-es programozók már bizonyították, hogy ez nem akkora ördöngõsség, csak nem frissdiplomás amatõrökre kell bízni), akkor egy eddig elképzelhetetlen teljesítmény-sûrûséget produkál a cucc. (Nem csak nyers FLOPS-okat, mint a GPU-k.)"
Úgy kell felvenni a programozókat, hogy a Pong (az elsõ asztaliteniszkonzol) játékot írd meg assemblyben 1K-ba!
Úgy kell felvenni a programozókat, hogy a Pong (az elsõ asztaliteniszkonzol) játékot írd meg assemblyben 1K-ba!
Munkaállomás: C64 64K RAM 5,25\" floppy & Dataset Szerver: XT8086 640K RAM 10 MB MFM HDD 12\" Hercules Monitor DOS 1.0 Megy rajta a Crisys, mint az állat!
Szerintem ez a cikk arról szól, hogy valaki az Nvidia részvényeket akarja "jóárasítani", hogy jól bevásároljon belõlük.
Munkaállomás: C64 64K RAM 5,25\" floppy & Dataset Szerver: XT8086 640K RAM 10 MB MFM HDD 12\" Hercules Monitor DOS 1.0 Megy rajta a Crisys, mint az állat!
#34
"Amúgy 48 egymástól független video-stream párhuzamos feldolgozását is valahogy megoldották egy demonstrácio során."
Igen, ezen nagyon elamultam anno amikor PII-es procikon hardveres gyorsitas nelkul ugyanezt demoztak a BeOS fejlesztoi. Aztan rajottem, hogy ez a legjobban optimalizalhato batch feladatok egyike, mivel nincs benne emberi interakcio.
...
"A könnyûség nem attól függ, hogy x86 vagy más uarc. A LArrabee-nek is meglehetnek azok a belsõ törvényei, amit figyelembe kell venni."
Igen, pl. azt hogy az osszes mag latja a teljes memoriat. Igy kepesek egyszerre _veletlen_modon_ elerni egy oriasi meretu adathalom elemeit. Azok az algoritmusok amik nem tudnak batch modban par kilobyte-os adatcsomagokon dolgozni, mert sokkal nagyobb az adatkeszletuk es az nem darabolhato egyertelmuen, sokkal jobb teljesitmennyel futnak egy kisebb sebessegu processzoron is. Ilyen pelda az octree-k esete, amiket raytracing-hez, hagyomanyos renderinghez, foglaltsag es utkereso terkepekhez hasznalnak. Ezek az adatok a mai jatekokban sokkal nagyobbak, minthogy beleferjenek egy cell spe-be. Ha meg feldaraboljuk oket, akkor az spe az ido jo reszeben varni fog a blokkok betoltesere. (ugyanis meg multithreading sincs bennuk) Ezzel szemben egy hagyomanyos processzor vagy egy mai programozhato shader 1 utasitasban es atlag 1 orajel alatt megoldja azt, ami egy cell spe-nek a dma egysegre torteno varasbol fog allni aminek a beallitasa mar eleve sok ezer utasitast igenyelt.
Ami egy mai cpu/gpu eseten fontos, hogy konnyu legyen ra fejleszteni:
-nagymeretu kozvetlen memoria elerese
-rendszerszo alapu veletlen memoria eleres a teljes rendszermemoriara
-alapveto matematikai muveletek nativ tamogatasa
-vezerelheto ugrasok tamogatasa
ennyi...
Ebbol a cell spe az elso kettot nem tudja. De hianyzik meg belole az smt tamogatas is, hogy ha mar var az spe a dma-ra, akkor legalabb legyen mit csinalnia addig is. A szoftveres taszkvaltas pedig megfelezi az spe amugy is kis meretu lokalis ram-jat es megtobb idot vesz el a munkatol. X86-on utoljara a valos modban futo szegmentalt memoriakezelesu 16 bites rendszerek hasznaltak overlay alapu adatkezelest es valositottak meg a felhasznaloi programok szintjen szoftveres taszkvaltast. Ezek a trukkok csak az akkori limitek megkerulesere szulettek es manapsag ilyen mesterseges limitekkel cpu-t epiteni eleg rossz otlet.
Egy fejlesztoi szempontbol idealis processzor a memoriat egy hatalmas lapos tombnek mutatja, amin alapveto matematikai muveletek lehet vegezni, majd a program folyasat ezen muveletek fuggvenyeben lehet befolyasolni. Ezt hivjuk ma Neumann architekturanak, bar Zuse hamarabb epitett ilyen elven mukodo gepet. Barmilyen trukkozes csak a programozo eletet bonyolitja, ezert is van az, hogy a mai operacios rendszerek mindent megtesznek azert, hogy a futo programok ilyennek lassak a gepet. (a kereskedelmi unix-ok, a linux es meg a windows is ezt a modellt koveti) A cell ezzel szemben a 60-70-es evek mikrovezerloinek elveit es trukkjeit koveti, amik elmeletben nagyobb teljesitmeny hoznak, a gyakorlatban viszont sikertelennek bizonyultak. Az ido nagyobb resze mindig az adatok pakolgatasara ment el, a tenyleges feladat megoldasa helyett.
A tapasztalatok fenyeben ki lehet jelenti, hogy ha nem vektoros feladatrol van szo, akkor a cell elverzik szinte minden valos feladton, belertve a nem vektorizalhato adatkeszleteken vegzett tudomanyos szamitasokat is. Ezzel szemben egy atlag x86-os vagy egy atlag ppc, ami mind 32, mind 64 bites modban kepes biztositani a szabvany neumann architektura felteteleit es gond nelkul hoz altalanosan jo teljesitmenyt barmilyen feladat eseten. (tehat semmiben sem jo, viszont semmiben sem rossz, ezert minden celra megfelel)
Ha a cell helyett valaki egy gyors, egyszeru es olcso processzort akarna csinalni, akkor fogjon N darab altalanos risc-es magot es epitsen ezekbol cpu-t. Mondjuk mivel az x86-ok eseten belul mar jo ideje risc-es magok vannak, ezert ugy nez ki az intel most eppen pont ezt teszi, csak az utasitasokat tomoritve tarolja (cisc-es x86-os formatumban), amit utasitasdekoderek pakolnak ki futtatas elott. Minden mas szemontbol egy 64 bites x86 pont megfelel az idealis Neumann rendszeru gepnek.
Igen, ezen nagyon elamultam anno amikor PII-es procikon hardveres gyorsitas nelkul ugyanezt demoztak a BeOS fejlesztoi. Aztan rajottem, hogy ez a legjobban optimalizalhato batch feladatok egyike, mivel nincs benne emberi interakcio.
...
"A könnyûség nem attól függ, hogy x86 vagy más uarc. A LArrabee-nek is meglehetnek azok a belsõ törvényei, amit figyelembe kell venni."
Igen, pl. azt hogy az osszes mag latja a teljes memoriat. Igy kepesek egyszerre _veletlen_modon_ elerni egy oriasi meretu adathalom elemeit. Azok az algoritmusok amik nem tudnak batch modban par kilobyte-os adatcsomagokon dolgozni, mert sokkal nagyobb az adatkeszletuk es az nem darabolhato egyertelmuen, sokkal jobb teljesitmennyel futnak egy kisebb sebessegu processzoron is. Ilyen pelda az octree-k esete, amiket raytracing-hez, hagyomanyos renderinghez, foglaltsag es utkereso terkepekhez hasznalnak. Ezek az adatok a mai jatekokban sokkal nagyobbak, minthogy beleferjenek egy cell spe-be. Ha meg feldaraboljuk oket, akkor az spe az ido jo reszeben varni fog a blokkok betoltesere. (ugyanis meg multithreading sincs bennuk) Ezzel szemben egy hagyomanyos processzor vagy egy mai programozhato shader 1 utasitasban es atlag 1 orajel alatt megoldja azt, ami egy cell spe-nek a dma egysegre torteno varasbol fog allni aminek a beallitasa mar eleve sok ezer utasitast igenyelt.
Ami egy mai cpu/gpu eseten fontos, hogy konnyu legyen ra fejleszteni:
-nagymeretu kozvetlen memoria elerese
-rendszerszo alapu veletlen memoria eleres a teljes rendszermemoriara
-alapveto matematikai muveletek nativ tamogatasa
-vezerelheto ugrasok tamogatasa
ennyi...
Ebbol a cell spe az elso kettot nem tudja. De hianyzik meg belole az smt tamogatas is, hogy ha mar var az spe a dma-ra, akkor legalabb legyen mit csinalnia addig is. A szoftveres taszkvaltas pedig megfelezi az spe amugy is kis meretu lokalis ram-jat es megtobb idot vesz el a munkatol. X86-on utoljara a valos modban futo szegmentalt memoriakezelesu 16 bites rendszerek hasznaltak overlay alapu adatkezelest es valositottak meg a felhasznaloi programok szintjen szoftveres taszkvaltast. Ezek a trukkok csak az akkori limitek megkerulesere szulettek es manapsag ilyen mesterseges limitekkel cpu-t epiteni eleg rossz otlet.
Egy fejlesztoi szempontbol idealis processzor a memoriat egy hatalmas lapos tombnek mutatja, amin alapveto matematikai muveletek lehet vegezni, majd a program folyasat ezen muveletek fuggvenyeben lehet befolyasolni. Ezt hivjuk ma Neumann architekturanak, bar Zuse hamarabb epitett ilyen elven mukodo gepet. Barmilyen trukkozes csak a programozo eletet bonyolitja, ezert is van az, hogy a mai operacios rendszerek mindent megtesznek azert, hogy a futo programok ilyennek lassak a gepet. (a kereskedelmi unix-ok, a linux es meg a windows is ezt a modellt koveti) A cell ezzel szemben a 60-70-es evek mikrovezerloinek elveit es trukkjeit koveti, amik elmeletben nagyobb teljesitmeny hoznak, a gyakorlatban viszont sikertelennek bizonyultak. Az ido nagyobb resze mindig az adatok pakolgatasara ment el, a tenyleges feladat megoldasa helyett.
A tapasztalatok fenyeben ki lehet jelenti, hogy ha nem vektoros feladatrol van szo, akkor a cell elverzik szinte minden valos feladton, belertve a nem vektorizalhato adatkeszleteken vegzett tudomanyos szamitasokat is. Ezzel szemben egy atlag x86-os vagy egy atlag ppc, ami mind 32, mind 64 bites modban kepes biztositani a szabvany neumann architektura felteteleit es gond nelkul hoz altalanosan jo teljesitmenyt barmilyen feladat eseten. (tehat semmiben sem jo, viszont semmiben sem rossz, ezert minden celra megfelel)
Ha a cell helyett valaki egy gyors, egyszeru es olcso processzort akarna csinalni, akkor fogjon N darab altalanos risc-es magot es epitsen ezekbol cpu-t. Mondjuk mivel az x86-ok eseten belul mar jo ideje risc-es magok vannak, ezert ugy nez ki az intel most eppen pont ezt teszi, csak az utasitasokat tomoritve tarolja (cisc-es x86-os formatumban), amit utasitasdekoderek pakolnak ki futtatas elott. Minden mas szemontbol egy 64 bites x86 pont megfelel az idealis Neumann rendszeru gepnek.
#33
Egyébként a jelen cikk forrásául szolgáló cikket egy bizonyos Charlie Demerjian írta, aki köztudottan és megszállottan Sony és PS3 ellenes, így állandóan hülyeségeket írkál a témában. Egy Sony illetékes már cáfolta is, fantáziadús sci-fi-nek címkézve. 😊
#32
Az a cikk egy teljes félrevezetés volt, mert egy fél évvel ezelõtti interjút szedtek elõ, amiben azt nyilatkozta egy Sony-fejes, hogy 2008-ban nem terveznek árcsökkentést. Most meg 2009 van...
#31
Hogy miért hülyeség: mert 1 x86 mag ugyanúgy 1-1 SIMD mûveletet tud egyszerre.
Mellesleg hiába ~3.0 az elméleti max. IPS (nem-SIMD utasítások esetén), ha a programok 99%-a ezt is 1.0 IPS körül használja ki. (PerfMon-nal ellenõrízhetõ.)
Egyébként ez is hülyeség:
"A cell spe-jei ezzel szemben skalar egysegek, tehat nem tudnak 1 ips fole menni."
Nem éppen, mert az SPE-k is dual-issue-sek: 1 SIMD, és mellette 1 Load-Store utasítást tudnak párhuzamosan. Jó lenne, ha végre befejeznéd a hónapok óta tartó FUD-hadjáratodat a PS3/Cell ellen.
Mellesleg hiába ~3.0 az elméleti max. IPS (nem-SIMD utasítások esetén), ha a programok 99%-a ezt is 1.0 IPS körül használja ki. (PerfMon-nal ellenõrízhetõ.)
Egyébként ez is hülyeség:
"A cell spe-jei ezzel szemben skalar egysegek, tehat nem tudnak 1 ips fole menni."
Nem éppen, mert az SPE-k is dual-issue-sek: 1 SIMD, és mellette 1 Load-Store utasítást tudnak párhuzamosan. Jó lenne, ha végre befejeznéd a hónapok óta tartó FUD-hadjáratodat a PS3/Cell ellen.
Oldal 1 / 2Következő →