PCTuning fórum

Osmijádrovej 8120. Moc testů nebo výsledků ode mne nčekej. Jednak nebudu vůbec testovat na defaultu, hned půjdu na OC a druhak budu testovat svoje věci, jako třeba mass spawn stovek botů v UT, budu zkoušet CPUmarky s různým přiřazením na thready abych cejtil jak se co navzájem zpomaluje či ne, zkusim zatížit na 100% všechny jádra krom jednoho a kouknout se jestli mi to neubralo výkon toho jednoho zbývajícího, zkusim přetížít paměťovej řačič jak hodně mi to zpomalí systém, zkusim jestli to ve full loadu nedělá stejnou paseku jako HT, atd.

no to mě právě zajímá.. to ostatní najdu na webu.

Pod to se taky podepíšu ... rád bych se dozvěděl, kde je ten návrh zpackanej a případně jak z toho ven. Počítám, že do roka budu měnit HW a pokud AMD nevyjde s něčím lépe konkurečním, nechci vidět ceny u Intelu. Navíc se dá asi očekávat, že jestli v AMD už dlouho ví, v čem je průšvih (předpokládám, že to otestovali podobně a ještě víc), dá se z toho co zjistíš jakž tak usoudit, co mohou do další genereace stihnout opravit a co už je příliš velký zásah. Tedy dát i nějakou hodně orientační predikci možného nárůstu výkonu. Ať je o čem spekulovat

DOC_ZENITH píše:JF je stejnej spekulant jako OBR, neni to žádnej vývojář ani odborník, je to samostatnej novinář s extrémním talentem pro sbírání leaků a fake, také je známý tím že je opak obra, tzn fandí spíš ATI/AMD.

JF-AMD == John Fruehe is the Director of Product Marketing for Server/Workstation products at AMD

Ne sorry, já jsem si pod JF vybavil narychlo toho týpka co píše na semmiacurate., ne tohodle JF, už se motám v těch zkratkách.

Jinak ta FX8120 co mám je final retailní prodejní a je dodávaná v plechové krabici co si dnes mohl někdo koupit kdybych to nezabavil, žádnej papír.

- je, že tento kus co tu mám má defaultní vcore 1,4v a topí dost on i napájejí kaskáda a to zatím jen sedím v biosu a nastavuji.

To je Charlie Demerjan ChD.

Podla toho co hovoril DOC_ZENITH tak jednoznacne L1 zmenit na write back aj ked v dnesnej dobe taky drasticky vplyv na vykon myslim, ze nema. Prakticky prekopat celu cache, L3 na full-speed, L2 len 2*256-512KB pre modul, velkost L3 cache 4MB podla mna staci L1D 2*32-64KB a L1I 96KB namiesto 64KB. Usetria 8-10MB cache, ktora zabera ~40-50mm2 na 32nm procese a hned mozu pridat dalsie 2 moduly(2*22.5mm2+10mm2 za 2MB L3 cache) a plocha narastie minimalne, samozrejme zmenit rozlozenie na obdlznik namiesto stvorca pre lahse pridavanie dalsich modulov.

Suhlasim s webwalkerom aj ked o front ende neviem, mozno akurat fetch 2*24B namiesto 2*16(K10 1*32B) ale decoder je podla mna dostatocny na 2ALU+2AGU a mozno by som pridal uops cache .
Ten napad s FPU vyzera velmi dobre, ale radsej rovno 4 a ponechat HT.

Ak tam ma byt int HT, tak
1. 4ALU+4AGU
2. 4ALU+3AGU
3. 4ALU+2AGU, podla toho ako casto sa AGU vyuzivaju.

Na tieto veci mozme v Piledriver rovno zabudnut a mam pohybnosti ci AMD bude mat niekedy L3 na full speed.

