[d n . r]

Idézet: hvuk - Dátum: 2005. nov. 28., hétfõ - 23:46

Igen, ezekben valóban igazatok van, de még mindig maradt egy sor

Hát azt hiszem, csak az SMT maradt meg.
Viszont az meg, persze szintén csak ha jól tudom, nem épen a legsikerültebb multi-threading megvalosítások közül való...

PS: 

Idézet

Sõt marad még egy, ha printervezérlõ és grafikus kártya gyorsító processzorok kimaradnak (I860).   Meg azok a sorok amiket még oda lehet írni, csak nem jutott hirtelen eszembe. 

És mi ez a reframing, kérem szépen? Mi _azokról_ a dolgokról beszéltünk, amiket _akkor_ írtál...

Szerkesztette: d n . r 2005. 11. 28. 23:15 -kor

[SFIJ]

Idézet: special - Dátum: 2005. nov. 28., hétfõ - 21:26

SFIJ, én igyekszem, igyekszem korrekt és objektív lenni. Nem érzem, hogy a béka segge alá én vinném a beszélgetést, hacsak nem azzal vádolsz, hogy nem fogadom el az itteni többség véleményét, mikor illene, ezzel gerjesztve diszfunkcionális vitát. Azt sem érzem, hogy meg lennék itt szégyenítve, persze ettõl a többség véleménye lehet egészen más.

Igen, mûszaki elõképzettség nélkül ingoványos talajon állok autoritás szempontjából. Ugyanakkor nehezemre esik elfogadni, hogy tévedek, mikor gunyoros megjegyzések és kacarászások érkeznek válaszként, megtámogatva a "többségben vagyok" pszichés extra töltetével, nem sokkal több. Persze ez csak az én érzésem, és csak egyszerûen képtelen vagyok átlátni és belátni dolgokat.

Nem baj, úgyis az utóbbi idõben túl sok idõt fordítottam erre, úgy látszik, legalább destruktívan. Ígérem a jövõben nem fogom felvenni a kesztyût az itteni x86-fétissel, akkor sem, ha egyoldalas pr-anyagokban mást olvasok.

Bocsánat mindenkitõl az offért.

special ha szavaim, amik migött bevallom állot némi indulat bántóak lettek volna, akkor elnézést. Tudni annyit illik, hogy a lebegõpöttyös mûködés keretparemétereit az IEEE specifikálja. Az általad most kidomborított RAS funkciókat ugynevezett featur set-ek formájában a JEDEC adta meg. vagyis hogy milyen csekkeket kell támogatni, milyen statisztikai számlálókat kell támogatni, stb... A cache hibatûrésnek paramétereit is a JEDEC specifikálja, különbözõ ajánlások mentén.
Aki jó termékeket akar, az aszondja én támogatom ezt meg azt meg amazt a JEDEC csomagot. A verseny azt okozza, hogy a gyártók egyre több ilyen meg olyan csomagot támogatnak. Ez tök olyan mint amikor cégek mûködnek valahogy, de arra komoly hangsúlyt fektetnek hogy errõl legyen egy ISO 9000/9001 tanusítványuk, mert ez versenyelõnyt és/vagy lehetõséget jelent komoly párlyázatok beadásakor. Magyarán az AMD és az Intel meg az IBM meg a SUN pontosan ezért támogatja a mgefelelõ JEDEC csomagokat. teszik ezt azért, mert szeretnek a termékeikkel pályázatokat nyerni US Governmental meg Military tendereken. Ott meg beleírják a pályázati anyagba, hogy ez, meg az amazt a JEDEC-et meg ezt és azt a IEEE-t kell tudni. Ezért az, hogy elõhozod, hogy bezzeg a power4/power5 az X86-hoz képest... Gondolod a többi versenytárs nem tudja? Gondolod az AMD szarik a US Governmental, NCSA meg Military megrendelésekre? Gondolod a Cary építhet szupergépet opteronokból a lawrence livermoore labs-nak (ahol az US legjelentõsebb atomkutatásait végzik) hogy az AMD nem támogatja a processzoraiban azokat a sztenderdeket amik nélkül érvényes pályázatot be se tudna adni?

