Zen 2 Platform for HEDT - Improvements over Last-Gen

Section by Andrei Frumusanu

The platform architecture of the new Threadripper 3000 series is fundamentally different, and a massive departure from what we’ve seen in the past on the first and second generation Threadripper products. Previously, AMD still made use of its monolithic die design used in Zen and Zen+ Ryzen, Threadripper and EPYC products. The approach was an economically smart one for AMD in regards to having to design only a single silicon die that would be used across the three product lines, however it had some fundamental technical disadvantages when it came to power efficiency as well as having to make some performance compromises.

The biggest disadvantage exhibited by the Threadripper 2000 series was the platform’s weakness in regards to its memory architecture, an issue that was particularly prevalent in the 32-core Threadripper 2990WX. As explained in our review of the TR2 products last year, the main problem with that SKU was that in order to achieve a 32-core product, AMD had to make use of 4 “Zeppelin” dies. Unlike the server-oriented SP3 socket however, Threadripper products come on the TR4 platform. While the two sockets are physically identical, they’re electrically incompatible with each other. In practice, the biggest difference between the two platforms is the fact that Threadripper products supports 4-channel memory setups, while the EPYC variants support the full 8-channel memory configuration possible.

The main conundrum for a product such as the 2990X which had to make use of 4 dies, each integrating 2 memory controller channels, is the decision on how you split up the memory controller setup between the dies and choose which 4 active controllers you’ll end up using. AMD’s approach here is that instead of using only one memory controller per die, the company chose to have two dies each with both memory controllers active, while the other two dies wouldn’t have any memory controllers enabled at all. The issue here is that the CPUs located on these dies would only have to access memory by hopping through the infinity fabric to the adjacent dies which did have memory controllers, and incur quite a large memory latency and bandwidth penalty. This penalty was large enough, that in situations where applications weren’t properly NUMA-aware and scaled across all core, the 2990WX ended up sometimes lagging behind the 16-core 2950X in performance.

Chiplet Architecture To The Rescue

Of course, AMD was aware of this drawback, but wasn’t planning to stay with this compromise forever. The new Ryzen 3000 series earlier this summer introduced the chiplet architecture for the first time ever, with some quite astounding success. The main differences here is that AMD is decoupling the actual CPU cores and cluster from the rest of the traditional SoC. The CPU chiplet contains nothing more than the CPU cores themselves, the CPU clusters L3 caches, and the I/O interface which communicates with the rest of the “traditional” system, which is now located on a separate silicon die.


AMD Ryzen 3000 Consumer IOD - Credit Fritzchens Fritz

For the Ryzen 3000 products, this I/O die is seemingly quite familiar in terms of design to what we saw in the first- and second-generation Zen architecture products. We find your various I/O IP blocks which take care of various connectivity such as USB, Ethernet, SATA, alongside the critical components such as the PCIe controllers and of course the memory controllers. In general, what’s found on the Ryzen 3000 IOD isn’t all too different in functionality than what we previously saw on the monolithic Zen dies from past years – of course, except for the CPUs themselves.


AMD EPYC2 / Threadripper 3000 sIOD - Credit Fritzchens Fritz

As we move on to the new Threadripper 3000 products (and new EPYC 2 processors), we however see the AMD’s main chiplet design advantage. Although the new Threadripper and EPYC products use the very same 7nm CPU chiplet dies (CCDs), they are using a different IO die, what seems to be called by AMD as the sIOD (server IO die?).

What’s interesting about the sIOD is that it’s not much of a “monolithic” design, but actually more similar to four consumer IO dies put together on one chip. In the above die shots (credit to Fritzchens Fritz), we actually see that AMD is employing an identical physical design of large parts of the chip’s IP blocks, with the main "central" block cluster going as far as being essentially identical. Of course, the layout of the various surrounding blocks is quite different. AMD here is essentially reusing design resources across its product ranges.

While the chip isn’t completely mirrored – there are still distinct unique IP blocks on each quarter of the die, it is in fact correct to say that it’s divided into quarters. These “quadrants” are in fact physically and logically separate from each other. Where this is important to consider, is in regards to the memory layout. In fact, logically, the layout is actually quite similar to what we’ve seen on the previous generation Threadripper and EPYC chips in terms of memory controller and CPU cluster distinction. Each quadrant still has its own two local memory controller channels, and the CPU CCXs connected to this quadrant have the best latency and bandwidth to memory. The CPUs accessing memory controllers of a different quadrant still have to do this via a hop over the infinity fabric, the biggest difference for this generation however is that instead of this hop being across different dies on the MCM package, it all remains on the same silicon die.

