Diskuze: Architektura procesorů Nehalem (2/2)

Uživatel bez registrace

Level 1

4. 9. 2008 23:27

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace cituji "L3 cache hrozivě pomalá a dokonce má i přes větší velikost menší asociativitu než L2 u Penrynu!" z toho je to jasne. Pokud byste znal jak se cache realizuje tak vite ze na vyssi stupen asociativity potrebujete krome spousty komparatoru a multiplexeru i vice pameti pro tagy datoveho bloku. Takze spravne tvrzeni by spise bylo: "Intel se rozhodl pro nizsi stupen asociativity a diky tomu ziskal navic misto na cipu pro vetsi velikost cache"
- jozef01

Uživatel bez registrace

Level 1

4. 9. 2008 23:44

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: jinak pokud se jednalo pouze o nevhodne zvolenou formulaci, tak se omlouvam za pripadne rypani ;-) pro me to bohuzel vyzniva ze vetsi cache musi mit nutne vyssi stupen asociativity. Osobne bych rekl ze tento navrh byl vytvoren na zaklade simulaci realneho kodu a proste takto navrzena triurovnova architektura je pravdepodobne pro tento procesor, s ohledem na technologii, nejefektivnejsi. Taky zde neni zminena velikost datoveho bloku s tou mohli take pohnout...
- jozef01

Uživatel bez registrace

Level 1

4. 9. 2008 23:40

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: S tímto tvrzením nemůžu souhlasit. Podle mého je cache v Nehalemu horší než u Penrynu. Jestli Intel potřeboval zmenšit množství tagů, aby mohl zvětšit velikost, to je mi upřímně řečeno jedno. Výsledek je pro mě jasný - nová cache je sice o 33 % větší, ale taky 3x tak pomalá a má horší asociativitu. Z toho mi tak nějak vyplývá, že hit rate může být podobný (větší velikost, ale menší asociativita) a to při třetinové rychlosti. Celkově tedy jednoznačně mínus.

Trošku off-topic: je zajímavé sledovat, že Intel cache skládá z bloků včetně tagů a asociativity. Penryn má 6 MB při 24-way, Conroe má 4 MB při 16-way, Conroe-2M jsou 2 MB při 8-way, Conroe-1M je 1 MB při 4-way a Conroe-512K je dokonce 512 kB při 2-way. Se snižující se velikostí je tak odrovnávána nejen účinnost vyplynoucí z kapacity, ale také účinnost plynoucí z asociativity. AMD s menší cache asociativitu zachovává.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 08:43

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: V pohodě, jako nevhodnou formulaci to určitě neberu. Datový blok by snad stále měl mít 64 byte, tahle hodnota se neměnila ani v Pentiu 4, kde byl velmi agresivní prefetch (2x 64 byte). Větší mi přijde, že už by nebyly efektivní.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 00:02

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: k te asociativite, to muze byt taky jen marketingova hra, aby levnejsi procesory proste byly v benchmarcich viditelne pomalejsi. Krome toho bude taky vyssi vyteznost, protoze pri nizsi asociativite jsou na cache kladeny mensi naroky. Pokud si dobre vzpominam tak podobna situace byla u Tualatinu, tehdy L2 cache PIII mela krome dvounasobne velikosti i dvounasobny stupen asociativity,
- jozef01

Uživatel bez registrace

Level 1

4. 9. 2008 23:53

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: hm, no nevim, asi zapominate na to, ze je tam stale ta L2 cache, ktera je naopak RYCHLEJSI, troufam si tvrdit ze L2, ackoliv je vyrazne mensi, tak pri o tretine nizsi latenci (4T) muze klidne dosahnout stejnych vykonovych parametru, protoze s rostouci kapacitou u techto velikosti jiz neprinasi razantni snizeni cache miss.
- jozef01

Uživatel bez registrace

Level 1

4. 9. 2008 23:54

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: upresneni, ta latence nove L2 je 10T misto 14T
- jozef01

Uživatel bez registrace

Level 1

5. 9. 2008 01:21

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Existuje nejakej patch na tohle "rotovani" procesu i pro XP x64 nebo 2003 Server?

Snazil jsem se o tomhle debilni jevu zjistit neco v EN, ale stranky MS jsou zticha a vseobecne je tak odbornej, ze vetsina lidi ani netusi, ze je to chyba v chovani scheduleru.
Docela by me zajimalo, jak moc to clouma se spotrebou na phenomu. Tam by mel bejt vliv este mnohem vetsi nez u C2D.

