Zen: New Core Features

Since August, AMD has been slowly releasing microarchitecture details about Zen. Initially it started with a formal disclosure during Intel’s annual developer event, the followed a paper at HotChips, some more details at the ‘New Horizon’ event in December, and recently a talk at ISSCC. The Zen Tech Day just before launch gave a chance to get some of those questions answered.

First up, let’s dive right in to the high-level block diagram:

In this diagram, the core is split into the ‘front-end’ in blue and the rest of the core is the ‘back-end’. The front-end is where instructions come into the core, branch predictors are activated and instructions are decoded into micro-ops (micro-operations) before being placed into a micro-op queue. In red is the part of the back-end that deals with integer (INT) based instructions, such as integer math, loops, loads and stores. In orange is the floating-point (FP) part of the back-end, typically focused on different forms of math compute. Both the INT and FP segments have their own separate execution port schedulers

If it looks somewhat similar to other high-performance CPU cores, you’d be correct: there seems to be a high-level way of ‘doing things’ when it comes to x86, with three levels of cache, multi-level TLBs, instruction coalescing, a set of decoders that dispatch a combined 4-5+ micro-ops per cycle, a very large micro-op queue (150+), shared retire resources, AVX support, and simultaneous hyper-threading.

What’s New to AMD

First up, and the most important, was the inclusion of the micro-op cache. This allows for instructions that were recently used to be called up to the micro-op queue rather than being decoded again, and saves a trip through the core and caches. Typically micro-op caches are still relatively small: Intel’s version can support 1536 uOps with 8-way associativity. We learned (after much asking) at AMD’s Tech Day that the micro-op cache for Zen can support ‘2K’ (aka 2048) micro-ops with up to 8-ops per cache line. This is good for AMD, although I conversed with Mike Clark on this: if AMD had said ‘512’, on one hand I’d be asking why it is so small, and on the other wondering if they would have done something different to account for the performance adjustments. But ‘2K’ fits in with what we would expect.

Secondly is the cache structure. We were given details for the L1, L2 and L3 cache sizes, along with associativity, to compare it to former microarchitectures as well as Intel’s offering.

In this case, AMD has given Zen a 64KB L1 Instruction cache per core with 4-way associativity, with a lop-sided 32KB L1 Data cache per core with 8-way associativity. The size and accessibility determines how frequently a cache line is missed, and it is typically a trade-off for die area and power (larger caches require more die area, more associativity usually costs power). The instruction cache, per cycle, can afford a 32byte fetch while the data cache allows for 2x 16-byte loads and one 16-byte store per cycle. AMD stated that allowing two D-cache loads per cycle is more representative of the most workloads that end up with more loads than stores.

The L2 is a large 512 KB, 8-way cache per core. This is double the size of Intel’s 256 KB 4-way cache in Skylake or 256 KB 8-way cache in Broadwell. Typically doubling the cache size affords a 1.414 (square root of 2) better chance of a cache hit, reducing the need to go further out to find data, but comes at the expense of die area. This will have a big impact on a lot of performance metrics, and AMD is promoting faster cache-to-cache transfers than previous generations. Both the L1 and L2 caches are write-back caches, improving over the L1 write-through cache in Bulldozer.

The L3 cache is an 8MB 16-way cache, although at the time last week it was not specified over how many cores this was. From the data release today, we can confirm rumors that this 8 MB cache is split over a four-core module, affording 2 MB of L3 cache per core or 16 MB of L3 cache for the whole 8-core Zen CPU. These two 8 MB caches are separate, so act as a last-level cache per 4-core module with the appropriate hooks into the other L3 to determine if data is needed. As part of the talk today we also learned that the L3 is a pure victim cache for L1/L2 victims, rather than a cache for prefetch/demand data, which tempers the expectations a little but the large L2 will make up for this. We’ll discuss it as part of today’s announcement.

AMD is also playing with SMT, or simultaneous multi-threading. We’ve covered this with Intel extensively, under the heading ‘HyperThreading’. At a high level both these terms are essentially saying the same thing, although their implementations may differ. Adding SMT to a core design has the potential to increase throughput by allowing a second thread (or third, or fourth, or like IBM up to eight) on the same core to have the same access to execution ports, queues and caches. However SMT requires hardware level support – not all structures can be dynamically shared between threads and can either be algorithmically partitioned (prefetch), statically partitioned (micro-op queue) or used in alternate cycles (retire queue).

We also have dual schedulers, one for INT and another for FP, which is different to Intel’s joint scheduler/buffer implementation. 

CPUs, Speeds, Pricing: AMD Ryzen 7 Launch Details The Ryzen Die
Comments Locked

574 Comments

