Stránka 17 z 31
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: úte 24. črc 2012, 13:10
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: úte 24. črc 2012, 14:26
od 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).

Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 10:36
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 10:57
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 11:26
od 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....
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 16:01
od ttxman
flanker píše: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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 17:09
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 18:01
od yuri.cs
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 18:25
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 18:34
od 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/
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 18:45
od 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č?
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 19:17
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 19:22
od 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á.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 19:34
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 20:57
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: pon 6. srp 2012, 21:05
od 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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: úte 7. srp 2012, 08:37
od nou
DOC_ZENITH píše: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.
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: úte 7. srp 2012, 19:18
od ttxman
nou píše:DOC_ZENITH píše: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...
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: stř 8. srp 2012, 13:51
od 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).
Re: AMD "Piledriver" Vishera refresh Zambezi -info,spekulace atd
Napsal: stř 8. srp 2012, 14:03
od 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.