Nekdy by MS vazne zaslouzil kopnout do *****.
- JoHnY2

Uživatel bez registrace

Level 1

5. 9. 2008 08:41

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @JoHnY2: Plně funkční oprava určitě neexistuje. Zkuste ale nainstalovat patche, třeba se to trochu zlepší - http://thehotfixshare.net/board/index.php?autocom=downloads&showcat=14
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 10:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace kolego, ja vim co je kontext switch, ale je na vuli scheduleru na jakem procesoru vlakno/proces spusti, protoze cely jeho stav je ulozen v hlavni pameti, ktera je pristupna vsem procesorum stejne.
- jozef01

Uživatel bez registrace

Level 1

5. 9. 2008 10:40

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: ok, nic ve zlym. ale vypadalo to, jako ze povazujete kontext switch za proceduru, kdy se prave proces zmigruje na jiny jadro... :)takze, uz si pravdepodobne rozumime ;-)
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 10:58

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @daniel zika: jeste uprava, ne ze se zmigruje, ale ze prave v tu dobu migruje jinam.
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 11:54

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @daniel zika: ano, v dobe kdyz je proces schedulerem vypnut se nachazi pouze v hlavni pameti, navaznost na puvodni jadro je pouze v moznosti existence nejakych relevantnich dat v cache konkretniho jadra, kterou si ale myslim ze nema cenu schedulerem vubec zjistovat, dopad na vykon muze byt nemaly a navic bude opravdu velmi zalezet na konkretni architekture procesoru, poctu cachi, jejich velikosti, asociativity, velikosti bloku, inkluzivite atd. atd... muselo by se to realizovat primo v HW aby to melo vubec smysl.
- jozef01

Uživatel bez registrace

Level 1

5. 9. 2008 12:04

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: je fakt, ze aby scheduler jeste zjistoval, jestli proces nema v nejaky cachi data, a proto se ho snazil opet probudit na stejnym jadru, je nesmysl.
Ale, slo spis o to, ze nekdy ty procesy migruji vic, nez by bylo ptoreba, protoze ani jedno jaro neni vytizeny tak, ze by nestihalo. sice pohled scheduleru muze byt jiny.. ale, snad by nebyl problem mit nejakou bitovou masku, ktera by rikala, na kterym jadre proces posledne bezel. zaroven scheduelr musi mit prehled o utilizaci jader.
z toho si myslim, ze uz by mohl nejak dat dohromady, na kterym jadru proces opet probudit, ne ? proste, kdyz jsou obe jadra vytizeny na 10%, tak mi to prijde divny a radsi bych jedno mel na treba i 25% a druhy v nejakym spacim stavu. zrovna na NB by to mohlo byt znat, na desktopu to v podstate muze byt jedno.

ale jeste me napadlo, s tim, ze jak intel, tak amd se sunou smerem k NUMe, tak probuzeni na jinym jadru muze dost zvysit latenci (pristup k pameti adresovane jinym procesorem). resp. ne jadru, ale procesoru.. ale nevim, jak ma scheduler namapovany vlakna/jadra/procesory. na tom asi bude hodne zalezet
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 12:11

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @daniel zika: tak tahle otazka je balancovani nad celkovym vykonem a latenci pridelovani procesoru a ne nad vyuzitelnosti cache. Primarne jde o to ze samotne prepnuti kontextu je pomerne narocna zalezitost, takze je potreba jeho pocty minimalizovat, ale zase ne za cenu zvyseni latence. Vemte si napriklad ze hloupa mys, ktera ma frekvenci 200Hz, techto prepnuti vygeneruje minimalne 200 za sekundu a neni to jen o mysi, muzete na pozadi stahovat soubor, takze Vam minimalne kazdy frame vyvola dalsi prepnuti...
- jozef01

Uživatel bez registrace

Level 1

