Az AMD "reverse multi-threading"-en dolgozik?

AMD

Egyes hírek szerint az AMD olyan technológián dolgozik, amely a több maggal rendelkező processzorokat egymagos processzornak hazudja az operációs rendszer felé. Ettől a chipgyártó teljesítmény növekedést vár.

Ha a hír igaz, akkor a technológia felbukkanása a K8 utáni következő architektúrában várható. A cikk szerint ismert tény, hogy két processzor - akár két különálló fizikai processzorról, vagy két maggal egy die-on megoldásról beszélünk - nem ad kétszer akkora teljesítményt mint amit egy processzor ad. Viszont ha a processzort úgy mutatjuk az operációs rendszer felé, mintha az egy processzor lenne, akkor az AMD szerint várhatóan dupla akkora single core teljesítményt lehet lehet kihozni egy két maggal rendelkező processzorból, és négyszer akkora single core teljesítményt lehet kihozni egy négy maggal rendelkező processzorból.

Ez az elgondolás homlokegyenest ellenkező az Intel által kitalált HyperThreading-gel, ahol egy maggal rendelkező processzort úgy nyomtak le az operációs rendszer torkán, mintha az két különálló fizikai processzor lenne, s ettől vártak teljesítménybeli javulást.

Az elképzelés érdekes. Kérdés, hogy mi igaz belőle, és ha igaz, akkor valóban lehet-e azt várni, hogy egy dual core processzor kétszer olyan gyors lesz, mint egy single core processzor kétszer.

A cikk itt.

( bra | 2006. 04. 19., sze – 09:55 )

Hát ennek így nem sok értelmét látom.

Meg szerveren is van, ahol CPU/core based a licensz. Akkor is van értelme ha nincs SMP vagy gyenge az SMP a kernelben, illetve nem skálázódik jól. Mondjuk egy nomrál SMP rendszerben 25-50% körüli javulás elérhető egy második CPU-val. Ha az AMD-nek sikerül 60-80%-ra tornáznia ezt és CPU-n belül, akkor egy dual-core-os SMP rendszernél (4 mag) eléggé komoly növekedés lehet.

A magok duplázása ugyanúgy nem lesz célrevezető, mint az észnélküli MHz hajszolás és ezt az AMD is tudja. Azt is hozzátéve, hogy egy 4-8 magos cuccal (a 4 magosok ugye 2007-ben már várhatóak), főleg abból duállal, már eléggé el kell maketteznie az OS-nek.

Az egessznek az az ertelme, hogy a GHz novelese fizikai (kvantum mechanikai) korlatokba utkozik, es az egvilagon mindent ki kell probalni, hogy a processzor teljesitmenyet lehessen novelni.
ugyanis a jelenleg eladott PC donto tobbsegeben egyetlen processzor van, na annak kell egyre nagyobb tejesitmenyt nyujtani, es az ugyfelek leszarjak, hogy mi van a tokon belul;)
probalkoznak a sracok, majd meglatjuk sikerul-e nekik, vagy nem.

Anr - http://andrej.initon.hu

Pedig van. Vannak olyan alkalmazasok (pl. video tomorites, wavelet-ek stb), ahol nem lehet tobb szalura bontani a programot, mert minden egyes lepes fugg az elozotol.
Ha megis felbontjak valahogy, az nagyon eroltetett, sok felesleges dolgot csinal (pl. megtippelik mi lesz a masik cpu-n meg folyamatban levo szamitas eredmenye, ez alapjan elkezdik elore a kovetkezo lepest, es ha megse jott be akkor elkezdik ujra.), ilyenkor nem hogy 2x nem lesz gyorsabb 2 cpu-val, de jo ha 30-50% ki lehet hasznalni a 2. cpu-bol. Ha meg tudnak oldani mindezt ugy hogy 1 cpu-kent latszodjon, es ez meg mukodne is, az kiraj lenne...

A'rpi

>Ha meg tudnak oldani mindezt ugy hogy 1 cpu-kent latszodjon, es ez meg mukodne is...

Na ezaz, pont most írtad le azt is, hogy miért is oly nehezen kivitelezhető mindez és miért nem lehet komoly teljesítménytöbbletre számítani emiatt.
---
Apparently the human mind is not unlike cookie dough.

( th v | 2006. 04. 19., sze – 10:03 )

Ja, ez kb olyan, minthogy a macska fel van maszva a fara...
Bar lehet, hogy csak a fa nott hirtelen a macska ala?
Hiaba, ezek az elet nagy kerdesei.
--
TH

( sz | 2006. 04. 19., sze – 10:11 )

Ha jól értem a "sorok között" a lényeget, akkor itt egyáltalán nem is az a lényeg, h most sikerül-e ténylegesen elérni a kétszeres teljesítményt két magos processzorral, vagy sem. Ami sokkal inkább fontos az az, h így gyakorlatilag a már létező alkalmazások is ki tudják majd használni a többmagos processzorokban lévő teljesítménytöbbletet, anélkül, h jelentős költséggel járó módosítások árán többszálúvá kellene tenni őket.

Én annak idején úgy tanultam (legalábbis így emlékszem :-)), hogy ha egy egyprocesszoros rendszerhez újabb különálló fizikai processzort adsz, akkor nem kapsz kétszeres egy processzoros teljesítményt. Mindig nőni fog a teljesítmény, de sosem lesz 3 processzor esetén 3-szoros, 4 processzor esetén négyszeres, stb.

