Procesory AMD 15h "Bulldozer&Bobcat"- info, testy, spekulace

[webwalker]

DOC_ZENITH: Představ si BD modul se 4 int jádry a společnou fpu vše pod jedním frontendem. Délku pipeline nemá cenu řešit, protože ji u BD neznáme (předpoklad je do 20 stage).
No ale pořád je to blíže k tvým úvahám, než SB, který svou fpu sdílí s int na stejném portu.

[del42sa]

Yuri: Aha , já vycházel z toho angl. postu, kde se mluvilo o cca ~48K L1 cache/core a dál už jsem to nezjíšťoval, ale je to skutečně tak jak píšeš:

Whereas K10 offered 64 KB of L1 instruction and 64 KB of L1 data cache per core, Bulldozer enables 16 KB of L1 data cache per core and 64 KB of 2-way L1 instruction cache per module. It remains to be seen how the smaller L1 affects performance.

Změnila se také hierarchie pamětí cache. L1 cache s kapacitou 16KB je 4-way asociativní, a je běžné že k nalezení požadovaných dat je nutno do paměti přistoupit čtyřikrát na různá místa. Bulldozer ale používá predikci k rozhodnutí, kde data leží. V případě úspěchu je požadavek vyřízen rychleji a ušetří se energie, pokud ale je předpověď špatná, má to za následek větší latence ve více cyklech. Load-to use latence se proti K8 (10h) o jeden cyklus prodloužila, stejně jako u Westmere. Bylo to nutné směrem k požadavku na vysoké frekvence čipu a vyšší propustnosti L1 cache. I přesto, že má jádro jen dvě AGU jednotky a není tedy schopné přistoupit do L1 cache třikrát za takt, ale jen dvakrát, je zde výhoda, že místo třetího přístupu je možné frontu operací vyprazdňovat. Zde je vidět srovnání architektury s budoucími Sandy Bridge procesory, propustnost L1 cache bude stejná, a klíčová pro AVX instrukce.

Paměť L2 cache je sdílená pro obě jádra v modulu a její velikost bude pravděpodobně 2MB na modul, což je proti 512KB u K8 (10h) a 256KB u Westmere značně vyšší kapacita. Jedná se 16-way asociativní paměť. Jak už jsem řekl několikrát, vzhledem k plánovaným vysokým frekvencím procesoru narostla latence L1 cache vůči K8 (10h), stejně je tomu I u L2 cache. Latence je 18-20 cyklů, jádro K8 (10h) operuje s latencí 10 cyklů stejně jako Westmere. Všechna data zapsaná do L1 jsou zkopírována do L2, pokud dojde k poškození dat v L1 jsou opět nahrána z ECC chráněné L2. Paměť L1 není chráněna ECC, čímž se sníží nároky na její spotřebu (K8 má ECC chráněnu i L1 cache).
I když je obsah L1 běžně zkopírován do L2, může se stát, že některá data z L1 budou v L2 chybět. V tento okamžik jádro prohledá L3 cache, a pokud neuspěje ani tam, opět se podívá do L1 cache. Tento provoz je nežádoucí, všechna tato hledání totiž zatěžují jádra a spotřebovávají energii zbytečně. AMD stejně jako Intel u architektury Westmere učinil kroky, aby tento nežádoucí provoz omezil. Jak to ale přesně funguje u architektury Bulldozer není známé.

\\Edit: k těm latencím, pokud poběží ty cache na vyšší frekvenci něž ty u K10 tak by to takový problém být nemusel. IMHO by to mohlo podobné jako s operačníma pamětma, kdy DDR2 paměti na taktu 667 MHz mají latence 4-4-4-5 a DDR3 na 1600MHz mají mnohem horší latence 9-9-9-27 a přesto jsou ty 1600MHz výkonnější....

Pokud je BD vysokofrekvenční architektura a bude mít těch 17-22 stages pipeline, tak by ty latence zase nemusely představovat takový problém... Jak velkou L1 cache měla P4 Prescott ? taky 16kB.. (Neuvedený Tejas měl mít 24kB L1 cache). Předchozí Netbursty měly jen 8kB L1 Cache.Dokud nebudeme vedět víc, tak bych K10 a K15 z hlediska latencí a cache vůbec nesrovnával.

[THANATOS]

K10 L1 data 64KB, L1 instruction 64KB = 128KB
BD modul s 1 integerom L1 data 16KB, L1 instruction 64KB = 80KB
BD modul s 2 integermi L1 data 2x16KB, L1 instruction 64KB = 96KB
Co je tu take strasne, ved vieme dobre ako sa zapinaju Integer klustre pri BD, najprv moduly s jednym integer klustrom a az potom sa zapnu dalsie klustre v moduloch. Tato penalizacia je tiez zahrnuta do poklesu vykonu modul versus 2 jadro alebo ste si mysleli, ze to hovorili len tak