5. 9. 2008 19:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: Jde primárně o to, že logická úvaha je taková, že přesunem na jiné jádro OS způsobí latence v důsledku cache miss (a to, jak se ukázalo z reálných měření, nikoli zanedbatelné). Systém má přehled o utilizaci paměti procesem (alokace RAM probíhá voláním funkcí OS), tak by přece mohl sám vyvodit, že aplikace, která alokuje větší objemy dat bude při přesunu do jiného jádra značně zpomalena vznikajícími cache miss, a proto by mohl klidně počkat na uvolnění původního jádra. Přijde mi, že je lepší mít latence na úrovni kontext switch, než pak způsobit ještě větší latenci na úrovni cache miss.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 12:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: ja to chapu, ze tech prepnuti je hodne. jde mi o to, jaky vsechny faktory ten scheduler umi vzit v uvahu. kdyz budu mit 2nehalemy, tak uz je velky rozdil, jestli kdyz se proces probudi na jadre druhyho procesoru, kterej je sice treba nezatizenej, ale do pameti, kterou proces ma alokovanou stejne poleze jako do vzdaleny.
takze, jsem zvedav, co s tim MS udela, nebo jestli uz na to mysleli a Visty to maj nejak vychytany (zavolaji treba CPUID a podle toho zvoli strategii scheduleru?), nebo se bude cekat treba na SP2.
V linuxu by to snad takovej problem byt nemel, tam se novy verze kernelu objevuji celkem casto, ale s frekvenci vydavani SP se bojim, ze nehalem jeste nejakou dobu nebude moct ukazat, co vlastne umi
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 10:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace nechci rejpat, ale... pokud namerim rozdil 1-2%, tak bych se mozna spis zamyslel nad tim, jestli 1) mam pro obe mereni uplne stejny podminky, 2) jaka je presnost mereni, ktery provadim. prece jen, 1-2% mi pripadaji jako prijatelna chyba... ?

navic, cekal bych, ze prave mezicachovej traffic se znacne zredukuje prave tim ,ze nektery cache jsou sdileny a v pripade Intelu inklusivni.
- daniel zika

Uživatel bez registrace

Level 1

4. 9. 2008 23:35

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace jasne ze OS rozdeluje cpu defacto jednotlivym vlaknum, procesy jsem zvolil pro zjednoduseni, princip je stejny. Je jasny ze pokud budu prepinat vlakna jednoho procesu tak bude zrejme vyhodnejsi ho obnovit na stejnem jadre. Zajimavejsi otazka k diskuzi by byla jestli on-line pocitani vyhodnosti obnoveni vlanka na konkretni cpu neprinese vetsi skodu nez uzitek. Uvedomme si, ze opravdu ve chvili kdy chceme konkretni vlakno obnovit muze byt jeho puvodni jadro mezitim zamestnano jinym procesem. Jak pak urcime jestli je vyhodnejsi tento proces presunout na druhe jadro nebo ho spustit na tom puvodnim? OS by musel on-line analyzovat spousteny kod a podle toho odhadovat aktualni vyuziti cache a to nebude zadarmo.
- jozef01

Uživatel bez registrace

Level 1

5. 9. 2008 19:24

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @daniel zika: ad 1) Ano, podmínky úplně stejné, protože se prostě v BIOSu druhé jádro vypnulo. Tedy úplně stejný HW i SW, jediný rozdíl byl počet zapnutých jader.

ad 2) Přesnost měření je taková, že opakování testu generuje přesně stejné výsledky, což vzhledem k reportované jednotce (sekundy) znamená maximální nepřesnost menší než 1 sekunda z času nějakých 100 až 130 sekund. Měření bylo provedeno na dvou procesorech a výsledkem byl pokles výkonu o cca 1 až 5 %.

U Intelu jsou ale sdíleny jen L2 cache, u Nehalemu dokonce až L3. Není sdílena L1. A právě že při rychlém střídání procesů a jejich přehazováním jinam se nejdřív musí do L2 zapsat upravené výsledky z L1 prvního CPU a pak se tyto výsledky musí dostat z L2 do L1 druhého CPU. To stojí hrozně moc výpočetního času.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 08:46

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @jozef01: A co třeba evidovat, kolik proces spotřeboval v posledních pár milisekundách času? Pokud by spotřeboval hodně, pak by to mohlo naznačovat, že bude ještě hodně času potřebovat. Nové procesy (... s potenciálně krátkou dobou běhu) by se přidělovaly jednomu jádru (byť i třeba s určitým čekáním) a starý proces s velkým vytížením nerušeně druhému.
- Eagle

Uživatel bez registrace

Level 1

