Új hozzászólás Aktív témák

• #553 proci985 MODERÁTOR ateszm #549

  Új Válasz 2008-09-11 00:59:54 #553

  Új hozzászólás

  Ö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

  

  proci985

  MODERÁTOR

  válasz ateszm #549 üzenetére

  egy felbontást/beállítást (előbbri tippre 1280, utóbbi gondolom ultra ) tudnál mondani? ezekszerint 3.16ghz mellett még procilimit volt, tehát 6 mega cachevel számolva 3.4 gigás 55nanos core2 már elég egy maghoz, hogy kihajtsa. tehát 4 megás core2 esetén olyan 3.8-4.0 ghzvel számolhatunk, figyelembe véve, hogy az 55nanos 3.2ghzs 9770 sebességét egy 65nanos 8megás quad 3.6 körül hozza.

  viszont tesztek alapján én némi CPUlimitet is véltem felfedezni, a 4870x2 kivételével... ami miatt felmerül a kérdés, hogy ha a többi kártyát a CPU miért fogja meg (amikor az x2 kihajtásához pont hogy több CPU kapacitás kéne). illetve van egy másik olvasata is a dolognak, miszerint a vidkari memória fogja vissza a frameratet, de akkor meg felmerül a kérdés, hogy a gtx280 a szintén egy giga ramjával mi a fenét csinál (az x2őn ugyan 2 giga van, de felépítésből és a képkockák felváltva számolása miatt a effekttíve chippenként csak egy gigáról beszélnük... más kérdés, hogy elvileg a két GPU már a 4870x2nél már hozzáférhet egymás memóriájához bizonyos műveletekkor). harmadik verzió, hogy a GTXet a memóriavezérlő és a ddr3 együtt foghatja vissza, illetve annál is van valami gixer a g80-g92 architektúrához hasonlóan a memkezeléssel kapcsolatban (utóbbi nem valszínű, akkor az utóbbiak is döglődnének).

  viszont, a 8800gt bőven a 3870 felett teljesít (és a 9600gtk is remekül tartják az iramot), ami arra enged következtetni, hogy az aluex arány továbbra is alacsonynak mondható (tehát a program inkább textúra, mint shaderintenzív, ez magyarázhatja a horror videomemhasználatot). viszont a videomemóriából nem ehet meg 512 mega felett, mert akkor a 8800gtk megdöglenének, tehát a 800mb a teszt szerint nem igaz... bár AAval lehet, hogy addig is fel lehet tornászni, asszem a tesztben az nem volt.

  harmadik verzió, hogy valamit nagyon-nagyon elszúrtak a programozók, esetleg megismétlik a Crysis fiaskót, avagy fusson rosszul Nvidia kártyákon, hogy az Atisokon katasztrofálisan menjen (és jé, ott is a CPUterhelésének elosztásával is trükköztek... lehet újra meg kéne néznem azt a progit ezzel a cuccal is). ez az NV logó miatt lehetséges, végülis a GTXeken játszhatóan megy, az Atit meg megfogjuk az emberek 90-95%ánál fellépő procilimittel (végülis itt mindkettő ugyanolyan gyors). ezt talán az a furcsaság támasztja alá, hogy az SoC aktívan terhelt két magot. ha a patchek során sem akaródzik majd effektíve egy magnál többet terhelni, akkor a gyanúm erősödik, bár programozói nemtörődömség/nem elégséges kiadói nyomás is állhat a dolog mögött.

  negyedik verzió, hogy a programot béta állapotban adták ki, optimalizálások nagyrésze így elmaradt megfelelő tesztelés hiányában (ez is magyarázhatja, hogy csak egy magot terhel... avagy terhelésütemezést még nem csináltak). erre utalhat az is, hogy az orosz felháborodás miatt két fontosabb piacon (USA, steam) a program csúszik, habár az angol fordítás már elkészült.

  na innentől jön a komment erősebb része, bár próbáltam érthetően fogalmazni. avagy párhuzamosítás:

  alapállapotban a windows csak annyit csinál, hogy engedélyezi a program számára X magon való futtatást, valamint a program számára elfedi a hardvert (ez ugye azért jó, hogy szegény programozónak ne kelljen már a hardver összes elemét ismernie, tehát ne kelljen hardverspecifikus kódokkal bíbelődnie... magasabb nyelveken általában gyorsabban átlátható és gyorsabb kódot írni, a futás meg a fordítón múlik). a párhuzamosítást végző programnál nem tudom, hogy oldották meg a dolgot (talán az ütemezőt bírálja felül futás idejű párhuzamoítással... viszont az baromi erőforrásigényes és a működés hatásfoka is nagymértékben függ a kódtól/mennyire jól van megírva a párhuzamosító).

  namármost bármelyik is az igazság, attól függetlenül a konkurens adatoknak továbbra is be kell várniuk egymást, tehát rossz esetben hiába működik minden mag, ha egymás eredményeire várnak, időben az eredmény ugyanannyi várakozási idő (tehát, 1. task eredmnyére vár a második task, harmadik a másodikéra, és így tovább, első task nulladik magon, második task első magon, harmadik task nulladik magon, tehát a taskokat az ütemező felváltva rendeli hozzá a magokhoz... és láss csodát, 50%os terhelés a program miatt, és semmit nem gyorsultunk két maggal... avagy a progi csak egy magra lett optimalizálva). tehát: ha tegyük fel a progi javult így 20%ot, akkor nem biztos, hogy nem lenne képes 100% javulásra, ha natívban futna két magon, vagy (X-1)x100% javulásra, ha X magon, mivel úgy egyrészt nem kéne egy plussz programnak a memóriában lennie és így prociidőt ennie, másrészt az utólagos párhuzamosítás egy eléggé macerás dolog (natívan párhuzamos kód általában lényegesen gyorsabb ügyes programozókat feltételezve).

  mint az eddigiekből kitűnik, a párhuzamosítás programozói szemszögből több odafigyelést (többek között időt és energiát) követel, tehát ha nem kimondottan muszáj, akkor az ember nem ír a programba párhuzamosítást (illetve pl az SoC és a Crysis esetében is fix volt az erőforráskezelés, nem pedig dinamikus a magok kihasználtságának függvényében). na ezért szoktak egy magra írni programokat... sokkal egyszerűbb. meg vannak alapvetően nehezen párhuzamosítható taskok (grafika nem ilyen pl).

  remélhetőleg nagyon nagy baromságot nem sikerült leírnom, tanultam erről, de alapvetően ez csak ilyen kiegészítő dolog volt (alapvetően egyprocesszoros és multiprocesszoros operációs rendszerekkel kapcsolatban).

Új hozzászólás Aktív témák