PCTuning fórum

Ja bych rek, ze L2 cache proste nefunguje. Takze je nouzove prodratovana na to jak to je. Ja si od zacatku myslel, ze bude viceportova a minimalne obe jadra k ni budou moct pristupovat soucasne, jenze neni. Vyvozoval sem tak z tech zvetsenejch latenci a pak i z toho, ze L1 je je jednoduzsi nez driv, takze L2 musi udelat vic prace.

Imho nesabotoval jim nekdo ten automat co jim navrhuje cpu?
To prece neni normalni aby ten cpu mel L1 cache jak 386.Jak psal doc zenith lepsi l1 cache mela uz 486...pripada mi to jako by to snad ani nekontrolovali po tom stroji????
Kdyby to navrhovali rucne, tak tohle nemuzou v zivote pustit ven.

nebyl jsi to ty HEADe ? přiznej se

ttxman: Imho podle Kantera nejsou zápisy do L2 přímé, ale prováděny prostřednictvím WCC (obě jádra) viz diagram
http://realworldtech.com/includes/image ... ozer-6.png

PS: Byl to HEAD a udělal to naschvál

zajímavé.... "splývající/slučovací" sdílená write cache jako mezičlánek mezi L1 a L2. Bože, k čemu to přesně slouží ? ....

HEAD píše:Imho nesabotoval jim nekdo ten automat co jim navrhuje cpu?
To prece neni normalni aby ten cpu mel L1 cache jak 386.Jak psal doc zenith lepsi l1 cache mela uz 486...pripada mi to jako by to snad ani nekontrolovali po tom stroji????
Kdyby to navrhovali rucne, tak tohle nemuzou v zivote pustit ven.

Špatně Heade. 386 žádnou L1 neměla. Mohlá mít jen L2 na boardu u super high-end boardů. 486 měla L1 a díky tomu byla taky mnohonásobně rychlejší než 386, takym měla první násobič, FPU, atd. 486 měla 8KB L1 cache s write trough u starejch modelů DX/DX2 (1989-1991), model DX4 pak jako první CPU přinesl write-back cache a navíc jí měl 2x takovou. Přepnutí L1 do write-back modu u tohoto CPU znamenalo nárůst výkonu na takt tak o 50-75%.

nicméně problémy se málokdy vyhnout při realizaci zcela nové architektury...Navíc Dresdenboy tvrdí, že to s tím automatem není vůbec pravda, protože bývalý zaměstnanec AMD tam prvně několik let již nepracuje a za druhé se velké čipy navrhují stále i ručně (automat jen určitě specializované části)
http://www.xtremesystems.org/forums/sho ... ost4975258

del42sa: Je to hrůza, ale asi jim nic jiného nezbývalo pokud chtěli W/T.
Proto zůstává otázka zda zisky ze společné L2 pro obě jádra v modulu stály za tyhle komplikace?
Víc udělátek = větší šance na chybu.

Spis jim Head dodava dobrej "matros" ,protoze to cely je nonsense. No asi kdyz nabirali novy inzenyry ,tak si zapomeli zjistit ,ze jsou to inzenyri stavebni odtud i Bulldozer, Piledriver.....

Radšej mali ostať pri tej výhovorke na automat
A ja som myslel že WT systém sa nepoužíva roky

dexterav píše:Radšej mali ostať pri tej výhovorke na automat
A ja som myslel že WT systém sa nepoužíva roky

No právě, protože byl překonán v první polovině 90. tých let. Co AMD vedlo k tomu se k němu vrátit nikdo neví, ale výkonu to rozhodně neprospělo.

dexterav píše: A ja som myslel že WT systém sa nepoužíva roky

V AMD najeli na system WTF...

Ne, to došlo pouze ke špatné komunikaci mězi vedením a zaměstnanaci.

" Jakže boss říkál že máme nastavit ten automatickej navrhovač? Aaaale, když jsem mu popisoval náš plán s Buldozerem, tak řekl jenom WTf..... " WT říkáš? - OK, je to tam. "

Edit: Víte že lehce (ne na strop) ocnutá Q6600 je lepší CPU než šestijádrovej buldozer?..... ach jo.....

webwalker píše:del42sa: Je to hrůza, ale asi jim nic jiného nezbývalo pokud chtěli W/T.
Proto zůstává otázka zda zisky ze společné L2 pro obě jádra v modulu stály za tyhle komplikace?
Víc udělátek = větší šance na chybu.

takže díky W/T zápis probíhá paralalně do L1 cache a zároveň do L2. U W/B zápis probíhá pouze do L1 a do L2 jen pokud je to nezbytně nutné, čímž se redukuje počet zápisů. W/T ale zase v určitých situacích zrychluje čtení protože stejná data jako v L2 jsou už zapsána ve stejný okamžik díky W/T i v L1. Problémem BD je IMHO, že ta nejrychlejší L1 je prostě příliš malá, takže ve finále je CPU závislé v podstatě na rychlosti L2.... Další otázka je jak celý ten cyklus brzdí ta CC

