[vers]

Idézet: SFIJ - Dátum: 2005. márc. 2., szerda - 1:03

Nos igen. a Az STI a mukodest apulet-eken at kepzeli el (nem veletlen a megnevezes hasonlosaga az applethez). Szoval tomenytelen mennyisegu kisalkalmazast futta(na) egy ilyen cell processzor es a cel, ammenyire csak lehet a kisalkalmazasok kommunikaciojat a processzoron belul tartani - ezert is van minden VU-nak 256K belso cimezhateo, mintegy cache szeru RAM-ja es a DMA muveletek az ide valo adatbehozatalra vonaktoznak. ami szamomra erdekes, bar nem jottem ra, hogyan tortenik a kivitelezes - az az izokrom mukodes, vagyis a kisalkalmazas garanatalt lappangasi/valaszideje, illetve ennek pontos tervezhetosege. Ez az egesz parasztosan fogalmazava tan egy 'hardware accelerated excel sheet'-re hajaz inkabb. Nem tudom most megitelni, hogy ez egy jarhatatlan dolog-e vagy sem. Meg akar jo is kisulhet belole. ha arra gondolsz, hogy proceduralis FORTRAN-t vagy C-t kene egy compilerenek erre lemappelnie az valoban egy mission impossible ugy. Ha ara gondolsz, hogy programozastechnologiailag paradigmavaltas szukseges, nos akkor valoban, igen szukseges. Csak csendben jegyeznem meg, hogy ez mar a modern risc processzorok eseteben is szukseges lett volna, mert mar a modern risc processzorok mukodese es a fortran altal feltetelezett runtimemodel kozott is oriasi szakadek tatong...

hasonloan müködik a dma mint a ps2 esetében, kiadsz egy parancsot hogy a memböl hozzon adatot, aztán majd behozza valamikor, de addig más adatokon dolgozgatsz
sajna emiatt 2-3-4 részre fel kell osztania  256 KB-ot , mert mig az egyik puffert irja,olvassa, a másikon dolgozik, és estleg még munkaterület is kell, na meg a codenak is kell hely
szoval  kb 64 KB-os csomagokat lehet max feldolgozni ugy hogy maxon  müködjön a vectorproci
tehát ez nem cache, a nagy latency-k miatt amugy sem lenne jo arra
aztán még van olyan lehetöség hogy a dma egyböl a regiszterekbe nyomja az adatot , ez nemtudom mire jo, talán ha másik vectorprocibol jön az adat ott nincs nagy latency, meg tud  csatornat is olvasni tehát az adat nem kerül sehova csak akkor jön a következö ha kiolvasod az elözöt
még minden nekem se tiszta,  pár ábrábol nem lehet mindent megtudni....

ez a cache nélküli megoldás elég favágonak tünik nekem, hiába van  nagy teljesitménye a procinak, nem minden feladatra jo, és nehéz is néha csomagokra bontani az adatokat
a m$ megoldása valahogy jobban tetszik , pedig az nagy szo mert sony fan vagyok
ez az xbox2 blockvázlata:



mondjuk itt meg a cpu állhat be , tul távol van a memoria töle, gondolom nagy is a késleltetése

Szerkesztette: vers 2005. 03. 02. 02:57 -kor

[max-pain]

Sok Cell slide a GDC-rol:

http://pc.watch.impr...0/kaigai165.htm

[vers]

mégiscsak lehet cache-ként használni a vectorprocik saját memoriáját:


[ Kattints ide a teljes méretû képhez ]

[SFIJ]

Ugy laccik, az lesz amire szamitottam. Gazdasagtalan RAD eszkozokkel gyertott nem hatekony bloated kodokkal lesz felemesztve a cell teljesitmenye: https://www.hwsw.hu/...=28428&count5=1

[vers]

Idézet: SFIJ - Dátum: 2005. márc. 10., csütörtök - 14:31

Ugy laccik, az lesz amire szamitottam. Gazdasagtalan RAD eszkozokkel gyertott nem hatekony bloated kodokkal lesz felemesztve a cell teljesitmenye: https://www.hwsw.hu/...=28428&count5=1

többnyire igy lesz, az elméleti  250 Gflopsbol lesz 20-50 valos Gflops,
ismersz valami megoldást a teljesitmény növelésére az assembly kivételével?

[Asker]

katt, nem fogod megbánni, minden Cellbuzinak ajánlott 

[Laa-Yosh]

Megjegyzés a diszkusszióhoz...
A CELL SPU-k csak 32 bites floatokkal dolgoznak, és az sem szabvány IEEE formátumú. Ha szuperszámítózni vagy CG animot renderelni akar rajta az ember, 64 bit precizitással, akkor az SPU-k tudnak emulálni, de kb. 10%-ra esik az elméleti max. teljesítményük.

