AMD Threadripper 1950X Review & Benchmarks – 4-channel DDR4 Cache & Memory Performance

What is “Threadripper”?

“Threadripper” (code-name ZP aka “Zeppelin”) is simply a combination of inter-connected Ryzen dies (“nodes”) on a single socket (TR4) that in effect provide a SMP system-on-a-single-socket – without the expense of multiple sockets, cooling solutions, etc. It also allows additional memory channels (4 in total) to be provided – thus equaling Intel’s HEDT solution.

It is worth noting that up to 4 dies/nodes can be provided on the socket – thus up to 32C/64T – can be enabled in the server (“EPYC”) designs – while current HEDT systems only use 2 – but AMD may release versions with more dies later on. The large socket allows for 4 DDR4 memory channels greatly increasing bandwidth over Ryzen, just as with Intel.

In this article we test CPU Cache and Memory performance; please see our other articles on:

• AMD Threadripper 1950X Review and Benchmarks – CPU 16-core Performance
• NUMA performance improvement for AMD ThreadRipper in Sandra SP2

Hardware Specifications

We are comparing the 2nd-from-the-top Ryzen (1700X) with previous generation competing architectures (i7 Skylake 4C and i7 Haswell-E 6C) with a view to upgrading to a mid-range high performance design. Another article compares the top-of-the-range Ryzen (1800X) with the latest generation competing architectures (i7 Kabylake 4C and i7 Broadwell-E 8C) with a view to upgrading to the top-of-the-range design.

Core Topology and Testing

As discussed in the previous article, cores on TR/Ryzen are grouped in blocks (CCX or compute units) each with its own 8MB L3 cache – but connected via a 256-bit bus running at memory controller clock. This is better than older designs like Intel Core 2 Quad or Pentium D which were effectively 2 CPU dies on the same socket – but not as good as a unified design where all cores are part of the same unit.

Running algorithms that require data to be shared between threads – e.g. producer/consumer – scheduling those threads on the same CCX would ensure lower latencies and higher bandwidth which we will test with presently.

In addition, Threadripper is a NUMA SMP design – with the other nodes effectively different CPUs; thus sharing data between cores on different nodes is equivalent to different CPUs in a SMP system.

We have thus modified Sandra’s ‘CPU Multi-Core Efficiency Benchmark‘ to report the latencies of each producer/consumer unit combination (e.g. same core, same CCX, different CCX) as well as providing different matching algorithms when selecting the producer/consumer units: best match (lowest latency), worst match (highest latency) thus allowing us to test inter-CCX bandwidth also. We hope users and reviewers alike will find the new features useful!

Native Performance

We are testing native arithmetic, SIMD and cryptography performance using the highest performing instruction sets (AVX2, AVX, etc.). TR (like Ryzen) supports all modern instruction sets including AVX2, FMA3 and even more.

Results Interpretation: Higher values (GOPS, MB/s, etc.) mean better performance.

Environment: Windows 10 x64, latest AMD and Intel drivers. Turbo / Dynamic Overclocking was enabled on both configurations.

Native Benchmarks		AMD Threadripper 1950X	Intel 9700X (SKL-X)	AMD Ryzen 1700X	Intel 6700K (SKL)	Comments
	Total Inter-Core Bandwidth – Best (GB/s)	92.2 [+7%]	85.5	47.2	39.5	With 16 cores (and thus 16 pairs) TR’s inter-core bandwidth beats SKL-X by over 7% – assuming threads are scheduled correctly.
	Total Inter-Core Bandwidth – Worst (GB/s)	7.51 [1/3]	24.4	5.75	16	In worst-case pairs on TR go not to just different CCX but NUMA nodes thus bandwidth is 1/3 that of SKL-X.
	Inter-Unit Latency – Same Core (ns)	15.4 [-1%]	15.8	15.5	16.1	Within the same core (sharing L1D/L2) , TR/Ryzen inter-unit is ~15ns comparative with both Intel’s CPUs.
	Inter-Unit Latency – Different Core (ns)	46.4 [-36%]	72.3	44.3	45	Within the same compute unit (sharing L3), the latency is ~45ns is much lower than SKL-X
	Inter-Unit Latency – Different CCX (ns)	184.7 [+4x]		135		Going inter-CCX increases the latency by 4 times thus threads sharing data must be properly scheduled.
	Inter-Unit Latency – Different Node(ns)	274.4 [+6x]				Going inter-node increases the latency yet again by 6 times, thus scheduling is everything.