[d n . r]

Idézet: hvuk - Dátum: 2005. nov. 28., hétfõ - 23:22

Igen, errõl már vitatkoztunk régebben, bár nem ártana, ha beírnád a 6 problémát, hogy mi is tudjuk mik azok.

Na akkor bemásoltam, de egyrészt ez szerzõi jogi problémákba ütközhet, másrészt leszakad a csuklóm, úgyhogy aki többet akar, annk irány a könyvtár

Idézet

A.S. Tanenbaum: Számítógép-architektúrák

2001 Budapest, Panem könvykiadó


5.8.1. A Pentium II problémái (419. o.)

A fõ ok, ami az IA-32 bajait okozza az, hogy egy õsi ISA az összes rossz tulajdonságaival a mai technológiában. AZ IA-32 CISC ISA, változó utasításhosszal, számtalan formával, amit nehéz gyorsan dekódolni. A jelenlegi technológiák legjobban a RISC ISA-val mûködnek, amelyekben egy utasításhossz és rögzített mûveleti kódhossz van, amit könnyû dekódolni. Az IA-32 utasításait szét lehet tördelni RISC-szerû mikroutasításokká futási idõben, de ez hardvert (lapka területet) és idõt igényel, továbbá bonyolultá teszi a tervezést. Ez az elsõ csapás.
Az IA-32 kétcímes, memoriaorientált ISA. A legtöbb utasítás hivatkozik a memóriára, és a legtöbb programozó és fordítóprogram nem foglalkozik a memóriahivatkozásokkal. A mai technológia elõnyben részesíti a töltõ/tároló architektúrákat, amelyek csak az operandusok kiolvasása végett hivatkoznak a memóriára, egyébként háromcímes memóriaregiszter utasításokkal számolnak. És mivel a CPU órajelsebessége nagyobb mértékben növekszik, mint a memóriáké, idõvel a probléma egyre súlyosabb lesz. Ez a második csapás.
Az IA-32nek kicsi és szabálytalan regiszterkészlete van. Az hagyján, hogy ez megköti a fordítóprogramok keét, de a kevés általános regiszter (négy vagy hat, attól függõen, hogy az ESI-t és az EDI-t hova soroljuk) miatt a részeredményeket a memóriában kell tárolni, ami fölösleges memóriahivatkozásokat generál, akkor is, amikor erre logikusan nincs szükség. Ez a harmadik csapás. Az IA-32 kiütve.
Kezdjük a második menetetet.A kevés számú regiszter sok függõséget okoz, különösen WAR-függõséget, mert az eredményt tárolni kell, de nincs elég regiszter. A regiszterek hiányának leküzdése belsõ átnevezésre kényszerít - a legrosszabb, ami létezhet - , titkos regiszterekké az átrendezõ pufferen belül. A gyorsítótár blokkolásának elkerülése gyakran késik, így az utasításokat sorrenden kívül kell végrehajtani. Azonban az IA-32 szemantika pontos megszakításokat specifikál, ezért a sorrenden kívüli utasítások sorrendjét helyre kell állítani. Mindez nagyon bonyolult hardvert igényel. Negyedik csapás.
Ahhoz, hogy mindezt gyorsan el lehessen végezni, nagyon hosszú (12 lépéses) csõvezetékre van szükség. Másrészt, a hosszú csõ azt eredményezi, hogy az utasításoknak a befejezésük elõtt 11 ciklussal be kell lépniük a csõbe. Következésképpen, , nagyon pontos elágazási jóslás kell ahhoz, hogy a megfelelõ utasítás kerüljön a csõbe. A jóslási tévedés a csõ kiürítését kényszeríti, ez nagy költség, még egy csekély tévedési arány is jelentõs hatékonyságcsökkenést okozhat. Ötödik csapás.
Hogy enyhítsék a jóslási tévedés okozta problémát, a processzornak spekulatív végrehajtást kell végeznie minden felmerülõ problémával, ha a téves úton való memóriahivatkozások megszakítást okoznak. Hatodik csapás.
Nem kivánjuk tovább folytatni a mérkõzést, de világos, hogy itt valóban probléma van. És még meg sem említettük azt a tényt, hogy a 32 bites címzés miatt az egyes programok a 4GB memóriában vannak korlátozva, ami egyre növekvõ problémája a nagy szerevereknek.