del42sa: Ano, přesně tak by to být mělo (pokud se tedy nepletu).
U W/T je každý zápis do L1 doprovázen také zápisem do L2 a u W/B do L2 jen, pokud je to nezbytně nutné.
Takto časté zápisy u W/T mohou vytvářet bottleneck v komunikaci s L2.

No, ale pokud by však byla L1 ještě větší, tenhle bottleneck by se imho ještě prohloubil (ještě víc komunikace). IMHO
Ale na to by měl odpovědět někdo chytřejší.

PS: Ta WCC by měla ten "bottleneck" v komunikaci s L2 právě odstraňovat. imho

webwalker píše:del42sa: Ano, přesně tak by to být mělo (pokud se tedy nepletu).
U W/T je každý zápis do L1 doprovázen také zápisem do L2 a u W/B do L2 jen, pokud je to nezbytně nutné.
Takto časté zápisy u W/T mohou vytvářet bottleneck v komunikaci s L2.

No, ale pokud by však byla L1 ještě větší, tenhle bottleneck by se imho ještě prohloubil (ještě víc komunikace). IMHO
Ale na to by měl odpovědět někdo chytřejší.

PS: Ta WCC by měla ten "bottleneck" v komunikaci s L2 právě odstraňovat. imho

Asi máš pravdu, ale další problém je že do L2 přistupují zároveň obě jádra, respektive nejdříve jedno a pak druhé, což vytváří další zpoždění...

No, ale pokud by však byla L1 ještě větší, tenhle bottleneck by se imho ještě prohloubil (ještě víc komunikace)

já jsem to myslel tak, že ta "výhoda" rychlejšího čtení se vlastně nevyužije díky tomu, že do mnohem menší L1 cache se toho moc nevejde a CPU musí stejně číst až z L2, čímž se ta výhoda rychlejšího čtení z L1 pomocí W/T ztrácí....

Ihmo tohle je přesně ten problém (jeden z nich) jakým trpěl Netburst, ala useless L1 a všechno se zapisovalo do L2. Chjo.

del42sa píše: ..., ale další problém je že do L2 přistupují zároveň obě jádra, respektive nejdříve jedno a pak druhé, což vytváří další zpoždění...

Pokud se to týká zápisů, tak o oba požadavky na zápis by se měla starat právě ta WCC.

já jsem to myslel tak, že ta "výhoda" rychlejšího čtení se vlastně nevyužije díky tomu, že do mnohem menší L1 cache se toho moc nevejde a CPU musí stejně číst až z L2, čímž se ta výhoda rychlejšího čtení z L1 pomocí W/T ztrácí....

Už rozumím

Jinak tohle sdílení L2 mezi dvě jádra trochu připomíná Core2, ale tak nějak si nevybavuju, jak jsou řešeny zápisy tam.

Doporučuji přečíst prvních 10 stránek tohoto threadu. Velmi zajímavé čtení o našich odhadech výkonu Bulldozeru, příliš vysokých očekávání a mnohdy velmi krutě přesných náznacích nízkého výkonu. Ale jinak jsem se pobavil, dá se říci, že jsme se sekli téměř ve všem, třeba launch BD jsme čekali zhruba o rok dřív, jenom Yuri.cs to skoro trefil na měsíc přesně. Jó to byly časy, tenkrát se za nižší výkon takt na takt než Thuban rovnou upalovalo, SB prý nebude nic moc, a BD bude mít tak brutální výkon, že Gultown bude jisto jistě poražen a díky tomu bude BD hrozně drahý.

Co se týče nevyrovnanosti výkonu BD, tak mě to zase tak nevyrovnané nepřijde - BD mi připadá jednoduše slabý ve všem, v encodingu videa i v hrách.

Také mi přišel velmi zajímavý článek (ted nevím kde jsem ho četl), že Dirk Meyer celý BD zachránil, když jej nuceně odložil až na 32nm výrobní proces - že prej tenkrát by proti čtyřjádrovému Nehalemu a poté proti Gulftownu nemě žádnou šanci (to je jasné že by 2-modul byla naprostá ostuda) - prý AMD klesaly akcie jak byli investoři naštvaní z odkladu, ale ve skutečnosti by mu měli poděkovat, že je zachránil. No já myslím, že vzhledem k tomu, že byl za vývoj BD od začátku zodpovědný, tak ho měli kopnout do zadku už tenkrát. A místo dnešní naprosto zpackané slepé větve BD by tu už mohla pomalu být nějaká pěkná osmijádrová evoluce K10.5 s AVX (a mezitím se makalo třeba na 6ALU+4way HT jádru).