View All Comments

  • bobsta22 - Saturday, March 4, 2017 - link

    Office with 20 PCs - all developers - loads of VMs and containers.

    All the PCs are due a CPU/Gfx refresh, but ITX mobos required.

    Cant wait tbh. This is a game changer.
  • prisonerX - Saturday, March 4, 2017 - link

    What if they come out with a 16 core line next year!
  • bobsta22 - Saturday, March 4, 2017 - link

    What?
  • lilmoe - Tuesday, March 7, 2017 - link

    It really is. As a freelance developer, I can't wait.
  • ericgl21 - Saturday, March 4, 2017 - link

    For me, the more important thing to see from AMD is if they can come up with a chip that can beat the mobile Core i7-7820HQ (4c/8t no ECC) & the Xeon E3-1575M v5 (4c/8t with ECC), for less money.
    And the number of PCIe gen3 lanes is very important, especially with the rise of M.2 NVMe storage sticks.
  • cmagic - Sunday, March 5, 2017 - link

    Will anandtech review Ryzen in gaming? I would really like Anandtech view, since I don't really trust other sites especially those "entertainment" sites. Want to see how Anandtech dive into its main cause.
  • Tchamber - Sunday, March 5, 2017 - link

    @cmagic
    Page 15
    2017 GPU
    The bad news for our Ryzen review is that our new 2017 GPU testing stack not yet complete. We recieved our Ryzen CPU samples on February 21st, and tested in the hotel at the event for 6hr before flying back to Europe.

    I just ordered my 1700X, I plan to keep it for at least 5 years, as my needs don't change much. My current Intel 6 core is coming up on 7 years old now. I like to buy high end and use it a long time.
  • Lazlo Panaflex - Monday, March 6, 2017 - link

    Same here...probably gonna grab a 1700 at some point and put this here i5-2500 non-k in the kids computer.
  • asH98 - Sunday, March 5, 2017 - link

    '''The BIG QUESTION is WHY are the HEDT benchmarks (professional ie Blender) fairer than gaming benchmarks??

    Bottom line is that CUTTING-EDGE CODING is happening NOW in AI, HPC, data, and AV/AR, game coders because of $$$ are the last to change or learn unless forced (great for NVidia Intel) so most of the game coding is stuck in yesteryear- Bethesda will be the test bed for game coders to move forward
    Hence the difference in game benchmarks vs 'professional' (HEDT) benchmarks. Game coders can get stuck using yesterday's code without repercussions and consequences as long as old hardware dominates and there are no incentives to change or learn new skills. The same Cant happen in the Professional area where speed is tantamount to performance and $$$
  • TheJian - Sunday, March 5, 2017 - link

    I hope you're going to test a dozen games at 1080p where most of us run for article #2 and the GAMING article should come in a week not 1/2 year later like 1080/1070 gtx reviews...LOL. As this article just seems like AMD told you "guys, please don't run any games so we can sell some chips to suckers before they figure out games suck". And you listened. No point in testing 1440p or 4k for CPU, and 95% of us run 1920x1200 and BELOW so you should be testing your games there for a CPU test.

    The fact they are talking Zen2 instead of fixing Zen1 kind of makes me think most of the gaming is NOT going to be fixable.
    http://www.legitreviews.com/amd-ryzen-7-1800x-1700...
    149fps for 7700 in theif vs. 108 for 1800x? JEEZ. GTA5 again, 163 to 138. Deus ex MD 127 to 103. These are massive losses to Intel's chip and Deus was clearly gpu bound as many of Intel's chips hit the same 127fps including my old 4790k :( OUCH AMD.

    https://www.guru3d.com/articles_pages/amd_ryzen_7_...
    Tombraider same 7700k vs. 1800x 132fps to 114 (never mind 6850 scoring 140fps). This will probably get worse as we move to 1080ti, vega, nvidia refresh for xmas, Volta, 10nm etc. If you were using a faster gpu the cpus will separate even more especially if people are mostly gaming at 1080p. Even if many move to 1440p, that maybe fixes some games (tombraider is one with 1080 regular that hits a wall at 90fps), but again goes back to major losses as we move to 10nm etc. We get 10nm chips for mobile now and gpus probably next year at 12nm (real? fake 12nm? Either way) and might squeak into 2017 (volta, TSMC). 10nm gpus will likely come 2018 at the latest. Those gpus will make 1440p look like 1080p today surely and cpus will again spread out (and no, we won't all be running 4k then...LOL). You could see cpus smaller than 10nm BEFORE you upgrade your cpu again if you buy this year. That could get pretty ugly if the benchmarks around the web for gaming are not going to improve. One more point you'll likely be looking at GDDR6 (16Gbps probably) for vid cards allowing them to possibly stretch their legs even more if needed. Again, all not good for a gamer here IMHO.

    “But Senior Engineer Mike Clark says he knows where the easy gains are for Zen 2, and they're already working through the list”

    So maybe no fix in sight for Zen1? Just excuses like "run higher res, and code right guys"...I hope that isn't the best they've got. I could go on about games, but most should get the point. I was going to buy ryzen purely for Handbrake, but I'll need to see motherboard improvements and at least some movement on gaming VERY soon.

    One more ouch statement from pcper.
    https://www.pcper.com/news/Processors/AMD-responds...
    "For buyers today that are gaming at 1080p, the situation is likely to remain as we have presented it going forward."
    So they don't think a fix is coming based on AMD info and as noted as gpus get much faster (along with their memory speeds) expect 1440p to look like today's 1080p benchmarks at least to some extent.

    The board part is of major interest to me, so I can wait a bit and also see Intel's response. So AMD has be hanging for a bit here, but not for too long. I do like the pro side of these though (handbrake especially, just not quite enough).

Log in

Don't have an account? Sign up now