[d n . r]

Idézet: hvuk - Dátum: 2005. nov. 28., hétfõ - 23:22

Most látom, hogy mennyire figyeltek a szavaimra, mert a fent d.nr által idézett szövegben alapvetõ kapitális elírás van.

Mellesleg én meg most látom, hogy általad a nick-emben alapvetõ kapitális elírás van

[SFIJ]

Idézet: Haderach - Dátum: 2005. nov. 28., hétfõ - 22:20

hat ha mar erre jarunk akkor 1989ben az intel i860 implementalta eloszor az mmx utasitaskeszletet, de az sem x86. 

meg az volt az elsõ vliw processzoruk is :Ð

[SFIJ]

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:09

Idézet

Tannembaum:  AZ IA-32 CISC ISA, változó utasításhosszal, számtalan formával, amit nehéz gyorsan dekódolni.

Nagyon egysíkú meglátás. Ami egyfelõl hátránynak tûnik más szempontból meg elõny: nagyon jól látszik, hogy a RAM technológia fényévekkel marad el az MPU technológia mögött. az x86 a huffmann-kódoálshoz hasonló változó utasításhosszával és a "RISC"-eknél alacsonyabb átlagos utasításhosszával versenyelõnyt tud felmutatni a memória sávszélesség limitáció miatt: Azonos memória-sávszélesség x86 ISA "átereszteõ-képessége" magasabb mint fix hosszú ISA (RISC/EPIC) (ami 32 ill 128 bites utasításokat jelenet) "áteresztõ-képessége". Soha nem szabad a dolgokat egyoldalúan megítélni: mindig vannak pro-k és con-ok.

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:09

Idézet

Tannembaum:  Az IA-32 kétcímes, memoriaorientált ISA. A legtöbb utasítás hivatkozik a memóriára, és a legtöbb programozó és fordítóprogram nem foglalkozik a memóriahivatkozásokkal. A mai technológia elõnyben részesíti a töltõ/tároló architektúrákat, amelyek csak az operandusok kiolvasása végett hivatkoznak a memóriára, egyébként háromcímes memóriaregiszter utasításokkal számolnak. És mivel a CPU órajelsebessége nagyobb mértékben növekszik, mint a memóriáké, idõvel a probléma egyre súlyosabb lesz. Ez a második csapás.

Ez a problémát 2 módon sikerült orvosolni: az egyik a nagyobb L1D$, am ásik a register reenaming technika. a processzor csak kifele mutat 2 címes alacsony regiszterszámú mûködést, odabent már 3 címes.

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:09

Idézet

Tannembaum:  Az IA-32nek kicsi és szabálytalan regiszterkészlete van. Az hagyján, hogy ez megköti a fordítóprogramok keét, de a kevés általános regiszter (négy vagy hat, attól függõen, hogy az ESI-t és az EDI-t hova soroljuk) miatt a részeredményeket a memóriában kell tárolni, ami fölösleges memóriahivatkozásokat generál, akkor is, amikor erre logikusan nincs szükség. Ez a harmadik csapás. Az IA-32 kiütve.

tannembaum itt tolja a FUD-ot. okosabb programozók és compilerek már idõtlen-idõk óta használták az Fp (XMM) regisztereket átmeneti adattárnak. amiról Tannembaum beszél az az IA-16 vagyis az 1979-es állapot. Azóta az AMD64/EMT64-nek köszönhetõen ISA kibõvült 8 db áltcélú és 8 db lebegõpontos reiszterrel így összesen 16 regiszter áll rendelkezésre mindkét fajtából, azaz 32 regiszter.