Sőt minél több processzort teszel bele annál kisebb telejsítmény-növekedést kapsz eredményként. Erre bonyolult számítások vannak. Ezért nem hiszem, hogy ennek bármilyen valóság alapja is lehetne. Ha mégis, akkor a multi-core processzorokra ez a törvényszerűség nem vonatkozik.

--
trey @ gépház

Nos ez azert van, mert egy 10 soros fuggvenyt senki sen fog tobbszalura atirni, de egy 1000 sorost mar igen. Ha tobbszor fut a 10 soros(marpedig ez a valoszinu) akkor a proci donti el, hogy melyik magon futtatja a fuggveny melyik reszet.

Ez persze egy kitekert pelda, de a valosagban mukodik.

A masik, hogy tenyleg nem kell ujrairni egy csomo progit es meg a DOS is ki tudja hasznalni _elmeletileg_ a tobb magot.

Nos ezt én hardver design oldalról közelítettem meg, egy sor köze nincs a kódokhoz. Könnyen kiszámolhatók a mai gépek belső sávszélességének limitjei. Meg ezer másik dolgotól is függ, de ezért most nem veszem elő a könyveket. :-))

A szoftveres oldal is belejátszik mindenképpen, de ettől függetlenül is igaz, amit írtam (legalábbis azt hiszem :-D).

--
trey @ gépház

Amdahl törvénye mond ki ilyesmiket elég jó közelítéssel, és érvényes többmagos processzorok esetén is.
Hogy tényleg sikerül(het)-e az AMD-nek ezzel a módszerrel (mitöbb: bármilyen módszerrel) lineáris skálázódást elérnie, abban egyelőre kételkedek...
De a világ nagy részét ez szerintem egyáltalán nem is érdekli. Mind a fejlesztők, mind a felhasználók ahhoz vannak szokva, h ha gyorsabb processzort vesznek, akkor a programjuk gyorsabban fut (i/o korlátos alkalmazásokat most hagyjuk). Ennek most ugye hirtelen vége szakadt, aminek sem a fejlesztő nem örül, mert több szálat programozni nehéz, sem a felhasználó, mert a régebbi alkalmazásai nem lesznek gyorsabbak (olvasnivaló a témában: The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software). Ha az AMD fejlesztései nem is érik el a lineáris skálázódást, de a több mag egyetlen processzornak hazudása által kiaknázhatóvá teszi a bennük rejlő teljesítménytöbbletet egy szálú programok számára is, még ha csak magonként néhány tíz százalék többletért is, az azért igen nagy dolog lenne... Visszatérnének a "boldog békeidők", úgymond.
Főleg azok a fejlesztők fogják ezt nagyra értékelni, akik már szembesültek a többszálú programozás esetén felmerülő nemdeterminisztikus problémákkal (;

Hmm... Kicsit továbbgondolva... Meg persze azok a felhasználók is örvendezni fognak, akik szívesen futtatnák gyorsabban a legacy appjaikat. Namost ha az AMD ezen fejlesztése sikerrel jár, és belekerül a processzorokba, és a konkurrens gyártók (konkértan: Intel) nem implementálnak majd hasonló feature-öket... Akkor a piac egészen érdekesen alakulhat a jövőben, mert az ilyen felhasználók valószínűleg AMD processzorral szerelt gépet vesznek majd.

Szerintem is ez lehet a cél. Érdekes tesztet olvastam a minap /talán a hup-on/
Tesztelték az új x-sok-magos (8 mag talán) sun procit vele szemben egy dualcore-os opteronnal szemben. Nagyjából hasonló pénzbe került a két vas. De teljesítményben még mindíg az opteron volt a jobb. Igaz fogyasztásban viszont kicsit a sun stuffja volt jobb (Na nem fele annyit fogyasztott, csak 10-20% megtakarítás). Szinte lefogadnám, hogy az elméleti-marketing performancija akár 5X akkora a sun procinak, viszont a valóság sokkal prózaibb. Na ennyit a giga-csoda cell prociról is (x-box és ps3 lelke...). Valószinüleg a valós teljesítménye közelébe sincs az elméleti számolt marketing maximumnak.
Tippem szerint programozni is nehezebb a Xkóros procikat, persze csak ha jelentős teljesítménytöbbletre vágyik az ember. Na ezt a terhet gondolták könnyíteni AMD-ék kb.

és valóban, sőt ki is rugtak egy mérnököt a sony-nál, mert azt írta a blogjában, hogy onnan lehet megtalálni a programozók irodáját, hogy ott a leghangosabb a káromkodás...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Pontosan errol van szo. A hulye is tudja, hogy baromi nehez hatekony tobbszalu programot fejleszteni.

Mond valamit az, hogy SGI Altix (v. Origin)? Ott egy clusternel (distributed memory) oldottak meg, hogy programozoi szempontbol SMP rendszernek latsszon (shared memory). Nem kis konnyebseg.

Ez az otlet ugyanilyen megoldas kicsiben.

Mond valamit az, hogy SGI Altix (v. Origin)?

Igen, nemrég vett ilyet az OMSZ, szóval pár hete egy ilyen irányítja Magyarország időjárását. :))) De programhiba miatt most overflow van a Dunán, a Tiszán és a Körösökön. ;)))