Szóval ez a 16 TFLOPS rack aligha teljesen komoly, inkább marketingszaga van, mint anno a PS2 EE+GS combóra épített GSCube-nak, ami szintén nem jutott túl a demo állapoton...

[vers]

Idézet: Laa-Yosh - Dátum: 2005. márc. 20., vasárnap - 1:43

Megjegyzés a diszkusszióhoz...
A CELL SPU-k csak 32 bites floatokkal dolgoznak, és az sem szabvány IEEE formátumú. Ha szuperszámítózni vagy CG animot renderelni akar rajta az ember, 64 bit precizitással, akkor az SPU-k tudnak emulálni, de kb. 10%-ra esik az elméleti max. teljesítményük.

Szóval ez a 16 TFLOPS rack aligha teljesen komoly, inkább marketingszaga van, mint anno a PS2 EE+GS combóra épített GSCube-nak, ami szintén nem jutott túl a demo állapoton...

nem emulalják a 64 bitet az SPE-k:)
a 128 bites regiszterekbe 2 darab 64 bites adat fér, a 4 32 bites helyett, ezért a müveleteket  csak 2  adaton végzi egyszerre, és maga a 64 bites áramkör  2-szer akkorra késleltetéssel müködik mint a 32 bites, emiatt van a kisebb teljesitmény, a 32 bites áramkör tényleg nem IEEE szabványu , de a 64 bites  az az

mondjuk azt én sem értem hogy hoztak ki 30 Gflops-ot , az adatok alapján a 32 bites teljesitmény 4-dét vagy felét kéne tudnia ami 64 vagy 128 Gflops
amugy az elméleti  sebesség nem sok mindent  mond mivel az csak szorzás+összeadásra müködik, ha elkezdünk osztani vagy gyököt vonni, esetleg sinus,log,exp vagy más egyéb bonyolultabb müveletet végezni akkor messze leszünk a 256 Gflopstol, mivel ezekhez semmilyen hardver nincs a procikban csak közelitéses modszerrel kaphatjuk meg az eredményt, pl newton-raphson eljárással, aminél a 32 bites és 64 bites eredmény között nincs 4-szeres végrehajtási idö különbség max 2-szeres

talán a nagy sebesség  eltérést okozhatja az is hogy nincs 64 bites MADD utasitás ami egyszerre szoroz is meg összead hanem csak külön összeado meg szorzo utasitás van, ez is lefelezné az elméleti sebességet, de ez se nagy baj, az elméleti 256 Gflops semmit se jelent mivel ez a MADD utasitás alapján számolodik, de a programok nem csak ebböl állnak

ezek alapján ha egy valodi programot amit C-ben irnak leforditjuk 32 biten kb kijön  50 Gflops, 64 biten meg 25gflops
egy intel -amd procin meg kijön 2-5 gflops és ez a lényeg

[vers]

ez az össz amit tudni lehet a 64 bites float-rol:

[vers]

a leirás alapján minden utasitás 3 forrás és 1 cél regiszterrel dolgozik tehát összesen 4-el, ilyen procit még nem láttam  minden risc core 3 reggel müködik....kellene már egy jo docsi

amugy Layosh a 256 Gflops is szép szám de simán tudok 512 Gflopsot hozni látszolagosan játék alatt,
16 bites integer regiszterekben  tárolva az object adatait egyszerre 8 adaton dolgozna az SPE , ez orajelenként 16 müvelet,
ps2-n is müködött már ez a rutinom igy jött ki a 100 millio polygon fölötti adat, holott a sony maxnak irt 75-öt ))
persze ehhez ASM kell de sok ..

Szerkesztette: vers 2005. 03. 20. 10:44 -kor

[cx.core]

Idézet: vers - Dátum: 2005. márc. 20., vasárnap - 11:43

persze ehhez ASM kell de sok ..

[vers]

Idézet: cx.core - Dátum: 2005. márc. 20., vasárnap - 11:14

ez nem cell téma.. tehát kicsit off

CX.CORE ugytudom jol nyomod az ASM-ot ?

van ötleted hogy lehet kihasználni az integer<->floating konvertálo utasitásokat , ha jol képzelem egy int-> float konvertálo utasitás az érték logaritmusát adja vissza valamilyen szinten,
lehetséges e az osztást gyorsitani ezekkel az alábbi képletre támaszkodva

a/b=exp(log(a)-log(b))

vagy csak erös közelitett érték származtathato belöle ?

[SFIJ]

Idézet: vers - Dátum: 2005. márc. 20., vasárnap - 22:21

ha jol képzelem egy int-> float konvertálo utasitás az érték logaritmusát adja vissza valamilyen szinten,
lehetséges e az osztást gyorsitani ezekkel az alábbi képletre támaszkodva