Úgy érzem tannembaum aggájai az idõk során orvosolva lettek. az egy más kérdés és ez átvonul is már az íráson, hogy Tannembaum-nak nem tetszenek ezek a megoldások. A nagy büdös helyzet ellnben az, hogy az X86 a spec tesztek alapján mára oda jutott, hogy nemcsak hogy felnõtt teljesítményben a RISC processzorokhoz, hanem az egyetlen itaniumot kivéve a teljes mezõnyt lemossa teljesítményben a porondról. És egy valamit ne felejtsünk el: Egy x86 egy gyenge minõségû, rosszul optimalizaált vagy uram bocsá egyéltalán nem optimalizált assembly kód esetén jó, elfogadható teljesítményt ér el, eközben egy RISC/EPIC proceszor egy gyengén optimailzált kódnál katasztrófálisan rossz teljesítményt ér el.

Szerkesztette: SFIJ 2005. 11. 28. 23:40 -kor

[bogdan]

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:14

UltraSPARC-I 1995 ben jelent meg, és ebben volt egy VIS (Visual Instruction Set) nevû utasításkészlet, ami pont arra szolgált, mint az MMX.

jaja, az mplayer meg optimalizal is ra! (azaz nem MMX, inkabb SSE vagy 3DNow jellegu)

Idézet

Viszont az MMX a P-IIvel jelent meg, és csak 1997ben.

ugyan erre mar jott elvadultabb pelda, de en egy egyszerubbet mondok. kersz tolem ajandekba 166MMX Pentium1 processzort?? (annyiban van igazad, hogy a PPro-ban nem volt, csak utana jott a P1 vonalra is.)

Idézet

különben special-nak igaza van, tényleg nem egyszerû a többség ellen védekezni (és az már szinte mindegy is, hogy igaza van-e az embernek, vagy sem )

mire gondolhatsz.. :D (es megbocsass, de a nikked olyan marhasag, hogy nem csodalom, hogy barkinek nehez ideznie..)

Idézet

de azért pár év múlva érdekes lesz visszaolvasni

jaja!! ezt tanusithatom, mert nagyon erdekes volt 2 honapja is vegigolvasni az egesz topicot. mindenkinek ajanlom, akinek van elcsapni valo 2 napja..

****************************************************************************************
V! az altalad beidezett 6+1 csapasbol a tobbseg nem all am ma! 2 (es nem 1) panaszkodik a regiszterek szamara, ezt az A64 kiuti. ketto hivatkozik a hosszu csovezetekre illetve a messzi memoriara: erre gyogyir a steaming, azaz az SSE, egy meg a microcode problemara (illetve az elozoek a bonyolult elagazasbecslesre, meg a spekulativ vegrehajtasra). ezek valoban problemak, de nekem ugy tunik a technologia eleg jol halad, hogy minimalizalja az ebbol fakado hatranyokat. egy marad csak, amihez nem ertek: a programszervezesi kerdes. (memoriahivatkozasok.)

[d n . r]

Idézet: SFIJ - Dátum: 2005. nov. 29., kedd - 0:23

(1) amiról Tannembaum beszél az az IA-16 vagyis az 1981-es állapot. Azóta az AMD64/EMt64 óta az ISA kibõvült 8 db áltcélú és 8 db lebegõpontos reiszterrel.

(2) A nagy büdös helyzet ellnben az, hogy az X86 a spec tesztek alapján mára oda jutott, hogy nemcsak hogy felnõtt teljesítményben a RISC processzorokhoz, hanem az egyetlen itaniumot kivéve a teljes mezõnyt lemossa teljesítményben a porondról. És egy valamit ne felejtsünk el: Egy x86 egy gyenge minõségû, rosszul optimalizaált vagy uram bocsá egyéltalán nem optimalizált assembly kód esetén jó, elfogadható teljesítményt ér el, eközben egy RISC/EPIC proceszor egy gyengén optimailzált kódnál katasztrófálisan rossz teljesítményt ér el.