--
Sokan nincsenek tudatában annak, / hogy egyszer mindenki meghal. / Akik ráébrednek erre, / azonnal abbahagyják az ellenségeskedést.

( r2d2 | 2006. 04. 19., sze – 11:58 )

Ez szerintem elméletben sem lehet igaz, bár életemben nem terveztem processzort:) Ha valamiből legalább kettő van, akkor már el kell dönteni, ki mit csináljon. Szinkronizálni kell a kettőt. Az eredményt össze kell fésülni. Ez idő, pénz és energia. Lehet, hogy ki lehet hozni 99%-os gyorsulást, de 100-at biztosan nem.
Azért csak hajrá AMD! :)))

( skrionius | 2006. 04. 19., sze – 13:10 )

Ahogy én ezt elképzelném, az az hogy hardware-esen osszák szét több szálra a műveleteket, elvéve ezt a szerepet programtól. Ehhez mondjuk egy a processzorok eléékelt előfeldolgozó egységgel lehetne megtenni. De hogy ez mennyire sokrétű kérdéseket vet fel, abba nem is akarok belegondolni...vagy talán ennél sokkal egyszerűbbet találtak ki. :)

( gliskard | 2006. 04. 19., sze – 14:14 )

az Apple is verte a mellét amikor kijött a G5 quad... 2x2 cpu core - ekkora, meg ekkora teljesitmény, stb. A hétköznapi életben sajnos nem ilyen szembetünö a különbség a 2 és a 2x2 proci között. Persze a Final Cut gyorsabb, de például hétköznapi mezei dtp munka (photoshop, indesign, illustrator) esetében nem látni "szembe ötlö" különbséget. Söt a 2,7 Ghz-es dual G5 általában fürgébbnek látszik mint a 2,5 Ghz-es quad...

( Som-Som | 2006. 04. 19., sze – 14:26 )

Az eset picit hasonlít a disk cache és swappelés látszólagos ellentmondására, a ram diskről már nem is beszélve. De ezek legalább egymás mellett is élhetnek.

- 1 nagy file fordítását vagy 1 linkelést nem lehet párhuzamosítani, tehát itt az 1, de gyors proci jobb.
- Sok fordítást lehet párhuzamosan végezni, de ha kevés az I/O-ra várakozás, akkor a HyperThreading nem fog igazán gyorsítani rajta. Sőt, az utolsó művelet (ahol már nincs párhuzamos folyamat) nem használja ki a procit.
- Ha sok az I/O, akkor 1 gyors procin is lehet párhuzamosan fordítani (make -j).
- A HyperThreading igazi előnyét én akkor láttam, amikor egy gépen fordítottam és böngésztem, és nehezemre esett a nice parancs használata. Tehát a fordítást lelassítottam, csak hogy a GUI ne akadozzon.

A probléma csak az, hogy nem lehet párhuzamosítani minden műveletet. Ezt ugyebár 10 éve már láttuk, amikor az x86-os procikban bevezetésre került a multi-pipeline. Úgyhogy szerintem csak a régi húrokat pengetik megint.

cégnél csinálnak többszálú adatgyűjtést/vezérlést /néhámy tucat szálból 2-3 fut egyszerre/.
Többfajta gépen próbálkoztak a kollegák, és azt kell mondani, a 3GHz-es P4 a hyperthreading-gel kenterbe verte a 3800+-as amd64-et /30-40%-kal több idő jutott egy szálnak/.
Ha a hyperthreading-et kikapcsoltuk, drasztikusan leromlott a P4, aláment az AMD-nek.

Szóval tessék egyáltalán nem lebecsülni a hyperthreading-et, igen jó dolog tud az lenni...

Lebecsültem volna? Nem hinném, csak utaltam arra, h nem elhanyagolható különbség van a kettő között.

Kollágáid esetleg megvizsgálhatnák azt is, h mennyit gyorsulást tapasztalnak
- kikapcsolt HT-ről bekapcsolt HT-re váltva
- egy processzorról két (ugyanolyan) processzorra váltva
- kikapcsolt dual-core-ról bekapcsolat dual-core-ra váltva
és a gyorsulás mértékét viszonyítgassák egymáshoz.

Én programfordítással játszadoztam pár hónapja (make helyett SCons, több linkelés is történik, valamint kellően sok memória, h minden cache-ből jöjjön, vagyis összességében elég jól párhuzamosítható), és a HT esetén a -j2 ~25%-ot hozott, két processzor esetén pedig ~85%-ot, dual-core-unk egyelőre nincs. (Niagaránk azóta van, de időm nincs...)

( ParadoxH | 2006. 04. 19., sze – 15:29 )

Tételezzük fel, hogy mindez összejön az AMD nek...
De akkor ezután az AMD -s többmagos gépek árai valahol nem a csillagos eget fogják súrolni?

Miért súrolnák? Az AMD eladni is akar majd gondolom és ad vmi nevet a teknólógijának (für helyesírásmegszállottak). Ezzel együtt azt is mondhatja, hogy a következő generációs cuccai (K9 mondjuk vagy KX) alapból tartalmazzák és nem GHz mámorban fejlődtek, hanem ésszel is. Jelenleg is van egymagos meg kétmagos opteron és A64, szóval nem látom, hogy miért nem lehet ezzel diverzifikálni később a kétmagos és többmagos CPU-kat.