4. 9. 2008 22:59

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace To je věc k diskuzi, každopádně stav bude takový, že jádro, byť bude odpojeno přes Power Gate, se stále bude hlásit operačnímu systému, a proto minimálně některé jeho části budou muset být v pohotovostním režimu. Případný cache flush před odpojením přes Power Gate (pokud bude vyžadován) může trvat natolik dlouho, že než se jádro připraví k odpojení, Windows mu přidělí další úlohu. S HTT to bude ještě horší.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 09:02

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: no, prece CPU hot swap uz na svete, aspon v oblasti serveru, nejakou dobu je, tak proc by MS nejakou podobnou ficuru nemhly implementovat ? urcite by to bylo uzitecnejsi nez nejaky Aero apod. omalovanky, ktery sice sou pekny, ale prakticky k nicemu a jen zerou vykon/pamet
- daniel zika

Uživatel bez registrace

Level 1

4. 9. 2008 22:38

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Ach ty automatické opravy. Poprvé jsem to nepsal v HTML a jak to dopadlo... díky.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 09:13

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace no, tam hodne zalezi co bezi za aplikaci. prece jen, xeon je mnohem dostupnejsi nez itanium a nasazujou se na uplne jiny masiny.
Je ale fakt, ze tam se spolehalo prave na to, ze kompilator dokaze generovat dostatecne paralelni kod, coz ne vzdycky jde - proste nema tolik informaci o kodu, jako ten, kdo ho stvoril, coz neprekvapi.
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 21:01

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Diskutujeme o Intelu, nikoliv o AMD to má technologii HTT (HyperTransporT). Samozřejmě vím, že ta rychlá odezva byla na úkor ignorování priorit, ale mě to nikdy nijak neomezovalo, ba právě naopak, pokud jsem potřeboval na net nebo na ICQ bylo to právě v tu chvíli a že se mi o pár vteřin zpomalí přepočet videa mě nemrzelo.
Často jsem hrával NFS jen už si nepamatuju podnázev a současně přepočítával video a hra byla naprosto plynulá, jen občas se stalo jako by vypadl jeden snímek. Při vyplém HT to bylo buď nehratelné, nebo se musely přepočtu videa snížit priority a značně prodloužit čas přepočtu. Samozřejmě se najde spousta testů, kde se prokáže nevhodnost HT, ale stejně tak se dají najít testy, kde by Trabant porazíl bez problémů Mercedes :-). O nevhodnosti HT se toho napsalo hodně a přečetl jsem si to naštěstí až po koupi procesoru, určitě by mě to od koupi odradilo, nicméně já byl s HT naprosto spokojený a nikdy se nesetkal s problémy.
Někdy je možná dobré přemýšlet nad tím k čemu to nebo ono využít a ne jak dokázat, že se jedná o špatnou technologii

- XXl

Uživatel bez registrace

Level 1

5. 9. 2008 09:20

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace jinak, kde se vlastne vzalo to srovnani SMT = HTT ? vi se ze nehalem bude podporovat beh 2vlaken na jednom jadre, coz ale nemusi nutne znamenat, ze je to ten samej princip ve vsech ohledech a tedy, ze se to bude chovat uplne stejne, nebo ?
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 09:17

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace nevim, jak to je na win s ignorovanim priorit pri zapnutym HTT. Kazdopadne, na Linuxovym serveru, kterej bratr spravoval, takovydle problemy nemeli. proste nice -n a bylo vymalovano. treba kdyz se kompilovala nejaka velka obluda (OOo, X, glibc), dostal tendle proces velkej nice a makalo to celkove tak o 30% rychleji nez s vypnutym HTT.
Je ale fakt, ze to vyuziti je uplne jiny, nez asi vetsina lidi provozuje doma
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 22:44

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @XXl: Název HyperTransport (HT) vzniknul dříve než Hyper-Threading Technology (HTT), proto zkratka HT náleží AMD.

S tím zpomalením výpočtu videa to, obávám se, ne úplně chápete - při správném nastavení priorit je výpočtu videa přidělena nízká a ICQ jako standardní aplikaci normální. ICQ pak má vždy při přidělování prostředků přednost, což je logický a správný stav (výpočet videa počká). Toto je standardní chování operačního systému a jakékoli jeho narušení je chyba. Na hraní hry vs. výpočtu videa z vašeho příkladu je jasně dokázáno zcela chybné chování, protože je to hra, kdo má dostat 100 % výkonu CPU (bez ohledu na její hratelnost nebo nehratelnost) a nikoli jen jeho polovinu vlivem hardwarové chyby v návrhu procesoru. HTT fakticky degraduje prioritu všech úloh na standardní, což vede k tomu, že tato činnost úplně postrádá smysl.

