PCTuning fórum

ArgCZ píše:no já to zkoušel u Trinity kdy mě fungovalo vždy jedno jádro v modulu a výkon byl spíše nižší, někde více, někde méně, ale nebyl vyší, ale je fakt, že 3 jádra odskakují dvoum více než 4 a více jader třem, tak to není asi zrovna dobrý příklad, jinak ASUS desky by to umět měli.

ale to je logické ARGu že dvě jádra budou slabší jak čtyři. To bys musel mít 8 jádro a porovnávat nastavení 2M/4C s 4M/4C. Pokud nastavíš u Trinity u každého modulu jenom jedno jádro, tak se ti z čtyřjádra stane dvoujádro a je logické že to pak bude pomalejší jak 4 jádra normálně nastavené Trinity...

mno jasně, ale po masáži kdy se tvrdilo že sdílená FPU je velká brzda a hry nevyužijí více než dvě jádra(fáma) jsem si to chtěl ověřit no, ale už z dob kdy se měřil rzdíl mezi Phenomem II X2, X3 a X4 je jasné že předěl jsou tři jádra, tam je nějvětší nárůst

ta jeho úvaha totiž není vůbec lichá viz tabulka



z té je jasné že tři jádra budou asi co se her týče nejefektivnější volbou(X3 720BE a jeho odstup od X4 940 na 3.0GHz a ztráta 3.1GHz X2ky

Ak sa niekto chysta rucne vypinat ALU, tak ocakavam, ze co sa nasobica tyka nepojde na automatiku (turbo), ale tiez si to nastavi. Context switching ma daleko vyssiu reziu ako to, ze svoje "1+1" si chce vykonat 50 sluzieb / procesov na pozadi.
Takze co je lepsie ? Ak ti za danu sekundu ma sancu sto krat podvyziveny dekoder "pokazit" "110%" vykon - aj to len v teoretickej rovine, alebo 100 context switchov ?

EDIT:
O vsade spominanej (k tejto hre) potrebe vykonu len na 2 jadra som sa "presvedcil" pred par minutami, ked som skusal Planetside 2 > keci na n-tu. Ako uz milion krat.
Podpis zostava (HD7700 / PII1090T), High priority, 18 multi (3.6GHz), GPU nastavenie (medium) - vytazenie GPU 30-80%:
1Core: 15fps
2Cores: 30fps
3Cores: 35fps
4Cores: 40fps
6Cores: 48fps
Samozrejme, vytazenie vsetkych jadier v priemere 55-60% + je na prvy pohlad jasne, ktore jadro vola D3D funkcie . Co je ale dolezite (a to ludia, ktori multithread neprogramovali maju obrovsky problem pochopit), ze paralelne vykonavane ulohy sa vacsinou musia v nejakom "bode" synchronizovat / odovzdavat si vysledky a podobne.

Priklad: program, ktory vykonava vypocet a zaroven vo svojom okne ma graficky vystup priebehu (normalna "oknova" aplikacia).
"Okna" aplikacie bezia spravidla vo svojom vlakne, takze "progress report" od vypoctoveho vlakna musi odovzdat spravu "vlaknu okien", ktory potom prekresli vystup.
Ako vyzera potom priebeh na 1 a na 2 jadrach CPU ?
1- vypoctove vlakno
2- graficke ("oknove") vlakno
"-" noop (idle)

1Core:
11111111(message/event/whatever)(context switch)222(context switch)1111111111

2Core:
11111111(message/event/whatever)1111111111
-----------------------------------222--------

Ako asi vyzera situacia ak je takychto "navlaknovanych" cinnosti viac a komunikacia je obojsmerna ? Zoserializovat vsetky vypocty na jedno jadro je zaroven z pohladu odozvy uplna katastrofa.

Ideální si bude znovu připomenout tuto kapitolu:

http://pctuning.tyden.cz/hardware/proce ... s?start=16

ArgCZ píše:mno jasně, ale po masáži kdy se tvrdilo že sdílená FPU je velká brzda a hry nevyužijí více než dvě jádra(fáma) jsem si to chtěl ověřit no, ale už z dob kdy se měřil rzdíl mezi Phenomem II X2, X3 a X4 je jasné že předěl jsou tři jádra, tam je nějvětší nárůst

ta jeho úvaha totiž není vůbec lichá viz tabulka



z té je jasné že tři jádra budou asi co se her týče nejefektivnější volbou(X3 720BE a jeho odstup od X4 940 na 3.0GHz a ztráta 3.1GHz X2ky

Nevytahuj testy z roku 2008/9, ve kterejch je Core2 quad lepší než Nehalem, i když dnes v jakékoliv CPU limited hře má Nehalem tak o 50% lepší výsledky.....

A ano, většina her používá 3 jádra, protože jsou to porty z Xboxu a ten má 3 jádra. Takže pak nemusej měnit počet threadů. Opimum je pořád bohužel plné 4 jádro. Ty 3 thready pro hru, ten 1 může zůstat aby na něm mohly sedět další věci co v OS běží a nemuselo se ubírat výkonu těch 3,.

Dolezite je vysoke IPC na jadro, tam AMD pokulhava.

CageJ píše:Dolezite je vysoke IPC na jadro, tam AMD pokulhava.

to je strašně obecný termín, který je velmi často vytrhávaný z kontextu. Např. Itanium má mnohem vyšší IPC než Nehalem, ale je proto automaticky lepší na hry ? Dost těžko ......Záleží na vícero faktorech než jen na IPC.

vysoka frekvencia X vysoke IPC
kratky prefetch a mnozstvo mikroinstrukcii za takt, FPU a scheduler

staci tak ?

CageJ píše:vysoka frekvencia X vysoke IPC
kratky prefetch a mnozstvo mikroinstrukcii za takt, FPU a scheduler

staci tak ?

akorát že tohle většinou nejde dost dobře dohromady, protože obojí jde proti sobě Např. špatný cache systém může ubrat až 40% výkonu i když budeš mít vše ostatní "super" ......

L1 je dnes tak rychle, ze je jedno ci ma 128KB alebo 512KB

CageJ píše:L1 je dnes tak rychle, ze je jedno ci ma 128KB alebo 512KB

to právě vůbec jedno není je vidět že této tématice bohužel vůbec nerozumíš 512KB L1 cache ? To by byly latence, to by zabilo každý procesor

CageJ píše:L1 je dnes tak rychle, ze je jedno ci ma 128KB alebo 512KB

prosim ta a ktory dnesny CPU ma datovu L1 (pisal si o prefetch) aspon tych 128kB ? Co myslis, ze stoji za tou rychlostou ?
Ak by bolo mozne zachovat latenciu "pri polmegovej" L1D cache tak to by sa pisali giganticke lookup tabulky jedna radost...
Nedavno som riesil 1kB vs 256kB lookup tab. Ta 256kB by operaciu vykonavala s dvojnasobnym objemom dat. Deployment target bol 2P Nehalem WS, kde cela L2!! jadra ma taku velkost ako ta vacsia tab.

Za posledne roky som zistil, ze velmi malo PC HW nadsencov su zaroven programatormi. Vacsina programatorov sa zase k HW stavia dost ignorantsky. A ludia, ktori sa venuju obom ak si uz aj najdu cas na citanie podobnych diskusii, tak sa v nich aktivne nezapajaju (lebo to konci facepalmom alebo mavnutim ruky).

IPC, IPC... viete co mi tieto diskusie pripominaju ? "Stara mat spominali"
medzi Bulldozer a SandyBridge architekturou su tak fundamentalne rozdiely (a to vobec nenarazam na modularnost, pozrite si ALU/FPU), ze robit z toho zavery je opravnenych vazne len hrstka ludi (ja nie )
Navrhujem namiesto minania casu (napisat prispevky a precitat nove prip. napisat reakciu vyzaduje vazne dost vela casu ) radsej zvolit diskusiu s polovicou prispevkov ale zato si diskutujuci precitaju napr. odkazy z tohto prispevku (nie ten YT, ale tie na realworldtech.com).

bulldozery maj L1D 128kB (8x16)

Trovaricon: Pacho Hybský zbojník

oneb1t píše:bulldozery maj L1D 128kB (8x16)

na jádro ? To těžko. S touhle metrikou a takovým sčítáním celkové cache se nikam nedostaneme

ne 128KB měly Phenomy II (64D Cache + 64I Cache)

Bulldozer má 2x16KB + 64KB sdílené Instrukční Cache/modul

del42sa píše:

CageJ píše:L1 je dnes tak rychle, ze je jedno ci ma 128KB alebo 512KB

to právě vůbec jedno není je vidět že této tématice bohužel vůbec nerozumíš 512KB L1 cache ? To by byly latence, to by zabilo každý procesor

priklad

oneb1t píše:bulldozery maj L1D 128kB (8x16)

ano v tej jednej vete na zaciatku som nespomenul, ze mam na mysli "na jadro". Vsade dalej a aj z kontextu to je hadam jasne.

a ja, ze myslim Phenom II x4 ktory ma na CPU ..

CageJ píše:a ja, ze myslim Phenom II x4 ktory ma na CPU ..

nekličkuj !

ta diskuze o vypinani jader

udelal sem takovej pokus v 3dmark vantage
zvolil sem schvalne test kterej vyuziva vsechny jadra abych zjistil o kolik vykonu prichazi tahle architektura sdilenim prostredku pro modul

a vysledky sou
8@4ghz jader = 2988
4@4ghz jadra (1 jadro na modul) = 1708

tudiz pro hry ktery vyuzijou pouze 2-4 jadra je vyhodnejsi mit ostatni vypnuty za predpokladu ze planovac neprideluje ulohy objadro (takhle by mel fungovat na win8 s buldozerem)

Preco by ale mal tie jadra vypinat, ved ak nastavi affinity flag na 85 (t.j. binarne na 8 jadre 01010101), tak aplikacia, ktora aj nieco na tie jadra dava pocitat pojde systemom 1CU/modul, ostatne jadra budu bud zaparkovane alebo sa na nich vykonaju background procesy, ktore ale zeru uplne minimum cache / instrukcii za dany cas v porovnani s "hlavnym procesom" @ hrou