( Kiskübi v | 2006. 04. 19., sze – 22:48 )

> Nos ez azert van, mert egy 10 soros fuggvenyt senki sen fog
> tobbszalura atirni, de egy 1000 sorost mar igen. Ha tobbszor
> fut a 10 soros(marpedig ez a valoszinu) akkor a proci donti
> el, hogy melyik magon futtatja a fuggveny melyik reszet.

Az a gond, hogy nem tudja eldönteni, mert egy 10 soros függvényt nem lehet több magon futtatni. Két példányban (szálon) persze lehet. :) A párhuzamosításnak több szintje van:
- utasításon belüli (pipeline)
- utasításszintű (szuperskalár, azaz több végrehajtóegység van)
- több szál vagy processz végrehajtása egy időben

Az első kettőnek minden lehetőségét kimerítették pár éve. Az, hogy pl. szuperskalár procival mennyi utasítást lehet végrehajtani egyszerre (hány végrehajtóegységet célszerű beletenni), az baromira függ a programoktól. Annyi függőség van egy átlag kódban, hogy nehéz sok utasítást egyszerre végrehajtani.

Gondolj bele, ha pl. egy szorzás eredményét még hozzá akarod adni valamihez, akkor ezt a két utasítást az életben nem tudod egyszerre végrehajtani, ezzel mindenképp meg kell várni az elsőt. A legtöbb, amit tehet egy processzor, hogy az ALU kimenetét ilyenkor rákapcsolja az egyik bemenetére - és ezt meg is teszik a tervezők, - hogy az ilyen esetekben a köztes érték a regiszterbe való mentéssel _párhuzamosan_ rögtön dobódjon is tovább.

Vagy ha jól emlékszem, átlagos programban kb. minden ötödik utasítás elágazás. Ráadásul ennek nagy része feltételes. Ugye nem kell magyaráznom, hány óraciklus büntetéssel jár, ha 3 pipeline-ból ki kell dobni az adatok felét, mert rosszfele néztük a programot. :) Ez az oka annak is, hogy a hosszú pipeline-os P4 azonos órajel mellett lassabb a P3-nál (cserébe a hosszú pipeline-on rövidebb egy órajel).

A szuperskalár procikban van már minden, ami gyorsítja, illetve egyáltalán lehetővé teszi utasítások párhuzamos végrehajtását, amennyire azt elméletben lehet. Regiszterátnevezéa, körbuffer, precízebb elágazásbecslés, nagyobb cache, és még rengeteg technika.

Általános célú programoknál 2, 2,5-szörös gyorsulást kapunk, akármekkora processzorunk is van. Optimalizált kód és bizonyos feladatkörök esetén ez lehet 6-8-10-szeres is. De ezzel a szuperskalárnak vége, többet nem tud a függőségek miatt.

Szóval ahogy a pipeline-technika kimerítése után rájöttek, hogy nem megy tovább, szükségképpen jött a szuperskalár. (Állítólag a Sparc eleinte nem akart áttérni, mondván, hogy bonyolultabb, mint amennyit hoz teljesítményben. Ami igaz is. De mással nem lehet pluszt hozni, a Sparc pedig lemaradt a versenyben.)

Most egy ideje pedig kimerült a szuperskalár. Muszáj szálakra vagy processzekre bontani a végrehajtást, hogy tovább tudjunk gyorsulni. Ezért én sem igazán értem az AMD döntését, hiszen ez akkor valójában - szerintem - egymagos processzor.

Illetve hogy mi az a mag, az definíció kérdése is lehet. :) De szerintem az, ami végrehajt egy programot, vagy szálat. Akkor tehát nem értem, hogy a fenti processzor mitől többmagos.

A HyperThreading - mindegy, hány magos - gyakorlatban azt csinálja, hogy amíg az egyik szál vár valamire, pl. hirtelen nem talált valamit a cache-ben, addig egy másik szálat kezd el futtatni. Ehhez nyilvánvaló, hogy a rendszernek is tudnia kell, hogy 2 szálat képes kezelni a proci. Talán azért nevezhetjük ezt mégis egymagosnak, mert ugyanazokon az egységeken futtatja mindkét szálat. (Már amennyire én tudom.) És lehet, hogy százalékosan nem nagy növekedés. Nade ott legalább van rá lehetőség, hogy amíg az egyik szál ,,beáll'', addig a másik menjen.

Ha az oprendszer nem tud a többes lehetőségről, akkor szerintem nincs.

Szerintem könnyen kiderülhet, hogy valami jó ötlettel rukkolnak elő, amit többszálasnak kell hívniuk, mindegy mi van benne, mert ha az Intel többszálút csinál, akkor az AMD-t sem fogják megvenni másképp. :)

Mint ahogy a ,,pluszos'' órajelekkel volt: kevesebb, mint ami rá van írva, de mégis gyorsabb az Intelnél állítólag.

Ja, esetleges pontatlanságokért elnézést kérek, felelősséget pedig nem vállalok. :) Nincs minden a fejemben nekem sem, amit tanultam.

