Aktív témák

• #2610 VinoRosso veterán kisfurko #2587

  2008-06-01 01:12:30 #2610

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VinoRosso

  veterán

  válasz kisfurko #2587 üzenetére

  eírtad, hogy max. 8 különböző utasítást hajthat végre. Hát akkor nem 8 db processzor?

  Nem, ha összefogsz 4 db X4PHENOMOT, és azokkal egyszerre ugyanazt az utasítást hajtatod végre, de különböző szálakon, azok attól még nem fognak 1 CPU-nak számítani. Annyi CPU van, ahány szál egymással párhuzamosan futhat. Ezeknek a száma pedig 128.

  A gondolatmeneted alapján akkor a hyperthreadinget használó processzormagok már egyből kettőnek számítanak?

  Nem mert az Intel a HT-ben csak a szálak ütemezéséhez szükséges egységeket duplázta meg, a végrehajtó egységek száma nem duplázódott. Ez csupán arra elég, hogy az OS két szálat tudjon párhuzamosan ütemezni, logikailag két processzort lát, de fizikailag csak 1 cpu-n, szekvenciálisan hajtódnak végre utasítások. Egyébként a nem az én gondolatmenetem, és nem azt mondja, hogy csupán az ütemezéshez szükséges elemek számát többszörözte meg. hanem van 128 végrehajtó egység, amelyek képesek párhuzamosan egymástól független szálak(=egymással összefüggő utasítás sorozatok) végrehajtására.

  Ki mondta, hogy minden stream processzornak külön mentődik az állapota?

  Ez abból adódik, hogy hogy a processzorok képesek egy blokkolt szál helyett egy másik szál végrehajtására átkapcsolni.Ez ennek szükséges feltétele.

  A nagyobb lebegőpontos teljesítmény sem a szervezésnek köszönhető, hanem a puszta ténynek, hogy sokkal több FP ALU van benne.

  Ez nem így van. Ha pusztán a végrehatjó egységeket többszörözték volna az architektúra tervezésénél, csupán egyetlen ütemezővel, akkor nem lehetne hatékonyan váltani a geometriai és a pixel folyamok közt. Nem a szél fújta oda azokat a lokális ütemezőket, szám szerint 8at, meg van belőle egy globális is, sőt hogy még hatékonyabb legyen a folyamok szervezése, a globális ütemező elé beiktattak külön geometriai, pixel, és vertex szálkezelő egységeket is. Ha ezeket mind kivennénk, akkor az olyan, mintha kiherélnénk a gtx-et, mert ezek gondoskodnak a folyamok hatékony szervezéséről. A g80 történetét pedig ismerjük, tudjuk, hogy amit csináltak, az jól, hatékonyan működik.

  nem függetlenek a "stream processzorok",

  Nem a processzorok közt alakul ki függés, hanem a vezérlésben és az adatok közt.

  De ami nem stream jellegű, az nem feltétlenül profitál ebből a nyers erőből.

  Ez pontosan így van, sőt a nem adatpárhuzamos számítások egyetalán nem profitálnak ebből semmit. Ez egy-két játékon is meglátszik, ahol csökken a párhuzamosíthatóság szinje, mert adatfüggések alakulnak ki a folyamok közt(pl az egyik olyan geometriát számol, aminek az eredményére egy másik folyamnál van szükség) Sok múlik azonban a szervezésen, és azon hogy az adott játék mennyire illeszkedik az architektúrához(vagy éppen mennyira optimalizálják, mennyire hangolják hozzá). Ezért van az, hogy a különböző architektúrák más és más játékban teljesítenek jól, ahol az egyik jó, ott a másik lehet éppen nagyon szar, mert nem fekszik neki annyira a gamma. Ez általánosságban is elmondható, hogy egy adott GPU-t mennyire sikerül általánosságban a grafikai alkalmazások elvárásaihoz illeszteni. Lehet egy architektúra nagyon jó, lehet óriási számítási kapacitása egymástól teljesen független adatfolyamok közt, ha a valós alkalmazások igényeit nem tudja kielégíteni, akkor max 3dmakkban lesz jó garfikából, de nem szintetikus alkalmazásoknál nem lesz hatékony a kihasználtság. Lásd 2900XT, ami tudományos számításokban, ahol nagy mennyiségű adatokon kell hasonló jellegű műveleteket végrehajtani(pl molekuláris modellezés, nyomásgörbék számítása, n-test modellezés, hullámegyenletek), elveri a GTX-et, grafikai alkalmazások(OGL és DX) nagyrészében meg elmarad tőle.