For Rome, AMD had explained that the latency differences between accessing memory on the local quadrant versus accessing remote memory controllers is ~+6-8ns and ~+8-10ns for adjacent quadrants (because of the rectangular die, the quadrants adjacent on the long side have larger latency than adjacent quadrants on the short side), and ~+20-25ns for the diagonally opposing quadrants. While for EPYC, AMD provides options to change the NUMA configuration of the system to optimize for either latency (quadrants are their own NUMA domain) or bandwidth (one big UMA domain), the Threadripper systems simply appear as one UMA domain, with the memory controllers of the quadrants being interleaved in the virtual memory space.

The interesting question here of course is, how is this UMA domain setup for the Threadripper 3950X and 3970X? The SKUs come with 4 chiplets each, with the 3950X employing 3 cores per CCX, totalling 24 cores, and the 3970X employing 4 cores per CCX, totaling 32 cores. However, what we don’t know is how these chiplets are divided and populated across the sIOD’s quadrants. In theory, one could have one chiplet and one memory controller per quadrant – or one could have just two fully populated quadrants with the other two quadrants disabled. Given we have numbers on a fully populated EPYC 7742 to compare against, and that the diagonally opposing quadrant latency penalty is quite big, we should be able to estimate the implementation based on the latency results.

   

Looking at the latency results, there’s a few comparisons to make. In regards to the L1, L2 and L3 performance, I refer to our original Zen2 analysis in our Ryzen 3000 review article. The numbers here don’t change, which is natural as we’re talking about the very same CPU chiplet across the different product lines.

Going out of the CCD, the DRAM latency is the most interesting difference that we need to have a closer look at. Comparing the new Threadripper 3970X to the 2950X we see a latency degradation of 16.2ns, with the structural DRAM latency rising from 62.2ns to 78.6ns. For this comparison we’re using the very same DRAM sticks with identical timings between the Ryzen and two Threadripper platforms, so any differences here are solely due to the architectural differences of the platforms.

This degradation is actually to be expected. The third generation Threadripper degrades in two aspects compared to its predecessor: First of all, the chiplet architecture does incur a latency penalty as the separation of the CPU cores onto a different silicon die comes with a latency penalty. Secondly, in the first and second generation Threadripper products, each CPU had access to its own die memory controller by default, and it wasn’t possible to use an UMA setup. The third-gen Threadripper comes with an UMA setup by default, and the fact that the IOD is interleaving memory accesses across the quadrant memory controllers again adds another latency penalty.

Looking at the differences between the EPYC 7742 running in NPS4 mode and the new 3970X, we however see that the new TR3000 platform has a definitive latency advantage of almost 25ns – albeit we’re no longer running apples-to-apples here in regards to the DRAM.

Finally, the most interesting comparison is using the very same DRAM and timings between a Ryzen 3000 processor and the new 3970X. Using an 3700X we had at hand, the latency penalty for the new TR chip is “only” 9.2ns, rising from 69.4ns to 78.6ns. Maybe I might sound a bit optimistic here, based on the Rome numbers from earlier this summer I had expected some quite worse results for the new Threadripper 3000 series, so I see this result to be actually quite good. While we don’t have definitive confirmation, it does look like the new 24 and 32-core Threadripper 3000 SKUs are using only two adjacent quadrants of the sIOD.

Of course, the structural latency degradations here don’t necessarily translate to performance degradations. As we saw on the Ryzen 3000 products, AMD’s new doubled L3 cache as well as improved prefetchers have managed to more than compensate for the worse structural latency, actually increasing the memory performance of the new Zen2 chips.

Power Consumption: 6-13W Per Core Test Bed and Setup
Comments Locked

245 Comments