(1) erre írtam az eredetiben, hogy ebben mindenképpen elõreléps az x86-64

(2) itt viszont az a kérdés, hogy mi lesz 3-4 év múlva?

Lesznek négymagos x86-procik. Na és? Ugyanígy lehet négymagos Itanium és Power is.
Az órajelet pedig növelhetik a jelenlegi DC 2,4 körülirõl mondjuk 3-3,5re (a Hammer ugyanúgy, mint a Merom/Conroe/Woodcrest)

Ki tudja, hogy nõ a konkurencia?

Én csupán arra akartam felhívni a figyelmet, hogy nagyon sok olyan dolog függvénye, mi lesz az x86-tal, amit most még (szerintem) nem igazán lehet látni.

Persze vitatkozni és jósolni attól még lehet

Szerkesztette: d n . r 2005. 11. 28. 23:49 -kor

[d n . r]

Idézet: bogdan - Dátum: 2005. nov. 29., kedd - 0:39

ugyan erre mar jott elvadultabb pelda, de en egy egyszerubbet mondok. kersz tolem ajandekba 166MMX Pentium1 processzort?? (annyiban van igazad, hogy a PPro-ban nem volt, csak utana jott a P1 vonalra is.)

Nemhogy "annyiban van igazam", hanem MIKOR is tették bele az MMXet a Pentium-ba?

Mert a könyv ezt is megmondja ám... Szóval a P-II _után_

[d n . r]

Idézet: hvuk - Dátum: 2005. nov. 28., hétfõ - 23:22

Az is látszik, hogy a multi-core-é a jövõ és ezen belül meg fognak jelenni a segédprocesszorok is, ezek pedig lényegesen nagyobb számítási kapacitással fognak rendelkezni, mint bármely általános célú mag, hívják azt akár Itaniumnak is. Mivel egy ilyen multi-core maghoz a fordító nem lesz semmiség, és mivel az erõforrások és az idõ véges, ezért nyilván az a processzor architekturára lesznek jobban implementált szoftverek, amelyekre érdemesebb lesz fejleszteni és amelyik nagyobb install base-el, így lényegesen nagyobb tesztelési lehetõséggel rendelkezik. Szerinted melyik lesz az: X86, Itanium, Power, SPARC?

Hm.
Mondanivalóm lényege éppen az, hogy nem kéne azt hinni, hogy ez a kérdés ilyen egyszerûen dõl majd el.

Melelsleg jelenleg _egyetlen_ ilyen architekturát ismerünk, mégpedig a CELL-t. Az ugyebár melyik is az általad felsoroltak közül?

[bogdan]

Idézet: d n . r - Dátum: 2005. nov. 29., kedd - 0:48

Nemhogy "annyiban van igazam", hanem MIKOR is tették bele az MMXet a Pentium-ba?

Mert a könyv ezt is megmondja ám... Szóval a P-II _után_

hat utana nehezen, mert nem MMX-es P2-es nincs. es eredetileg Te azt irtad, hogy "az MMX a P2-vel jott", ami azt mondja, hogy az elotte valo processzorgeneraciokban ilyen nincs. pedig van. (a PPro utan jott. ez a teny, es ennyiben van igazad, nem masban. )

a konyvet meg olvasd figyelmesebben, hatha megsem azt mondja, hogy utana.

Idézet

Melelsleg jelenleg _egyetlen_ ilyen architekturát ismerünk, mégpedig a CELL-t. Az ugyebár melyik is az általad felsoroltak közül?

ne kavarj, nem ez volt a kerdes! mert hiaba Power ISA a Cell, ha a kerdes az, hogy mire olcso fejleszteni.

[SFIJ]

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:48

