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
Fetch/Prefetch
Starting with the front end of the processor, the prefetchers.
AMD’s primary advertised improvement here is the use of a TAGE predictor, although it is only used for non-L1 fetches. This might not sound too impressive: AMD is still using a hashed perceptron prefetch engine for L1 fetches, which is going to be as many fetches as possible, but the TAGE L2 branch predictor uses additional tagging to enable longer branch histories for better prediction pathways. This becomes more important for the L2 prefetches and beyond, with the hashed perceptron preferred for short prefetches in the L1 based on power.
In the front end we also get larger BTBs, to help keep track of instruction branches and cache requests. The L1 BTB has doubled in size from 256 entry to 512 entry, and the L2 is almost doubled to 7K from 4K. The L0 BTB stays at 16 entries, but the Indirect target array goes up to 1K entries. Overall, these changes according to AMD affords a 30% lower mispredict rate, saving power.
One other major change is the L1 instruction cache. We noted that it is smaller for Zen 2: only 32 KB rather than 64 KB, however the associativity has doubled, from 4-way to 8-way. Given the way a cache works, these two effects ultimately don’t cancel each other out, however the 32 KB L1-I cache should be more power efficient, and experience higher utilization. The L1-I cache hasn’t just decreased in isolation – one of the benefits of reducing the size of the I-cache is that it has allowed AMD to double the size of the micro-op cache. These two structures are next to each other inside the core, and so even at 7nm we have an instance of space limitations causing a trade-off between structures within a core. AMD stated that this configuration, the smaller L1 with the larger micro-op cache, ended up being better in more of the scenarios it tested.
Facebook
Twitter
RSS
216 Comments
View All Comments
scineram - Wednesday, June 12, 2019 - link
No.Xyler94 - Thursday, June 13, 2019 - link
YesXyler94 - Thursday, June 13, 2019 - link
If he meant 2700x, of course. Darn misreading :Pnevcairiel - Monday, June 10, 2019 - link
A quick note. AVX2 is actually primarily Integer. AVX1 (or just AVX) is 256-bit floating point. The article often refers to "full AVX2 support", which isn't necessarily wrong, but Zen2 also adds full AVX support equally.NikosD - Saturday, June 15, 2019 - link
AVX256 is both integer and floating point because it includes AVX2 FMA which doubles floating point capability compared to AVX1NikosD - Saturday, June 15, 2019 - link
AVX256 was a typo, I meant AVX2 obviously.eastcoast_pete - Monday, June 10, 2019 - link
Thanks Ian? Two questions: what is the official memory bandwidth for the consumer chips? (Sounds like they remain dual channel) and: Any words on relative performance of AMD's AVX 2 implementation vs. Intel's AVX 512 with software that can use either?emn13 - Tuesday, June 11, 2019 - link
AVX-512 is a really misleading name; the interesting... bits... aren't the 512-bit width, but the dramatically increased flexibility. All kinds of operations are now maskable and better reshufflable, and where specific sub-segements of the vector were used, they're now sometimes usable at 1bit granularity (whereas previously that was greater).Assuming x86 sticks around for high-perf computing long enough for compilers to be able to automatically leverage it and then for most software to use it, AVX-512 is likely to be quite the game changer - but given intel's super-slow rollout so far, and AFAIK no AMD support... that's going to take a while.
Which is all a long-winded way to say that you might well expect AMDs AVX2 implementation to be not all that much slower than intel's 512 when executing code that's essentially AVX2-esque (because intel drops the frequency, so won't get the full factor 2 speedup), but AVX-512 has the potential to be *much* faster than that, because the win isn't actually in vector-width.
GreenReaper - Tuesday, June 11, 2019 - link
Intel's own product segmentation has caused it to lose its first-mover advantage here. System software aside, there's little point in most developers seeking to use instructions that most of their users will not have (and which they themselves may not have). By the time software does support it, AMD is likely to have it. And of course an increasing number of developers will be pouncing on Zen 2 thanks to fast, cheap cores that they can use to compile on...HStewart - Tuesday, June 11, 2019 - link
Intel only had AVX 512 versions in Xeon and Xeon derive chips, but the with Ice Lake ( don't really count Canon Lake test run ) AVX 512 will hit main stream starting with in a month and 2020 should be fully roll out.As for AMD AVX 2 is true 256 bit, the last I heard is that it actually like dual 128 bit unless they change it in Zen 2. I serious doubt AMD AVX 2 implement is going to any much different that Intel AVX 2 and AVX 512 is a total different beast.
It funny years ago we heard the same thing about 64 bit in x86 instructions, and now we here in 512 bit AVX.
As for as AMD support for AVX 512, that does not matter much since Intel is coming out with AVX 512 in full line over next year or so.
But keep in mind unlike normal x86 instruction, AVX is kind of specialize with vectorize processing, I know with Video processing like Power Director this was a deciding factor earlier for it.,