The multiple CCX design does present some challenges to programmers and threads will have to be carefully scheduled – as latencies are much larger than inter-core; going off node increases latencies yet again but not by a lot; if anything inter-node interconnect seems pretty low latency comparatively.
	Aggregated L1D Bandwidth (GB/s)	1372 [-40%]	2252	739	878	SKL/X has 512-bit data ports (for AVX512) so TR/Ryzen cannot compete but they would do better against older designs.
	Aggregated L2 Bandwidth (GB/s)	990 [-2%]	1010	565	402	The 16x L2 caches have similar bandwidth to the 10x much bigger caches on SKL-X.
	Aggregated L3 Bandwidth (GB/s)	749 [+2.6x]	289	300	247	The 4x L3 caches have much higher bandwidth than the single SKL-X cache.
	Aggregated Memory (GB/s)	56 [-18%]	69	28	31	Running at lower memory speed TR cannot beat SKL-X but has comparatively higher memory efficiency
Even with 16x L1D and L2 caches, TR cannot match the much faster SKL-X 10x caches – that have been updated for 512-bit support but they are competitive; the 4x L3 caches do soundly beat the unified one on SKL-X but then again sharing data not within the same CCX is going to be very much slower. At 2400Mt/s TR is running 33% slower than SKL-X at 3200Mt/s but its bandwidth is just 18% lower – thus its 4x DDR4 controllers are more efficient – not something we’re used to seeing.
	Data In-Page Random Latency (ns)	72.8 [4-17-37] [+2.75x]	26.4 [4-13-33]	70.7 [4-17-37]	20 [4-12-21]	What we saw previously with Ryzen was not accident; TR also suffers from surprisingly large in-page latency, almost 3x of Intel designs. Either the TLBs are very slow or not working.
	Data Full Random Latency (ns)	111.5 [4-17-44] [+47%]	75.5 [4-13-70]	87.9 [4-17-37]	65 [4-12-34]	Out-of-page latencies are ‘better’ with TR/Ryzen ‘only’ ~50% slower than SKL/X.
	Data Sequential Latency (ns)	5.5 [4-7-8] [=]	5.4 [4-11-13]	3.8 [4-7-8]	4.1 [4-12-13]	TR’s prefetchers are working well with sequential access pattern latency at ~5ns matching SKL-X.
We finally discover an issue – TR (just like Ryzen) memory latencies (in-page, random access pattern) are huge – almost 3x higher than Intel’s. It is a mystery as to why, as both out-of-page random and sequential are competitive. It does point to something with the TLBs as to whether they do work or are just very much slower for some reason.
	Code In-Page Random Latency (ns)	17.2 [4-10-26] [+43%]	12 [4-14-28]	16.1 [4-9-25]	10 [4-11-21]	With code we don’t see the same problem – with in-page latency a bit higher than SKL-X (40%) but nowhere as high as what we saw before.
	Code Full Random Latency (ns)	178 [4-15-60] [+2x]	86.1 [4-16-106]	95.4 [4-13-49]	70 [4-11-47]	Out-of-page latency is a bit higher than SKL-X but not as bad as before.
	Code Sequential Latency (ns)	8.7 [4-10-20] [+33%]	6.5 [4-7-12]	8.4 [4-9-18]	5.3 [4-9-20]	Ryzen’s prefetchers are working well with sequential access pattern latency at ~9ns and thus 33% higher than SKL-X.
While code access latencies are higher than the new SKL-X – they are comparative with the older designs and not as bad as we’ve seen with data. Overall it seems TR (like Ryzen) will need some memory controller optimisations regarding latencies – though bandwidth seems just great.
	Memory Update Transactional (MTPS)	1.9	52.2 [HLE]	4.18	32.4 [HLE]	SKL/X is in a world of its own due to support for HLE/RTM and there is not much TR/Ryzen can do about it.
	Memory Update Record Only (MTPS)	1.88	57.23 [HLE]	4.22	25.4 [HLE]	We see a similar pattern here.
Without HLE/RTM TR (like Ryzen) don’t have much chance against SKL/X but considering support for it is disabled in most SKUs, there’s not much AMD has to be worried about – no to mention Intel disabling it in the older HSW and BRW designs. But should AMD enable it in future designs Intel will have a problem on its hands…

Threadripper’s core, memory and cache bandwidths are great, in many cases much higher than its Intel rivals partly due to more cores and more caches (16 vs 10); overall latencies are also fine for caches and memory – except the crucial ‘in-page random access’ data latencies which are far higher – about 3 times – TLB issues? We’ve been here before with Bulldozer which could not be easily fixed – but if AMD does manage it this time Ryzen’s performance will literally fly!

Still, despite this issue we’ve seen in the previous article that TR’s CPU performance is very strong thus it may not be such a big problem.

SiSoftware Official Ranker Scores

• AMD Threadripper 1950X (16C)
• AMD Threadrupper 1920X (12C)

Final Thoughts / Conclusions

TR’s memory performance is not the clean-sweep we’ve seen in CPU testing but it is competitive with Intel’s designs,and especially against older designs. The bandwidths are all competitive and especially the memory controllers seem to be more efficient – but latencies are a bit of a problem which AMD may have to improve in future designs.

Overall we’d still recommend TR over Intel CPUs unless you want absolutely tried and tested design which have already been patched by microcode and firmware/BIOS updates.