PCTuning fórum

Testy účinnosti CMT u BD:


Vzhledem k tomu, že PD je stále plánován pro servery, nedá se imho počítat se zásadními změny oproti BD ve prospěch desktopu.

Tak to je spatny.
3-5% na takt zbytek pomoci frekvenci.Porad to bude hluboko pod phenom2 v ipc.
Ale uz to asi prekona nekde 2600k a v prumeru to da 2500k.
Ve hrach to bude porad nepouzitelny.
Meli by si koupit lepsi automat na navrhovani cpu.Sem si jistej, ze se z toho da vytriskat urcite daleko vic nez 3-5%

Del42sa
Ja to tak nejak vedel a i psal ,ze tech deklarovanych 10% narustu v X86 neni rust IPC ,ale frekvence. Uz jsem tu i psal v dlouhym postu aby se lidi drzeli na zemi (Flankere) a nedochazelo k vytvareni dalsiho hype ,ze to vlastne bude super a Piledriver prinese velky boost. No ted je to i potvrzene.

sorry, smazat...

HEAD píše:Tak to je spatny.
3-5% na takt zbytek pomoci frekvenci.Porad to bude hluboko pod phenom2 v ipc.
Ale uz to asi prekona nekde 2600k a v prumeru to da 2500k.
Ve hrach to bude porad nepouzitelny.
Meli by si koupit lepsi automat na navrhovani cpu.Sem si jistej, ze se z toho da vytriskat urcite daleko vic nez 3-5%

Pochybuji, že ten "automat" se dovede opravit. Ala automat udělá návrh a tak ho udělá, udělá ho 10x stejně když ho to necháš udělat 10x. Neni to něco co by se dovedlo učit z vlastních chyb, neni to AI probůh heh... to pak musej přeprogramovat lidi aby to fungovalo lépe, a návrh CPU aby chodil lépe musej opět opravit lidi, to automat neudělá. Takže nárůst výkonu čistě jen frekvencí je prostě to jediné co automat dovede.....

Hladis píše:Del42sa
Ja to tak nejak vedel a i psal ,ze tech deklarovanych 10% narustu v X86 neni rust IPC ,ale frekvence. Uz jsem tu i psal v dlouhym postu aby se lidi drzeli na zemi (Flankere) a nedochazelo k vytvareni dalsiho hype ,ze to vlastne bude super a Piledriver prinese velky boost. No ted je to i potvrzene.

to znamená, že těch 3-5% budou zřejmě úpravy v cache , integrer units zůstanou zřejmě nezměněné (počet ALU/AGU/FPU), zbytek budou vyšší takty v základu, při stejném nebo menším TDP....

del42sa: Souhlas, budou tam asi jen minoritní změny, ale je také možné, že deklarovaný nárůst 10-15% byl odvozen od plánovaného výkonu BD, který se však nedostavil (to je jen úvaha)

Jinak tady jsou ještě latence různých typů výpočtů v porovnání K10 vs BD vs SB:

Kdyby odkaz na obrázek opět přestal fungovat tak:
http://www.hardware.fr/articles/842-6/u ... lculs.html

PS: Obrázek nefunguje, tak jen dodám, že latence výpočtů jsou většinou opět vyšší než u K10

už funguje

del42sa: Díky, jsi lepší
A já línej

koukám že už se chytnul i ten tvůj obrázek, tak to bude asi muset Flanker smáznout, nahrál jsem na rajce i ten předchozí obrázek, nejdřív se ti ve zprávě nezobrazoval a až když jsem postnul ten svůj re-upload, tak tam najednou byl i ten originál od tebe

Tak CHD už začíná šetřit problémy BD:
http://semiaccurate.com/2011/10/17/bull ... e-problem/
http://semiaccurate.com/2011/10/17/why- ... nderwhelm/

Charlie v podstatě shrnul všechno, co jsme tu už probírali:

Cache latence
Frontend
počet ALU/AGU ma jádro
IPC
problémy s 32nm v GloFo

také mluví o revizi B3, kterou už vzpomenul i v dřívějším článku na SA a která by měla údajně zvednou INT IPC a mluví se o ní i v oficiálních AMD materiálech. Otázka je jak a o kolik ? Bohužel si narozdíl od Charlieho nemyslím, že Piledriver vyřeší všechny nedostatky BD a to z důvodů, které jsem zmínil na předchozí stránce... K nějakému zlepšení nicméně dojde

Bulldozer seems to suffer from a lot of little tuning problems that are not easily correctable. There is a purported B3/C0 stepping in the works for Q1/12 that supposedly increases integer IPC performance by an appreciable amount, but we will wait and see what the end result is. Most of the ‘little’ problems are not really correctable without a major core revision, and that is not happening until Piledriver.

revizí dle mě nejde radikálně změnit výkon. Může přinést lepší takty, spotřebu a možná pár detailů...Můj odhad je, že FX 8170 bude již B3 revize. C-čková by mohla být až Piledriver.

de42lsa: on taky nerika, ze se vyresi vsechny nedostatky, jenom ze by to mohlo byt podstatne lepsi

Kdyz i CD predpoklada, ze je to dobrej zaklad pro vylepsovani, tak to pro AMD vyhledove vypada celkem rozumne.

flanker: urcite spotreba, ale napadlo me, ze by mohli navyst vic proudu do L2 cache a snizit jeji latence to by jit mohlo a nejakej vykon by to urcite prineslo. (otazka je jestli by se to potom mmistne neprehrivalo))

Imho ChD zatím nic konkrétního nezjistil, to co napsal přeci víme také.
No snad jen to, že mnoho drobných chyb může zlikvidovat výkon celého cpu ... bla bla bla ... a že část těchto chyb může být napraveno v nové revizi a ty zbylé "neodstranitelné" až v PD (no nevím?).
ttxman: No mě spíš zaráží ten šílený propad v zápisu do L1D.

L1 neni write-back ale write-trough, L2 je těžce latentní, a L3 neni fullspeed tudiž neni synchro. Ala první megagigaproblémy co musej fixnout. Zádné jádro nebude rychlé když bude mít k dispozici takhle spackané cache.

DOC_ZENITH: Ano ty propady v zápisu do L1D mají příčinu ve W/T, ale musí být ten propad takový?

Edit: No možná ano, když je zápis do L2 také pomalejší než u K10!

Podivne nizka propustnost v zapisu do L1D kesky je zrejme dilem WT.

http://images.sudhian.com/review/cpu/in ... chemem.jpg
Porovnejte NetBurst s WT.

Mě stačí 486 DX4, ala první CPU s writeback cache a volně nastavovatelnou. Když dám WT, tak na 120Mhz mam CPUmark99 asi 2,8 bodu (je to jen jako DX2 na větší frekvenci). Když dam WB, tak 4,2 bodu......

Writeback L1 cache je základ všech dnešních výkonnejch CPU. L1 s write-trough je pro denšní užití tak slow v zápisu, že její přítomnost ztrácí smysl .

No co si budeme povídat, system cache v BD je bída a nikdo neví proč. Kdyby alespoň ty zisky ze sdílené L2 mezi jádry by za to W/T stály? Na Real World Tech to probírali mnozí pod tématem

AMD CPU designers aren't idiots ... they must have had a plan ... what was it?

Ale stejně nedospěli k žádnému rozumnému zdůvodnění