Pedig nem jársz szerintem messze a megoldástól. Pontosan azért, mert a szuperskalár architektúra miatt rengeteg áramkört már így is beépítettek az adatfüggőségek beazonosítására.
Vannak esetek, amikor nem az adatfüggés a szűk keresztmetszet, hanem a végrehajtóegységek kapacitása. Ezt bizonyítja az, hogy az Intel olyan nagy teljesítménynövekedést tudott elérni azzal, hogy a conroe magban megnövelte az utasításdekóder és a végrehajtóegységek közötti portok számát és szélességüket 64bitről 128bitre növelte. Megjegyzem ez igazán az SSEx utasítások végrehajtásánál számít csak. Vagyis olyan kódról van szó, ami utasítás szintű párhuzamosságot tartalmaz, mégpedig előre kijelőlt módon. Tehát nem a processzornak kell észrevennie a párhuzamosítási lehetőséget, hanem már a programozó/fordító kijelölte ezeket.
Az AMD nem tudja megcsinálni azt, amit az Intel, illetve nincs értelme, mert a K7/K8 3-3-3 (ALU/FPU/AGU) általános célú végrehajtóegységet tartalmaz, míg az Intelnek külön végrehajtóegységei vannak a vektoros MMX/SSEx utasítások végrehajtására. Egy 4 regiszteres SSE művelet (mondjuk lebegőpontos) esetén az Intel csoda core arhcitektúrájában egy mikroműveletet hajt végre a kifejezetten erre a célra ott lévő 4 műveletes vektoros FPU. Az K7/8 esetén viszont a 3 db különálló FPU-nak kell összesen 4 mikroműveletet végrehajtania, ami nyilván nem megy 1 ciklus alatt. Ez tovább kombinálható azzal, hogy ha a program jól van megírva vagy a soron kívüli végrehajtás megfelelően átrendezi a vektoros utasításokat, illetve a közöttük lévő nem vektoros utasításokat, akkor további párhuzamosítás is elérhető, és ilyenkor már tényleg erősen korlátoz a végrehajtóegységek száma. Tehát ilyenkor esetleg kölcsön lehet venni a másik mag kihasználatlan végrehajtóegységeit és azoknak is lehet küldeni mikroműveleteket, így már összesen 6 ALU 6 FPU és 6 AGU áll rendelkezésre. Persze amit itt leírtam csak akkor működik, ha tényleg olyan a feladat, hogy sok egymástól független adatot kell piszkálni. Megjegyzem a 3D-s játékok, videotömörítés meg ilyesmi elég sok ilyen részt tartalmaz és szerintem az AMD pontosan ezt vette célba. Szerintem semmi egyébről nincs itt szó.

Ja, de még egyvalamiről van: marketingről.

---
Apparently the human mind is not unlike cookie dough.

Tehát ilyenkor esetleg kölcsön lehet venni a másik mag kihasználatlan végrehajtóegységeit és azoknak is lehet küldeni mikroműveleteket, így már összesen 6 ALU 6 FPU és 6 AGU áll rendelkezésre.

Általános esetben ebben van valami, csak ez miért is kétmagos processzor?
Miért nem egy széles processzor Hyper-threading-gel?

Nade itt egy konkrét hírről van szó:

Egyes hírek szerint az AMD olyan technológián dolgozik, amely a több maggal rendelkező processzorokat egymagos processzornak hazudja az operációs rendszer felé.

Akkor milyen másik mag? Hiszen az OS csak egy magról tud, tehát egy magra ütemez. Az egyszerre egy futó thread, tehát a másik mag nem csinál semmit. Ha "kölcsönvesszük" a végrehajtó egységeket, akkor kapunk egy egyszerű széles processzort.

Az egésznek max virtualizációval lenne értelme...


Ez tovább kombinálható azzal, hogy ha a program jól van megírva vagy a soron kívüli végrehajtás megfelelően átrendezi a vektoros utasításokat, illetve a közöttük lévő nem vektoros utasításokat, akkor további párhuzamosítás is elérhető, és ilyenkor már tényleg erősen korlátoz a végrehajtóegységek száma.

Persze, csak a program nincs jól megírva. Egyrészt mert kevesen szeretnek asm-ben kódolni, egy konkrét processzorcsaládra optimalizálva.
Másrészt mert a fordítónak nehéz egy bonyolultságon túl átrendezni az utasításokat.

A Hyper-thread-ben pont az a pláne, hogy a két thread már logikailag is függetlenül fut egymástól, így sokkal jobban lehet a két thread utasításait párhuzamosan futtatni, azaz eloszatni az utasításokat a végrehajtóegységek között.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

>Akkor milyen másik mag?
...
>Ha "kölcsönvesszük" a végrehajtó egységeket, akkor kapunk egy egyszerű széles processzort.

Megmondom neked, mi az értelme. Az, hogy átkapcsolható lesz a processzor 1 thread dupla szuperskalár vagy 2 thread-es üzemmód között. Ne felejtsd utolsó szavam: marketing! Ez egy hangzatos feature, ami eladható. Ezért ölni fogják egymást a gamerek, mert idáig kb hány multithread-képes játék is van? Quake4 az biztos és ... van még egy azt tudom, talán a Call of Duty2, de nem 100%, viszont az biztos, hogy jelenleg kettő van összesen. Amíg a játékok többsége nem multithread-es, addig bizony jobb egy széles szuperskalár processzor, mint egy kétmagos.
Akkor miért nem gyártanak egy 6-6-6 végrehajtóegységes egymagos változatot? A kérdés jó. Talán mert nem akarnak bevezetni egy teljesen új termékvonalat arra, hogy a régi alkalmazások gyorsabban fussanak, inkább a meglévő terméket akarják univerzálisabbá fejleszteni.