a/b=exp(log(a)-log(b))

vagy csak erös közelitett érték származtathato belöle ?

az int/float konverzio nem a logaritmust adja vissza. a konverzio soran addig osztjuk a szamot 2-vel amig az 1.0... -1.0 tartomanyba nem esik es feljegyezzuk, hogy hanyszor osztottuk el a szamot 2-vel.

Amit az osztasrol irsz az igaz, csak azt ne feledd el, hogy altalaban valaminek a logaritmusat kiszamolni az egy dragabb muvelet, mint az osztas. Persze ha a cpu-ban vannak ezt segito fuggvenytablazatok, akkor nemaz, de ilyesmi minimalist cpu-ban nem szokik lenni, a log2() tipikusan olyan cucc, amit inkabb cisc cpuk eseten implementalnak.

[vers]

Idézet: SFIJ - Dátum: 2005. márc. 21., hétfõ - 12:30

az int/float konverzio nem a logaritmust adja vissza. a konverzio soran addig osztjuk a szamot 2-vel amig az 1.0... -1.0 tartomanyba nem esik es feljegyezzuk, hogy hanyszor osztottuk el a szamot 2-vel.

Amit az osztasrol irsz az igaz, csak azt ne feledd el, hogy altalaban valaminek a logaritmusat kiszamolni az egy dragabb muvelet, mint az osztas. Persze ha a cpu-ban vannak ezt segito fuggvenytablazatok, akkor nemaz, de ilyesmi minimalist cpu-ban nem szokik lenni, a log2() tipikusan olyan cucc, amit inkabb cisc cpuk eseten implementalnak.

akkor egy példa:

1024 floating értéke 1*2^10
1024 logaritmusa 10, mi az ha nem a logaritmus?, persze nem 2 hatványu számoknál már lehetséges hogy csak közelitö értéket ad, de azt is talán ki lehet küszöbölni egy felszorzással
vagy rosszul gondolok valamit?

[SFIJ]

Idézet: vers - Dátum: 2005. márc. 21., hétfõ - 14:44

akkor egy példa:

1024 floating értéke 1*2^10
1024 logaritmusa 10, mi az ha nem a logaritmus?, persze nem 2 hatványu számoknál már lehetséges hogy csak közelitö értéket ad, de azt is talán ki lehet küszöbölni egy felszorzással
vagy rosszul gondolok valamit?

jo akkor nezzuk mondjuk a Pi-t.

log2(pi) =  1.651496127823799
pi floatban meg: 0.100101011100110110000101000 * 2 ^ 10 = (pi/4) * 2^2

log2(x)= az a szam ahanyadik kitevore kell emelni a 2-t, hogy x-et kapjal.
a float abrazolas meg az, amit leirtam.

a folat nem mas, mint a 2-espont balszelre tolasa es az eltolas mertekenek feljegyzese. a float arra jo, hogy korlatolt szohosszusagu regiszterekben pontosabban lehessen szamolni.

a float ket reszbol all, egy mantisszabol es egy kitevobol. ha csak a kitevot nezed akkor az valoban logaritmusszeruen vielkedik, decsak szeruen!

Szerkesztette: SFIJ 2005. 03. 21. 15:56 -kor

[vers]

na akkor menjünk neki a problémának matematikailag:)

a floating szám:

N=M*2^K ahol 1 <= M < 2


a logaritmus :

log N=L  ahol 2^L=N

most számoljuk ki az N szám logaritmusát:

log N= log (M*2^K) = log(M) + log(2^K)= log (M) + K

tehát kijött az hogy az N szám logaritmusa egyenlö a karakterisztikával, meg a mantissza logaritmusának összegével

a log(M) értéke 0 és 1 közé esik mivel a mantissza 1 és 2 közé
ha kitudjuk számolni a log (M)-et készen vagyunk , ehhez elméletileg eltoljuk balra a számot pár bittel, legyen mondjuk 10
akkor igy néz ki:

log (M*1024)=log(M)+10 ebböl log (M) = log(m*1024) - 10

a log (m*1024)-et kitudjuk számolni egy int>float konvertálással ahol a karakterisztika adja a közelitett értéket ebböl kivonjuk a 10-et és megkapjuk a log (M )közelitett értékét

és igy a K+log (M) már megad egy jo közelitést a logaritmus értékre és innen az osztáshoz márcsak kivonni kell


eddig jutottam még folytatom , de dolgozni is kell ..

[SFIJ]

Idézet: vers - Dátum: 2005. márc. 21., hétfõ - 16:25

na akkor menjünk neki a problémának matematikailag:)

a floating szám:

N=M*2^K   ahol   1 <= M < 2


a logaritmus   :

log N=L  ahol 2^L=N

most számoljuk ki az N szám logaritmusát:

log N= log (M*2^K) = log(M) + log(2^K)= log (M) + K

tehát kijött az hogy az N szám logaritmusa egyenlö a karakterisztikával, meg a mantissza logaritmusának összegével

a log(M) értéke 0 és 1 közé esik mivel a mantissza 1 és 2 közé
ha kitudjuk számolni a log (M)-et készen vagyunk , ehhez elméletileg eltoljuk balra a számot pár bittel, legyen mondjuk 10
akkor igy néz ki:

log (M*1024)=log(M)+10 ebböl   log (M) = log(m*1024) - 10

a log (m*1024)-et kitudjuk számolni egy int>float konvertálással ahol a karakterisztika adja a közelitett értéket ebböl kivonjuk a 10-et és megkapjuk a log (M )közelitett értékét

és igy a K+log (M) már megad egy jo közelitést a logaritmus értékre és innen az osztáshoz márcsak kivonni kell


eddig jutottam még folytatom , de dolgozni is kell ..

látom nagyon beleszerelmesedtél az okosságodba, de ez így hihetelenül lassú lesz ám Már a mezitlábas pentium is tudott osztani 1994-ben 2-3 gépi ciklus alatt. a répacsel a modulo-n aritmetikák ferde testének a viselkedése. goedel, abel, frobenius maredéktételeit és a kongruenciaszabolyályokat felhasználva 2-3 iterációs lépésben számíthatsz hányados egy kb 10kByte méretû beépített függvénytáblázat segítségével iteratíve. voltis nagy bashnig 1995-ben amikor az intel elcseszte a beépített függvénytáblázatot a pentium pro-ban.

nálad int->float 1. ciklus
10 kivonása 2. ciklus
karakteristika hozzáadása 3. ciklus

mindezt 2x elvégezve (ostó, osztandó) és még különbségképzés már a 7. ciklusnál tartasz. Oké interleavelsz, kijössz 4 ciklusra. Ezek után még kell egy exp()-et hívnod, hogy visszakapd a hányadost. tehát jó esetben 5 ciklus, rossz esetben 8 ciklus. ennyi idõ alatt a pentium pro és minden normális fpu val rendelkezõ processzor már túl van 2-3 osztáson

arról nemis beszélve, hogy a te módszered egy textúrázáshoz mégy elmegy, de mérnüki gykorlatban, ahol 4-5 tizedesre minimum pontosnak kell lenned, már bajod lesz...

sokat szoptam a dologgal mikrokontrollerbe épített földgáz-kompressziós tényezõ számító algoritmus kapcsán. és hidd el nem így csináljuk már. Amit leírtál az az a módszer, ahogy az 50-es, 60-as években számolgattak magyarországon a mérnökök logarléccel. De utána már a mérnöki gyakorlatban is áttértek a függvénytáblázatos módszerre.

egyébként te is jobban jársz ha lerax a RAM-ba egy 1024 elemû log és exp táblát - tokkal vonóval 8 k és ezzel már 3 jegy pontos vagy, én így csináltam meg sok mindent a mikrokontrolleren (tablicával), habár egy 4 Gigán forgolódó proci számára az indirekt indexelt címzés 50 nanos RAM esetén már valszeg elég fájdalmas tud lenni.

Szerkesztette: SFIJ 2005. 03. 21. 21:00 -kor

[vers]

hát lehet hogy kicsit tul bonyolultra sikerült , és eljutottam  egy sima közelitéses algoritmushoz, ennyi erövel newton-raphson is mehet lookuptablaval, de probálkozásnak jo volt:)
másra még jo lehet, kitudja... pl n-edik hatványra gyors megoldás

Szerkesztette: vers 2005. 03. 21. 21:08 -kor

[vers]

"egyébként te is jobban jársz ha lerax a RAM-ba egy 1024 elemû log és exp táblát - tokkal vonóval 8 k és ezzel már 3 jegy pontos vagy, én így csináltam meg sok mindent a mikrokontrolleren (tablicával), habár egy 4 Gigán forgolódó proci számára az indirekt indexelt címzés 50 nanos RAM esetén már valszeg elég fájdalmas tud lenni. "

ugy látszik a táblázatoktol már sose szabadulunk meg 20 éve táblátzatbol szedem a szinuszt is
a vectorprocikban lehet táblákat tárolni a saját memoban ami gyors is, csak a  késleltetés  6 cycle, az se kevés...

Szerkesztette: vers 2005. 03. 21. 21:19 -kor

[vers]

a "hirek" szerint a ps3 devkitekben nincs grafikus proci, hanem valoszinüsithetöen 2 cell dübörög,valakinek  van ötlete hogy van ez? netán raytracing algoritmust használnak ?

Szerkesztette: vers 2005. 03. 22. 00:46 -kor