Nemhogy "annyiban van igazam", hanem MIKOR is tették bele az MMXet a Pentium-ba?

Mert a könyv ezt is megmondja ám... Szóval a P-II _után_

Az intel az MMX-et 1997 februárjában jelenti be PII esetére. Mivel az AMD k6 eladások nagyon felfutnak megjelenik a kiterjesztés szeptemberre a még tradicionáls CISC szuperskalár pentium vonalban is.

[SFIJ]

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:45

Ki tudja, hogy nõ a konkurencia?

Én csupán arra akartam felhívni a figyelmet, hogy nagyon sok olyan dolog függvénye, mi lesz az x86-tal, amit most még (szerintem) nem igazán lehet látni.

Nem tudom. De én azt látom, hogy az AMD feljövõ hammer-derivatív ecosysteme olymértékû bevételgyarapodást okoz és ezáltál fejlesztési budgetet hozva létre, amit a "RISC" versenytársak már nehezen bírnak követni. A fene tudja az Intel mit tud felmutatni. De az intelnek az a baja, hogy egyfelõl a XEON termékvonalaon is ráncfervarrást kell végrehajtania, a netburst architektúrát fel kell váltani pentium-m alapúval aközben az itanium tervezési hibáit is orvosolnia kell. Intel esetében az látszik, hogy 2 frontharcos processzort még õ sem tud pénzügyileg finanszírozni, ráadásul mindkettõ piaca szûkülõfélben vagyon. Az Intel elõbb utóbb választani kényszerül az itanium és az EMT64 platformjai közül.

Szerkesztette: SFIJ 2005. 11. 29. 00:11 -kor

[hvuk]

Idézet: d n . r - Dátum: 2005. nov. 28., hétfõ - 23:09

Na akkor bemásoltam, de egyrészt ez szerzõi jogi problémákba ütközhet, másrészt leszakad a csuklóm, úgyhogy aki többet akar, annk irány a könyvtár

Köszi. Bár elég lett volna címszavakban.

1. Változó utasításhossz. Egyrészt elõnye is van (lásd SFIJ megjegyzését), másodszor elég gyorsan dekódolják. Pont elég gyorsan ahhoz, hgoy megverjék a RISC-eket.

2. Kétcímes, memóriaorientált ISA. Ez az ami nem vált igazzá. Nem nõ és nem is fog olyan sebességgel nõni a processzorok órajele, hogy ez igazi probléma legyen, a cache és más technikák elfedik ezt.

3. Kicsi és szabálytalan regiszterkészlet. Ma már nem igaz. X86 nincs kiütve.

4. Átnevezés és regiszterhiány. Szintén nem áll fent.

5. RISC-ek csöve is hosszú ma már. A nagyon pontos elágazásjelzést pedig az X86 procikban ma már benne van.

6. Spekulatív végrehajtás. Nem tudom. Gond ez?

+1. 4 Gbyte korlát. Ma már nem az.

Látszik, hogy milyen nehéz jósolni, különösen, ha a jövõre vonatkozik. Mondjuk kisebb arccal azért probálkozhatott volna, mert ez a sok "kiütés" és "csapás" duma elég mókás így 2005-bõl nézve.

Szerkesztette: hvuk 2005. 11. 29. 00:36 -kor

[SFIJ]

Idézet: hvuk - Dátum: 2005. nov. 29., kedd - 0:21

Látszik, hogy milyen nehéz jósolni, különösen, ha a jövõre vonatkozik. Mondjuk kisebb arccal azért probálkozhatott, mert ez a sok "kiütés" és "csapás" duma elég mókás így 2005-bõl nézve.

ugyanarrol a tanembaum bácsiról beszélünk aki megmondta frankót, hogy a monolitikus kernelek kipusztunak és a mikrokerneleké a jövõ. talán itt esett pofára a leginkább. az nt mikrokernelként indult és mára plugin architektúrájú monolitikus kernellé vált :Ð