>Persze, csak a program nincs jól megírva. Egyrészt mert kevesen szeretnek asm-ben kódolni, egy konkrét processzorcsaládra optimalizálva.
Másrészt mert a fordítónak nehéz egy bonyolultságon túl átrendezni az utasításokat.

Csak nem biztos, hogy kell. Példa modjuk audiotömörítésből: 16 pontos FFT. 16 pontos klasszikus pillangóműveletes FFT az 64 db szorzás és 128 db összeadás ha jól rémlik. A műveletek szépen csoportosíthatók belső adatfüggés nélküli fázisokba. 1. fázis 16 db szorzás, 2. fázis 32 db összeadás (jó ez 16 összeadás 16 kivonás), majd 3. megint 16 szozás, 4. megint 32 összeadás, stb egészen 8-ig. Ha a műveleteket az algoritmusból természetesen adódó módon csoportosítod, akkor mindenféle assembly és kézi optimalizálás nélkül olyan műveletek kerülnek egymás mellé, amikben nincs adatfüggés egymás között. Vagyis egy fázis összes művelete párhuzamosan elvégezhető. Namost egy hangtömörítő tipikusan nem 16-os, hanem mondjuk 512-2048 pontos FFT-ket szokot használni, ahol egy fázison belül ennek megfelelően 512-4096 párhuzamosítható művelet lesz. Itt tényleg csak a végrehajtóegységek troughputja számít. Hasonló a helyzet videotömörítésnél, csak ott 8x8-as DCT-vel, utána meg a mozgás detektálásnál egy jó adag koreláció számítás, ami szintén ilyen széles DSP-nek való feladat. 3D alkalmazásoknál a geometriai transzformációk többnyire szintén ilyenek (és a grafkártya T&L egysége nem tud elvégezni mindenfélét a CPU helyett, bár azért ebbe az irányba fejlődik az ipar), a fizikai modellezés szintén tartalmaz ilyen jól párhuzamosítható számításokat. Szóval volna hol kihasználni ezt a lehetőséget. Tény, hogy a gcc ettől aligha fog akárcsak 1%-al is gyorsabban fordítani, tény, hogy a mysql ettől aligha fog gyorsabban kiszolgálni queryket, a bzip2 vagy a lzmash nem fog gyorsabban tömöríteni, de viszont a pl gimp várhatóan sokkal gyorsabb lesz tőle.

EDIT: ja arról el is feledkeztem, hogy ha a két magot összekapcsolják akkor elvileg lehetőség volna a két L2 cache egyesítésére is, ami viszont elsősorban ott fog előnyt hozni, ha csak pár %-ot is, ahol a széles végrehajtás általában nem segít.

---
Apparently the human mind is not unlike cookie dough.

Az, hogy átkapcsolható lesz a processzor 1 thread dupla szuperskalár vagy 2 thread-es üzemmód között.
De hát pont ezt tudja a hyper-threading. Én legalábbis nem hallottam olyat, hogy egy HT-s procin lassabb lenne egy 1 thread-es számítás, mint HT nélkül.
Olyat viszont hallottam, hogy gyorsabb a 2 thread-es.

