44
-
#44
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
-
dez #43 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. -
dez #42 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. -
dez #41 (É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.) -
dez #40 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. -
dez #39 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. -
ewtoto #38 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:) -
ewtoto #37 "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:) -
Zedas #36 Szerinted miért vettem Athlon64-et? :D
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. -
dez #35 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.
-
dez #34 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. -
dez #33 Hát, sokmindent lehetne, de nekem úgy tűnik, most évekig inkább egyszerűen csak magot dupláznak majd, egyébként nem erőltetik meg magukat. -
dez #32 "Megint kevered."
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. -
Zedas #31 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. -
Zedas #30 "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). -
dez #29 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... -
Zedas #28 "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ő).
-
dez #27 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). -
dez #26 "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. -
dez #25 "ez nagyon messze áll a valóságtól."
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.) -
Zedas #24 Ezt nézd meg esetleg, 4. oldal.
http://www.intel.com/technology/itj/q12001/pdf/art_2.pdf
Itt azt is láthatod hogy simán befér egy 2. SSE2
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) -
Zedas #23 "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) -
dez #22 #18-ban van egy kis tévedés, túl sietősen írtam. Lásd helyette #21. -
dez #21 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). -
dez #20 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. -
#19
szted a processzor tervezők legóznak?
nem ugy van az, h "beletesznek még két sse2 egységet" ... :) -
dez #18 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. -
dez #17 Ugyan. Ez kb. olyan kijelentés, hogy ha egy zsigába 2 motort tesznek, F1 lesz belőle. -
dez #16 Neked Xeon van az asztali gépedben? -
Zedas #15 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. -
Komolytalan #14 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. -
Zedas #13 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.
-
Komolytalan #12 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. -
#11
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... -
Zedas #10 "A tobbmagos megoldasnak nem sok ertelme zsakutca"
Ezt még gondold át egy kicsit. Ami eddig volt, az zsákutca, a paralellizáció a jövő. -
Zedas #9 Szerintem is tök fura, még beleraknak +4 db SSE2 blokkot (magonként +1), akkor már pontosan ugyanott vagyunk mint a Cell, sőt...
-
Akuma #8 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 -
ewtoto #7 re
Nah vajon most hol vannak a cell fun ok akik 2008 ra jósolták a pc 4 magos CPU it:) -
#6
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ő. -
Komolytalan #5 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.