Když už L3 není fullspeed tak by jsme jí mohli řešit externě heh... Jako v 90.tých letech u slotových procesorů, kdy Intel už nedokázal zvyšovat frekvenci Pentia PRO ne kvůli jeho jádru ale že L2 nedokázala pracovat tak rychle, tak jí u P2 dal mimo CPU na paměťové čipy a běžela na 2/3 či 1/2 CPU frekvence a 1/1 synchro měly jen Xeony kde výrobní cena nebyla prioritou. AMDto se slotovými Athlony mělo také, ale pak se výroba posunula a už jsme byli opět schopni ji dělat na fullspeed v CPU, ale aMD se 12 let poté dostává do situace kdy už jí opět fullspeed nezvládá heh... (nebo ona by i šla ale cache o takovém oběmu a taktech dost žere a topí, proto asi neni na fullspeed, tady už nám začíná trošku "backfirovat" přistup honění výkonu frekvencema, přesně tyhle problémy vyvztanou. Pipeline se dá přizpůsobit aby takty zvládala, cache už ne, ne aniž by měla velké latence či obrovskej odběr, či neběžela na fullspeed. AMD si vybralo jak latence tak non-fullspeed mod, což je u cache dost fatální protože nárůst latencí když ta věc nepoběží synchro nemusíme moc rovádět, je prostě ohavnej.

A tím řešit externě myslím že by mohla bejt třeba v dalším slotu, kdo by jí nechtěl, měl byCP bez L3 a s horším výkonem. A kdo by jí chtěl, mohl by si jí koupi a byly by různé velikosti i rychlosti heh.... vím, na dnešní poměry šílené a mimo ale rád bych to stejně viděl.

No ten OBRuv test je zase dilo. Tu kravinu s Unigine Heaven tam nechal a hned se toho lidi chytaji a vyber by mohl byt bohatsi ,ale zase abych mu nekrivdil ,tak sehnat a testnout hodne zanru her je dost narocny. Chybi mi tam treba Shogun 2 a dalsi MMO jako Aion a Rift ci BC2,BF3 nejaky seriozni letecky simulatory, CoD:BO ,Drago Age:Origins......Kazdopadne jde videt ze to tady bedlive cetl a dost odtud cerpal

K JF bych jen mohl rici....on mu nekdo snad veril ? Ja teda ne.

DOC_ZENITH: Koukej ho pekne mucit a rici vysledky

THANATOS: Koukám, že nešetříš
Tam je imho problém v tom, že když je jádro BD 4 issue může zpracovat pouze 4Mops. Každá Mops může obsahovat jenom jednu "modify" uops, takže v jednom taktu obsadíš pouze max 4 výpočetní jednotky.
Kdyby tam tedy byly 3ALU a 4fpu, obsadíš jich jen něco přes 50%, zbytek je k neužitku a stojí
Ono by to sice asi šlo, ale pak by zase nemusely být totožné, ale specializované jen na některé výpočty(rychlejší). Bohužel třeba tyto nesymetrické fpu by pak zase dělaly problém při sdílení. IMHO

webwalker nemal by 4 issue davat 1-8 uops, 1 uops pre 1 ALU alebo 1 FPU? Navyse ja som myslel 4 issue decoder len pre terajsi BD a nie pre toto hyper BD a ratam aj s uops cache

P.S. ale ved setrim, nevidel si cast, kde som usetril 8-10MB cache

mě by spíš zajímalo jak by se to chovalo, kdyby si systém a programy "myslely" že to je Intel CPU

THANATOS: šetříš, ale ne ve výpočetních jednotkách, v té tvé konfiguraci by pravděpodobně pouze žraly elektřinu a nepřinášely žádný nárůst výkonu http://pctforum.tyden.cz/viewtopic.php? ... 1#p8222781

ještě něco k FPU přímo od "lháře" (JF) :

We have a 256b FP datapath (pipes 0 and 1) AND a 256b INT datapath (pipes 2 and 3), so

2 128b FP + 2 128b INT
or
1 256b FP + 2 128b INT
or
1 256b FP + 1 256b INT
or
2 128b FP + 1 256b INT

The INT here is an integer unit for doing the integer portion of math inside an SSE instruction, that is not the integer clusters that you would commonly call cores.

Plus there is a really cool feature around moves. Technically, we can do 4 128b SSE moves per cycle with a ZERO cycle latency. This is known as “MOVE ELIMINATION”.

THANATOS: Jsou to sice pro mě hluboké vody, ale pochopil jsem to takto:
AMD cpu pracují v pipeline s Mops až do chvíle, než je odešlou do výpočetních jednotek (vytvoří uops a odešlou).
Každá Mops může obsahovat až 3uops, ale pouze jediná z nich může být "modify" ostatní práce s pamětí atd.
Pokud se pletu, opravte mě prosím.

del42sa ved ja viem , tato konfiguracia by viac papala, ale ja chcem mat z HT nie len 15-20% vykonu ale viac preto som dal 4ALU aj ked neviem ci 3ALU su limitujuci faktor alebo nieco ine podla extra dobrych HT vysledkov v sandre.
Ak sa dobre pamatam tak JF daval nejake porovnanie co najviac spotrebuva elektrinu v cpu a FPU jednoznacne vyhralo a ALU papalo celkom malo a preto FPU nema turbo, ale mozno sa uz zle pamatam.
4FPU su aj teraz v BD ja ich len chcem mat rovnake, hadam spotrebe to tak velmi neublizi.

webwalker tieto casti su aj na mna trochu vysoko, hlavne ked poriadne info som nikde nenasiel
raz bud vsetko nazvu ako mops alebo uops popripade oboje. Nezda sa mi, ze pri 4ALU+4FPU+4AGU by 4 boli pre ALU a FPU zvysnych 8 pre AGU, skor naopak ale priznam sa, ze 1mops=3uops(4mops=12uops) som pocul prvy krat.

THANATOS: Myslím, že link na Kantera máš, ale raději ještě posílám:
http://realworldtech.com/page.cfm?Artic ... 181333&p=5
To je ta práce, z které "čerpal" ZLOBR.

webwalker mam a cital som ho ako som pisal ten svoj koment.

Schema prevodu u AMD 15h by melo asi byt:
AMD64/x86 -> 1,2-x macro-ops/cops -> 1-3(?) micro-ops

u x86 je nejcasteji 1-3B; max 15B
http://www.strchr.com/media/instruction_length.png

Vektorove a FP budou zajiste (i mnohem) delsi.

Takze pri 16B okne se tam sice vejde i 5 x86 instrukci, ale rozhodne min treba pri SSEx.

BD by mel za cyklus nacist 32B. Je to rozdeleno do dvou oken po 16B. Maximalne se v nich muzou nalezat 4 AMD64/x86 instrukce. Tyhle 4 instrukce se dekodujou na macro-ops/cops, takze 4 * 1,2-x. Pak jsou poslany ve ctvericich do scheduleru, ktery je dekodujou na micro-ops a po 4 poslou vykonat.

Takze pak se to dle nejakeho mechanismu deli na thready (aby jeden teoreticky nekradl vsech 32B). Netusim jak.

Kazdopadne, pri vyuziti obou jader 32B/2 = 16B. Coz je polovina K10.

Taková drobná perlička kterou mě napadlo vygoolit až teď a to je počet tranďáků.

Zambezi má cca dvě miliardy tranzistorů. Zatímco snad 2x výkonější Gulftown cca 1.2miliardy.
To je neskutečný rozdíl v účinnosti architektury. Jak to CPU v AMD navrohovali??

Taky z toho lze velmi pěkně odhadnout marže jednotlivých výrobců.

Hustota transistoru neni konstantni napric technologii a cipy.

Gulftown 248mm2 vs Zambezi 315mm2

BD je tudiz plne srovnatelny s Gulftownem a selskym rozumem by mel byt na nej cilen.

8120 aj 8150 má podľa Obrovskej recenzie 0,9 miliárd tranzistorov

Netušíte někdo, kolik CPU spolkne projekt Jaguár ... http://extrahardware.cnews.cz/cray-chys ... veta-titan ... jestli jde výroba primárně sem (asi to nebude jediný odbyt na Interlagos), tak chápu, že je prodej pro desktop a nějaké ladění BD na druhé až další koleji.