AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd

[DOC_ZENITH]

Není sdílená jen FPU, i na ALU klesá výkon tak o 25% pokud je obě dvě v modulu zatížíš najednou. Tudiž ten procesor nemá fyzických 8 jader. Má 4, 4x front end, 4x L2, 4x sheduler, 4x FPU, jen 8x ALU. Ještě k tomu ne moc sylnejch (stěží to porazí Phenom II X6, kdy jsme koukli na stejnejch taktech, tak vesměs plichta). Jde to opravdu easy srovnat s Netburstem kde sice nebylo 2x tolik ALU, ale jeho ALU běžely na oproti FPU na dvojnásobném interním taktu, a pak přišlo HT aby se toaspoň ňák využilo že.

Jejich vůle merno mocí docílit zpracování 8 threadů je důkaz toho že už nedovedou dále vylepšovat architekturu čipu a výkon na thread. Pokles IPC je věc neomluvitelná. Pokud chceš srovnávat plochu, nesrovnávej s CPU kde je obrovskej northbridge součástí die, srovnej to s Gulftownem a jeho plochou, ten má totiž 6 jader, větší výkon a také NB jinde a v CPU jen paměťovej řadič (ještě o kanál širší)

Tohle srovnání nedopadne moc hezky, stejně tak jako nedopadá hezky srovnání s klasickým mainstreamovým sandy bridge.

A tím že herní CPU prodávaj nemyslim mass prodeje jak za dob K7 a K8. Ale taky to, že to dělá jméno. Pokud jsou CPU AMD tak slabé že ta samá firma musí už mnoho let prezentovat vlastní high end grafiky na platformách konkurence, je to prostě průser a BFU kupujou co je in a super, aniž by to využili, na BD neni nic takového. Pro běžného usera je dokonce stále lepší PhenomII, typu 960T (kdyby se ještě vyráběl), v hrách má stabilnější výkon, žádná zabugovanost platformy/biosů, žádné problémy s throtlingem, atd.

[del42sa]

težko říct zda za to může chybějící třetí ALU, nebo hlubší pipeline, nebo jen pomalá cache (nebo taky všechno dohromady)


\\ DOC-ZENITH AMD GAMING CPU (Bulldozer based)

4 jádra , 8 vláken, 8 FPU.

4 moduly, každý modul = 1 jádro (4 ALU/4AGU) + HT, na každé jádro 2 x 256BIT FPU, micro- Uop cache, 32k L1 Cache (Write-Back), 256K L2 Cache, 6MB L3, 22nm Fin- FET, 3,6 GHz (Turbo 4,5GHz).

[flanker]

Procesory budou za pár chvil tady a ke měn se dostalo již několik dalších informací.
Finální procesory budou revize C (to jsem měl typ před mnoha měsíci správný)
Nyní se testují C0 mezi uživateli, zda finální bude C0 a nebo C1 se ještě neví.

Níže je ES tokající na frekvenci 3.3 GHz (turbo 3.9???).




Zvětšení výkonu zde je, v x87 však například velmi mizivé. Více tedy bude poznat v renderu apod. Procesor má také vylepšen mírně IMC a zvládne lehce RAM nad 2400 MHz s nízkým DRAM napětím.

PS:osobně jsme čekal o něco vyšší nárust výkonu v x87, zbylé zhruba souhlasí jak jsem odhadoval.

[del42sa]

to se dalo čekat. Už někdy v lednu Charlie psal na fóru Semiaccurate, že rev. C zvedne hlavně výkon v int. nikoliv v x87

The first one is that there is a new stepping coming, SemiAccurate is hearing mid-to late Q3/2012 for the next rev. That revis said to bump performance, specifically integer performance, up by quite a bit, and possibly improve clocks too. Either way, it looks like that stepping is the one to keep an eye out for.It isn’t a Barcelona type fiasco, but it isn’t an HD4870 launch either.

[flanker]

krucinál, kde má tedy x87 ještě praktický smysl? Mě to jako overclockera jen mrzí z důvodu, že WR AMD asi v superpí ještě nepadne....

[ttxman]

krucinál, kde má tedy x87 ještě praktický smysl? Mě to jako overclockera jen mrzí z důvodu, že WR AMD asi v superpí ještě nepadne....

No smysl ma tak v extended presnosti vypoctu s plovouci radovou carkou, to jeste nikdo nikde nenahradil), to je tak vsechno. Ale pouziva se to uplne vsude, jelikoz ty instrukce plivou kompilatory na skoro vsechno, pokud jim to primo nezakazes.

Docela by me zajimal vykon cpu (specificky bulldozeru) na single instukcich SSE v porovnani s x87 (bez vektorizace). Pokud by nebyl zadnej rozdil je to relativne v pohode, pokud by nektera skupina instrukci byla pomalejsi tak by se treba nasel duvod proc je pouzivat vsude.

[DOC_ZENITH]