• #2573 VinoRosso veterán kisfurko #2566

  2008-05-31 16:09:57 #2573

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  VinoRosso

  veterán

  válasz kisfurko #2566 üzenetére

  Egyrészt az ALU az nem egyenlő a stream procival.(!!!) Hogy mást ne mondjak a legjellemzőbb különbség az, hogy egy ALU belsőábrázolása fixpontos, jellemzően kettes komplemenses. Ha tehát ha csupán ALU-k dolgoznák fel a streamet, akkor nem valószínű, hogy túl jók lennének a GPU-k float-ban, amihez ugye lebegőpontos aritmetika kell, teljesen már belsőábrázolással(IEE754),ehhez kell az FPU, mint kiegészítés Az FPU meg az ALU nem ugyanaz. ALU van FPU nélkül is.Egy stream procihoz tartozik ALU, FPU, CU, regiszterek, lokális osztott memória, lokális ütemező, cache, stb...ami egy ALU-hoz nem. Másrészt egy asztali prociban, annyi szál futhat párhuzamosan, amennyi mag van. Egy magon belül nincsenek egyszerre, párhuzamosan futó szálak. Az hogy van elágazás becslés pl, és mondjuk amig a proci IOlöketre vár, addig kiértékeli a másik feltétel szerint is a szálat, még nem azt jelenti, hogy a valóságban is két szál fut egyszerre egy procin, mivel az utasítások végrehajtása itt egy magon belül szekvenciálisan történik. Tehát egy 4magos procin maximum 4 szál futhat egyszerre, és a magokon belül nincs további párhuzamosság, ott már csak szekvenciális sorrenben követik egymást a szálankénti utasítások. Persze az utasítások felbonthatók több részre, és a pipeline miatt ezek átlapolódhatnak, de ez a sorrendi végrehatjáson nem, csak egy utasítás feldolgozásának idején változtat( az ILP nem tud olyat, hogy mondjuk 4 különböző szál 32bites utasításait összefogod egy 128 bites molekulába, maximum 1 szálon belül megengedett ez, és ott sem mindíg, mert egy szálon belül lehetnek függések az utasítások közt!!!) . GPU-n belül pedig nem 16 szál futhet egyszerre, hanem sokkal de sokkal több. Nem is tudom honnét jött ez hogy 16 blokk, szerintem kevered a szezont a fazonnal. Egyrészt nem blokkokról van szó, hanem klaszterekről, Olyanról hogy ALU klaszter én még nem hallottam, ellenben processzrokat szokás klaszterbe szervezni. Aztán meg ebből összesen a g80-ban 8 darab van, nem 16. A 8 klaszteren belül van a 16 stream proci. Ezek mindegyike képes külön szálon dolgozni, egy proci összesen 96 szál kezelésére képes. Tehát ha egy szál IO löketet kap, és a proci éppen lazsálna, akkor átvált egy másik szálra, és így javul a kihasználtság. Simán elképzelhető az, hogy egy proci, ami idáig geometriát számolt pl, és éppen egy memóriamáveletre vár a végrehajtott szálon, közben átvált egy másik szálra, és elkezd pixelekkel dolgozni( SM 4.0 ) Ehhez ugye elég sokminden kell, mert ahhoz hogy ezt meg lehessen tenni, a szálak között tudni kell váltani, amihez kell egy ütemező, és ezeknek el kell tudni menteni a környezetüket stb..tehát ebből is megint látszik, hogy nem szimpla ALU-król van szó. Mivel 128 darab ilyen van egy g80GTX-ben, ezért a valós párhuzamosság foka ennyi lehet. Ez azt jelenti, hogy 128 darab különböző egymástól független szál futhat egymással párhuzamosan. Ebből 8 darab teljesen más utasításokat is végrehajthat, és a 8 darab klaszteren belül van 16, ami ugyanazt az utasítást hajtja végre, de teljesen független adatfolyamokon( tehát ezek nem befolyásolják egymás futását, nincs sem adat, sem vezérlésfüggés az utasításaik között). Az egész hóbelebanc tehát egy 8irányú MIMD, ezen belül pedig 16os SIMD. Így jön ki a 8x16=128. Az meg már csak a hab a tortán, hogy minden egyes procira 96 szálat lehet ütemezni, ami összesen 96x128=12228 szál futtatását teszi lehetővé egyetlen GPU-n. Ez óriási szám, és emiatt van hogy a GPU-k ennyivel verik a procikat float-ban. Igaz ezek még nem 64, csak 32bitesek, de már rajta vannak az ügyön, és lesz nemsokára 64bites is. Amit meg írtál, hogy nem lehet megmondani, hogy melyik szál hol fusson, nos jobb estben ezt a CPU-knál sem lehet, de ennek semmi köze nincs ahhoz, hogy most van párhuzamosság a szálak között vagy nincs. Persze le lehet korlátozni az affinitást egyetlen pocesszorra minden szálnál, és akkor azok csak adott magon fognak futni, de ennek max hibakeresésnél van jelentőssége, amugy csak ront a futási teljesítményen, hiszen kihasználatlanul maradhat a CPU idő az egyes magokon. Ezen túl elég nagy gubanc így is, ha már csak pár konkurrens folyamatot vagy szálat kell a programozónak kezelnie, szinkronizálnia, mert nagyon könnyen deadlockos vagy livelockos lehet a progi, és lehet, hogy a futtatórendszer( OS vagy keretrendszer,vagy VM) ami a szálakat ütemezi, éppen olyan ütemezési stratégiát használ, amivel a hibadetektálás nagyon nehéz. Az hogy expliciten kezeljenek akár még csak 100 szálat is, nemhogy 12 ezret, elképzelhetetlenül bonyolult feladat. Ezért a jobb programozási környezetek szépen leveszik ezt a terhet a programozók válláról, hogy ne nekik kelljen törődni az ilyen hibák elkerülésével. Az meg hogy a GPU-k teljesítménye floatban jóval felülmúlja a CPU-két, nem kérdéses szerintem senki számára,a ki egy kicsit is hozzá tud szagolni ahhoz amiről szó van, de hogy zt kevés helyen lehet kihasználni, az baromság. Szinte minden tudományos számítás a főleg fizikában, kémiában, műszaki tudományokban, közgazdaságtanban, és még sorolhatnám lineáris algebrára épül, a GPU-k meg már a kezdetek óra vektorokkal és mátrixokkal számolnak. Az egyetlen bibi ott van, hogy sok számításban nagypontosságú aritmetikára lenne szükség, mert nem lehet elég jól kondícionálni az egyenleteket ahhoz hogy elfogadható küzelítő megoldást lehessen kapni, de amint említettem úgy tudom, már mindkét gyártó dolgozik a 64 bites FPU+regisztereken, tehát a jövőben még nagyobb sikerre lehet majd számítani ezen a területen. De hogy ne csak az nvidiát ajnározzam, itt van egy ábra a CTM teljesítményéről.
  Akinek meg esetleg nem megy a SZAR, nem tudja megkülönböztetni a CPU-t, ALU-t,FPU-t, CU-t, nem tudja mi az hogy belső ábrázolás, stb.. az tanulmányozza át ezeket.

  [link]

  [link]

  [link]

  [link]

  [link]

  [link]

  na erre most nem lehet azt mondani, hogy az NVIDIA-tól van, bár tudom, hogy a wikipedia-t is ők pénzelik...de most már nem offolok többet, mert aki ebből nem ért, annak már tökmind1 mit mondok.

Aktív témák