Igen, vannak algoritmusok, melyek remekül párhuzamosíthatók. De nem véletlen, hogy a világon mindenhol a több mag irányába indultak el, s nem a szélesebb processzorok irányába.(Itaniumot leszámítva, de az annyira más, hogy ne keverjük ide.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

>De hát pont ezt tudja a hyper-threading.

Nem, a hyperthreading nem ezt tudja, ott van egy magban x végrehjtóegység, amiből y db van kihasználva a maradék x-y-ből valamennyit megpróbál egy másik thread futtatására használni.
Itt most az az elképzelés(em), hogy van x végrehajtőegység az egyik magban, van x végrehajtóegység a másik magban akkor a processzort olyan üzemmódban is el lehet indítani, hogy egy mag látszik 2x végrehajtóegységgel. De szerintem te itt valami egészen másra akartál gondolni, mert úgy hiszem, hogy amit most leírtam azt te is tudod.

>Én legalábbis nem hallottam olyat, hogy egy HT-s procin lassabb lenne egy 1 thread-es számítás, mint HT nélkül.

lásd mysql benchmark: http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=5

>De nem véletlen, hogy a világon mindenhol a több mag irányába indultak el

Persze, de van x millió game, ami nem multithreades és soha nem is fogják átírni olyanra, viszont ki tudna használni egy szélesebb processzort. Az AMD most a gamereket célozza meg ezzel.

>... s nem a szélesebb processzorok irányába. (Itaniumot leszámítva, de az annyira más, hogy ne keverjük ide.)

lásd conroe: http://www.realworldtech.com/page.cfm?ArticleID=RWT030906143144&p=3
Érdemes megfigyelni az utasításdekóderek és a végrehajtóegységek számát. Szerintem igencsak keményen a szélesítés irányába változik az architektúra és az (egyébként vitatott) előzetes benchmarkok ezt a döntést igazolni látszanak.
---
Apparently the human mind is not unlike cookie dough.

Teljesen értem az elképzelésed, csak nem látom, miért lenne jobb, mint a HT.
Kívülröl ugye nincs különbség.
A HT mint te is írod dinamikus, ami jó.
Nem értem, miért lenne jó két külön magot építeni, és azok között bonyolult végrehajtóegység kérési protokollokat kidolgozni.
Még mindig úgy látom, hogy egy 2x széles HT-s proci gyorsabb kell legyen egy thread esetén, mint 2 magú, magonként x széles, mindenféle trükközéssel egybegyúrt proci.

lásd mysql benchmark: http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=5
Ez érdekes, de szerintem ez vagy mysql specifikus, vagy adatbázis lekérés specifikus. Mert ha nem így lenne, akkor semmi értelme nem lenne a HT-nak.
Egyébként az én felvetésem az 1 thread-re vonatkozott, annak meg az első sor felel meg, ami nem mond nekem ellent.

Persze, de van x millió game, ami nem multithreades és soha nem is fogják átírni olyanra, viszont ki tudna használni egy szélesebb processzort. Az AMD most a gamereket célozza meg ezzel.
De az az x millió game már létezik, ergó már van gép amin fut rendesen, erre felesleges új procit tervezni.
A jövőben megjelenő game-ek pedig úgyis multithread-esek lesznek, főleg ha megnézzük az xbox360-at, és a ps3-mat.
Egyébként eltértünk a tárgytól, mert én nem azt vitatom, hogy jó lenne egy ilyen technika, hanem azt mondom, hogy lehetetlen, ergó a hír kacsa.
Nem azért indultak el mindenhol a több mag irányába, mert az milyen jól programozható, meg hatékony, sőt kifejezetten szar programozni, és nem hatékony, de az órajelek növelése már problémás, Moore törvénye még él, tehát egyre több tranzisztorunk van, így ezzel próbálják fenntartani a teljesítmény növekedést.

Érdemes megfigyelni az utasításdekóderek és a végrehajtóegységek számát. Szerintem igencsak keményen a szélesítés irányába változik az architektúra és az (egyébként vitatott) előzetes benchmarkok ezt a döntést igazolni látszanak.

Valóban a szélesítés mellett döntöttek, de vélhetően kb ez lesz az utolsó rókabőr amit lehúznak az egymagos rendszerekről.
Már erősen közelítjük az elméleti maximumot amit elérhetünk ezzel a technológiával. Intel megduplázta az L2 cache méretét, megnövelt mindent amit lehetett, hogy elérjen 20% teljesítménynövekedést.
Ha megnézünk egy processzort, a legtöbb helyet az L2 cache foglalja el. Látható, hogy hiába növeltük a cache méretét a duplájára, és a magméretet is (bár azt talán nem a duplájára), alig nyertünk valamit.
Ellenben ha két magot teszünk ugyanekkora helyre, az bár nem dupla teljesítmény, de 40%-50% körül biztos van.
Tetszik, nem tetszik, ez a jövő.

De mégegyszer mondom, nem azt állítom, hogy nem jó dolog az egy mag, és nem állítom, hogy nincs benne még rejtett tartalék, hanem azt mondom, hogy a jövő (sajnos) a többmagos rendszereké, továbbá azt, hogy a hírben említett technológia nem létezik/létezhet, a hír kacsa.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

> Még mindig úgy látom, hogy egy 2x széles HT-s proci gyorsabb kell legyen egy thread esetén, mint 2 magú, magonként x széles, mindenféle trükközéssel egybegyúrt proci.

Err, itt kicsit más a probléma. Az AMD nem hyperthread-el, mert mittudomén, nem akarnak szabadalmi díjat fizetni az Intelnek vagy valami ilyesmi. Vagy lehet, hogy most éppen ők játsszák a "nem veszünk át technológiát a másiktól, mert mi vagyunk az elsők" szindrómát. Pedig szerintem jobban is működne a hyperthread a sok egyforma általános célú végrehajtóegységen, ami az AMD-nek van, mint a sok különböző fajta végrehajtóegységen, ami az Intelnek van. Legalábbis lényegesen egyszerűbb ütemezni az utasításokat.

Azon kívül meg mindegy ha hyperthread-et, ha inverz hyperthread-et, ha szélesítést csinálnak, minden esetben alaposan át kell tervezni a magot, ebből a szempontból nincs előnye egyik megoldásnak sem a másikhoz képest.

>Mert ha nem így lenne, akkor semmi értelme nem lenne a HT-nak.

Jó, hát ez egy példa, ami csak azt mutatja, hogy sajnos néha van hátulütője is a HT-nek, ami miatt server workload esetén többnyire azt javasolják, hogy tiltsák le, de tény, hogy nem ez az általános. Csak te valami olyasmit mondtál, hogy nem láttál még példát rá, hogy a hyperthreading rontott volna a teljesítményen.

>De az az x millió game már létezik, ergó már van gép amin fut rendesen, erre felesleges új procit tervezni.
Igen de sajnos a gamer egy olyan állatfajta, hogy nembaj, hogy nincs megjelenítő a világon, ami olyan gyorsan tudná váltani a képeket, ahogy a grafkártya rendereli, nekik akkor sem elég az fps. A soknál mindig jobb a több. Különben ki a francot érdekelne, hogy a quake3 500 vagy 600fps-el meg-e...

>azt mondom, hogy lehetetlen, ergó a hír kacsa.

Jó, hát ebben különbözünk, szerintem lehetséges, bár a hatásossága igen spéci körülmények között fog csak előjönni, ami miatt tényleg lehet, hogy végül mégsem kerül piacra. Egyébként ha elolvasod Árpi hozzászólására írt válaszomat valahol a thread tetején, akkor láthatod, hogy nekem is az volt az első gondolatom, hogy kacsa a hír és csak azért van, hogy megint valami hype legyen az AMD körül. Vedd úgy, hogy ez gondolatkisérlet a részemről, hogy szerintem, ha igaz lenne, akkor hogy lenne lehetséges és mire lehetne számítani tőle. Úgysem kerül ez egyhamar piacra, még ha igaz is, mert, mint írtam nyilván át kell tervezni a magot ígyis, úgyis, az meg sokba kerül, és sok idő, mire sorozatgyártásba kerülhet.

>Már erősen közelítjük az elméleti maximumot amit elérhetünk ezzel a technológiával. Intel megduplázta az L2 cache méretét, megnövelt mindent amit lehetett, hogy elérjen 20% teljesítménynövekedést.
> Ha megnézünk egy processzort, a legtöbb helyet az L2 cache foglalja el. Látható, hogy hiába növeltük a cache méretét a duplájára, és a magméretet is (bár azt talán nem a duplájára), alig nyertünk valamit.
> Ellenben ha két magot teszünk ugyanekkora helyre, az bár nem dupla teljesítmény, de 40%-50% körül biztos van.
> Tetszik, nem tetszik, ez a jövő.

Azért nem teljesen. Két mag az még ok, de 4 mag már megint csak elég speciális körülmények között tud hasznos lenni. Ez is csak az első lépésnél skálázódik igazán jól. Szóval szerintem itt a szélesítés és a magok számának növelése egy jó darabig párhuzamosan fog menni egymás mellett. Aztán ahogy a szoftverfejlesztők szép fokozatosan elkezdenek egyre több threadet rendszeresen használni majd azzal párhuzamosan lesz értelme növelni a magok számát.

---
Apparently the human mind is not unlike cookie dough.

5-ös, leülhet. :)

