Feeding the Beast

When frequency was all that mattered for CPUs, the main problem became efficiency, thermal performance, and yields: the higher the frequency was pushed, the more voltage needed, the further outside the peak efficiency window the CPU was, and the more power it consumed per unit work. For the CPU that was to sit at the top of the product stack as the performance halo part, it didn’t particularly matter – until the chip hit 90C+ on a regular basis.

Now with the Core Wars, the challenges are different. When there was only one core, making data available to that core through caches and DRAM was a relatively easy task. With 6, 8, 10, 12 and 16 cores, a major bottleneck suddenly becomes the ability to make sure each core has enough data to work continuously, rather than waiting at idle for data to get through. This is not an easy task: each processor now needs a fast way of communicating to each other core, and to the main memory. This is known within the industry as feeding the beast.

Top Trumps: 60 PCIe Lanes vs 44 PCIe lanes

After playing the underdog for so long, AMD has been pushing the specifications of its new processors as one of the big selling points (among others). Whereas Ryzen 7 only had 16 PCIe lanes, competing in part against CPUs from Intel that had 28/44 PCIe lanes, Threadripper will have access to 60 lanes for PCIe add-in cards. In some places this might be referred to as 64 lanes, however four of those lanes are reserved for the X399 chipset. At $799 and $999, this competes against the 44 PCIe lanes on Intel’s Core i9-7900X at $999.

The goal of having so many PCIe lanes is to support the sort of market these processors are addressing: high-performance prosumers. These are users that run multiple GPUs, multiple PCIe storage devices, need high-end networking, high-end storage, and as many other features as you can fit through PCIe. The end result is that we are likely to see motherboards earmark 32 or 48 of these lanes for PCIe slots (x16/x16, x8/x8/x8/x8, x16/x16/x16, x16/x8/x16/x8), followed by a two or three for PCIe 3.0 x4 storage via U.2 drives or M.2 drives, then faster Ethernet (5 Gbit, 10 Gbit). AMD allows each of the PCIe root complexes on the CPU, which are x16 each, to be bifurcated down to x1 as needed, for a maximum of 7 devices. The 4 PCIe lanes going to the chipset will also support several PCIe 3.0 and PCIe 2.0 lanes for SATA or USB controllers.

Intel’s strategy is different, allowing 44 lanes into x16/x16/x8 (40 lanes) or x16/x8/x16/x8 (40 lanes) or x16/x16 to x8/x8/x8x8 (32 lanes) with 4-12 lanes left over for PCIe storage or faster Ethernet controllers or Thunderbolt 3. The Skylake-X chipset then has an additional 24 PCIe lanes for SATA controllers, gigabit Ethernet controllers, SATA controllers and USB controllers.

Top Trumps: DRAM and ECC

One of Intel’s common product segmentations is that if a customer wants a high core count processor with ECC memory, they have to buy a Xeon. Typically Xeons will support a fixed memory speed depending on the number of channels populated (1 DIMM per channel at DDR4-2666, 2 DIMMs per channel at DDR4-2400), as well as ECC and RDIMM technologies. However, the consumer HEDT platforms for Broadwell-E and Skylake-X will not support these and use UDIMM Non-ECC only.

AMD is supporting ECC on their Threadripper processors, giving customers sixteen cores with ECC. However, these have to be UDIMMs only, but do support DRAM overclocking in order to boost the speed of the internal Infinity Fabric. AMD has officially stated that the Threadripper CPUs can support up to 1 TB of DRAM, although on close inspection it requires 128GB UDIMMs, which max out at 16GB currently. Intel currently lists a 128GB limit for Skylake-X, based on 16GB UDIMMs.

Both processors run quad-channel memory at DDR4-2666 (1DPC) and DDR4-2400 (2DPC).

Top Trumps: Cache

Both AMD and Intel use private L2 caches for each core, then have a victim L3 cache before leading to main memory. A victim cache is a cache that obtains data when it is evicted from the cache underneath it, and cannot pre-fetch data. But the size of those caches and how AMD/Intel has the cores interact with them is different.

AMD uses 512 KB of L2 cache per core, leading to an 8 MB of L3 victim cache per core complex of four cores. In a 16-core Threadripper, there are four core complexes, leading to a total of 32 MB of L3 cache, however each core can only access the data found in its local L3. In order to access the L3 of a different complex, this requires additional time and snooping. As a result there can be different latencies based on where the data is in other L3 caches compared to a local cache.

Intel’s Skylake-X uses 1MB of L2 cache per core, leading to a higher hit-rate in the L2, and uses 1.375MB of L3 victim cache per core. This L3 cache has associated tags and the mesh topology used to communicate between the cores means that like AMD there is still time and latency associated with snooping other caches, however the latency is somewhat homogenized by the design. Nonetheless, this is different to the Broadwell-E cache structure, that had 256 KB of L2 and 2.5 MB of L3 per core, both inclusive caches.

The AMD Ryzen Threadripper 1950X and 1920X Review Silicon, Glue, & NUMA Too
Comments Locked

