[dezz]

Idézet: Laa-Yosh - Dátum: 2007. máj. 31., csütörtök - 16:35

"Egy??? Hiszen mind szembe jön!!!!"

Nem jön itt szembe senki, csak kicsit túlerõben vannak az anti-cellisták+anti-ps3isták, akik még azt is fogat összeszorítva ismerik el, hogy pl. lehet egyátalán olyan feladat, amiben a Cell 20x gyorsabb, mint egy P4. Version, hová tûntél? :Ð

[SFIJ]

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Folyt. [URL=http://
Szerinted a 0-ról terveztek teljesen új SIMD alapegységeket, amikor már rég volt nekik?

Egyfelol siman lehet, masfelol a keresztsegben ha nagyon akarjuk inkabb az EE VU-ja az anyuka, mint a VMX

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Version hónapok óta nincs "sehol".

varj turelemmel

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

És mit értesz az alatt, hogy PPC értelemben vett, ha nem azt, hogy ugyanúgy vannak integer formátumok, és mindenféle általános jellegû mûvelet is végezhetõ velük?

Polo a reiszterblokk az opkodban maskepp cimzodik, a maszk flagek maskepp vannak, nincs meg a PPC-bol ismert utasitas orthogonalitas (mai nem baj) - ja es a PPC veremautomata - ezmeg nem, staobbi...

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Nem az lényeg, hogy van-e C++ fordító, hanem hogy milyen kódot lehet rá fordítani... A TMS chip kezeli az integer formátumokat? Vannak mindenféle integer mûveletek? Vannak pl. bitmanipulációs mûveletek? Vannak különféle címzésmódok?

perszehogy vannak

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Régen ezt az MMU-k még nem igazán tudták, az alapvetõ funkciójuk az address translation, azaz a memória-virtualizálás.

Nem. az MMU legfontosabb feladata a hozzaferesi jogosultsagok kezelese, ill. ezek megsertesekor kivetel dobasa

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

De mindegy, mert úgy tûnik, mindkettõt tudja:
"The MFC uses a memory management unit (MMU) to perform all MFC address translations and MFC access protection checks required for the DMA transfers. The MMU handles MFC transfers in much the same way that a PPE handles load and store operations."
Pl. tud olyat (asszem ezt a PPE állíthatja be, privileged módban), hogy a main memben hozzárendelhetõ 1-1 terület az egyes SPE-khez, és egymás területeit nem bánthatják.

Es szerinted hol allitodik ez be, tancsak nem a PPE deszkriptortablaiban?

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Hát nem egészen:
"Two steps are required to convert an effective address to a real address:
1. Convert the effective address to a virtual address. The conversion to a virtual address uses a segment lookaside buffer (SLB). The MMU for an SPE differs from the PowerPC Architecture only in the minimum number of SLB entries that must be provided by an implementation. The PowerPC Architecture requires a minimum of 64 entries; an SPE MMU requires a minimum of eight SLB entries. The maximum number of SLB entries is 4 K. All implementations must have at least a minimum number of SLB entries and the associated management instructions, special purpose registers (SPRs), and memory-mapped I/O (MMIO) registers.
2. Convert the virtual address to a real address. The conversion of a virtual address to a real address uses a page table in main storage. The page table format and the conversion process are described in PowerPC Architecture, Book III. In the software-managed mode, the TLB management instructions and registers must provide the capability to directly specify a virtual address to real address translation without using a hardware-accessed page table in main storage."

latod latod, szepen leirod, hogy a PPE konfigolja be lenyegileg az egeszet szupervigyorkent

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Ezt nem teheted meg, mert tudtommal ez a mûvelet privilegizált.

igen, de az SPE olyat hogy privilegizalt muvelet nemnagyon ismer

Idézet: dezz - Dátum: 2007. máj. 31., csütörtök - 1:20

Hagyjuk a core-t! Az Intel CPU-knál a nagy területet kitevõ L2 nem is tartozik bele. A die-ról volt szó. (Nem számoltam semmilyen pöttyöket, hanem kivágtam az egyik területet, és egymás mellé és fölé tettem annyit, amennyi kifért. [Egy oszlop, egy sor, nem tapétázás.])

szemantikai elbeszeles van koztunk, ugy latom. GPU-ban logikailag csak L1$ es tetxture$ letezik. Az L1$-t meg bele szokas erteni a core-ba.

[Laa-Yosh]

Akkor is enyém lesz az utolsó szó.

[SFIJ]

Idézet: Laa-Yosh - Dátum: 2007. máj. 31., csütörtök - 16:46

Akkor is enyém lesz az utolsó szó.

:Ð

[vers]

ennyi faszságot összehordani:D, a cell asmban gyorsabb csak, c-ben egy trágya
de ugyse áll neki senki asmban , ha neki is állna arra lesz16 cores pc szar, meg 2 teraflopsos gpu
amik eröböl lenyomják
a ps3 el lett cseszve , meg is látszik az eladásokon

[dezz]

Idézet: Laa-Yosh - Dátum: 2007. máj. 31., csütörtök - 17:46

Akkor is enyém lesz az utolsó szó.

Sosem ez motivált. Most pl. inkább a kíváncsiság. Baj? Nem foglalkozol velem egy kicsit túl sokat?

Idézet: SFIJ - Dátum: 2007. máj. 31., csütörtök - 17:46

Egyfelol siman lehet, masfelol a keresztsegben ha nagyon akarjuk inkabb az EE VU-ja az anyuka, mint a VMX

Mert?

Idézet

Polo a reiszterblokk az opkodban maskepp cimzodik a maszk flagek maskepp vannak, nincs meg a PPC-bol ismert utasitas orthogonalitas (mai nem baj) - ja es a PPC veremautomata - ezmeg nem, staobbi...

Attól még a regiszterek kialakítása és funkcionalitása hasonló. Megjegyzem, a GPR-rõl beszélünk, tudom, hogy vannak hiányzó és új regiszterek ezeken kívül.

Idézet

perszehogy vannak

Nocsak. Nem rossz. De az SPU-k azért okosabbak. Jóval több utasításuk van, közelebb állnak a CPU-khoz, van megszakításkezelés, tudnak multitaskingban mûködni, stb. Bár lehetne, de nem tudok olyan DSP-rõl, amiben ennyi belsõ, címezhetõ ram lenne.

Szó volt még a vektor-procikról. Eredetileg ezek cooprocesszorok voltak, egy normáls CPU nélkül nem sokra mentek. Azt hiszem, sokan most is így gondolnak rájuk. Látom, ma már vannak "okosabbak" is, amik egyedül is elboldogulnak. Ilyen értelemben tényleg beleférnek az SPU-k is ebbe a körbe. (Fõleg, hogy - ha jól látom - mindig 128 biten végzik a mûveleteket. Azt gondoltam, tudnak kisebb operandussal is dolgozni.)

Idézet

Nem. az MMU legfontosabb feladata a hozzaferesi jogosultsagok kezelese, ill. ezek megsertesekor kivetel dobasa

Jaj, de hát az elsõ MMU-kban ez a két dolog (szegmentálás és virtualizálás) teljesen összefonódott.

Idézet

Es szerinted hol allitodik ez be, tancsak nem a PPE deszkriptortablaiban?

Nem. Abban is van egy SDR1 nevû regiszter, de az rá vonatkozik. Az SPE-knek van saját MFC_SDR regisztere (amit a PPE ér el).

Idézet

latod latod, szepen leirod, hogy a PPE konfigolja be lenyegileg az egeszet szupervigyorkent

És? Magam is azt írtam, hogy a PPE indítja el a dolgokat, de utána már önállóan mûködhetnek az SPE-k.

Idézet

igen, de az SPE olyat hogy privilegizalt muvelet nemnagyon ismer

Ezt úgy kell érteni, hogy az SPE nem ismeri ezeket az utasításokat, nem fér hozzá ezekhez a regiszterekhez. Szép is lenne... És a PPE is csak privilegizált módban, azaz csak az OS által. Így oldották meg a DRM-et is, és nem tûnik túl könnyûnek a rendszer feltörése.

Idézet

szemantikai elbeszeles van koztunk, ugy latom. GPU-ban logikailag csak L1$ es tetxture$ letezik. Az L1$-t meg bele szokas erteni a core-ba.

És? A L2 a CPU-kkal kapcsolatban jött fel, hogy ott az teszi ki a die jelentõs részét. És mivel a L2 nem tartozik a core-hoz a prociknál, nem lehet azt mondani, hogy a core adott része, hanem a die adott része. Ezért a GPU esetén is értelemszerûen a die méretet kell alapul venni az összehasonlításban.

Idézet: vers - Dátum: 2007. máj. 31., csütörtök - 18:54

ennyi faszságot összehordani:D, a cell asmban gyorsabb csak, c-ben egy trágya
de ugyse áll neki senki asmban , ha neki is állna arra lesz16 cores pc szar, meg 2 teraflopsos gpu
amik eröböl lenyomják
a ps3 el lett cseszve , meg is látszik az eladásokon

Ez most valami pálfordulás akar lenni? Befuccsolt a játékprojekt, vagy mi? Akkor nem lesz 1 milliárd poligonos engine?
Egykbént mintha máshol azt írtad volna, hogy te C-ben is és asm-ben is nyomod.
Persze, hogy lesz mindenféle proci meg GPU (meg összvérek). Igen, majd pár év múlva... (Addigra lesz több PPE-s + még több SPE-s Cell is, persze ez a PS3 szempontjából nagyrészt mindegy.) Sokan mondják, hogy a PS3 el kell cseszve, de te miért mondod?

[SFIJ]

dezz szemantikailag sokmindenben kezdünk egyet érteni, nünaszny dolgokon meg nem érdemes folytatni a dolgokat. a TMS320C80 egy kedvenc gumicsontom, egy nagyon okos kis proci manapság leginkább a DLP projektorokban találod meg, elég áltcélú szvsz, talán azért nem mennék bele részletesebben mert az itaniumra hajaz, amugy nagyon cuki kis algebraic assembly nyelve van, a hozzáadott c/c++ fordítót használni ezértis fasság

Amit MMUilag vélsz az az IA32 platform evolúciójára igaz, deh az m68k-t, dec VAX prociját, vagy az IBM VM/ESA prociját nézed akkor azt látod hogy az MMU eredendõen a jogosultságok kezelésére jött létre ez még a 80286-ra is igaz éscsak ezután adták neki oda a virtuál->lineár->fizikai címfordítási mókát. Én amondó vagyok hogy az effektív PS3 kódokban valszeg virtcím=fizcím módot használják, mert az 2x-es indirekciózás hihetetlenül megfogja ám a teljesítményt. nota bene a windows se használ virtuális címeket, csak lineárisokat, a win-es DLL-ek elõre kötött lin címekre vannak befordítva. az M$ gondosan ügyel arra, hogy az általa szállított DLL-ek és exe-k ne tertelmazzanak címütközést és az M$ fontos partnereinek is - pl SAP, MAcromeda, Apple osztott ki címtartományokat. Ha ütközés van, akkor win alatt szépen kezdõdik a relokálási tánc. Mondjuk az M$nél ezt nem a címkezelés gyorsítása miatt használják így, hanem a valójában csak statikus linkelésre képes COFF3 object model kényszeríti ki.



szerintem a cell nem lett elcseszve, csak ezt a processzortípust nem lett volna szabad konzolba eröltetni. kb 3-4 év mire a szofferipar a cell-t kitatapsztalja, ennyi deje meg a PS3-nak mint terméknek nincs. Mindamellett a SONY-nak a 100milliós PS2 eladásokra való tekintettel egy PS2-vel visszamenõlegesen kompatibilis processzort/gépet kellett volna készítenie.


a szökõkutas udvar lemodellezéséért meg gratula, bár Boba kicsit leszólta, megmondom õszintén én ilyen dítéld és szép modell-t nem tudtam volna összetákolni és még a textúráis is elég szépek. kicist archicad style, de azért még csecse

Szerkesztette: SFIJ 2007. 05. 31. 23:22 -kor

[dezz]

Oks.

Kösz, de az nem az én munkám, csak kellett valami összetettebb. Elnézést, ha úgy jött le.

[special]

késve bár, de

a vektor processzor definíciója ugye nem attól függ, hogy milyen implementációk szoktak lenni, hogy van-e memóriavezérlõ, tud-e integer mûveletet vagy elágazásbecslést. sokkal egyszerûbb: a processzor vektorizáltan, egyszerre több adaton, vagy skalárisan hajtja végre a mûveleteket, egy adaton egy utasítás.

tekintve, hogy a spe-k vektormûveletekre vannak kihegyezve, hiszen mi másért lennének single precision fp mûveletekhez kizárólag 128 bites datapathok és registerek, és hogy kvázi skaláris mûveletvégzés csak valami perverz aberráció lehetne a programozó részérõl, így egyértelmûen vektorprocesszornak lehet hívni -- függetlenül bármi más maszatolástól a memóriahozzáférési modellben, vagy hogy milyen gyökerû ISA-t alkalmaz.

Szerkesztette: special 2007. 06. 06. 10:36 -kor

[dezz]

Tekintve, hogy a normál procik ma már skaláris és SIMD mûveleteket is végeznek, pontosabb lenne úgy megfogalmazni, hogy az a vektorproci, ami csak vektoros, azaz SIMD mûveleteket végez. Azonban, az SPU-knak is vannak skaláris, skaláris központú, ill. skaláris számítást is tartalmazó utasításai. Viszont a fõ aritmetikai mûveletek mind SIMD-esek.

Tehát, talán a legpontosabb megfogalmazás az, hogy az a vektorproci, aminek fõ aritmetikai mûveletei mind SIMD-esek.

Idézet

single precision fp mûveletekhez

(Nem csak SP-t ismer, és nem csak FP-t, ha így értetted.)

Idézet

kvázi skaláris mûveletvégzés csak valami perverz aberráció lehetne a programozó részérõl

Hát ezt azért nem mondanám. Akármilyen vektoros programban szükség lehet skaláris mûveletekre is. (És ha túl sok ilyen van, egyszerûen az architektúra nem-hatékony kihasználásáról beszélhetünk. Ebben az esetben a szám. telj. leredukálódik nagyjából egy hétköznapi proci szintére, na bumm. (Figyelembe véve, hogy az átlagos programok egy amúgy modern superscalar procin is csak 1.0 körüli IPC-vel futnak.))

[special]

Idézet: dezz - Dátum: 2007. jún. 9., szombat - 2:53

Tehát, talán a legpontosabb megfogalmazás az, hogy az a vektorproci, aminek fõ aritmetikai mûveletei mind SIMD-esek.

közel vagyunk. az SPE vektorprocesszor, mely képes ugyan kvázi skaláris végrehajtásra, de implementációja miatt alapvetõen vektorizált a felépítése: a skaláris számításokat is a vektoregységek hajtják végre.

az általános(abb) célú skaláris mpu-k skaláris végrehajtóegységekkel rendelkeznek, és vektor kiegészítéssel, mely csak egy toldalék mind az ISA-hoz, mind a chipek architektúrájához (persze mára integráns toldalék, a skaláris FP egység ma már tipikusan osztja a regisztereket és a logikát a vektorossal, hogy magasabb legyen a szilíciumterület kihasználtsága).

Idézet

(Nem csak SP-t ismer, és nem csak FP-t, ha így értetted.)

természetesen nem. úgy értettem, hogy az SPE-k tervezési célterülete a játékokban domináló 32 bites FP mûveletek. az integer végrehajtás és az akár 128 bites FP mûveletek explicit támogatása a rugalmasság miatt került bele.

Idézet

Hát ezt azért nem mondanám. Akármilyen vektoros programban szükség lehet skaláris mûveletekre is. (És ha túl sok ilyen van, egyszerûen az architektúra nem-hatékony kihasználásáról beszélhetünk. Ebben az esetben a szám. telj. leredukálódik nagyjából egy hétköznapi proci szintére, na bumm. (Figyelembe véve, hogy az átlagos programok egy amúgy modern superscalar procin is csak 1.0 körüli IPC-vel futnak.))

márpedig a cell nem vektorizált kódnál a potenciáljának töredékét hozza ki, ez tirivális. innentõl kezdve skaláris mûveletvégzésre alkalmazni az SPE-ket néhány az idõ néhány százaléknál nagyobb részében aberrált. arra ott van a PPE.

[dezz]

Talán kicsit aberrált, de ha éppen a PPE csutkára le van már terhelve, és van még feladat, ami éppen nem, vagy csak alig vektorizálható (de belefér az SPE-k kis ramjába, vagy streamelhetõ, stb.), adja magát a dolog. Még mindig jobb kis hatékonysággal használni õket, mint sehogy. Nem dõl össze a világ, ha csak egy valamivel átlag alatti egymagos proci teljesítményét hozzák (bizonyos feladatokban legalábbis), egyenként... Mégiscsak +6/8 mag. Vélhetõen sokszor fogják így, ill. így is használni õket. Ott vannak, nem szednek használati díjat, stb. Ugyanakkor jól vektorizálható feladatokban meg mindent bele... Kicsit más eset ez, mint ha külön építenénk egy vektor-procis gépet, aztán sima skaláris programokat futtatnánk rajta egyfolytában.

[Laa-Yosh]

Nyilván azért raktak bele skalár végrehajtást, hgoy ne kelljen minden ilyen utasításnál leállni a végrehajtással és DMA-zni meg a PPE-re várni. A sima számítási teljesítmény kérdése itt másodlagos, de hát soha nem is csak arról szól egy processzor...

[dezz]

Megint azt fogod talán majd mondani, hogy "mondatonként szétcincálom", de én egyszerûen csak értelemszerûen válaszolok, ill. kérdezek.

Idézet: Laa-Yosh - Dátum: 2007. jún. 10., vasárnap - 2:19

Nyilván azért raktak bele skalár végrehajtást

(Az alap aritmetikai mûveletek mind SIMD-ben mennek.)

Idézet

hgoy ne kelljen minden ilyen utasításnál leállni a végrehajtással és DMA-zni

Megmagyaráznád, mi a csudáért kellene ilyenkor DMA-zni?

Idézet

meg a PPE-re várni.

Tudomásom szerint DMA-zásnál nem kell a PPE-re várni. A PPE egy korai felkonfigurálásban állítja be az SPE-k MMU-it, a futás közbeni DMA-zást már az SPE-k maguk intézik. (De javíts ki, ha tévedek, fokozatosan ismerkedem a Cellel.)

Idézet

A sima számítási teljesítmény kérdése itt másodlagos, de hát soha nem is csak arról szól egy processzor...

Nem tudom, itt arra gondolsz-e, amirõl gondolom, hogy gondolsz, esetleg pontosíthatnád.

[special]

Idézet: dezz - Dátum: 2007. jún. 10., vasárnap - 11:38

(Az alap aritmetikai mûveletek mind SIMD-ben mennek.)

Mint mondtam, a skaláris végrehajtás nincs explicite támogatva az SPE hardverben, csak 128 bites vektor regiszterei vannak, így a processzor szemszögébõl minden adat és végrehajtás vektorizált. Nyilvánvalóan ebbõl fakad a hatalmas performance penalty is, ha átléped a hardver célterületét, a 32 bites FP mûveleteket.

Idézet

Megmagyaráznád, mi a csudáért kellene ilyenkor DMA-zni?

Az PPE és az SPE DMA-n keresztül kommunikálnak, vagy az ún. mailbox regisztereken keresztül, amikor elemi adatokat akarunk az PPE és az SPE között mozgatni. A ringbuson nem állnak kapcsolatba, ott az SPE-k beszélgetnek egymással meg a memóriavezérlõvel. Nagyobb adatblokkok mozgatásnál, vagyis például egy utasításfolyamnál, mikor jönnek esetleg skaláris mûveletek (rossebb tudja, miért), a DMA-t kellene használni, hogy a PPE átvegye az adatokat és a kontextust. A processzor szemszögébõl a DMA ugyebár rohadt lassú, és adatfüggõség esetén még többszálusítással  is túl költséges a PPE-re várni.

Idézet

Nem tudom, itt arra gondolsz-e, amirõl gondolom, hogy gondolsz, esetleg pontosíthatnád.

[dezz]

Idézet: special - Dátum: 2007. jún. 10., vasárnap - 12:13

Mint mondtam

Igen, mondtad, én is mondtam, akkor minek írod le még1x?

Idézet

csak 128 bites vektor regiszterei vannak

Ettõl még lehetne skalár végrehajtás is - csak éppen az aritmetikai mûveletek alapvetõen SIMD-esek, azaz minden elemre végrehajtódnak az adott regiszter(ek)ben. Viszont van néhány skalár, ill. skalár mûveletet is tartalmazó utasítás, ahol vagy egy predefined elemen, vagy kiválasztható elemekkel történik meg a mûvelet, vagy annak egy része. (szerk: szóval ha nagyon akarták volna, az arithmetikai utasításoknak is lehetne ilyen módozata. Csak ennek semmi értelme nem lenne itt, mert semmivel sem lenne gyorsabb egy ilyen skaláris mûvelet, mint a full SIMD-es, mert adott a 128 bites adat-út.)

Idézet

Nyilvánvalóan ebbõl fakad a hatalmas performance penalty is, ha átléped a hardver célterületét, a 32 bites FP mûveleteket.

Integer wordökkel (itt 32 bit) és halfwordökkel (itt 16 bit) is lehet szépen SIMD-esen dolgozni, így itt sincs kölönösebb penalty. (Sõt, egyes játékprogramozók kimondottan a fixpontosként használt wordös feldolgozást ajánlják, ahol elegendõ, mert az további 2x-es sebesség...)

Idézet

Az PPE és az SPE DMA-n keresztül kommunikálnak, vagy az ún. mailbox regisztereken keresztül, amikor elemi adatokat akarunk az PPE és az SPE között mozgatni.

(Valahol azt olvastam korábban, hogy PPE látja az SPE-k ramjait, de akkor úgy látszik, ez téves volt, ill. szerencsétlenül volt megfogalmazva.)

Idézet

A ringbuson nem állnak kapcsolatba, ott az SPE-k beszélgetnek egymással meg a memóriavezérlõvel. Nagyobb adatblokkok mozgatásnál, vagyis például egy utasításfolyamnál, mikor jönnek esetleg skaláris mûveletek (rossebb tudja, miért), a DMA-t kellene használni, hogy a PPE átvegye az adatokat és a kontextust. A processzor szemszögébõl a DMA ugyebár rohadt lassú, és adatfüggõség esetén még többszálusítással  is túl költséges a PPE-re várni.

Igen, csakhogy itt nem errõl volt szó, tehát hogy átadjuk a skaláris mûveleteket a PPE-nek, mert adott esetben ez több idõbe tellne, mintha az SPE-vel valósítjuk meg, igaz a hatékonyság rontásával. Az utóbbiról volt szó, így no PPE és DMA.

Szerkesztette: dezz 2007. 06. 10. 12:14 -kor

[special]

LY pont azt írta, hogy valószínûleg azért van értelme skaláris mûveleteket végeztetni az SPE-n, hogy ne kelljen DMA-n keresztül beszélni a PPE-vel.

[dezz]

Idézet: special - Dátum: 2007. jún. 10., vasárnap - 13:20

LY pont azt írta, hogy valószínûleg azért van értelme skaláris mûveleteket végeztetni az SPE-n, hogy ne kelljen DMA-n keresztül beszélni a PPE-vel.

Jahh, igaz. Elvonta a figyelmemet a "raktak bele skalár végrehajtást", miközben az alap aritmetikai mûveletekre vonatkozóan arról van szó, hogy bár az összes elemre végrehajtódnak, ilyenkor csak egy elemmel foglalkozunk, tehát a hatékonyság negyedelõdik (1db sp fp-nél v. int wordnél), illetve nyolcadolódik (1db halfwordnél). (És azért így sem lesz olyan nagyon kevés.)

[bogdan]

dezz, foglaljuk akkor ossze ertelmesen, amit mondasz! az az allitas, hogy ha SIMD modon nem is tudjuk kihasznalni a cell 8 SPE-jet, akkor meg mindig tudjuk hasznalni MIMD modon 8 szal egyideju vegrehajtasara.

nos azt kell mondjam, hogy bar ez hatarozott elony, de megsem akkora. HA mar tudunk parhuzamositani, akkor sokszor tudjuk az SIMD-t is hasznalni (plane mivel az vegyesen SIMD/MIMD, hiszen 8 kulonallo SIMD vegrehajtoegysegunk van.)

a tobbiek allitasa ezzel szemben valami olyasmi, hogy HA nem tudunk parhuzamositani, akkor megette a fene az SPE-ket, akar vektorosan, akar nem vektorosan hasznalnank oket..

(nagy leptekben, es pontatlanul, de ugy hiszem itt all a vita.)

[dezz]

Nem egészen. Amit "én mondok", az csak annyi, hogy az SPE-kkel skaláris számításokat is lehet végezni (és amúgy ez eleve elkerülhetetlen legalább néha-néha, mert nem lehet szinte semmit 100%-osan SIMD-esíteni), csak ilyenkor a hatékonyság, vagyis kihasználtság 25 v. 12.5 %-os lesz. Ennyi, sem több, sem kevesebb. Nem tudom, mi értelme lenne ezt vitatni.

Párhuzamosításról nem volt szó. De ha már szóba hoztad, ill. a 8 (6) SPE-t: na most képzeld el azt az esetet, hogy minden SPE más-más feladaton dolgozik... (Ezt nem tudod SIMD-esítve összehozni egy szálba.) Vagy együtt, de nem párhuzamosan ugyanazt csinálják, hanem a feladat más-más fázisát.

Szerkesztette: dezz 2007. 06. 10. 23:34 -kor