[yuri.cs]

L1 a L2 AFAIK bezi na klasicke vnitrni frekvenci. L3 bezi na frekvenci NB - ocekavanych 2300-2400 MHz. Narust frekvence CPU o 20-30% zakryje jen cast ztraty vs 'K10'.

Btw proc je tu to nutkani ty cache secitat? Jsou dedikovane - jednu nezamenime za druhou.

[THANATOS]

del42sa Prescott mal 16KB datovu L1 cache. Aku velkost mala instrukcnu L1 cache som nikde nenasiel.
http://techreport.com/articles.x/6213/2

yuri.cs v tom pripade instrukcna L1 je rovnaka a datova je "len" 1/4 z K10.


P.S. Aha, ta Trace cache bola nahrada instrukcnej alebo nieco podobne.
http://www.techimo.com/forum/attachment ... che-p4.jpg
A jej velkost bola.

Instead of measuring with the more traditional Kilobyte size rating, Intel has rated the trace cache with the ability to buffer 12,000 micro-operations. To simplify terminology, a micro-operation can be thought of as decoded data ready to be processed by the core execution stage. For most processing functions the average x86 operation is approximately 3.5 bytes large and requires an average of 2 micro-operations for decoding. Let's do a little math:

3.5 bytes * 12,000 / 2 micro-ops = 21 Kilobytes (approximately)

[del42sa]

L1 a L2 AFAIK bezi na klasicke vnitrni frekvenci. L3 bezi na frekvenci NB - ocekavanych 2300-2400 MHz. Narust frekvence CPU o 20-30% zakryje jen cast ztraty vs 'K10'.

ale u Nehalemu taky narostly latence L1 oproti předchůdci Conroe/Penrynu.

The first level L1 caches of each core of the Nehalem have the same size characteristics as the Core 2: 32 KB for data and 32 KB for instructions. Doing away with the micro-TLB, which we mentioned above, unfortunately translates into a slight increase in access time to L1. The data L1’s latency thus goes to 4 cycles (versus the 3 with Core 2). For L1 devoted to instructions, Intel chose to favor latency to the detriment of associativity. Indeed, managing cache ways takes time and this is all the more so the greater the number of ways. By reducing the associativity of L1 instruction cache from 8 to 4 ways, it can keep a latency of 3 cycles like on the Core 2 and this despite the absence of a micro-TLB. Why this choice? Because an instructions cache is more sensitive to latency than a data cache. Access latency on the latter can be (or at least partially) compensated for by the work of the OOO engine which reorganizes instructions in order to mask latency (the Nehalem’s has been considerably improved), while each access to the instructions cache is directly affected by the effects of higher latency, in particular access carried out by branching prediction mechanisms. The instructions L1 thus has less to lose when reducing its associativity instead of increasing its latency. In the end it’s a compromise.

http://www.xbitlabs.com/articles/cpu/di ... ure_5.html
http://www.anandtech.com/show/2542/5

[yuri.cs]

Narust o tretinu u L1, ale snizeni u L2 o stejnou miru.

Ja rozhodne nevylucuju moznost zakryti vsemoznejch latenci pomoci OoO, ale do jake miry? Viz

bla bla bla da se tohle 100% zakryt OoO enginem?

V tehle oblasti jsou urcite znacne pokroky (minimalne narusty velikost ROB apod.).

[webwalker]

Sakra yuri, teď jsi mě dostal. Já žil v domnění, že BD reorder buffer nepoužívá.

[yuri.cs]

nj, mas pravdu u BD se ROB nejmenuje ROB a vypada pokrocilejs - a je vetsi.

The final version, referred to as the “B2 stepping” version, corrects a known flaw with the Hyper Transport system between the CPU cores. The B0 and B1 versions that were allowed to be tested “in the wild” both experienced an issue where under heavy load the HT bus would flood, resulting in slower operational multi-core threading and generally crippling the overall memory read and write performance, and this explains why AMD opted to remove the product from it’s expected release dates earlier this year.

http://donthatethegeek.com/2011/08/18/a ... roduction/

[THANATOS]

yuri.cs tak problem s HT som fakt necakal, toto ma dostalo.

[Betruger]

o vela zaujimavejsie by to bolo keby sa to tykalo single thread vykonu

[THANATOS]

Betruger Single thread sme este nevideli a OBR tvrdi, ze vykon B0 a B2 je rovnaky co ak toto je pravda nemoze platit, mozno myslel single . Tato chyba musela mat dost velky dopad na vykon ked posunuli vydanie o 3 mesiace, to sa nestalo ani pri Barcelone, ale mozno prave pre zlu publicitu to radsej neriskli.

P.S. nebol by som prekvapeny keby tam boli aj dalsie chyby

[oso]

Kód: Vybrat vše