Ez egy igen érdekes gondolat, hogy ha valami kifelé egymagos, azaz egy thread-et kezel, akkor azt miért is hívnánk többmagos procinak, miért ne neveznénk mondjuk ultraskalárnak. :)

De a lényegre térve:
Ez egy kapitálsi f@szság polgártársak, legalábbis a tudomány mai (és holnapi) állása szerint.
Csak gondolkozzunk el azon, hogy létezik-e olyan fordító, mely képes egy egyszálú programot többszálúvá átírni magától.
(Aki szerint nem, az 1-es, leülhet)
Létezik persze (legrosszabb esetben több szál van, de csak egy dolgozik :) ), de azért elég siralmas a teljesítménye.

Vajon mi van több információ birtokában, egy fordító, vagy egy processzor?
Egy fordító, a teljes forrás birtokában, típusokkal, kifejezésfával, 1GB rammal, stb, vagy egy processzor pártíz/párszáz utasításnyi utasításablakkal?

Vajon mi egyszerűbb, egy algoritmust leprogramozni, vagy bedrótozni?

Tehát kedves polgártársak, ez vagy egy kacsa, vagy egy marketingfogás.

Legjobb esetben is az AMD max a szuperskalár architektúrát javítja egy kicsit, és ezt valaki szándékosan, vagy saját hülyeségből túlgondolkozta.

De kedves polgártársak, továbbra sincs ingyenebéd...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Vajon mi van több információ birtokában, egy fordító, vagy egy processzor?
Egy fordító, a teljes forrás birtokában, típusokkal, kifejezésfával, 1GB rammal, stb, vagy egy processzor pártíz/párszáz utasításnyi utasításablakkal?"

Plusz igen fontos run-time információknak, amiknek a fordító nincs. Lásd Itanium fordítók gyengélkedése.

Nyilván vannak run-time információk. Csak a kettő nem egy súlycsoport...

Azt viszont nem értem, hogy jön ide az Itanium. Már csak azért sem, mert az annyira más, hogy össze sem lehet hasonlítani.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az Itanium úgy jön ide, h végülis az is ilyen "mi tud többet, a fordító vagy a processzor" elgondolásból született. Azt gondolták, h azt a szilíciumot, amit mostanság mindenféle teljesítménynövelő workaroundokra (soronkívüli utasításvégrehajtás, etc...) használnak, azt használhatnák értelmesebb célokra is, pl több végrehajtóegység processzorba pakolásába, ha ezeket a feladatukat rábízzák a fordítóra. Így aztán van egy CPU tervezői szemmel nézve gyönyörű processzorunk, csak éppen még mindig nincs olyan compiler, ami képes lenne megfelelő hatékonyságú kódot generálni. Egyrészt a végrehajtóegységek kihasználtsága eléggé elmarad az ideálistól, másrészt pedig nem tudja azokat a feladatokat megfelelően ellátni, amiket régebben a processzornak kellett, mégpedig éppen azért, mert nincs az ahhoz szükséges run-time információk birtokában.

Saját tapasztalatom sajnos nincs, de akivel én beszéltem, az nagyon meg volt elégedve az Itaniummal. Persze ez lehet attól is, hogy elsősorban numerikus számításokra használták.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o