opět se potvrzuje minimální nárust výkonu v desktopu ( kvůli frekvenčnímu stropu) , naopak nárust výkonu a frekvencí u mobilních čipů. (podobně jako u Kaveri)
4jádra
~30% perf increase at 15W
2MB Cache L2 versus Kaveri 4MB Cache L2
8 CU - VI GPU
DX12
menší L2 cache je zajímavá, bohužel latence mají být údajně stejné jako u 2MB L2...
yuri_cs píše:Puvodni BD mel dle dokumentace 20 cyklu latenci s 2MB variantou a 18 cyklu s 1MB variantou (ktera na svetlo sveta neprisla). SR ma u 2MB varianty zrejme 19 cyklu.
Pokud by propad hit-rate u klientskych apps nebyl drasticky s 1MB L2 a naopak by se povedlo jeste vyrazneji snizit latenci...
Na Anandu se objevil nazor, ze je mozne, aby byla opravdu snizena, protoze v dobe navrhu L2 XV jiz nebylo pocitano se skutecne vysokymi takty, pro ktere byla pomala cache 15h navrzena puvodne.
Ano přesně tak. Pokud by tomu tak bylo, pak by měli udělat i všechny exekuční jednotky širší (wide exec unit) jako to v podstatě představoval ten "fake"(?)
Steamroller/Excavator die shot se 4 ALU/core a native 256bit FPU. Ten by umožňoval při nižších frekvencích dosáhnout stejný nebo i vyšší výkon. Kdo ví, možná to není fake a AMD opravdu původně takové úpravy plánovala pro velké serverové Opterony. Vzhledem ke zrušení těchto serverových čipů a jejich desktopových FX klonů, zbyly jen APU čipy a pro ty se zdá takové "uber" jádro zbytečné...
Zatím to vypadá, že Carrizo bude vlastně jen Kaveri s rozšířenou instrukční sadou (AVX2,BMI2,RDRAND). A i když CPUID
Programming Guide naznačovalo, že BDver4 bude mít nativní 256bit FPU, zdá se nakonec, že FPU u EXcavátoru bude zřejmě stále zpracovávat AVX jako dvě sub-128bit operace. Očekává se i "streamlined GPU", co přesně to bude znamenat není jisté. Jestli bude mít GPU méně SP jednotek, nebo jiné části GPU budou očesány na kost není zřejmé. Za všemi těmi úpravami stojí snaha dále srazit spotřebu čipu.
Ještě k té cache u BD:
Jakkoliv je myšlenka BD architektury zajímavá a revoluční, je opravdu k zamyšlení, co vlastně s tou cache hierarchií AMD při navrhování BD architektury zamýšlelo ? To jakým způsobem je ta cache hierarchie navžená nedává moc smysl, ať se na to člověk dívá z ktérékoliv strany. Malá write through L1 cache (16KB) podpořená extra velkou L2 cache (2MB) s ultra vysokýmu latencemi, extrémně slow L3 cache s 64 way asociativitou a navíc nějaký bugem, který snižuje její už tak mizerný výkon. Naproti tomu L1 instrukční cache jen 2way asociative ( Haswell má 8 way ).
Celých 41% z BD die je L2 a L3cache. Do desktopu asi úplně zbytečné. Z toho člověk snadno dospěje k názoru, že menší a efektivnější L2 cache by mohla u desktopových CPU zvednout výkon a snížit spotřebu i velikost čipu, že se člověk diví, že s tímhle nepřišli už dříve.Také latence L2 je téměř dvojnásobná oproti Phenomu II. Těžko odhadovat jak by si se stejná architektura vedla s jinou cache hierarchií. Např write- back 2x32KB L1 cache 8 way + 2x 256/512KB L2 cache 8way + efektivnější a rychlejší L3...
Stejně tak výkonu Integer operací nepomohla redukce počtu ALU, čili logicky návrat zpátky ke konfiguraci 3ALU/AGU by měl vést k vyššímu výkonu. Proč ale AMD nic z toho neudělala a proč nechávají věci tak jak jsou není úplně zřejmé. Pokud mají prostředky na tweakování BD architektury, měli by mít možnost udělat i větší změny. Je pravda, že u PD se jim za poměrně malých úprav podařilo dosáhnout poměrně výrazné zvýšení výkonu,jenže u BD byl zřejmě i nějaký bug v návrhu.
U SR bylo těch úprav už o něco více a výsledek je tak trochu sporný, někde je nárust výrazný a někde zase minimální či horší než u PD. Zatímco PD přinesl agresivnější prefetch a větší TLB buffer, SR řešil bottleneck front-endu v dekodéru a instrukční cache. Logicky by pak člověk u Excavátoru očekával , že pořeší zbytek. Tedy bottleneck u exekučních jednotek, tedy počet Integer ALU a hlavně cache latence,konkrétně latence L2 cache a také velikost cache (včetně té chyby u L3).
Steamroller má sice dynamicky vypínatelnou L2 cache, ale bohužel bez pozitivního dopadu na latenci....
BD je ukázkový příklad, jak zničit dobrý nápad a promrhat příležitost návrhem nedomyšleným až do konce.
Well, to that I say: why didn't the geniuses at AMD think of that while designing this processor?
If AMD has any level of self-awareness, they should know that building large, dense caches with low latency and high associativity is not something they can compete with. Traditionally AMD has always had relatively modest caches.
tak či tak, Carrizo je spíš důkazem toho, že opravování chyb v BD architektuře není pro AMD prioritou a tak víceméně rezignují na další tweakování tohoto tabugovaného návrhu a veškerou pozornost inženýrů a všechny svoje finance směřují na nové x86/ARM CPU a na Skybridge.