View All Comments

  • Xyler94 - Tuesday, November 26, 2019 - link

    Gotta love the "But what about this" with you fanboys.

    Did AMD beat Intel to the X86-64 Race? Yes
    Did AMD beat Intel to the 1Ghz Race? Yes
    Did AMD beat Intel to the true dual-core arc? Yes
    Does AMD still continue to innovate and bring us better products, despite their peanut funding compared to Intel, while Intel just tries to weasel their way through the market? Of course. Do you honestly believe if TR3 wasn't so amazing, that Intel would have reduced their 18 core part to 1k out of the goodness of their heart? If you think that, you're more of a fanboy than I thought.

    It is still known as AMD-64 today, because AMD found the way to do both 32bit and 64bit X86 at the same time, and Intel has to license that tech from AMD. Without AMD, Intel would not be releasing 8 core CPUs today. The reason for their shortages isn't really due to high demand, it's due to varying demand of their products. the 6-8 core silicon is different from their 4 core ones, and they needed to manufacture separate LCC and HCC core i9/Xeons, further hogging their supply chain. And there's also the fact the 9900k is also a legitimately great CPU, so people want it, further hurting the supply chain. Intel did this to themselves due to years of complacency, so I don't feel bad at all.
  • blppt - Wednesday, November 27, 2019 - link

    "Did AMD beat Intel to the X86-64 Race? Yes"

    They didn't beat Intel to anything---Intel was going with IA64, never going with x64, Then AMD threw a MASSIVE wrench into those plans, lol. Intel was forced to then copy AMD64 with EMT64 when Itanium flopped.

    But make no mistake---if AMD didn't create x86-64, Intel wouldn't have either. We'd all be running Itaniums and Itanium clones.
  • Qasar - Wednesday, November 27, 2019 - link

    actually, for the most part, the industry didnt want ia 64, it would me a redo of most, if not all of the software just to use it, before they could even use it, with AMD64, you could keep using existing 32 bit software, and transition of 64 bit, when you can, or wanted to. amd just found a better, and quicker way to 64 bit then when intel was trying to cram down every ones throats.
    "
    But make no mistake---if AMD didn't create x86-64, Intel wouldn't have either." and chances are, we could be still using 32 bit cpus, as i said above, most, if not all of the industry didnt want to have to re compile all of the software we used then. and wasnt itanium slower then x86 over all ?
    ahh yep.. it was slower : " By the time Itanium was released in June 2001, its performance was not superior to competing RISC and CISC processors. " from https://en.wikipedia.org/wiki/IA-64
  • Qasar - Wednesday, November 27, 2019 - link

    would me a redo of most = would mean a redo of most
  • blppt - Monday, December 2, 2019 - link

    One of the big reasons Itanium/IA-64 failed was that its "backwards compatibility" (i.e. x86 emulation) was much slower than the native x86 cpus out at the time.

    So, while they wouldn't need to redo all that x86 software, it wasn't exactly speedy while emulating.

    To take full advantage of the IA64 architecture, yes, they would need to rewrite a lot of software, but it would have *run* without a rewrite.

    And that's where x86-64 stepped in. 64 bit memory addressing, perfect x86-32 performance at a lower price.

    But Intel was never going to create x64 by themselves unless the new EPIC/VLIW IA64 hit some kind of performance brick wall, or people just kept coding to x86 anyways (which Itanium would run, but slowly).

    Bear in mind that part of the reason it was slow in 2001, x86 and Power had been extensively optimized compilers for a decade (or more for x86) and IA64 was in its nascent stages. Since it was never adopted by the mass public (include home users, etc), development of IA64 never came close to the level of development and optimization of x86.
  • Qasar - Tuesday, December 3, 2019 - link

    either way you look at it, it seems AMD is doing more to move the cpu farther, then intel does. AMD seems to be the one that innovates, while intel sleeps. i know some who is a fan of intel, will refute this, but think about it... AMD improves the cpu, and moves it forward, while intel stagnates and stifles it..
  • eva02langley - Monday, November 25, 2019 - link

    Desktop and HEDT is not Intel business anymore. Just a matter of time for server and laptop to eat the same bullet.
  • eek2121 - Monday, November 25, 2019 - link

    I wouldn't say that AMD fans are wrong. Look at AMD's revenue years ago vs today. Do you think the growth came out of thin air? No, AMD is eroding Intel's marketshare. It hasn't begun to show yet, because the last reported earnings did not include Zen 2 eating into things. More and more people are buying AMD, and as long as AMD continues to execute as they have (and even more so: they have to get into bed with OEMs), Intel will gradually begin to suffer. They already HAVE suffered. Drastic price reductions on their highest end parts.
  • eek2121 - Monday, November 25, 2019 - link

    Oh and I should add that Intel is in a lot more markets than AMD. In addition, Intel actually does a ton of fab work for other companies. Intel makes networking cards, storage, and much more. So in translation: Revenue is meaningless. Intel does not have endless amounts of cash to throw at creating new CPUs, GPUs (which are coming out in 2021), and chipsets. What matters is marketshare. For Intel, it's shrinking.
  • tygrus - Tuesday, November 26, 2019 - link

    AMD have taken market share from Intel but it's not uniform across all markets. Fancy brand names, servers and ultra notebooks are still dominated by Intel and where the end-user isn't making a choice. Enthusiasts using a local store to select parts & assemble are a small market that have swung to AMD.

Log in

Don't have an account? Sign up now