Azt a fontos dolgot kihagytátok a tényekbõl, hogy adott esetben elég az OS-nek is "okosan" kiosztani a dolgokat... mondok egy tényt, amit kipróbáltam.
Otthon ülsz, és épp játszom egy játékkal (most mindegy mi, az újabbak közül egy "gépfaló"), közben dvd-t írok 4x néróval (arra odafigyeltem, hogy másik vinyó legyen!), közben rar-ral csomagolok be egy 8gigás dvd mappát, miközben felhívtam valakit skype-on, hogy beszélgessünk.
A lénye: a skype társam kikpacsolt HT-nél nem nagyon értett, mert akadozott a hangom, bekapcsolva nem volt semmi gond.
Tehát én azt akarom mondani, hogy egy általános otthoni felhasználásnál is lehet elõnye, NEM KÖTELEZÕ MINDEN ESETBEN ARRA GONDOLNI, HOGY VAN EGY PROGRAM, AMIT FUTTATOK, kihasználja és akkor überkirály?
Nem csak erról szól a fáma, hanem arról, hogy több program futása közben (bármi is legyen az), ha "ügyes" az OS, akkor nem érzed a "lassulást"!
Ezt a fontos dolgot miért hagyjátok ki???
UI: Természetesen a cikkben leírtak elõfordulhatnak, de hálistennek engem eddig pozitívan érintett a HT, még ha nincs is se szerverem, se SQL-em
Ja, kicsit csalóka a cikk: a képeken nem 4-magos, hanem 2-magos Xeon látható... De a cikk közepe táján ott van, hogy a 4-magosat csak 2007-ben mutatják majd be.
Elvileg elõbb lehet majd (nemsokára) kapni a dual Cell alapú Blade szervereket, mint a PS3-at. (Már kész van hozzá egy Linux port, ami az SPE-khez is nyújt támogatást [megkönnyíti a kihasználását]. Alapból a PPC magon [amely mag azt hiszem az eddigi legjobb PPC] futnak a programok, és ahol szükséges, át lehet írni a teljesítmény-érzékeny részeket az SPE-k használatához.) Bár gondolom ára is lesz, ezért egyelõre katonai és pl. orvosimûszer vonalon fogják nyomni.
(És az lenne a jó, ha kikapcsolt HT-val is lenne benne teszt, mert elõfordul, hogy 1-1 program eleve jóval gyorsabb Intelen, mert pl. egyszerûen nem használja AMD-n az SSE2-3-at, vagy esetleg egyéb módon van erõsen P4-re optimizálva. Ezekben az esetben HT nélkül is hasonlóan gyorsabb.)
Erre nem vennék mérget. Egyelõre ugye 90nm-en gyártják a procikat, legalábbis a Pentium/Celeron vonalon. Ezért a 4 maghoz kb. 2x nagyobb chip kell, mint a 2 magoshoz. Valószínû ezért 2x többért is adnák, hiszen miért dolgoznának kisebb haszonkulccsal?
Xeon vonalon kevésbé számítanak a költségek és jobban a teljesítmény önmagában, ott hajlandóak megfizetni ennek árát a vevõk. De ki venne félmillióért procit PC-be?
A másik: a Xeonnak kicsivel ütõsebb lehet a rendszerbusza (plusz a hozzá tartozó chipset), az (még) elviszi a 4 magot. Vajon a Pentium/Celeron-féle rendszerbuszról is elmondható ugyanez? Nem hinném.
Ha mutatsz olyan tesztet, ahol egy HT-s P4 párhuzamos szálak esetén tényleg jóval gyorsabb egy A64-nél, akkor más szemmel fogok rá nézni. :) Természetesen én sem egy tesztbõl indultam ki, fõleg hogy tomshw, annak idején néztem néhány másikat is. Olyannal eddig nem találkoztam, ahol a fenti esemény következett volna be.
itt még mindig az a baj egészen le1xerûsítve hogy a cell-t még nem lehet =nlõre megvásárólni ellentétben a 4 magos Xeon al :( az elõzõ eseteben olyan dologrol vitatkoztok ami még nincs is alán csak képen és elméletben=cell ha végre lessz cell az meg fogja könnyíteni a vita dolgokat a a prototipustól kezdve nézzük a cell-t és mire polcokra kerûl .. már lassan a cell en is újjitani kell mert már 1 éve van de még sincsen ez itt a nagy baj:)
"Neked Xeon van az asztali gépedben?"
Ezt most kérdezted Dez, szerintem ez teljesen mindegy ez a 4 mag bennne lessz az az EE procikban és párhónap mulva még a Celeronokban is:)
Most keressek olyan teszteket ahol a P4HT gyorsabb? ;)
Egyébként teljesen igazad van, soha sem lesz 100%-os, de megfelelõ programozással simán el lehet érni a 60%-ot. Itt megint a fõ gond hogy csak az Intel támogatja (rövid pipe-nál nincs értelme megcsinálni) ezért hülyeség vele idõt eltölteni.
Nem akarlak mindenáron meggyõzni hogy ez valami tökéletes dolog - nem is az - de szerintem ez a merev ellenérzés nem helytálló, hiszen egy egyszerû módszerrel ingyen teljesítményhez juttatja a felhasználókat. Ez szerintem óriási dolog.
Az utolsó mondatokhoz még: plusz, ami van gyorsulás, az végülis a hosszú pipe multi-thread környezetben szenvedett hátrányát ellensúlyozza - azaz nem egy A64-hez képest lesz ennyivel gyorsabb, csak saját magához.
Nézd csak ezt az oldalt. Itt egyrészt nem sokkal gyorsabban fut, mint A64-en, másrészt semmivel sem gyorsabb P4-en (A64-hez viszonyítva), mint a többi hasonló program. Ugyanakkor különös, hogy miközben az X2-n kb. 2x gyorsabb, mint az egymagoson (egyforma órajelen), a P-D-n alig gyorsabb, mint a simán (kicsivel alacsonyabb órajelen bár a P-D-n, de ez nem magyarázza meg). Tehát ki tudja használni a dual-core-t (legalábbis AMD vonalon), azaz 2 szálon fut párhuzamosan.
Nem keverem, csak leírtam, hogy nem kimondottan a HT miatt van 2 ALU.
"Megpróbálom röviden: - A modernebb CPUkban a magas órajel és a komplex utasítások miatt (több órajel egy utasítás) pipelineokat vezettek be, ezeken ülnek a végrehajtási egységek. - Intelnél hosszú pipelineok vannak, AMDnél rövidek (P3 is rövid volt) - Minél hosszabb a pipe, annál költségesebb egy ugrás (ki kell dobni az összes elõkészített adatot a pipeline-ból). - Viszont a hosszú pipeline elõnye, hogy ha jó predikciós egységed van, össze tudod válogatni úgy a következõ n darab utasítást, hogy viszonylag jól ki legyen használva mindegyik funkcionális egység. Minnél hosszabb a line, annál nagyobb az n."
Ehhez képest a K7/K8-nak jobb az IPC-je... Mivel az Intel célja a pipe növeléssel inkább az órajel növelése volt. (Amúgy tudtommal IPC manapság 1.0 fölötti szám, így nem több órajel egy utasítás, hanem fordítva - bár lehet, hogy most tévedek, de nem számolok utána, ahhoz késõ van :)).
"Ámde! Sokszor van olyan, hogy van egymás után sok olyan utasítás, melyek ugyanazokat a belsõ részeket használják. Ilyenkor rengeteg rész üzemen kívül van (ezt használja ki az M, ezeket lekapcsolja), de van egy másik mód: duplikáljuk meg a címregisztert, illetve lássuk el az összes belsõ egységet egy bittel, ami jelzi hogy az adott részegység mely szálat futtat. Így, ha olyan a kód, lehetõség van két független szál futtatására: az egyes szálak ugyanazt a pipeline-t használják, ám (szerencsés esetben) más más belsõ részeket vesznek igénybe."
Na, hát erre mondható, hogy egy "trükkös" és igencsak butított SMT, és hogy fõleg a hosszú pipe-ok kompenzálására való (Miközben a K7/K8 a rövid pipe-ok miatt elég gyorsan tud váltogatni a szálak között, ami némileg ellensúlyozza ezt.)
"Remélem sikerült értelmesen leírnom."
Sikerült. Csak kár, hogy a valóságban szinte sosem jön ki a 100% teljesítménynövekedés, csak sokkal kevesebb. Sõt, pár ismerõsöm egyenesen lassulásról számolt be bizonyos esetekben.
Egy dolog biztos, én saját bõrömön tapasztaltam hogy WMV kódolásban majdnem 2x volt a sebesség difi a HT és az A64 között. De nem akarok a tények ellen beszélni.
"Valami miatt az asztali változatban (pontosabban amit az M-bõl és a P4 egyes részeibõl gyúrnak) sem lesz." Ennek oka abban keresendõ, hogy az áramkörök kikapcsolásával nagy mértékben csökkenthetõ a szivárgási áram. Ezzel tudják növelni a MHz-et ami abban segít hogy egy szálat gyorsabban tudnak futtatni.
A jövõ ennek ellenére szerintem továbbra is az SSE duplikálás, 4x-es HT akár még hosszabb pipeline-okkal, még több mag, belsõ crossbar busz, vagy valami olyan SSE4, amely ki van egészítve ciklusszervezõ és elágazó utasításokkal (tehát részben önnáló lenne).
Na, a HT-val kapcsolatban vess egy pillantást erre a képre. (A mi szempontukból a P4 660 és az A64 4000+ érdekes persze). Semmivel sem terheli jobban több feladat futtatáasa az A64-et, sõt...
"1. Mint az általad linkelt doksiból kiderül, csak a simple instruction ALU-ból van kettõ, a lassabb complex instruction ALU-ból csak egy van."
Az esetek 90%-ban egyszerû aritmetikai mûveletek történnek (rotálás, shiftelés, add, adc, stb.), de nem is ezért írtam, csak példának hogy igenis duplikálva van.
"2. A K7-K8-ban is több ALU van, függetlenül attól, hogy nem HT/SMT-s. Ettõl van, hogy több (integer) utasítást tud végrehajtani egy órajelciklus alatt (még többet, mint a P4)." Megint kevered. Megpróbálom röviden: - A modernebb CPUkban a magas órajel és a komplex utasítások miatt (több órajel egy utasítás) pipelineokat vezettek be, ezeken ülnek a végrehajtási egységek. - Intelnél hosszú pipelineok vannak, AMDnél rövidek (P3 is rövid volt) - Minél hosszabb a pipe, annál költségesebb egy ugrás (ki kell dobni az összes elõkészített adatot a pipeline-ból). - Viszont a hosszú pipeline elõnye, hogy ha jó predikciós egységed van, össze tudod válogatni úgy a következõ n darab utasítást, hogy viszonylag jól ki legyen használva mindegyik funkcionális egység. Minnél hosszabb a line, annál nagyobb az n.
Namost eddig a pontig a HT nélküli P4 és az A64 azonosak, egy szálat futtatnak. Nyilván, minnél jobban van duplikálva az összes belsõ egység, annál több utasítást tudnak futtatni.
Ámde! Sokszor van olyan, hogy van egymás után sok olyan utasítás, melyek ugyanazokat a belsõ részeket használják. Ilyenkor rengeteg rész üzemen kívül van (ezt használja ki az M, ezeket lekapcsolja), de van egy másik mód: duplikáljuk meg a címregisztert, illetve lássuk el az összes belsõ egységet egy bittel, ami jelzi hogy az adott részegység mely szálat futtat. Így, ha olyan a kód, lehetõség van két független szál futtatására: az egyes szálak ugyanazt a pipeline-t használják, ám (szerencsés esetben) más más belsõ részeket vesznek igénybe. Tehát ha ilyen kódod van végtelen ciklusban:
cyc1: add eax, ebx mul ecx jmp cyc2
akkor látható hogy a 2. utasítás az elsõ eredményére vár, viszont más ALU-t használ. Namost ha van két ilyen szálad és HT futtatod õket, akkor az egyik szál az 1. utasítást hajtja végre, a második a 2. at (egyszerre), és utána fordítva.
Belátható hogy ebben az esetben a teljesítménynovekedés 100%, hiszen a kódot amúgy nem lehetne párhuzamosítani semmilyen módon az egymásra utaltság miatt.
Remélem sikerült értelmesen leírnom.
A lényeg tehát az, hogy a HT lényegében minimális új egység hozzáadásával segíthet a nem használt pipeline egységek kihasználásában.
Ja, még annyi hogy a plusz SSE2 (vagy persze 3, ami +13 új utasítás) alig valamennyi helyet fogkal a DIE-on, mert nincs hozzá se cache, se predikció, se mikrokód (illetve elenyészõ).
Egy kis kiigazítás. Ezt írtam: "Nem túl sokat ér a 2 ALU 1db INT, FPU, SSE, MMU, stb. egységgel." - Nos, (itt) az ALU-k az integer blokk részei, és - mint írtad is - az FPU végülis egy blokkot képez az SSE2/MMX-szel (mondjuk kérdés, blokkon belül mi a helyzet).
Viszont 2 plusz megjegyzés is: 1. Mint az általad linkelt doksiból kiderül, csak a simple instruction ALU-ból van kettõ, a lassabb complex instruction ALU-ból csak egy van. 2. A K7-K8-ban is több ALU van, függetlenül attól, hogy nem HT/SMT-s. Ettõl van, hogy több (integer) utasítást tud végrehajtani egy órajelciklus alatt (még többet, mint a P4).
"Itt azt is láthatod hogy simán befér egy 2. SSE2"
Az OK, talán elférne (bár azt is látni kéne, ez a chipen mekkora terület valójában, és a belsõ vezértést mennyire bonyolítja) de a lényeg, hogy watt/FLOPS és össztranyószám/FLOPS szempontból nem a legjobb irány.
"Egyébként most tényleg eléggé habzó szájúnak tûntél. Nyugi :)"
Pedig csak leírtam, amit tudok. :P
"Ha kéred (és nem nagyarcúskodni akarok) szívesen elmagyarázom a HT-t."
Nyugodtan, de nem kell túl szájbarágosan, csak a lényeget. Mi van megduplázva, és mi nincs, mennyire meríti ki a valódi SMT fogalmát (szerintem kevéssé), stb.
"Még annyi, hogy a D-ben helyhiány miatt nem volt, az M-ben pedig nem tudták megoldani a részleges kikapcsolást a HT mellett (a nem használt áramköröket lekapcsolja az M)"
Valami miatt az asztali változatban (pontosabban amit az M-bõl és a P4 egyes részeibõl gyúrnak) sem lesz.
Gondolhatod, hogy nem én találtam ki, hanem tesztekbõl jött ki. Sajnos nem tettem el az oldalt, ahol pont ezt hasonlították össze, de keresem. 1-2x már belinkeltem. Az volt látható, hogy egy szál futtatása mellett egyforma teljesítményt adó P4-et és K8-at véve, 2 szál futtatása lellett kikapcsolt HT-val sokkal jobban lelassult a P4, mint a K8, utána bekapcsolt HT-val újra egálba kerültek.
"Nézz utánna pontosan mit csinál a HT."
Hát, attól tartok, ez most nem érdekel eléggé ahhoz. :)
"Egyébként valóban gyorsabb a K8, azonban ha több szálat kezdessz futtatni, vagy olyan programot használsz ami direkt HT-re optimalizált, bizony messze lehagyja a K8-at a P4HT. (Pl. WMV enkóder)."
Nonono. A fent említett tesztbõl nem ez jött le, legalábbis általános esetben. Az egy dolog, hogy kimondottan HT-ra optimizált kód gyorsabb lesz. Mint ahogy egyszálas esetben is gyorsabbak a kimondottan P4-re optimizált programok. (Ami néha azt jelenti, hogy akkor sem használja AMD-n a SSE2-t, 3-at, ha jelen van.)
"Ja és nekem Athlon64-em van, mielõtt le Intelfanoznál."
Nem szokásom.
""szted a processzor tervezõk legóznak?" ha azt veszed alapul, hogy a 387-> MMX -> SSE -> SSE2 ma már ugyanaz az egység, akkor azt kell mondjam hogy igen."
(Ezt nem én írtam, célszerû lenne külön válaszolni.)
"Többek közt két ALU van, a CPU hoz képest 2x órajelen."
Nem túl sokat ér a 2 ALU 1db INT, FPU, SSE, MMU, stb. egységgel.
"az SPE egy programozható vektor CPU ami azonban igen ostoba."
Az igaz, hogy egy általános procihoz képest jóval lassabban tudna futtatni egy általános kódot (mivel mindene megvan, ami ehhez kell, csak nem erre van kihegyezve), de tudna, tehát azért nem annyira ostoba. (A PPE-tõl teljesen függetlenül is tudnak programokat futtatni - mellesleg 1-1 saját nagyon gyors belsõ kis ramból is, de a main ramhoz is hozzáférnek.)
"Amire én gondoltam az az, hogy a két HT szál simán el tudna futni 2 SSE egységgel (mivel teljesen más pipeline egységeket használnak) így nagyon jó teljesítményt lehetne velük elérni (a CPU egy-egy szála végezné el az SSEk vezérlését)."
2 SSE nyilván jobb, mint 1, de egy önálló vektor-egység számítási szempontból sokkal hatékonyabb megoldás, mint általános célú magokat feltartani az SSE-zéssel.
Mindenesetre úgy tûnik, az Intel is inkább a több, de "egyszálú" magra megy rá, egyelõre.
Tényleg, össze lehetne hasonlítani, hogy 1db SPE hogy aránylik egy SSE-s P4 maghoz (számítási teljesítményben).
"Nagyon valószínû hogy az Intel nem az én "brilliáns" ötletemet fogja alapul venni a jövõben, de szerintem rá lesznek kényszerítve valami hasonlóra."
A távlati tervekben egy Cellhez hasonló felépítésû architektúra szerepel. Azaz az általános magok mellé õk is vektor-magokat terveznek majd. (Úgy 6-8 év múlva.)
Egyébként most tényleg eléggé habzó szájúnak tûntél. Nyugi :) Ha kéred (és nem nagyarcúskodni akarok) szívesen elmagyarázom a HT-t. A Prescottban mellesleg 31 hosszú pipeline van. Még annyi, hogy a D-ben helyhiány miatt nem volt, az M-ben pedig nem tudták megoldani a részleges kikapcsolást a HT mellett (a nem használt áramköröket lekapcsolja az M)
"Ne nevettess az Intel féle HyperThreadinggel... Az (a mai formájában) csak annyi, hogy 1-2 trükkel némileg kompenzálja a P4 hosszú csöveibõl eredõ hátrányokat. Így hozza - szerencsés esetben - amit a P3 hozna azonos órajelen"
"Ne nevettess az Intel féle HyperThreadinggel... Az csak annyi, hogy 1-2 trükkel némileg kompenzálja a P4 hosszú csöveibõl eredõ hátrányokat, amiket két szál fzttatásakor szenved - miközben a K7-nak, K8-nek ez nem okoz különösebb gondot, azok HT nélkül tudják ugyanazt, mint a P4 HT-vel."
Nenenene. Én nagyon tájékozottnak ismertelek eddig, de ez nagyon messze áll a valóságtól. Nézz utánna pontosan mit csinál a HT. Egyébként valóban gyorsabb a K8, azonban ha több szálat kezdessz futtatni, vagy olyan programot használsz ami direkt HT-re optimalizált, bizony messze lehagyja a K8-at a P4HT. (Pl. WMV enkóder). Ja és nekem Athlon64-em van, mielõtt le Intelfanoznál.
"szted a processzor tervezõk legóznak?" ha azt veszed alapul, hogy a 387-> MMX -> SSE -> SSE2 ma már ugyanaz az egység, akkor azt kell mondjam hogy igen.
"Mellesleg a HT-s P4-ekben is 1, azaz egy darab SSE egység van" ez stimm, ezért írtam a +1-et, így mindkét szálra jutna 1-1.
"szerintem másból sincs 2" Többek közt két ALU van, a CPU hoz képest 2x órajelen.
"az SPE-k is messze többek, mint 1-1 SSE egység." 100% százalékig igazad van, de az SPE egy programozható vektor CPU ami azonban igen ostoba. Amire én gondoltam az az, hogy a két HT szál simán el tudna futni 2 SSE egységgel (mivel teljesen más pipeline egységeket használnak) így nagyon jó teljesítményt lehetne velük elérni (a CPU egy-egy szála végezné el az SSEk vezérlését).
Nagyon valószínû hogy az Intel nem az én "brilliáns" ötletemet fogja alapul venni a jövõben, de szerintem rá lesznek kényszerítve valami hasonlóra. Egyébként a jelenlegi mikrokód architektúra mellett semmibõl nem állna még egy SSE2-t berakni (jelenlegi SSE2 kódok +1 új prefix - abból már úgy is van elég)
Ne nevettess az Intel féle HyperThreadinggel... Az csak annyi, hogy 1-2 trükkel némileg kompenzálja a P4 hosszú csöveibõl eredõ hátrányokat, amiket két szál fzttatásakor szenved - miközben a K7-nak, K8-nek ez nem okoz különösebb gondot, azok HT nélkül tudják ugyanazt, mint a P4 HT-vel. Nem csoda, hogy a P3-on alapuló Pentium-M-ekben már nincs ilyen, és a késõbbi P-M-re alapuló, P4-et leváltó prociban sem lesz. (Mondjuk normális SMT lehetne benne, de nem "szórakoznak" ilyesmivel.) A dual-core P4-ekben sincs. Mellesleg a HT-s P4-ekben is 1, azaz egy darab SSE egység van (szerintem másból sincs 2, esetleg csak a regiszter-bankból).
Jahh, és még valami: szal ne keverjük a HT-t egy valódi SMT-vel (2-way hardware simultaneous multi-thteading), amit a Cellben lévõ PPE (vagy pl. az Xbox360-ban lévõ 3 magos Xenox) tud. A fõbb belsõ egység meg vannak duplázva, állítólag még a VMX is. Tehát ezek tényleg majdnem olyanok, mintha eleve dual-core-osok lennének (Xenox esetén 3x2).
És nem utolsó sorban: az SPE-k is messze többek, mint 1-1 SSE egység.
Ne nevettess az Intel féle HyperThreadinggel... Az (a mai formájában) csak annyi, hogy 1-2 trükkel némileg kompenzálja a P4 hosszú csöveibõl eredõ hátrányokat. Így hozza - szerencsés esetben - amit a P3 hozna azonos órajelen. Nem csoda, hogy a P3-on alapuló Pentium-M-ekben már nincs ilyen, és a késõbbi P-M-re alapuló, P4-et leváltó prociban sem lesz. A dual-core P4-ekben sincs. Mellesleg a HT-s P4-ekben is 1, azaz egy darab SSE egység van.
Figyusz, a modern nyelvekben eleve meg van oldva ennek a támogatása. Itt nem az a kérdés hogy meg lehet e oldani egyszerûen egy szinkronizált program megírását, mert erre a válasz igen. Ez assemblyben ma már öngyilkosság.
A probléma az oktatásban és a jelenleg nem létezõ PC-s multiprocesszoros tudásbázison van. Nincs hagyománya hogy hogy lehet egy quickshortot, bináris keresést stb. dolgot elosztani több task között. Ha gondolkozol rajta meg lehet csinálni, de nem fogod automatikusan így tervezni az algoritmusokat. Még nincs a nyelvekbe sem beépítve ilyen könyvtár. Ez még hosszú évek kérdése.
Egyébként már nagyon sok utasítás lemegy egy órajelciklus alatt, sõt, az összes regiszter elérõ utasítás ilyen. A memóriát elérõ utasítások is jórészt végrehajtódnak 2 órajelciklus alatt (L1 cache hit esetén), szóval amit írtál az már a múlt.
Maximum 8 utasítást, minimum 1 utasítást - ez a nem mindegy. Egyébként a promo anyagok arról se szólnak, hogy jó kevés az az utasítás ami 1 ütemciklus alatt lemegy, ráadásul ez valójában nem is egy utasítás, hanem mondjuk 8*(1/8)-ad utasítás, ha a csõvezeték 8 részbõl áll. Szóval nehéz a szénbányászok élete, de a párhuzamos mûködésre való optimalizálás se piskóta. Jópár éve beszélgettem egy sráccal, aki elég jól nyomta assemblyben is a dolgokat. Akkoriban Pentium volt a szerverünk (kliensek 386SXek, DXek, 486DLC-k). A pentium már tudott párhuzamosan utasítást végrehajtani (U ill. V pipe). Viszont ennek volt jópár feltétele, pl V bemenõ operandusa nem függhetett U eredményétõl, csak az egyik tudott lebegõpontosat, csak az egyik lehetett feltételes ugrás, stb. Szóval gyakorlatban úgy nézett ki, hogy egy átlag program kb 10-15%-ban használta ki a V csövet (U mindig tele volt). Ha optimalizált az ember kézzel, assemblyben, akkor el lehetett érni kb 70-80% kihasználtságot szinte bármilyen kódnál. De ezt nem csinálta meg senki se, a C fordítók pláne nem. A többmagos prociknál az a baj, hogy ez a probléma elég vastagon hatványozott, mert itt már nem 2 végrehajtó egységet kellene teletölteni folyamatosan, hanem mondjuk magonként nem tudom hány darabot (2 biztosan, de inkább több). Ezt általános feladatoknál biztos nem lehet (ezért 8 mag közel sem lesz 8x gyorsabb), renderelésnél meg biztos hogy meg lehetne közel 100% hatákonyságra, ha megerõltetné magát az engine írója.
Szarból van, ezzel nem vitatkozom (ha az x86-os assembly örökségrõl van szó).
Másrészrõl "Nézd át a cell architektúrát stb. utána beszélj." ezzel menj vissza az oviba.
Nagyon sokat tudok mindkét architektráról és tuom hogy az SPE-kkel nagyon sok mindent meg lehet csinálni. De:
Ha van 4 hyperthread-es magod, az el tud vinni 8db SSE2-t, ami így viszont bár be fogja darálni a cellt. Tudom hogy a cellben írtó gyors a belsõ busz, de ennek a CPU-nak óriási elõnye lenne hogy mindegyik blokk használható mindenre (DSPnek is és akár adatbáziskezelõ futtatásra is), ami a Cellrõl nem mondható el.
Az egyetlen dolog amiben a Cell erõsebb lenne az az ár. Mire egy ilyen Intel szörny ára lemenne, már fillérekbe kerülne a Cell.
Na azért gizikét gõzekével ne keverjük. Analóg gépek nem (csak) azért voltak gyorsabbak a digitálisaknál mert párhuzamosítva volt rajtuk pár dolog, hanem pl azért, mert célhardwarek voltak, egy adott analóg bemenetû, analóg kimenetû feladat végrehajtására. Digi gépeknél ez AD konverter, végrehajtás általános célú gépen, DA konverter - ez nyilván sokkal lassabb.
LOL Nézd át a cell architektúrát stb. utána beszélj. Sz*rból is lehet építeni házat persze de minek? Ház alakja van meg lehet benne lakni is de hát sz*rból van...
ha van értelme, ha nem ez a négy magos hyper threadinges cucc ütni fog, ugyebár ez már nyolcszálas utasítást tud órajelenként, ami azért nem mind1 mellesleg szerverekhez hamar írnak hozzá megfelelõ programot is, csak az átlagfelhasználóhoz fog késõn eljutni ez a technológia és annak az értelme
re
Nah vajon most hol vannak a cell fun ok akik 2008 ra jósolták a pc 4 magos CPU it:)
Ha így nézzük a 8 bites prockóhoz képest a 16/32/64 bites prockók is zsákutcát jelentenek, mert a nyolcbites kódot nem képesek annyival gyorsabban futtatni ha a progi nincs optimalizálva.
Amúgy szerintem ha lehetett volna, már eddig is így írták volna a kódot, mert jelenleg a programok különbözõ funkcióit szépen egymás mögé kell állítanai, még akkor is egymásra várnak ha egymással nincsenek is közvetlen kapcsolatban.
10 évvel ezelött már voltak neurális felépítésû hibrid(analog/digitális) csipek, amik bizonyos alkalmazásoknál 30W fogyasztás mellett hozták modjuk egy 500 000W fogyasztású nagyszámítógép teljesítményét. Ez nagyrészt a párhuzamos felépítésnek is köszönhetõ.
Nem zsákutca a többmagos proci, csak hát ahhoz olyan kódot kell írni ami ki is tudja használni. Szervereknél ez nem igazán gond, mert aránylag kevés féle szoftvert használnak rajtuk, viszont mire a gámákat is többszálú végrehajtásra optimalizálják addigra lehet hogy leesik a hó. Párszor.
A tobbmagos megoldasnak nem sok ertelme zsakutca.. Valamit ki kellett talalni a mert a sebesseg mar nem novekedhetett...
A baj minössze annyi, hogy rakhatnak 100 magot is egy prociba ameddig az az egy nyamvatt 2 csatornás memó vezérlõ szolgálja ki az egész gépet legyen szó tetszõleges számú processzoról. Xeon esetében ugye. AMD Opteron -nál ez úgy néz ki, hogy processzoronként ott figyel a DUAL DDR. Minnél több processzor van a gépben annál nagyobb az AMD fõlénye. De mondjuk a DUAL CORE sem lett átütõ siker Inteléknél, max az árával. Sebességével nem tud kápráztatni még az EE sem rúg labába HT ide oda amoda. Szóval nem értem én ezt a dolgot. Ameddig itt sem lesz meg a Processzoronkénti (és nem magonkénti) DUAL DDR addig AMD Opteron -nak áll a zászló Szerintem.
a frelvenciák növelésénél már most hatalmas problémákba ütköznek. pláne intel oldalról. 120 wattos átlagfogyasztás:):)....
Elõbb-utóbb az otthoni gépekben is ez a technológia fog elterjedni (majd ha olcsó lesz). A GHz-eket sokáig már nem lehetne növelni, valódi teljesítménynövelésre a többprocesszoros rendszerek a legalkalmasabbak. Persze ehhez az alkalmazásokat is ennek megfelelõen át kell majd írni.