347 Comments

View All Comments

  • NikosD - Sunday, August 13, 2017 - link

    Well, reading the whole review today - 13/08/2017 - I can see that the reviewer did something more evil than not using DDR4-3200 to give us performance numbers.

    He used DDR4-2400, as he clearly states in the configuration table, filling up the performance tables BUT in the power consumption page he added DDR4-3200 results (!) just to inform us that DDR4-3200 consumes 13W more, without providing any performance numbers for that memory speed (!!)

    The only thing left for the reviewer is to tell us in which department of Intel works exactly, because in the first pages he wanted to test TR against a 2P Intel system as Skylake-X has only 10C/20T but Intel didn't allow him.

    Ask for your Intel department to permit it next time.
  • Zingam - Sunday, August 13, 2017 - link

    Yeah! You make a great point! Too much emphasis on gaming all the time! These processors aren't GPUs after all! Most people who buy PCs don't play games at all. Even I as a game developer would like to see more real world tests, especially compilation and data-crunching tests that are typical for game content creation and development workloads. Even I as a game developer spend 99% of my time in front of the computer not playing any games.
  • pm9819 - Friday, August 18, 2017 - link

    So Intel made AMD release the underpowered overheating Bulldozer cpu's? Did Intel also make them sell there US and EU based fabs so they'll be wholly dependant on the Chinese to make their chips? Did Intel also make them buy a equally struggling graphics card company? Truth is AMD lost all the mind and market share they had because of bad corporate decision and uncompetitive cpu designs post Thunderbird. It's no one's fault but there own that it took seven years to produce a competitive replacement. Was Intel suppose to wait till they caught up? And Intel was a monopoly long before AMD started producing competitive cpu's.

    You can keep blaming Intel for AMD's screw ups but those of us with common sense and the ability to read know the fault lays with AMD's management.
  • ddriver - Thursday, August 10, 2017 - link

    You are not sampled because of your divine objectivity Ian, you are sampled because you review for a site that is still somewhat popular for its former glory. You can deny it all you want, and understandable, as it is part of your job, but AT is heavily biased towards the rich american boys - intel, apple, nvidia... You are definitely subtle enough for the dumdums, but for better or worse, we are not all dumdums yet.

    But hey, it is not all that bad, after all, nowadays there are scores of websites running reviews, so people have a base for comparison, and extrapolate objective results for themselves.
  • ddriver - Thursday, August 10, 2017 - link

    And some bits of constructive criticism - it would be nicer if those reviews featured more workloads people actually use in practice. Too much synthetics, too much short running tests, too much tests with software that is like "wtf is it and who in the world is using it".

    For example rendering - very few people in the industry actually use corona or blender, blender is used for modelling and texturing a lot, but not really for rendering. Neither is luxmark. Neither is povray, neither is CB.

    Most people who render stuff nowadays use 3d max and vray, so testing this will actually be indicative of actual, practical perforamnce to more people than all those other tests combined.

    Also, people want render times, not scores. That's very poor indication of actual performance that you will get, because many of those tests are short, so the CPU doesn't operate in the same mode it will operate if it sweats under continuous work.

    Another rendering test that would benefit prosumers is after effects. A lot of people use after effects, all the time.

    You also don't have a DAW test, something like cubase or studio one.

    A lot of the target market for HEDT is also interested in multiphysics, for example ansys or comsol.

    The compilation test you run, as already mentioned several times by different people, is not the most adequate either.

    Basically, this review has very low informational value for people who are actually likely to purchase TR.
  • mapesdhs - Thursday, August 10, 2017 - link

    AE would definitely be a good test for TR, it's something that can hammer an entire system, unlike games which only stress certain elements. I've seen AE renders grab 40GB RAM in seconds. A guy at Sony told me some of their renders can gobble 500GB of data just for a single frame, imposing astonishing I/O demands on their SAN and render nodes. Someone at a London movie company told me they use a 10GB/sec SAN to handle this sort of thing, and the issues surrounding memory access vs. cache vs. cores are very important, eg. their render management sw can disable cores where some types of render benefit from a larger slice of mem bw per core.

    There are all sorts of tasks which impose heavy I/O loads while also needing varying degrees of main CPU power. Some gobble enormous amounts of RAM, like ANSYS, though I don't know if that's still used.

    I'd be interested to know how threaded Sparks in Flame/Smoke behave with TR, though I guess that won't happen unless Autodesk/HP sort out the platform support.

    Ian.
  • Zingam - Sunday, August 13, 2017 - link

    Good points!
  • Notmyusualid - Sunday, August 13, 2017 - link

    ...only he WAS sampled. Read the review.
  • bongey - Thursday, August 10, 2017 - link

    You don't have to be paid by Intel, but this is just a bad review.
  • Gothmoth - Thursday, August 10, 2017 - link

    where is smoke there is fire.

    there are clear indications that anandtech is a bit biased.

Log in

Don't have an account? Sign up now