BD architektura jde stejnym směrem kudy šel netburst, dále snaha navyšovíní INT výkonu a počtu threadů a žádná snaha o vyřešení mizerného x87 výkonu, ba naopak, v budoucnu nám může i klesnout výkon x87 na takt. P4ka failnula ačkoliv se intel snažil seč mohl jí prosadit. BD dopadne stejně, vše tomu zatím nasvědčuje. Pokud přežije bude to jen v APU a to jen díky těm grafickejm jádrům, jako CPU architektura zatím epic fail. Od mobilů přes desktopy po servery.

[yuri.cs]

AMD64 specifikace vyzaduje SSE a SSE2 - xmm registry. Zrejme kazda 64b aplikace/kompiler by je mel nativne vyuzivat.

8c 3.3/3.9GHz
WinRar 4.2
http://a8.sphotos.ak.fbcdn.net/hphotos- ... 4829_o.jpg
3DMark06
http://a8.sphotos.ak.fbcdn.net/hphotos- ... 4999_o.jpg
3DMark Vantage
http://a7.sphotos.ak.fbcdn.net/hphotos- ... 0374_o.jpg
CB R11.5 MT
http://a1.sphotos.ak.fbcdn.net/hphotos- ... 6655_o.jpg
SuperPi 32M
http://a1.sphotos.ak.fbcdn.net/hphotos- ... 8807_o.jpg

OC
http://a6.sphotos.ak.fbcdn.net/hphotos- ... 1952_n.jpg

[DOC_ZENITH]

A? SSE2 je 12 let stará technologie.

Teprve asi rok dozadu se najelo na to že se SSE vůbec v mainstream aplikacích používá, P2 už jich dost nespustí, P3 všechny. Tak rok dozadu ještě P2 spustila téměř vše tzn SSE to nepoužívalo vůbec.

A dále pak kompiler je jedna věc a to na co SSE bude opravdu použito je věc druhá. Bude použito na to co nás v hrách bottleneckuje ala výpočty geometrie a animací? Pokud ne nikam se nepohneme.

[yuri.cs]

"kompiler vs opravdu pouzije"

Jak myslis, ze se to opravdu pouzije? Vysvetlit.

//trivialni uloha nasobeni DP matic; jenom kompiler (MSVS) nahradil x87 za sse2; rychlost se dokonce zdvojnasobila; kompiler neni zle monstrum

http://www.geeks3d.com/20100711/test-si ... plication/

[DOC_ZENITH]

Upřímně nevim jak to funguje, ale můj laickej pohled na programování je ten, že SSE je set instrukcí. Narozdíl od MMX ale neanalizuje kód a k tomu aby se použil pro něj musí být kód přímo napsán. Je tu k tomu, že s jeho pomocí můžeme dosahnout většího výkonu u některejch operací než kdyby se počítaly přes x86 a x87 neni tomu tak?

Ok, ale lze pomocí něj počítat vše? Asi ne. + Kompiler vezme kód a udělá z něj spustitelnou věc na určité architektuře a OS, to jestli se rozhodne pro tu a tu část kódu použít SSE či x87 je čistě na něm a na tom zdali to je možné. Aspoň tak to chápu já. Protože kdyby to bylo jinak, tak by se přeci každej soft jen prohnal x-compilery, existovalo by rázem x-verzí každá optimalizovaná pro svůj typ CPU a vše by všem chodilo krásně protože nám to compiler "sám na míru instrukčních sad jemu daných optimalizoval" ale ee, máme jednu verzi programu, v 90+% případů sedící na prvních verzích SSE nebo čistě x86+x87. Otázka zní teda proč?

[yuri.cs]

Jak MMX analyzuje kod? MMX je stary 64b SIMD, ktery vyuziva stejne registry jako x87. http://download.intel.com/design/archiv ... 318504.pdf

Neni problem udelat binarku, ktera obsahuje detekcni launcher, ktery dle CPUID bitu spusti vybranej codepath.

[DOC_ZENITH]

Ok ale o MMX se tu snad nebavíme ne? To o co mi šlo u MMX je to, že zrychluje chod programů, i těch co jej vůbec neznaj a nejsou pro něj psány, což SSE nedělá.

[yuri.cs]

Jiste, ze 'Intel MMX technology TM' zrychluje vsechny programy. Jeste aby ne, kdyz zmenilo:
• Doubled code and data cache sizes to 16 KB each
• Improved branch prediction
• Enhanced pipeline
• Deeper write buffers

a pak vlastni MMX SIMD.

[webwalker]

Yuri má pravdu, 64 bit mají nativně SSE a SSE2.

Starý výtah z Wiki:

SSE instructions: The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions. SSE3 instructions were added in April 2005. SSE2 replaces the x87 instruction set's IEEE 80-bit precision with the choice of either IEEE 32-bit or 64-bit floating-point mathematics. This provides floating-point operations compatible with many other modern CPUs. The SSE and SSE2 instructions have also been extended to operate on the eight new XMM registers. SSE and SSE2 are available in 32-bit mode in modern x86 processors; however, if they're used in 32-bit programs, those programs will only work on systems with processors that have the feature. This is not an issue in 64-bit programs, as all AMD64 processors have SSE and SSE2, so using SSE and SSE2 instructions instead of x87 instructions does not reduce the set of machines on which x64 programs can be run. SSE and SSE2 are generally faster than, and duplicate most of the features of the traditional x87 instructions, MMX, and 3DNow!.