Intel vymyslel HTT pro servery, kde mají všechny úlohy stejnou prioritu. U desktopů to byl jednoznačný marketingový tahák.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 19:15

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @daniel zika: Možná si nerozumíme - ignorování priorit je věc, která se nedá řešit na úrovni software. Musí tím tedy trpět i Linux, protože je to vlastně hardwarová závada. Řešení této vady by vyžadovalo úpravy operačních systémů a zřejmě i nějaký standardizovaný přístup k řízení priorit na úrovni hardware. Nic takového Intel ani MSFT neudělali.
- Eagle

Uživatel bez registrace

Level 1

6. 9. 2008 19:54

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: Zvláštní ovšem je, že po zadání HT do prohlížeče mi to ukazuje pouze odkazy na články s Intely a HyperTheardingem - nu což asi se můj PC mýlí ve zktatce stejně jako já :-)
Mimochodem testoval jsem se stejnými programy i AMD a bez zásahu do priorit se chovalo naprosto stejně jako ten Intel při vyplém HT.
Co se týče ICQ a toho zda daný problém chápu můžu dodat jediné, s C2D i s dvojjádrovým AMD procesorem musím čekat až si na mě procesor udělá čas, u HT technologie k tomu nedošlo ani v případě, že jsem vypaloval, další film kopíroval na HDD, přepočítával video a měl 2* spuštěného klienta hry Lineage. Prostě v odezvě systémů měl starý P4 navrch i když jsem měl tehdy pouhý 1GB RAM
Ne nebylo to standartní využití PC, ale test a taky tak trochu předvádění mého počítače před kamarády, kteří měli vesměs AMD a nedovedli pochopit, proč jsem si pořídil Intel.
- XXl

Uživatel bez registrace

Level 1

6. 9. 2008 20:34

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @XXl: Když si nechám vyhledat zkratku HT na stránkách Intel.com, tak mi to vždycky vyjede se slovem "technology". Z toho je celková zkratka HTT. AMD představilo HyperTransport již v roce 2001, tedy rok před tím, než Intel uvolnil HTT do Xeonů.

P4 s vypnutým HTT se samozřejmě chová úplně stejně jako jakýkoli jiný procesor - respektuje priority.

Odezva u HTT může být o něco lepší, protože tam nemusí docházet k tolika cache miss u L1 cache. Nicméně rozdíl takového charakteru mi přijde zcela neměřitelný a mnohem větší vliv má dle mého celková velikost cache (u Intel Penryn 6 MB) a rychlá RAM (u Athlonu integrovaný paměťový řadič). Přijde mi tedy, že "cítit" lepší odezvu HTT je spíš placebo efekt.
- Eagle

Uživatel bez registrace

Level 1

7. 9. 2008 19:01

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: Žádny intel.com :-) ale normální české servry. Vžilo se skutečně označení HT pro Hyperthearding a HTT pro HyperTransport, nicméně jsou i tací, kteří používají opak :-). Je v celku jedno jak kdo tuhle funkci ve zkratce označuje, pro mne bylo podstatné, že fungovala.

Nj Intel s vyplým HT respektuje priority, ale současný běh hry a přepočtu nezvládl stejně jako tehdy testované AMD s o krapet vyšším výkonem. Pro HT to byla brnkačka a pokud bych to vzal podle měření byl přepočet videa pomalejší o 10-15% než když bylo zpracováváno samostatně a hra se zpomalila jen nepatrně - docházelo pouze občas jakoby k vypadnutí jednoho snímku - obraz se občas na okamžik jakoby trhnul ale tyhle chyby byly ojedinělé a navíc skutečně kratičké. Dá se tedy říct, že HT mi umožnilo dostat z PC cca 160% výkonu, jestli ne víc. Samozřejmě pokud bych používal dva stejné programy, tento efekt by se neprojevil - byly by využívané stejné části procesoru.

Nenazval bych to placebo efektem, sám jsem počítal, že to bude s C2D ještě lepší přeci jen je rozdíl mít místo dvou virtuálních jader dvě skutečné – nejde o nijak katastrofální rozdíly, ale poznat to je.

- XXl

Uživatel bez registrace

Level 1

7. 9. 2008 19:43

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @XXl: A byl výkon hry otestován nebo je to jen dojem? Ono totiž sotva poznám, jestli mi klesl počet fps ze 100 na 50 za sekundu a beztak u her kritické situace s rapidním poklesem výkonu zaviní většinou grafická karta.
- Eagle