The B2 version was never released as an engineering sample to be tested “in the wild,” 

takze OBR nemoze mat B2 reviziu takze placa do vetra

[maltra]

Test v 2560x1600 s 8xAA to nerekne o cpu vykonu ani s SLI nic.

Myslim ze rekne hodne, teda ak sa bavime o svete realneho testovania. Testy procesorov v 1280x1024 s vypnutym AA a podobne nezmysly v uvahu neberiem. Sam vies z nasho porovnania i5-2500K a Phenomu II X4 v CFX, ze Phenom II kurevsky nestiha. Z testu co dal OBR na PCT ale vyplyva, ze v realnych hracskych podmienkach a nastaveniach ma BD dost vykonu na to aby sa drzal len par percent pod Intelackym sestjadrom.

[yuri.cs]

Ale ne, i OBR pripousti nejaky rozdil mezi B0 a B2. Tvrdi, ze se zmenilo taky napeti. Jeho B2 na CPU-Z, ale stale ukazuje 0.94-1.44V. Coz porad neodpovida tomu, pro co byl navrzen - 0.8-1.3V (viz 'Design Solutions for the Bulldozer 32nm SOI 2-Core Processor Module in an 8-Core CPU'). Takze zas prevoltovani jako u Llana?

[THANATOS]

oso mne sa zdalo cudne, ze v cpu-z ma
pod revision OR-B2 da sa to prehodit -> OBR-2 aka nahoda

http://2.bp.blogspot.com/-PUuKgQISeuw/T ... master.png

[DOC_ZENITH]

Test v 2560x1600 s 8xAA to nerekne o cpu vykonu ani s SLI nic.

Myslim ze rekne hodne, teda ak sa bavime o svete realneho testovania. Testy procesorov v 1280x1024 s vypnutym AA a podobne nezmysly v uvahu neberiem. Sam vies z nasho porovnania i5-2500K a Phenomu II X4 v CFX, ze Phenom II kurevsky nestiha. Z testu co dal OBR na PCT ale vyplyva, ze v realnych hracskych podmienkach a nastaveniach ma BD dost vykonu na to aby sa drzal len par percent pod Intelackym sestjadrom.

Toto je jedna z možnostáí jak to otestovat, ala jak otestovat CPU výkon v hrách a toto ti odrazí jak bude vypadat situace kde bude extrém a dojde na CPU limit.

http://www.youtube.com/watch?v=dcXezr16fKA

Začni sledovat od 14:40 Tohle je přesně ta situace. Ano celou tu dobu to jelo všem plynule. Ale jakmile nastane ta vřava a dojde na CPU limit, tak v současnosti je to tak že lidé s Phenom II či Core2 tam maj 10- 12 fps když lidi se Sandybridge maj 25, po OC 35. A ačkoliv všichni to měli hratelný 99% zápasu, a dle průměrnejch fps by vyšlo že "je to jedno zahrajete si i s nejlevnějšim dvoujádrem", tak právě v ten moment kdy se to prpokázalo, těch kritickejch 10 sekund kdy se ty armády střetly to ten horní tým prohrál, že jejich CPU nebyl dost silnej a měli tak malý FPS že nedokázali microvat ty jednotky.

Dokud si toto lidé jako ty neuvědomí, nemá smysl nad tím dále diskutovat.

[THANATOS]

DOC_ZENITH A nebolo to tym, ze tie jednotky boli slabsie alebo nepriatel bol v presile
Viem co chces povedat, ale podla mna toto nebol najlepsi priklad.

P.S. Odkial vies, ze ten horny tym nemal take iste CPU ako ten dolny? Bolo to niekde pisane lebo cele video sa mi nechcelo pozerat.

[DOC_ZENITH]

Myslim že byl, kdyby neměl 5 fps neměl by problém s těma mariňákama z těch stormů utéct. Asi by to projeli ale ne takhle výrazně a za pár vteřin. Myslim si že je to příklad dost dobrej, nesmíš to brát z pohledu SC hráče ale obecně, to co se tam stalo a co ten propad framerate způsobil. Přesně jak jsem to popsal v minulém postu. Průměrnejch 60 fps celou hru tě nezachrání když v klíčovym největšim střetu budeš mít 10 a soupeř 25.

[THANATOS]

DOC_ZENITH Takze ani nevies na com bezali, toto cele je potom o nicom. Odkial vies, ze prave druha skupina nemala lepsie stroje? Nevies a davas toto ako priklad, hoci to moze robit len skusenost hracov a ten marinakovi sa kludne mohol prekvapit a preto neskoro reagoval.

Ak by tam mali napisane stroje a je to ako hovoris, tak v poriadku a je to realny dovod, ale takto nie.
Neviem preco by si niekto na online zapasy daval Thuban alebo Deneb, ked sa vie davno, ze AMD v hrach straca.