A Jako to bude s kompilátorem VC11 (Windows8)¨

The default instruction set for code generation using the x86 VC++ 11.0 compiler is SSE2. This will be better documented closer to the release date. If you need to target older architectures you can use /arch:IA32.

[ttxman]

No a jeste k tomu MMX instrukce pracujou pouze v pevny radovy carce, takze se s nima zadna x87 instrukce ani nahradit neda. Hodne dulezity bylo v zavedeni saturovanych aritmetickych operaci. (proste buffery nepretecou, ale zustanou na maximalni nebo minimalni hodnote). A vzhledem k tomu, mmx registry prekryvaji x87 registry tak kombinovani x87 instrukci a mmx instrukci byla celkem problematicka (a pomala) vec.

[nou]

Protože kdyby to bylo jinak, tak by se přeci každej soft jen prohnal x-compilery, existovalo by rázem x-verzí každá optimalizovaná pro svůj typ CPU a vše by všem chodilo krásně protože nám to compiler "sám na míru instrukčních sad jemu daných optimalizoval" ale ee, máme jednu verzi programu, v 90+% případů sedící na prvních verzích SSE nebo čistě x86+x87. Otázka zní teda proč?

ciastocne to tak funguje. ale clovek tym dostane len skalarny SSE kod. aby to malo zmysel treba dosiahnut vektorizovanie kodu ktore kompiler dosiahne dost tazko preto treba pouzit specialne kniznice alebo pisat v ASM.

[ttxman]

Protože kdyby to bylo jinak, tak by se přeci každej soft jen prohnal x-compilery...

ciastocne to tak funguje. ale clovek tym dostane len skalarny SSE kod...

Navic je jeste mozna automaticka vektorizace nekterejch algoritmu (typicky pruchod polem a identicka jednoducha operace nad kazdym prvkem - nasobeni 2 treba) neco k tomu je i na wiki

Takze to urcitej smysl ma, nejaky zrychleni se tim ziska. Problem je, ze vetsina kodu nejde automaticky vektorizovat, protoze pouzity algoritmus vektorizovat nejde.

Typickej priklad je faktorial, kazdej krok je zavislej na predchozim. (a zacinam zbytecne od 1 aby to bylo cely)

Kód: Vybrat vše

fact = 1;
for(int i=2;i<=10;i++)
  fact*=i;

kdyz to rozepisete tak je to 1*2*3*4*5*6*7*8*9*10, ze znalosti toho, ze je nasobeni asociativní se to da sepsat jako (pro 2 prvkovy vektory)
(1*2)*(3*4)*(5*6)*(7*8)*(9*10)
zakladni vektorizace je dejme tomu (.* je nasobeni prvek po prvku)
(a,b) = (1;2).*(3;4).*(5;6).*(7;8).*(9;10)
fact = a*b;
to je v podstate
(a,b) = (1,2).*((1,2) + 1*(2,2)).*((1,2) + 2*(2,2)).*((1,2) + 3*(2,2)).*((1,2) + 4*(2,2))

da se tedy udelat neco jako

Kód: Vybrat vše

v = (1,2);
fv = (1,2);
k = (2,2);
for(int i=1;i<=4;i++)
{
  v = v+k;
  fv = v.*fv;
}
fact = fv[0]*fv[1];

Analogicky pro delsi vektory . Tohle je velmi jednoduchy priklad, ale pochybuju, ze dnesni kompilatory dokazou funkci nahore vektorizovat na to dole.

kdezto tohle (kdyby to bylo napsany pro vic jak 2 prvky, a nejspis i kdyby se vnitrni 2 cykly spojily do jednoho)

Kód: Vybrat vše

v = [1,2];
fv = [1,2];
k = 2;
for(int i=1;i<=4;i++)
{
  for(int j=0;j<2;j++)
     v[j] = v[j]+k;
  for(int j=0;j<2;j++)
     fv[j] = v[j]*fv[j];
}
fact = fv[0]*fv[1];

By se nejpsis automaticky vektorizovalo celkem dobre. A po rozvinuti vnitrnich cyklu kompilatorem a natazeni co L1 cache to mozna bude i +- stejne rychle i bez vektorizace

A to je taky duvod proc pouziti v praxi nebude nic horkyho: moc prace to vymyslet a je to 3* vic radku...

[webwalker]

Imho na začátek by pouze stačilo kdyby kompilátory překládaly rovnou do SSE instrukcí místo x87 instrukcí. Pokud vím, tak u VS2010 kompiler překládá do mixu x87 a SSE. O vektorizaci a optimalizaci kritické části kódu se imho stejně musíš postarat sám (ale možná se pletu).

[flanker]

K domnělému čipu Vishera se vyjádřil uživatel Stilt s tím, že dle CPU-Z ID by to neměl být Vishera, ale Zambezi ES C0...No to je bordel...Osobně si myslím, že to pouze CPU-Z nepřečte správně a bez logu CPU-Z se to nedozvíme. Osobně to dle výkonu v R11.5 tipuju na Visheru.