Uživatel bez registrace

Level 1

7. 9. 2008 21:33

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Eagle: U NFS jde skutečně o dojem, ale vzhledem k tomu, že byla hra odzkoušena na podobné konfiguraci jen se slabším procesorem, dá se usuzovat že procesor při HT a zpracování dvou úloh neklesl pod 80% V některých hrách jsem ovšem mohl pomocí zobrazování počtu snímků udělat testy podrobnější a ani tam nedocházelo k poklesu o více jak 15%

Jsem si vědom toho jak HT fungovalo a je mi jasné, že ta technologie nebyla zcela dokonalá ale v mém případě tj. spušťěná hra a na pozadí přepočet videa skutečně fungovalo bezvadně.
Na druhé straně jsem si však nevšiml žádného zrychlení mezi během programu s vyplým a se zaplým HT. Malou vyjímkou byl DVD Shrink kde bylo zrychlení cca 10%.
HT bylo tedy využitelné pro spouštění dvou různých úloh, ale nikoliv pro programy které dovedou využít dvojjádro, nebo pro provoz programů využívajících stejné výpočetní jednotky procesoru.

- XXl

Uživatel bez registrace

Level 1

6. 9. 2008 14:04

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace jinak, SSEx umi vyuzit i jiny kompilery ;-) (gcc, icc)
je pravda, ze je treba to tomu prekladaci nejak inteligentne naznacit a pouzit intrinsicty, takze je treba zvazit, jestli se pro danou aplikaci vubec vyplati zabyvat se nejakou takovou vychytavkou, ktera zesloziti kod a tim ho nejspis prodrazi a pritom poskytne vykon. boost 5% :)
nicmene, z vlastni zkusenosti, pkud se nekde intenzivne pocita, opravdu se SSEx vyplati nastudovat. tech intrinsictu nakonec neni az tak moc a jsou celkem srozumitelne popsany.
ale chce to zvazit tu potrebnost
- daniel zika

Uživatel bez registrace

Level 1

6. 9. 2008 14:00

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace no, nevim, jak by optimalizace mohla ostatni zpomalit ? proste bude zakladni binarka, ktera na zacatku zavola CPUID a podle toho natahne .dll (.so) s takovou verzi kodu, ktera bude nejak optimalizovana.
ano, je to nejaka rezie, ktera se ale potom urcite vyplati.
je to sice prace navic, ale pokud by slo jen o vytipovany casti, par funkci, ne psat celou aplikacku znova.. tak by to snad nebyl tak divoky a narocny.
- daniel zika

Uživatel bez registrace

Level 1

6. 9. 2008 20:45

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @daniel zika: Odpověděl jste si sám - volání CPUID (což je mimochodem serializovaná instrukce !) a následná podmínka může dost zpomalovat. Např. Intel C++ Compiler vkládá CPUID rozhodovací podmínky ke každému podle něj vhodnému bloku - a to prostě znamená už slušnou režii. Kdyby to dělal na úrovni DLL, tak se poněkud zvětší výsledný kód.

Jinak pokud se vyplatí dělat nějaké optimalizace, tak profile guided. S těmi se dá získat klidně 30 % výkonu navrch a to bez jakýchkoli podmínek na přítomnost nějakého konkrétního CPU.
- Eagle

Uživatel bez registrace

Level 1

5. 9. 2008 11:49

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace Myslym si, že v servrech kde běží SQL databáze se to těžce vyplatí.
- Radek Horáček

Uživatel bez registrace

Level 1

5. 9. 2008 12:24

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Radek Horáček: spis jem to myslel tak, ze i ta DB ma uz napsanej a do instrukci prelozenej kod. takze, idkyz nehalem bude umet nejaky triky s retezci, tak si bude treba nejak tuhle vlastnost vynutit. a to si myslim, ze prave stavajici kody nebudou umet... takze, si asi budu muset pockat, treba na Oracle 12G :)
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 12:22

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace @Radek Horáček: no, jo, to je prave ale jedna z mala situaci, ktera me napa :)
- daniel zika

Uživatel bez registrace

Level 1

5. 9. 2008 11:40

Komentáře tohoto uživatele máš zablokované.

@Uživatel bez registrace http://en.wikipedia.org/wiki/SSE4
http://xtreview.com/addcomment-id-3391-view-Intel-SSE4.2.html

- Radek Horáček