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
Windows Optimizations
One of the key points that have been a pain in the side of non-Intel processors using Windows has been the optimizations and scheduler arrangements in the operating system. We’ve seen in the past how Windows has not been kind to non-Intel microarchitecture layouts, such as AMD’s previous module design in Bulldozer, the Qualcomm hybrid CPU strategy with Windows on Snapdragon, and more recently with multi-die arrangements on Threadripper that introduce different memory latency domains into consumer computing.
Obviously AMD has a close relationship with Microsoft when it comes down to identifying a non-regular core topology with a processor, and the two companies work towards ensuring that thread and memory assignments, absent of program driven direction, attempt to make the most out of the system. With the May 10th update to Windows, some additional features have been put in place to get the most out of the upcoming Zen 2 microarchitecture and Ryzen 3000 silicon layouts.
The optimizations come on two fronts, both of which are reasonably easy to explain.
Thread Grouping
The first is thread allocation. When a processor has different ‘groups’ of CPU cores, there are different ways in which threads are allocated, all of which have pros and cons. The two extremes for thread allocation come down to thread grouping and thread expansion.
Thread grouping is where as new threads are spawned, they will be allocated onto cores directly next to cores that already have threads. This keeps the threads close together, for thread-to-thread communication, however it can create regions of high power density, especially when there are many cores on the processor but only a couple are active.
Thread expansion is where cores are placed as far away from each other as possible. In AMD’s case, this would mean a second thread spawning on a different chiplet, or a different core complex/CCX, as far away as possible. This allows the CPU to maintain high performance by not having regions of high power density, typically providing the best turbo performance across multiple threads.
The danger of thread expansion is when a program spawns two threads that end up on different sides of the CPU. In Threadripper, this could even mean that the second thread was on a part of the CPU that had a long memory latency, causing an imbalance in the potential performance between the two threads, even though the cores those threads were on would have been at the higher turbo frequency.
Because of how modern software, and in particular video games, are now spawning multiple threads rather than relying on a single thread, and those threads need to talk to each other, AMD is moving from a hybrid thread expansion technique to a thread grouping technique. This means that one CCX will fill up with threads before another CCX is even accessed. AMD believes that despite the potential for high power density within a chiplet, while the other might be inactive, is still worth it for overall performance.
For Matisse, this should afford a nice improvement for limited thread scenarios, and on the face of the technology, gaming. It will be interesting to see how much of an affect this has on the upcoming EPYC Rome CPUs or future Threadripper designs. The single benchmark AMD provided in its explanation was Rocket League at 1080p Low, which reported a +15% frame rate gain.
Clock Ramping
For any of our users familiar with our Skylake microarchitecture deep dive, you may remember that Intel introduced a new feature called Speed Shift that enabled the processor to adjust between different P-states more freely, as well as ramping from idle to load very quickly – from 100 ms to 40ms in the first version in Skylake, then down to 15 ms with Kaby Lake. It did this by handing P-state control back from the OS to the processor, which reacted based on instruction throughput and request. With Zen 2, AMD is now enabling the same feature.
AMD already has sufficiently more granularity in its frequency adjustments over Intel, allowing for 25 MHz differences rather than 100 MHz differences, however enabling a faster ramp-to-load frequency jump is going to help AMD when it comes to very burst-driven workloads, such as WebXPRT (Intel’s favorite for this sort of demonstration). According to AMD, the way that this has been implemented with Zen 2 will require BIOS updates as well as moving to the Windows May 10th update, but it will reduce frequency ramping from ~30 milliseconds on Zen to ~1-2 milliseconds on Zen 2. It should be noted that this is much faster than the numbers Intel tends to provide.
The technical name for AMD’s implementation involves CPPC2, or Collaborative Power Performance Control 2, and AMD’s metrics state that this can increase burst workloads and also application loading. AMD cites a +6% performance gain in application launch times using PCMark10’s app launch sub-test.
Hardened Security for Zen 2
Another aspect to Zen 2 is AMD’s approach to heightened security requirements of modern processors. As has been reported, a good number of the recent array of side channel exploits do not affect AMD processors, primarily because of how AMD manages its TLB buffers that have always required additional security checks before most of this became an issue. Nonetheless, for the issues to which AMD is vulnerable, it has implemented a full hardware-based security platform for them.
The change here comes for the Speculative Store Bypass, known as Spectre v4, which AMD now has additional hardware to work in conjunction with the OS or virtual memory managers such as hypervisors in order to control. AMD doesn’t expect any performance change from these updates. Newer issues such as Foreshadow and Zombieload do not affect AMD processors.
Facebook
Twitter
RSS
216 Comments
View All Comments
wurizen - Friday, June 14, 2019 - link
flex^^^wurizen - Friday, June 14, 2019 - link
OMFG! I. Am. Not. Talking. About. Intel. Mesh.I. Am. Talking. About. Infinity. Fabric. High. Memory. Latency!
Now that I got that off my chest, let's proceed shall we...
OMFG!
L3 Cache? WTF!
Do you think you're so clever to talk about L3 cache to show off your knowledge as if to convince ppl here you know something? Nah, man!
WTF are you talking about L3 cache, dude? Come on, dude, get with the program.
The program is "Cross-CCX-High-Memory-Latency" with Infinity Fabric 1.0
And, games (BO3, BF1, BF4 from my testing) are what is affected by this high latency penalty in real-time. Imagine playing a game of BO3 while throughout the game, the game is "micro-pausing" "Micro-slow-motioning" repeatedly throughout the match? Yep, you got it, it makes it unplayeable.
In productive work like video editing, I would not see the high latency as an issue unless it affects "timeline editing" causing it to lag, as well.
I have heard some complain issues with it in audio editing with audio work. But I don't do that so I can't say.
As for "compute-intensive applications (y'know, real work)" --delatFx2
....
.....
......
You duh man, bruh! a real compute-intensive, man!
"This article mentions a Windows 10 patch to ensure that threads get assigned to the same CCX before going to the adjacent one." --deltaFx2
Uhhh... that won't fix it. Only AMD can fix it in Infinity Fabric 2.0 (Ryzen 2), if, indeed, AMD has fixed it. By making it faster! And/or, reducing that ~110ns latency to around 69ns.
Now, my question is, and you (deltaFx2) hasn't mentioned it in your wise-response to my comments is that SLIDE of "Raw Memory Performance" showing 69ns latency at 3200 Mhz RAM. Is that Raw memory performance Intra-CCX-Memory-Performance or Inter-core-Memory-Performance? Bada-boom, bish!
wurizen - Friday, June 14, 2019 - link
it's a problem ppl are having, if you search enough....Alistair - Wednesday, June 12, 2019 - link
those kinds of micro stutters are usually motherboard or most likely your windows installation causing it, reinstall windows, then try a different motherboard maybewurizen - Wednesday, June 12, 2019 - link
Wow, really? Re-install windows?I just wanna know (cough, cough Anand) what the Cross-CCX-Latency is for Ryzen 2 and Infinity Fabric 2.0.
If, it is still ~110ns like before.... well, guess what? 110 nano-effin-seconds is not fast enough. It's too HIGH a latency!
You can't update bios/motherboard or re-install windows, or get 6000 Mhz RAM (the price for that, tjo?) to fix it. (As shown in the graph for whatever "Raw Memory Latency" is for that 3200 Mhz RAM to 3600 Mhz stays at 69 ns and only at 37333 Mhz RAM does it drop to 67ns?).... This is the same result PCPER did with Ryzen IF 1.0 showing that getting Faster RAM at 3200 Mhz did not improve the Cross-CCX-Memory-Latency....
supdawgwtfd - Thursday, June 13, 2019 - link
O don't get any stutters with my 1600.As above. It's nothing to do with the CPU directly.
Something else is causing the problem.
deltaFx2 - Thursday, June 13, 2019 - link
How so you know for sure that the microstutter or whatever it is you think you are facing is due to the inter-ccx latency? Did you actually pin threads to CCXs to confirm this theory? Do you know when inter-ccx latency even comes into play? Inter-ccx latency ONLY matters for shared memory being modified by different threads; this should be a tiny fraction of your execution time, otherwise you are not much better going multithreaded. Moreover, Each CCX runs 8 threads so are you saying your game uses more than 8? That would be an interesting game indeed, given that intel's mainstream gaming CPUs don't have a problem on 4c8t.To me, you've just jumped the the gun and gone from "I have got some microstutter issues" to "I know PCPer ran some microbenchmark to find out the latency" to "that must be the problem". It does not follow.
FreckledTrout - Thursday, June 13, 2019 - link
I agree. If micro stutter from CCX latency was really occurring this would be a huge issue. These issues really have to be something unrelated.wurizen - Friday, June 14, 2019 - link
Another thing that was weird was GPU usage drop from 98% to like 0% in-game, midst-action, while I was playing... constantly, in a repeated pattern throughout the game... this is not a server or games hitching. we understand as gamers that a game will "hitch" once in a while. this is like "slow-motion" "micro-pause" thing happening through out the game. happens in single player (BF1) so I ruled out server-side. It's like the game goes in "slow-motion" for a second... not once or twice in a match, per se. But, throughout and in a repeated constant fashion... along with seeing GPU usage to accompany the effect dropping from 98% or so (normal) to 0% for split seconds (again, not once or twice in a match; but a constant, repeated pattern throughout the match)And, there are people having head-scratching issues similar to me with Ryzen CPU.
No one (cough, cough Anand; nor youtube tech tubers will address it) seems to address it tho.
But, I think that Ryzen 2 is coming out and if Cross-CCX-High-LAtency-Issue is the same, then we're bound to hear more. I'm sure.
I am thinking tech sites are giving AMD a chance... but not sure... doesn't matter tho. I got a 7700k (I wanted the 8-core thing when 1700x Ryzen came out) but its fine. Im not a fanboy. Just a techboy.... if anything...
wurizen - Friday, June 14, 2019 - link
The "micro-stutter" or "micro-pausing" is not once or twice (I get those with Intel, as well) but, a repeated, constant pattern throughout the match and round of game. The "micro-stutter" and "micro-pause" also "FEELS" different than what I felt with my prior 3700K CPU and current 7700K CPU. It's like a "micro-slow-motion." I am not making this up. I am not crazy!