Szerkesztette: SFIJ 2005. 11. 29. 00:36 -kor

[bogdan]

Idézet: hvuk - Dátum: 2005. nov. 29., kedd - 1:21

Látszik, hogy milyen nehéz jósolni, különösen, ha a jövõre vonatkozik. Mondjuk kisebb arccal azért probálkozhatott volna, mert ez a sok "kiütés" és "csapás" duma elég mókás így 2005-bõl nézve.

azert valakinek szabad.. megha nem is lesz igaza a vegen. (es igen, o volt az, aki megmondta Linus-nak, hogy marhasag, amit csinal )

[Haderach]

Idézet: SFIJ - Dátum: 2005. nov. 29., kedd - 0:35

ugyanarrol a tanembaum bácsiról beszélünk aki megmondta frankót, hogy a monolitikus kernelek kipusztunak és a mikrokerneleké a jövõ. talán itt esett pofára a leginkább. az nt mikrokernelként indult és mára plugin architektúrájú monolitikus kernellé vált :Ð

a minix meg tartja magat, most is igazi mikrokernel, es most sem hasznalja senki

[d n . r]

Idézet: bogdan - Dátum: 2005. nov. 29., kedd - 0:56

hat utana nehezen, mert nem MMX-es P2-es nincs. es eredetileg Te azt irtad, hogy "az MMX a P2-vel jott", ami azt mondja, hogy az elotte valo processzorgeneraciokban ilyen nincs. pedig van. (a PPro utan jott. ez a teny, es ennyiben van igazad, nem masban. )

a konyvet meg olvasd figyelmesebben, hatha megsem azt mondja, hogy utana.

Hát pedig azt mondja

Szerintem gondold ezt végig még egyszer

(ja, ajánlom hozzá SFIJ post-ját is)

PS: szóval még egyszer: amit ott leírtam, abban úgy tûnik _mindenben_ igazam volt

[d n . r]

Idézet: bogdan - Dátum: 2005. nov. 29., kedd - 0:56

ne kavarj, nem ez volt a kerdes! mert hiaba Power ISA a Cell, ha a kerdes az, hogy mire olcso fejleszteni.

Hmm, szerintem pl. Mac-re jó csomó dolog _már_ megvan...
(sõt, néha már az a baj, hogy  - "hála" Jobbs-nak - _csak_ Mac-re van, x86-win-re pedig _már_ nincs - zeneszerkesztés, videoeditálás)

Amúgy pedig itt* nem ám az a helyzet, mint az IA-64nél, hogy iszonyat problémás a portolás!

(* szerk: mármint a power-derivált CPUra gondolok, hogy nem hiszem, hogy nehéz rá portolni.
A cell-szerû architektúra persze más ügy, de az akkor sem lesz egyszerûbb, ha x86 mag lesz a központban)

Szerkesztette: d n . r 2005. 11. 29. 01:03 -kor

[SFIJ]

urak ne kavarjunk. ha az SPE-re teccettek gondloni, na annak az ISA-ja nem része a power ISA-nak. Azt Az ISA-t a sony tervezte és az emotion engine-ben (PS2) debütált. csak mot 8 darab van belõle egy cpu-ban nemcsak 1

Ami a mekket illeti gyönyörüen szala már X86-on a 10.4.3. épp a garageband-del jáccom sirály. tudjátok mi a lexebb az egészben? nos az hogy a szoftok 80%-a PPC kód, egy rosetta nevû emulátoron fut (olyasmi int az IA32El az itanichoz) és egy prescotton HT és SSE3 esetén rohadt gyors. nem viccelek! Az interpetált quicktime realtime, framedrop nélkül játszik HD videot míg a windows alá rakot "natív" quicktime erre nem képes :Ð

edit. most futtattam cinebench-et is. a Pentium4 640-em úgy hogy interpretálja a PPC kódot lemosta porondról az 1.44GHz-es G4-et. wow   

Szerkesztette: SFIJ 2005. 11. 29. 01:14 -kor