AMD Zen 2 Microarchitecture Analysis: Ryzen 3000 and EPYC Rome
by Dr. Ian Cutress on June 10, 2019 7:22 PM EST- Posted in
- CPUs
- AMD
- Ryzen
- EPYC
- Infinity Fabric
- PCIe 4.0
- Zen 2
- Rome
- Ryzen 3000
- Ryzen 3rd Gen
New Instructions
Cache and Memory Bandwidth QoS Control
As with most new x86 microarchitectures, there is a drive to increase performance through new instructions, but also try for parity between different vendors in what instructions are supported. For Zen 2, while AMD is not catering to some of the more exotic instruction sets that Intel might do, it is adding in new instructions in three different areas.
The first one, CLWB, has been seen before from Intel processors in relation to non-volatile memory. This instruction allows the program to push data back into the non-volatile memory, just in case the system receives a halting command and data might be lost. There are other instructions associated with securing data to non-volatile memory systems, although this wasn’t explicitly commented on by AMD. It could be an indication that AMD is looking to better support non-volatile memory hardware and structures in future designs, particularly in its EPYC processors.
The second cache instruction, WBNOINVD, is an AMD-only command, but builds on other similar commands such as WBINVD. This command is designed to predict when particular parts of the cache might be needed in the future, and clears them up ready in order to accelerate future calculations. In the event that the cache line needed isn’t ready, a flush command would be processed in advance of the needed operation, increasing latency – by running a cache line flush in advance while the latency-critical instruction is still coming down the pipe helps accelerate its ultimate execution.
The final set of instructions, filed under QoS, actually relates to how cache and memory priorities are assigned.
When a cloud CPU is split into different containers or VMs for different customers, the level of performance is not always consistent as performance could be limited based on what another VM is doing on the system. This is known as the ‘noisy neighbor’ issue: if someone else is eating all the core-to-memory bandwidth, or L3 cache, it can be very difficult for another VM on the system to have access to what it needs. As a result of that noisy neighbor, the other VM will have a highly variable latency on how it can process its workload. Alternatively, if a mission critical VM is on a system and another VM keeps asking for resources, the mission critical one might end up missing its targets as it doesn’t have all the resources it needs access to.
Dealing with noisy neighbors, beyond ensuring full access to the hardware as a single user, is difficult. Most cloud providers and operations won’t even tell you if you have any neighbors, and in the event of live VM migration, those neighbors might change very frequently, so there is no guarantee of sustained performance at any time. This is where a set of dedicated QoS (Quality of Service) instructions come in.
As with Intel’s implementation, when a series of VMs is allocated onto a system on top of a hypervisor, the hypervisor can control how much memory bandwidth and cache that each VM has access to. If a mission critical 8-core VM requires access to 64 MB of L3 and at least 30 GB/s of memory bandwidth, the hypervisor can control that the priority VM will always have access to that amount, and either eliminate it entirely from the pool for other VMs, or intelligently restrict the requirements as the mission critical VM bursts into full access.
Intel only enables this feature on its Xeon Scalable processors, however AMD will enable it up and down its Zen 2 processor family range, for consumers and enterprise users.
The immediate issue I had with this feature is on the consumer side. Imagine if a video game demands access to all the cache and all the memory bandwidth, while some streaming software would get access to none – it could cause havoc on the system. AMD explained that while technically individual programs can request a certain level of QoS, however it will be up to the OS or the hypervisor to control if those requests are both valid and suitable. They see this feature more as an enterprise feature used when hypervisors are in play, rather than bare metal installations on consumer systems.
Facebook
Twitter
RSS
216 Comments
View All Comments
GreenReaper - Wednesday, June 12, 2019 - link
The last you heard? It says clearly on page 6 that there is "single-op" AVX 256, and on page 9 explicitly that the width has been increased to 256 bits:https://www.anandtech.com/show/14525/amd-zen-2-mic...
https://www.anandtech.com/show/14525/amd-zen-2-mic...
To be honest, I don't mind how it's implemented as long as the real-world performance is there at a reasonable price and power budget. It'll be interesting to see the difference in benchmarks.
arashi - Wednesday, June 12, 2019 - link
Don't expect too much cognitive abilities regarding AMD from HStewart, his pay from big blue depends on his misinformation disguised as misunderstanding.Qasar - Thursday, June 13, 2019 - link
HA ! so that explains it..... the more misinformation and misunderstanding he spreads.. the more he gets paid.......HStewart - Thursday, June 13, 2019 - link
I don't get paid for any of this - I just not extremely heavily AMD bias like a lot of people here. It just really interesting to me when Intel release information about new Ice Lake processor with 2 load / s store processor that with in a a couple days here bla bla about Zen+++. Just because 7nm does not mean they change much.Maybe AMD did change it 256 width - and not dual 128, they should be AVX 2 has been that way for a long time and Ice Lake is now 512. Maybe by time of Zen 4 or Zen+++++ it will be AVX 512 support.
Korguz - Thursday, June 13, 2019 - link
no.. but it is known.. you are heavily intel bias..whats zen +++++++++ ????
x 86-512 ??????
but you are usually the one spreading misinformation about amd...
" and support for single-operation AVX-256 (or AVX2). AMD has stated that there is no frequency penalty for AVX2 " " AMD has increased the execution unit width from 128-bit to 256-bit, allowing for single-cycle AVX2 calculations, rather than cracking the calculation into two instructions and two cycles. This is enhanced by giving 256-bit loads and stores, so the FMA units can be continuously fed. "
HStewart - Thursday, June 13, 2019 - link
Zen+++++ was my joke as every AMD fan jokes about Intel 10+++ Just get over itx-86 512 - is likely not going to happen, it just to make sure people are not confusing vector processing bits with cpu bits 64 bit is what most os uses now. for last decade or so
Intel has been using 256 AVX 2 since day one, the earlier version of AMD chips on only had two combine 128 bit - did they fix this with Zen 2 - this is of course different that AVX 512. which standard in in all Ice Lake and higher cpus and older Xeon's.
Qasar - Thursday, June 13, 2019 - link
sorry HStewart... but even sone intel fans are making fun of the 14++++++ and it would be funny.. if you were making fun of the process node.. not the architeCture..."
x-86 512 - is likely not going to happen, it just to make sure people are not confusing vector processing bits with cpu bits 64 bit is what most os uses now. for last decade or so " that makes NO sense...
HStewart - Thursday, June 13, 2019 - link
One more thing I stay away from AMD unless there are one that bias against Intel like spreading misinformation that AVX 512 is misleading. and it really not 512 surely they do not have proof of that.AVX 512 is not the same as x86-512, I seriously doubt we will ever need that that but then at time people didn't think we need x86-64 - I remember original day of 8088,. no body thought we needed more 64meg AVX-512 is for vectors which is totally different.
just4U - Thursday, June 13, 2019 - link
I always have a higher end Intel setup and normally a AMD setup as well.. plus I build a fair amount of setups on both. No bias here except maybe.. wanting AMD to be competitive. The news that dropped over the past month was the biggest for AMD in over a decade HS.. If you can't even acknowledge that (even grudgingly..) then geez.. I dunno.This has been awesome news for the industry and will put intel on their toes to do better. Be happy about it.
Xyler94 - Monday, June 17, 2019 - link
HStewart, please. You don't stay away from AMD at all. You take ANY opportunity to try and make Intel look better than AMD.There was an article, it was Windows on ARM. You somehow managed to make a post about Intel winning over AMD. Don't spew that BS. People don't hate Intel as much as you make them out to be, they don't like you glorifying Intel.