Adrian Silasi – SiSoftware

SiSoftware »

SiSoftware Sandra Titanium/2018 RTMa Update

By Adrian Silasi | 21st May 2018 - 11:57 am |21st May 2018 Releases, Updates

SiSoftware Sandra Titanium (2018) Released!

By Adrian Silasi | 27th April 2018 - 12:00 am |21st May 2018 Releases

Comments Off

FOR IMMEDIATE RELEASE

Contact: Press Office

SiSoftware Sandra Titanium (2018) Released:
Brand-new benchmarks, hardware support

Updates: RTMa.

Articles & Benchmarks: None.

London, UK, April 27th 2018 – We are pleased to announce the launch of SiSoftware Sandra Titanium (2018), the latest version of our award-winning utility, which includes remote analysis, benchmarking and diagnostic features for PCs, servers, mobile devices and networks.

We have added new Overall Performance benchmarks for all major components (CPU, GPGPU, Video/Graphics, Memory/Cache and Disk) and thus simplified the Overall Computer Performance benchmark.

We have added hardware support and optimisations for brand-new CPU architectures (AMD Ryzen 2, AMD Vega GPGPU, future Intel) not forgetting GPGPU architectures across the various interfaces (CUDA, OpenCL, DirectX ComputeShader, OpenGL Compute).

As SiSoftware operates a “just-in-time” release cycle, some features were introduced in Sandra 2017 service packs: in Sandra Titanium they have been updated and enhanced based on all the feedback received.

Broad Operating System Support

All current versions supported: Windows 10*, 8.1, 8, 7; Server 2019*, 2016, 2012/R2 and 2008/R2

Brand new Overall Performance Benchmarks allowing easy and complete device performance analysis without individually running all the benchmarks: now you need to run just one benchmarks that aggregates the results from all the component benchmarks.

	Processor Overall Index A combined performance index of all major CPU-related benchmarks: Multi-Media, Scientific Analysis, Financial Analysis, Image Processing, Multi-Core Efficiency. Ranker: Processor Overall Index
	GPGPU Overall Index A combined performance index of all major GPGPU-related benchmarks: Processing, Scientific Analysis, Financial Analysis, Image Processing, Memory Bandwidth, Memory Latency. Ranker: GPGPU Overall Index
	Video/Graphics Overall Index A combined performance index of all major video benchmarks: Shader Processing, Memory Bandwidth, Media Transcoding. Ranker: Video/Graphics Overall Index
	Memory/Cache Overall Index A combined performance index of all major memory and cache-related benchmarks: Memory Bandwidth, Cache Bandwidth, Memory Latency. Ranker: Memory/Cache Overall Index
	Disk Overall Index A combined performance index of all major disk-related benchmarks: File System Bandwidth, File System I/O, Physical Disk Bandwidth. Ranker: Disk Overall Index

As a result, the Overall Compute Benchmark was simplified to be an aggregate of the component overall benchmarks:

Overall (2018) Computer Index

A combined performance index of all component overall indexes (CPU, GPGPU, Video/Graphics, Memory/Cache and Disk)

Ranker: Overall (2018) Computer Index

Key features of Sandra Titanium

4 native architectures support (x86, x64 – Windows; ARM, ARM64, x86, x64 – Android)
Huge official hardware support through technology partners (AMD/ATI, nVidia, Intel).
4 native (GP)GPU/APU platforms support (OpenCL 2.0+, CUDA 9.0+, DirectX Compute Shader 10+, OpenGL Compute 4.3+, Vulkan 1.0+).
4 native Graphics platforms support (DirectX 12.x, DirectX 11.x, DirectX 10.x, OpenGL 4.0+, Vulkan 1.0+).
9 language versions (English, German, French, Italian, Spanish, Japanese, Chinese (Traditional, Simplified), Russian) in a single installer.
Enhanced Sandra Lite (Eval) version (free for personal/educational use, evaluation for other uses)

Relevant Articles

For more details, please see the following articles:

SiSoftware Official Live Ranker

Purchasing

For more details, and to purchase the commercial versions, please click here.

Updating or Upgrading

To update your existing commercial version, please click here.

Downloading

For more details, and to download the Lite (Evaluation) version, please click here.

Reviewers and Editors

For your free review copies, please contact us.

About SiSoftware

SiSoftware, founded in 1995, is one of the leading providers of computer analysis, diagnostic and benchmarking software. The flagship product, known as “SANDRA”, was launched in 1997 and has become one of the most widely used products in its field. Many worldwide IT publications, magazines and review sites use SANDRA to analyse the performance of today’s computers. Thousands on-line reviews of computer hardware that use SANDRA are catalogued on our website alone.

Since launch, SiSoftware has always been at the forefront of the technology arena, being among the first providers of benchmarks that show the power of emerging new technologies such as multi-core, GPGPU, OpenCL, OpenGL, DirectCompute, x64, ARM, NUMA, SMT (Hyper-Threading), SMP (multi-threading), AVX512, AVX2, AVX, FMA3, NEON, SSE4.2, SSE4, SSSE3, SSE2, SSE, Java and .NET.

SiSoftware is located in London, UK. For more information, please visit http://www.sisoftware.net, http://www.sisoftware.eu, or http://www.sisoftware.co.uk

AMD Ryzen2 2700X Review & Benchmarks – 2-channel DDR4 Cache & Memory Performance

By Adrian Silasi | 20th April 2018 - 12:01 pm |20th April 2018 Reviews

Comments Off

What is “Ryzen2” ZEN+?

After the very successful launch of the original “Ryzen” (Zen/Zeppelin – “Summit Ridge” on 14nm), AMD has been hard at work optimising and improving the design: “Ryzen2” (code-name “Pinnacle Ridge”) is thus a 12nm die shrink that also includes APU – with integrated “Vega RX” graphics” – as well as traditional CPU versions.

While new chipsets (400 series) will also be introduced, the CPUs do work with existing AM4 300-series chipsets (e.g. X370, B350, A320) with a BIOS/firmware update which makes them great upgrades.

Here’s what AMD says it has done for Ryzen2:

Process technology optimisations (12nm vs 14nm) – lower power but higher frequencies
Improvements for cache & memory speed & latencies (we are testing them in this article!)
Multi-core optimised boost (aka Turbo) algorithm – XFR2 – higher speeds

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

AMD Ryzen2 ZEN+ CPU Performance

Hardware Specifications

We are comparing the top-of-the-range Ryzen2 (2700X, 2600) with previous generation (1700X) and competing architectures with a view to upgrading to a mid-range high performance design.

CPU Specifications	AMD Ryzen2 2700X Pinnacle Ridge	AMD Ryzen2 2600 Pinnacle Ridge	AMD Ryzen 1700X Summit Ridge	Intel i7-6700K SkyLake	Comments
L1D / L1I Caches	8x 32kB 8-way / 8x 64kB 8-way	6x 32kB 8-way / 6x 64kB 8-way	8x 32kB 8-way / 8x 64kB 8-way	4x 32kB 8-way / 4x 32kB 8-way	Ryzen2 data/instruction caches is unchanged; icache is still 2x as big as Intel’s.
L2 Caches	8x 512kB 8-way	6x 512kB 8-way	8x 512kB 8-way	4x 256kB 8-way	Ryzen2 L2 cache is unchanged but we’re told latencies have been improved. And 4x bigger than Intel’s!
L3 Caches	2x 8MB 16-way	2x 8MB 16-way	2x 8MB 16-way	8MB 16-way	Ryzen2 L3 caches are also unchanged – but again lantencies are meant to have improved. With each CCX having 8MB even the 2600 has 2x as much cache as an i7.
TLB 4kB pages	64 full-way 1536 8-way	64 full-way 1536 8-way	64 full-way 1536 8-way	64 8-way 1536 6-way	No TLB changes.
TLB 2MB pages	64 full-way 1536 2-way	64 full-way 1536 2-way	64 full-way 1536 2-way	8 full-way 1536 6-way	No TLB changes, same as 4kB pages.
Memory Controller Speed (MHz)	600-1200	600-1200	600-1200	1200-4000	Ryzen’s memory controller runs at memory clock (MCLK) base rate thus depends on memory installed. Intel’s UNC (uncore) runs between min and max CPU clock thus perhaps faster.
Memory Speed (MHz) Max	2400 / 2933	2400 / 2933	2400 / 2666	2533 / 2400	Ryzen2 how supports up to 2933MHz (officially) which should improve its performance quite a bit – unfortunately fast DDR4 is very expensive right now.
Memory Channels / Width	2 / 128-bit	2 / 128-bit	2 / 128-bit	2 / 128-bit	All have 128-bit total channel width.
Memory Timing (clocks)	14-16-16-32 7-54-18-9 2T	14-16-16-32 7-54-18-9 2T	14-16-16-32 7-54-18-9 2T	16-18-18-36 5-54-21-10 2T	Memory runs at the same timings on both Ryzen2 and Ryzen1 but we shall see if measured latencies are different.

Core Topology and Testing

As discussed in the previous article, cores on 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.

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

Results Interpretation: Higher rate values (GOPS, MB/s, etc.) mean better performance. Lower latencies (ns, ms, etc.) mean better performance.

Environment: Windows 10 x64, latest AMD and Intel drivers. 2MB “large pages” were enabled and in use. Turbo / Boost was enabled on all configurations.

Native Benchmarks		Ryzen2 2700X 8C/16T Pinnacle Ridge	Ryzen2 2600 6C/12T Pinnacle Ridge	Ryzen 1700X 8C/16T Summit Ridge	i7-6700K 4C/8T SkyLake	Comments

	Total Inter-Core Bandwidth – Best (GB/s)	54.9 [+15%]	46.5	47.8	39	Ryzen2 manages 15% higher bandwidth between its cores, slightly better than just 11% clock increase – signalling some improvements under the hood.
	Total Inter-Core Bandwidth – Worst (GB/s)	5.89 [+2%]	5.53	5.8	16.3	In worst-case pairs on Ryzen must go across CCXes – and with this link running at the same clock (1200MHz) on Ryzen2 we can only manage a 2% increase in bandwidth. This is why faster memory is needed.

	Inter-Unit Latency – Same Core (ns)	13.5 [-13%]	15.4	15.6	16.2	Within the same core (sharing L1D/L2), Ryzen2 manages a 13% reduction in latency, again better than just clock speed increase.
	Inter-Unit Latency – Same Compute Unit (ns)	40.1 [-7%]	43.5	43.2	47.3	Within the same compute unit (sharing L3), the latency decreased by 7% on Ryzen2 thus L3 seems to have improved also.
	Inter-Unit Latency – Different Compute Unit (ns)	128 [-6%]	132	236	–	Going inter-CCX we still see a 6% reduction in latency on Ryzen2 – with the CCX link at the same speed – a welcome surprise.
The multiple CCX design still presents some challenges to programmers requiring threads to be carefully scheduled – but we see a decent 6-7% reduction in L3/CCX latencies on Ryzen2 even when running at the same clock as Ryzen1.

	Aggregated L1D Bandwidth (GB/s)	862 [+18%]	615	730	837	Right off we see a 18% bandwidth increase – almost 2x higher (than the 11% clock increase) – thus some improvements have been made to the cache system. It allows Ryzen2 to finally beat the i7 with its wide L1 data paths (512-bit) though with 2x more caches (8 vs 4).
	Aggregated L2 Bandwidth (GB/s)	736 [+32%]	542	556	329	We see a huge 32% increase in L2 cache bandwidth – almost 3x clock increase (the 11%) suggesting the L2 caches have been improved also. Ryzen2 has thus 2x the L2 bandwidth of i7 though with 2x more caches (8 vs 4).
	Aggregated L3 Bandwidth (GB/s)	339 [+19%]	398	284	238	The bandwidth of the L3 caches has also increased by 19% (2x clock increase) though we see the 6-core 2600 doing better (398 vs 339) likely due to less threads competing for the same L3 caches (12 vs 16). Ryzen2 L3 caches are not just 2x bigger than Intel but also 2x more bandwidth.
	Aggregated Memory (GB/s)	30.2 [+2%]	30.2	29.6	29.1	With the same memory clock, Ryzen2 does still manage a small 2% improvement – signalling memory controller improvements. We also see Ryzen’s memory at 2400Mt/s having better bandwidth than Intel at 2533.
We see big improvements on Ryzen2 for all caches L1D/L2/L3 of 20-30% – more than just raw clock increase (11%) – so AMD has indeed made improvements – which to be fair needed to be done. The memory controller is also a bit more efficient (2%) though it can run at higher clocks than tested (2400Mt/s) – hopefully fast DDR4 memory will become more affordable.

	Data In-Page Random Latency (ns)	66.4 (4-12-31) [-6%] [0][-5][-4]	66.4 (4-12-31)	70.5 (4-17-35)	20.4 (4-12-21)	In-page latency has decreased by a noticeable 6% on Ryzen2 (both 2700X and 2600) – we see 5 clocks reduction for L2 and 4 for L3 a welcome improvement. But still a way to go to catch Intel which has 1/3x (three times less) latency.
	Data Full Random Latency (ns)	80.9 (4-12-32) [-8%] [0][-5][-4]	79.4 (4-12-32)	87.6 (4-17-36)	63.9 (4-12-34)	Out-of-page latencies have also been reduced by 8% on Ryzen2 (same memory) and we see the same 5 and 4 clock reduction for L2 and L3 (on both 2700X and 2600 it’s no fluke). Again these are welcome but still have a way to go to catch Intel.
	Data Sequential Latency (ns)	3.4 (4-6-7) [-8%] [0][-1][0]	3.5 (4-6-7)	3.7 (4-7-7)	4.1 (4-12-13)	Ryzen’s prefetchers are working well with sequential access pattern latency and we see a 8% latency drop for Ryzen2.
Ryzen1’s issue was high memory latencies (in-page/full random) and Ryzen2 has reduced them all by 6-8%. While it is a good improvement, they are still pretty high compared to Intel’s thus more work needs to be done here.

	Code In-Page Random Latency (ns)	14.2 (4-9-24) [-9%] [0][0][0]	14.6 (4-9-24)	15.6 (4-9-24)	10.1 (2-10-21)	Code latencies were not a problem on Ryzen1 but we still see a welcome reduction of 9% on Ryzen2. (no clocks delta)
	Code Full Random Latency (ns)	88.6 (4-14-49) [-9%] [0][+1][+2]	89.3 (4-14-49)	97.4 (4-13-47)	70.7 (2-11-46)	Out-of-page latency also sees a 9% decrease on Ryzen2 but somewhat surprisingly a 1-2 clock increase.
	Code Sequential Latency (ns)	7.6 (4-12-20) [-8%] [0][+1][+1]	7.8 (4-12-20)	8.3 (4-11-19)	5.0 (2-4-9)	Ryzen’s prefetchers are working well with sequential access pattern latency and we see a 8% reduction on Ryzen2.
While code access latencies were not a problem on Ryzen1 and they also see a 8% improvement on Ryzen2 which is welcome. Note code L1i cache is 2x Intel’s (64kB vs 32).

	Memory Update Transactional (MTPS)	4.7 [+10%]	5	4.28	33.2 HLE	Ryzen2 is 10% faster than Ryzen1 but naturally without HLE support it cannot match the i7. But with Intel disabling HLE on all but top-end CPUs AMD does not have much to worry.
	Memory Update Record Only (MTPS)	4.6 [+11%]	4.75	4.16	23 HLE	With only record updates we still see an 11% increase.

Ryzen2 brings nice updates – good bandwidth increases to all caches L1D/L2/L3 and also well-needed latency reduction for data (and code) accesses. Yes, there is still work to be done to bring the latencies down further – but it may be just enough to beat Intel to 2nd place for a good while.

At the high-end, ThreadRipper2 will likely benefit most as it’s going against many-core SKL-X AVX512-enabled competitor which is a lot “tougher” than the normal SKL/KBL/CFL consumer versions.

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

As with original Ryzen, the cache and memory system performance is not the clean-sweep we’ve seen in CPU testing – but Ryzen2 does bring welcome improvements in bandwidth and latency – which hopefully will further improve with firmware/BIOS updates (AGESA firmware).

With the potential to use faster DDR4 memory – Ryzen2 can do far better than in this test (e.g. with 2933/3200MHz memory). Unfortunately at this time DDR4 – especially high-end fast versions – memory is hideously expensive which is a bit of a problem. You may be better off using less but fast(er) memory with Ryzen designs.

Ryzen2 is a great update that will not disappoint upgraders and is likely to increase AMD’s market share. AMD is here to stay!

AMD Ryzen2 2700X Review & Benchmarks – CPU 8-core Performance

By Adrian Silasi | 20th April 2018 - 12:00 pm |20th April 2018 Reviews

Comments Off

What is “Ryzen2” ZEN+?

While new chipsets (400 series) will also be introduced, the CPUs do work with existing AM4 300-series chipsets (e.g. X370, B350, A320) with a BIOS/firmware update which makes them great upgrades.

Here’s what AMD says it has done for Ryzen2:

Process technology optimisations (12nm vs 14nm) – lower power but higher frequencies
Improvements for cache & memory speed & latencies (we shall test that ourselves!)
Multi-core optimised boost (aka Turbo) algorithm – XFR2 – higher speeds

In this article we test CPU core performance; please see our other articles on:

AMD Ryzen2 Cache & Memory Performance

Hardware Specifications

We are comparing the top-of-the-range Ryzen2 (2700X, 2600) with previous generation (1700X) and competing architectures with a view to upgrading to a mid-range high performance design.

CPU Specifications	AMD Ryzen2 2700X Pinnacle Ridge	AMD Ryzen2 2600 Pinnacle Ridge	AMD Ryzen 1700X Summit Ridge	Intel i7-6700K SkyLake	Comments
Cores (CU) / Threads (SP)	8C / 16T	6C / 12T	8C / 16T	4C / 8T	Ryzen2 like its predecessor has the most cores and threads; it thus be down to IPC and clock speeds for performance improvements.
Speed (Min / Max / Turbo)	2.2-3.7-4.2GHz (22x-37x-42x) [+9% rated, +11% turbo]	1.55-3.4-3.9GHz (15x-34x-39x)	2.2-3.3-3.8GHz (22x-34x-38x)	0.8-4.0-4.2GHz (8x-40x-42x)	Ryzen2 base clock is 9% higher while Turbo/Boost/XFR is 11% higher; we thus expect at least about 10% improvement in CPU benchmarks.
Power (TDP)	105W	65W	95W	91W	Ryzen2 also increases TDP by 11% (105W vs 95) which may require a bit more cooling especially when overclocking.
L1D / L1I Caches	8x 32kB 8-way / 8x 64kB 8-way	6x 32kB 8-way / 6x 64kB 8-way	8x 32kB 8-way / 8x 64kB 8-way	4x 32kB 8-way / 4x 32kB 8-way	Ryzen2 data/instruction caches is unchanged; icache is still 2x as big as Intel’s.
L2 Caches	8x 512kB 8-way	6x 512kB 8-way	8x 512kB 8-way	4x 256kB 8-way	Ryzen2 L2 cache is unchanged but we’re told latencies have been improved. 4x bigger than Intel’s.
L3 Caches	2x 8MB 16-way	2x 8MB 16-way	2x 8MB 16-way	8MB 16-way	Ryzen2 L3 caches are also unchanged – but again lantencies are meant to have improved. With each CCX having 8MB even the 2600 has 2x as much cache as an i7.

Native Performance

We are testing native arithmetic, SIMD and cryptography performance using the highest performing instruction sets (AVX2, AVX, etc.). Ryzen supports all modern instruction sets including AVX2, FMA3 and even more like SHA HWA (supported by Intel’s Atom only) but has dropped all AMD’s variations like FMA4 and XOP likely due to low usage.

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

Environment: Windows 10 x64, latest AMD and Intel drivers. 2MB “large pages” were enabled and in use. Turbo / Boost was enabled on all configurations.

Native Benchmarks		Ryzen2 2700X 8C/16T Pinnacle Ridge	Ryzen2 2600 6C/12T Pinnacle Ridge	Ryzen 1700X 8C/16T Summit Ridge	i7-6700K 4C/8T Skylake	Comments

	Native Dhrystone Integer (GIPS)	323 [+8%]	236	298	194	Right off Ryzen2 is 8% faster than Ryzen1, let’s hope it does better. Even 2600 beats the i7 easily
	Native Dhrystone Long (GIPS)	337 [+12%]	238	301	194	With a 64-bit integer workload – we finally get into gear, Ryzen2 is 12% faster than its old brother.
	Native FP32 (Float) Whetstone (GFLOPS)	204 [+12%]	144	182	107	Even in this floating-point test, Ryzen2 is again 12% faster. All AMD CPUs beat the i7 into dust.
	Native FP64 (Double) Whetstone (GFLOPS)	172 [+11%]	123	155	89	With FP64 nothing much changes, Ryzen2 is still 11% faster.
From integer workloads in Dhyrstone to floating-point workloads in Whestone, Ryzen2 is about 10% faster than Ryzen1: this is exactly in line with the speed increase (9-11%) but if you were expecting more you may be a tiny bit disappointed.

	Native Integer (Int32) Multi-Media (Mpix/s)	619 [+16%]	428	535	510	In this vectorised AVX2 integer test Ryzen2 starts to pull ahead and is 16% faster than Ryzen1; perhaps some of the arch improvements benefit SIMD vectorised workloads.
	Native Long (Int64) Multi-Media (Mpix/s)	187 [+10%]	132	170	197	With a 64-bit AVX2 integer vectorised workload, Ryzen2 drops to just 10% but still in line with speed increase.
	Native Quad-Int (Int128) Multi-Media (Mpix/s)	5.83 [+7%]	4.12	5.47	3	This is a tough test using Long integers to emulate Int128 without SIMD; here Ryzen2 drops to just 7% faster than Ryzen1 but still a decent improvement.
	Native Float/FP32 Multi-Media (Mpix/s)	577 [+11%]	409	520	453	In this floating-point AVX/FMA vectorised test, Ryzen2 is the standard 11% faster than Ryzen1.
	Native Double/FP64 Multi-Media (Mpix/s)	332 [+11%]	236	299	267	Switching to FP64 SIMD code, again Ryzen2 is just the standard 11% faster than Ryzen1.
	Native Quad-Float/FP128 Multi-Media (Mpix/s)	15.6 [+15%]	11	13.7	11	In this heavy algorithm using FP64 to mantissa extend FP128 but not vectorised – Ryzen2 manages to pull ahead further and is 15% faster.
In vectorised AVX2/FMA code we see a similar story with 10% average improvement (7-15%). It seems the SIMD units are unchanged. In any case the i7 is left in the dust.

	Crypto AES-256 (GB/s)	14.1 [+1%]	14.1	13.9	14.7	With AES HWA support all CPUs are memory bandwidth bound; as we’re testing Ryzen2 running at the same memory speed/timings there is still a very small improvement of 1%. But its advantage is that the memory controller is rated for 2933Mt/s operation (vs. 2533) thus with faster memory it could run considerably faster.
	Crypto AES-128 (GB/s)	14.2 [+1%]	14.2	14	14.8	What we saw with AES-256 just repeats with AES-128; Ryzen2 is marginally faster but the improvement is there.
	Crypto SHA2-256 (GB/s)	18.4 [+12%]	13.2	16.5	5.9	With SHA HWA Ryzen2 similarly powers through hashing tests leaving Intel in the dust; SHA is still memory bound but with just one (1) buffer it has larger headroom. Thus Ryzen2 can use its speed advantage and be 12% faster – impressive.
	Crypto SHA1 (GB/s)	19.2 [+14%]	13.1	16.8	11.3	Ryzen also accelerates the soon-to-be-defunct SHA1 and here it is even faster – 14% faster than Ryzen1.
	Crypto SHA2-512 (GB/s)	3.75 [+12%]	2.66	3.34	4.4	SHA2-512 is not accelerated by SHA HWA (version 1) thus Ryzen has to use the same vectorised AVX2 code path – it still is 12% faster than Ryzen1 but still loses to the i7. Those SIMD units are tough to beat.
In memory bandwidth bound algorithms, Ryzen2 will have to be used with faster memory (up to 2933Mt/s officially) in order to significantly beat its older Ryzen1 brother. Otherwise there is only a tiny 1% improvement.

	Black-Scholes float/FP32 (MOPT/s)	260 [+11%]	184	235	126	In this non-vectorised test we see Ryzen2 is the standard 11% faster than Ryzen1.
	Black-Scholes double/FP64 (MOPT/s)	221 [+11%]	157	199	112	Switching to FP64 code, nothing changes, Ryzen2 is still 11% faster.
	Binomial float/FP32 (kOPT/s)	106 [+23%]	76	86	27	Binomial uses thread shared data thus stresses the cache & memory system; here the arch(itecture) improvements do show, Ryzen2 23% faster – 2x more than expected. Not to mention 3x (three times) faster than the i7.
	Binomial double/FP64 (kOPT/s)	60.8 [+28%]	43.2	47.5	29.2	With FP64 code Ryzen2 is now even faster – 28% faster than Ryzen1 not to mention 2x faster than the i7. Indeed it seems there improvements to the cache and memory system.
	Monte-Carlo float/FP32 (kOPT/s)	54.4 [+11%]	38.6	49.2	49.2	Monte-Carlo also uses thread shared data but read-only thus reducing modify pressure on the caches; Ryzen2 does not seem to be able to reproduce its previous gain and is just the standard 11% faster.
	Monte-Carlo double/FP64 (kOPT/s)	41.2 [+10%]	29.1	37.3	20.3	Switching to FP64 nothing much changes, Ryzen2 is 10% faster.
Ryzen1 dies very well in these algorithms, but Ryzen2 does even better – especially when thread-local data is involved managing 23-28% improvement. For financial workloads Intel does not seem to have a chance anymore – Ryzen is impossible to beat.

	SGEMM (GFLOPS) float/FP32	275 [+10%]	238	250	267	In this tough vectorised AVX2/FMA algorithm Ryzen2 is still “just” the 10% faster than older Ryzen1 – but it finally manages to beat the i7.
	DGEMM (GFLOPS) double/FP64	113 [+4%]	103	109	116	With FP64 vectorised code, Ryzen2 only manages to be 4% faster. It seems the memory is holding it back thus faster memory would allow it to do much better.
	SFFT (GFLOPS) float/FP32	8.56 [+4%]	7.36	8.2	19.4	FFT is also heavily vectorised (x4 AVX/FMA) but stresses the memory sub-system more; Ryzen2 is just 4% faster again and is still 1/2x the speed of the i7. Again it seems faster memory would help.
	DFFT (GFLOPS) double/FP64	7.42 [+1%]	6.87	7.32	9.19	With FP64 code, Ryzen2’s improvement reduces to just 1% over Ryzen1 and again slower than the i7.
	SNBODY (GFLOPS) float/FP32	279 [+12%]	197	249	269	N-Body simulation is vectorised but many memory accesses to shared data and Ryzen2 gets back to 12% improvement over Ryzen1. This allows it to finally overtake the i7.
	DNBODY (GFLOPS) double/FP64	114 [+13%]	80	101	79	With FP64 code nothing much changes, Ryzen2 is still 13% faster.
With highly vectorised SIMD code Ryzen2 still improves by the standard 10-12% but in memory-heavy code it needs to run at higher memory speed to significantly overtake Ryzen1. But it allows it to beat the i7 in more algorithms.

	Blur (3×3) Filter (MPix/s)	1290 [+11%]	913	1160	1170	In this vectorised integer AVX2 workload Ryzen2 is 11% faster allowing it to soundly beat the i7.
	Sharpen (5×5) Filter (MPix/s)	551 [+11%]	391	497	435	Same algorithm but more shared data does not change things for Ryzen2. Only the i7 falls behind.
	Motion-Blur (7×7) Filter (MPix/s)	307 [+11%]	218	276	233	Again same algorithm but even more data shared does not change anything, but now the i7 is so far behind Ryzen2 is 50% faster. Incredible.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	461 [+11%]	326	415	384	Different algorithm but still AVX2 vectorised workload still changes nothing – Ryzen2 is 11% faster.
	Noise Removal (5×5) Median Filter (MPix/s)	69.7 [+12%]	49.7	62	38	Still AVX2 vectorised code and still nothing changes; the i7 falls even further behind with Ryzen2 2x (two times) as fast.
	Oil Painting Quantise Filter (MPix/s)	24.7 [+11%]	17.5	22.3	20	Again we see Ryzen2 11% faster than the older Ryzen1 and pulling away from the i7.
	Diffusion Randomise (XorShift) Filter (MPix/s)	1460 [+8%]	1130	1350	1670	Here Ryzen2 is just 8% faster than Ryzen1 but strangely it’s not enough to beat the i7. Those SIMD units are way fast.
	Marbling Perlin Noise 2D Filter (MPix/s)	243 [+11%]	172	219	268	In this final test, Ryzen2 returns to being 11% faster and again strangely not enough to beat the i7.

With all the modern instruction sets supported (AVX2, FMA, AES and SHA HWA) Ryzen2 does extremely well in all workloads – but it generally improves only by the 11% as per clock speed increase, except in some cases which seem to show improvements in the cache and memory system (which we have not tested yet).

Software VM (.Net/Java) Performance

We are testing arithmetic and vectorised performance of software virtual machines (SVM), i.e. Java and .Net. With operating systems – like Windows 10 – favouring SVM applications over “legacy” native, the performance of .Net CLR (and Java JVM) has become far more important.

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

Environment: Windows 10 x64, latest drivers. .Net 4.7.x (RyuJit), Java 1.9.x. Turbo / Boost was enabled on all configurations.

VM Benchmarks		Ryzen2 2700X 8C/16T Pinnacle Ridge	Ryzen2 2600 6C/12T Pinnacle Ridge	Ryzen 1700X 8C/16T Summit Ridge	i7-6700K 4C/8T Skylake	Comments

	.Net Dhrystone Integer (GIPS)	63.2 [+8%]	30	58.6	26	.Net CLR integer performance starts off OK with Ryzen2 just 8% faster than Ryzen1 but now almost 3x (three times) faster than i7.
	.Net Dhrystone Long (GIPS)	49.6 [+20%]	33.6	41.2	27	Ryzen seems to favour 64-bit integer workloads, with Ryzen2 20% faster a lot higher than expected.
	.Net Whetstone float/FP32 (GFLOPS)	104 [+15%]	71.2	90.5	54.3	Floating-Point CLR performance was pretty spectacular with Ryzen already, but Ryzen2 is 15% than Ryzen1 still.
	.Net Whetstone double/FP64 (GFLOPS)	122 [+20%]	88.2	102	65.6	FP64 performance is also great (CLR seems to promote FP32 to FP64 anyway) with Ryzen2 even faster by 20%.
Ryzen1’s performance in .Net was pretty incredible but Ryzen2 is even faster – even faster than expected by mere clock speed increase. There is only one game in town now for .Net applications.

	.Net Integer Vectorised/Multi-Media (MPix/s)	106 [+9%]	74	97	54	Just as we saw with Dhrystone, this integer workload sees a 9% improvement for Ryzen2 which makes it 2x faster than the i7.
	.Net Long Vectorised/Multi-Media (MPix/s)	111 [+8%]	78	103	57	With 64-bit integer workload we see a similar story – Ryzen2 is 8% faster and again 2x faster than the i7.
	.Net Float/FP32 Vectorised/Multi-Media (MPix/s)	387 [+11%]	278	348	240	Here we make use of RyuJit’s support for SIMD vectors thus running AVX/FMA code; Ryzen2 is 11% faster but still almost 2x faster than i7 despite its fast SIMD units
	.Net Double/FP64 Vectorised/Multi-Media (MPix/s)	217 [+12%]	153	194	48.6	Switching to FP64 SIMD vector code – still running AVX/FMA – Ryzen2 is still 12% faster. i7 is truly left in the dust 1/4x the speed.
Ryzen2 is the usual 9-12% faster than Ryzen1 here but it means that even RyuJit’s SIMD support cannot save Intel’s i7 – it would take 2x as many cores (not 50%) to beat Ryzen2.

	Java Dhrystone Integer (GIPS)	574 [+12%]	399	514		We start JVM integer performance with the usual 12% gain over Ryzen1.
	Java Dhrystone Long (GIPS)	559 [+12%]	392	500		Nothing much changes with 64-bit integer workload, we have Ryzen2 12% faster.
	Java Whetstone float/FP32 (GFLOPS)	138 [+13%]	99	122		With a floating-point workload Ryzen2 performance improvement is 13%.
	Java Whetstone double/FP64 (GFLOPS)	137 [+7%]	97	128		With FP64 workload Ryzen2 is just 7% faster but still welcome
Java performance improves by the expected amount 7-13% on Ryzen2 and allows it to completely dominate the i7.

	Java Integer Vectorised/Multi-Media (MPix/s)	108 [+15%]	76	94		Oracle’s JVM does not yet support native vector to SIMD translation like .Net’s CLR but here Ryzen2 manages a 15% lead over Ryzen1.
	Java Long Vectorised/Multi-Media (MPix/s)	114 [+24%]	73	92		With 64-bit vectorised workload Ryzen2 (similar to .Net) increases its lead by 24%.
	Java Float/FP32 Vectorised/Multi-Media (MPix/s)	99 [+14%]	69	87		Switching to floating-point we return to the usual 14% speed improvement.
	Java Double/FP64 Vectorised/Multi-Media (MPix/s)	93 [+1%]	64	92		With FP64 workload Ryzen2’s lead somewhat unexplicably drops to 1%.
Java’s lack of vectorised primitives to allow the JVM to use SIMD instruction sets (aka SSE2, AVX/FMA) gives Ryzen2 free reign to dominate all the tests, be they integer or floating-point. It is pretty incredible that neither Intel CPU can come close to its performance.

Ryzen1 dominated the .Net and Java benchmarks – but now Ryzen2 extends that dominance out-of-reach. It would take a very much improved run-time or Intel CPU to get anywhere close. For .Net and Java code, Ryzen is the CPU to get!

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

Ryzen2 is a worthy update but its speed increase is generally due to its faster clock speed – similar to Intel’s SkyLake > KabyLake (gen 6 to gen 7) transition. But coming at the same price, a “free” performance increase of 10% or so is obviously not to be ignored. Let’s not forget that Ryzen2 can still use all the existing series 300 mainboards – subject to BIOS update.

The process shrink and power optimisations does allow Ryzen2 to run at lower voltages and consume less power – even though TDP has increased at least “on paper”.

Some algorithms do seem to show that the cache and memory system has been improved – but Ryzen2’s advantage is that it can (much) faster memory. Unfortunately at this time DDR4 memory, especially fast versions, are very expensive. Here Intel does (still) have an advantage in that fast DDR4 memory is not required except for bandwidth bound algorithms.

One advantage is that by now operating systems (and applications) have been updated to deal with its dual-CCX design that used to be so much trouble when we benchmarked Ryzen1 initially. With AMD increasing its market share no high-performance application can afford to ignore AMD CPUs.

We (just) cannot wait to see the new improvements in future AMD designs and especially the ThreadRipper2 update!

Sandra Platinum (2017) SP4 – Updates for ‘Meltdown’ and ‘Spectre’

By Adrian Silasi | 11th January 2018 - 11:15 am |29th January 2018 Releases, Updates

Comments Off

NB: SP4 has been refreshed to version 24.61 vs. the original 24.55 a day later.

We are pleased to release SP4 (Service Pack 4 – version 24.61) update for Sandra Platinum (2017) with the following updates:

Sandra Platinum (2017) Press Release

Reporting of Operating System (Windows) speculation control settings for the recently discovered vulnerabilities:
- BTI (Branch Target Injection) aka ‘Spectre’
- RDCL (Rogue Data Cache Load) aka ‘Meltdown’
Reporting of latest CPU microcode update availability
- Hardware mitigation for BTI/’Spectre’
Reporting of CPU features for branch control
- Hardware enumeration and control for speculation and predictors
  - Indirect branch restricted speculation (IBRS) and Indirect branch predictor barrier (IBPB)
  - Single thread indirect branch predictors (STIBP)
  - Architecture Capabilities (affected by IB or not)
Reporting of CPU support for Context ID / Indirect CID
- Hardware acceleration for context switching thus mitigating performance loss when KVA (Kernel’s Virtual Address) Shadowing is enabled.

Windows speculation control settings reporting:

Recommended Settings (Windows and CPU updated)
	Operating System Mitigation: Enabled (Windows updated) BTI Mitigation: Enabled, CPU indirect branch-control enumeration support (microcode updated) RDCL Mitigation: KVA Shadowing enabled, Windows/CPU context-ID support
OK Settings (Windows updated, but CPU not updated)
	Operating System Mitigation: Enabled (Windows updated) BTI Mitigation: Not enabled, no CPU support (e.g. firmware not updated – check for BIOS update) RDCL Mitigation: KVA Shadowing enabled, Windows/CPU context-ID support
OK Settings (Windows updated, but CPU not updated, no CID)
	Operating System Mitigation: Enabled (Windows updated) BTI Mitigation: Not enabled, no CPU support (e.g. firmware not updated – check for BIOS update) RDCL Mitigation: KVA Shadowing not enabled, no context-ID support (either CPU or Windows obsolete)
Not Recommended (Windows not updated)
	Operating System Mitigation: Not enabled, Windows has not been updated – install the OS update)

Processor features and microcode updates:

CPU microcode not latest
	CPU has not been updated with the latest microcode update: check for an updated BIOS/firmware from the OEM/computer manufacturer.
CPU microcode w/speculation support
	CPU supports IBRS/PB (indirect branch restricted speculation/predictor barrier) ennumeration as well as STIBP (single thread indirect branch predictors).
CPU supports CID or InvPCID
	CPU supports either CID (Context ID) or InvPCID (Process Context ID) for faster context switch – thus mitigating performance loss.

Microcode Updates for Intel processors (non-exhaustive list):

Generation	Old Microcode	Updated Microcode
IvyBridge 3rd Gen (IVB C0)	28	2a
Haswell 4th Gen (HSW-U/Y Cx/Dx)	20	21
Haswell-X 4th Gen (HSX C0)	3a	3b
Haswell-EX 4th Gen (HSW-EX E0)	0f	10
Broadwell 5th Gen (BDW-U/Y E/F)	25	28
Crystalwell 5th Gen (CRW CX)	17	18
Broadwell 5th Gen (BDW-H E/G)	17	1b
Broadwell 5th Gen (BDX-DE V0/V1)	0f	14
Broadwell 5th Gen (BDX-DE V2)	0d	11
SkyLake 6th Gen (SKL-U/Y D0/R0)	ba	c2
SkyLake-X 6th Gen (SKX H0)	35	3c
KabyLake 7th Gen (KBL-U/Y H0)	62	80
KabyLake 7th Gen (KBL Y0 / CFL D0)	70	80
KabyLake 7th Gen (KBL-H/S B0)	5e	80
CofeeLake 8th Gen (CFL U0/B0)	70	80

Note: Due to some unexplained crashes, resume from sleep issues, etc. the current (January 2018) microcode updates have been suspended by Intel. They are scheduled to be resumed in March 2018.

In preliminary benchmarking, we have observed no or very minor performance impact to CPU, GPGPU and memory scores; disk performance for small transfers is impacted when KVA shadowing is enabled.

Commercial version customers can download the free updates from their software distributor; Lite users please download from your favourite download site.

Download Sandra Lite

Sandra Platinum (2017) SP3 – Updates and Fixes

By Adrian Silasi | 10th November 2017 - 12:41 pm |11th January 2018 Releases, Updates

Comments Off

We are pleased to release SP3 (Service Pack 3 – version 24.50) update for Sandra Platinum (2017) with the following updates:

Sandra Platinum (2017) Press Release

Fix start-up crash with non-AVX older systems (both x86 and x64)
Tools update allowing further optimisations to AVX512 benchmarks
Other hardware information fixes depending on APIC ID configuration
- AMD Ryzen 5 – L3 cache detection 4x not 2x
- AMD Ryzen 3 – detected as SMP

Commercial version customers can download the free updates from their software distributor; Lite users please download from your favourite download site.

Download Sandra Lite

Sandra Platinum (2017) SP2 – NUMA for ThreadRipper, AVX512 for SKL-X

By Adrian Silasi | 12th September 2017 - 1:42 am |12th September 2017 Releases, Updates

Comments Off

We are pleased to release SP2 (Service Pack 2 – version 24.41) update for Sandra Platinum (2017) with the following updates:

Sandra Platinum (2017) Press Release

Tools update allowing further ports of benchmarks to AVX512, e.g.:
- CPU Multi-Media: 128-bit (octa) floating-point benchmark
- CPU Scientific: GEMM, FFT N-Body (single and double floating-point)
- CPU Image Processing: All filters vectorised and ported to AVX512 (Blur/Sharpen/Motion-Blur, Edge/Noise/Oil, Diffusion/Marble)

Algorithm harness update allowing NUMA multi-block performance improvement, e.g.:
- CPU Multi-Media: all algorithms. both integer and floating-point.
- CPU Cryptography: all algorithms, both crypto and hashing.
- CPU Scientific: all algorithms (but especially (F/D)GEMM)
- CPU Financial: Monte-Carlo (N/A others).
- CPU Image Processing: All filters (Blur/Sharpen/Motion-Blur, Edge/Noise/Oil, Diffusion/Marble).

New articles showing the improvement that AVX512 and NUMA bring:

Commercial version customers can download the free updates from their software distributor; Lite users please download from your favourite download site.

Download Sandra Lite

AVX512 performance improvement for SKL-X in Sandra SP2

By Adrian Silasi | 12th September 2017 - 1:25 am |12th September 2017 Reviews

Comments Off

What is AVX512?

AVX512 (Advanced Vector eXtensions) is the 512-bit SIMD instruction set that follows from previous 256-bit AVX2/FMA3/AVX instruction set. Originally introduced by Intel with its “Xeon Phi” GPGPU accelerators – albeit in a somewhat different form – it has finally made it to its CPU lines with Skylake-X (SKL-X/EX/EP) – for now HEDT (i9) and Server (Xeon) – and hopefully to mainstream at some point.

Note it is rumoured the current Skylake (SKL)/Kabylake (KBL) are also supposed to support it based on core changes (widening of ports to 512-bit, unit changes, etc.) – nevertheless no public way of engaging them has been found.

AVX512 consists of multiple extensions and not all CPUs (or GPGPUs) may implement them all:

AVX512F – Foundation – most floating-point single/double instructions widened to 512-bit. [supported by SKL-X, Phi]
AVX512DQ – Double-Word & Quad-Word – most 32 and 64-bit integer instructions widened to 512-bit [supported by SKL-X]
AVX512BW – Byte & Word – most 8-bit and 16-bit integer instructions widened to 512-bit [supported by SKL-X]
AVX512VL – Vector Length eXtensions – most AVX512 instructions on previous 256-bit and 128-bit SIMD registers [supported by SKL-X]
AVX512CD – Conflict Detection – loop vectorisation through predication [not supported by SKL-X but Phi]
AVX512ER – Exponential & Reciprocal – transcedental operations [not supported by SKL-X but Phi]
more sets will be introduced in future versions

As with anything, simply doubling register width does not automagically increase performance by 2x as dependencies, memory load/store latencies and even data characteristics limit performance gains – some of which may require future arch or even tools to realise their true potential.

In this article we test AVX512 core performance; please see our other articles on:

Native SIMD Performance

We are testing native SIMD performance using various instruction sets: AVX512, AVX2/FMA3, AVX to determine the gains the new instruction sets bring.

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		SKL-X AVX512	SKL-X AVX2/FMA3	Comments

	Native Integer (Int32) Multi-Media (Mpix/s)	1460 [+23%]	1180	For integer workloads we manage only 23% improvement, not quite the 100% we were hoping but still decent.
	Native Long (Int64) Multi-Media (Mpix/s)	519 [+19%]	435	With a 64-bit integer workload the improvement reduces to 19%.
	Native Quad-Int (Int128) Multi-Media (Mpix/s)	7.72 [=]	7.62	No SIMD here
	Native Float/FP32 Multi-Media (Mpix/s)	1800 [+80%]	1000	In this floating-point test we finally see the power of AVX512 – it is 80% faster than AVX2/FMA3 – a huge improvement.
	Native Double/FP64 Multi-Media (Mpix/s)	1150 [+85%]	622	Switching to FP64 increases the improvement to 85% a huge gain.
	Native Quad-Float/FP128 Multi-Media (Mpix/s)	36 [+50%]	24	In this heavy algorithm using FP64 to mantissa extend FP128 we see only 50% improvement still nothing to ignore.
AVX512 cannot bring 100% improvement but does manage up to 85% improvement – a no mean feat! While integer workload is only 20-25% it is still decent. Heavy compute algorithms will greatly benefit from AVX512.

	Crypto SHA2-256 (GB/s)	26 [+78%]	14.6	With no data dependency – we get good scaling of almost 80% even with this integer workload.
	Crypto SHA1 (GB/s)	39.8 [+51%]	26.4	Here we see only 50% improvement likely due to lack of (more) memory bandwidth – it likely would scale higher.
	Crypto SHA2-512 (GB/s)	21.2 [+94%]	10.9	With 64-bit integer workload we see almost perfect scaling of 94%.
As we work on different buffers and have no dependencies, AVX512 brings up to 94% performance improvement – only limited by memory bandwidth with even 4 channel DDR4 @ 3200Mt/s not enough for 10C/20T CPU. AVX512 is absolutely worth it to drive the system to the limit.

	SGEMM (GFLOPS) float/FP32	558 [-7%]	605	Unfortunately the current compiler does not seem to help.
	DGEMM (GFLOPS) double/FP64	235 [+2%]	229	Changing to FP64 at least allows AVX512 to with by a meagre 2%.
	SFFT (GFLOPS) float/FP32	35.3 [=]	35.3	Again the compiler does not seem to help here.
	DFFT (GFLOPS) double/FP64	19.9 [-2%]	20.2	With FP64 nothing much happens.
	SNBODY (GFLOPS) float/FP32	585 [-1%]	591	No help from the compiler here either.
	DNBODY (GFLOPS) double/FP64	175 [-1%]	178	With FP64 workload nothing much changes.
With complex SIMD code – not written in assembler the compiler has some ways to go and performance is not great. But at least the performance is not worse.

	Blur (3×3) Filter (MPix/s)	3830 [+60%]	2390	We start well here with AVX512 60% faster with float FP32 workload.
	Sharpen (5×5) Filter (MPix/s)	1700 [+70%]	1000	Same algorithm but more shared data improves by 70%.
	Motion-Blur (7×7) Filter (MPix/s)	885 [+56%]	566	Again same algorithm but even more data shared now brings the improvement down to 56%.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	1290 [+56%]	826	Using two buffers does not change much still 56% improvement.
	Noise Removal (5×5) Median Filter (MPix/s)	136 [+59%]	85	Different algorithm keeps the AVX512 advantage the same at about 60%.
	Oil Painting Quantise Filter (MPix/s)	65.6 [+31.7%]	49.8	Using the new scatter/gather in AVX512 still brings 30% better performance.
	Diffusion Randomise (XorShift) Filter (MPix/s)	3920 [+3%]	3800	Here we have a 64-bit integer workload algorithm with many gathers with AVX512 likely memory latency bound thus almost no improvement.
	Marbling Perlin Noise 2D Filter (MPix/s)	770 [+2%]	755	Again loads of gathers does not allow AVX512 to shine but still decent performance
As with other SIMD tests, AVX512 brings between 60-70% performance increase, very impressive. However in algorithms that involve heavy memory access (scatter/gather) we are limited by memory latency and thus we see almost no delta but at least it is not slower.

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

It is clear that even for a 1st-generation CPU with AVX512 support, SKL-X greatly benefits from the new instruction set – with anything between 50-95% performance improvement. However compiler/tools are raw (VC++ 2017 only added support in the recent 15.3 version) and performance sketchy where hand-crafted assembler is not used. But these will get better and future CPU generations (CFL-X, etc.) will likely improve performance.

Also let’s remember that some SKUs have 2x FMA (aka 512-bit) (and other instructions) licence – while most SKUs have only 1x FMA (aka 256-bit); the former SKUs likely benefit even more from AVX512 and it is something Intel may be more generous in enabling in future generations.

In algorithms heavily dependent on memory bandwidth or latency AVX512 cannot work miracles, but at least will extract the maximum possible compute performance from the CPU. SKUs with lower number of cores (8, 6, 4, etc.) likely to gain even more from AVX512.

In addition let’s not forget the “Phi” accelerators – that also support AVX512 – thus porting code will allow great performance on many-core (MIC) architecture too.

NUMA performance improvement for ThreadRipper in Sandra SP2

By Adrian Silasi | 11th September 2017 - 1:54 pm |16th March 2018 Reviews

Comments Off

What is NUMA?

Modern CPUs have had a built-in memory controller for many years now, starting with the K8/Opteron, in order to higher better bandwidth and lower latency. As a result in SMP systems each CPU has their own memory controller and its own system memory that it can access at high speed – while to access other memory it must send requests to the other CPUs. NUMA is a way of describing such systems and allow the operating system and applications to allocate memory on the node they are running on for best performance.

As ThreadRipper is really two (2) Ryzen dies connected internally through InfinityFabric – it is basically a 2-CPU SMP system and thus a 2-node NUMA system.

While it is possible to configure it in UMA (Uniform Memory Access mode) where all memory appears to be unified and interleaved between nodes, for best performance the NUMA mode is recommended when the operating system and applications support it.

While Sandra has always supported NUMA in the standard benchmarks – some of the new benchmarks have not been updated with NUMA support especially since multi-core systems have pretty much killed SMP systems on the desktop – with only expensive severs left to bring SMP / NUMA support.

Note that all the NUMA improvements here would apply to competitor NUMA (e.g. Intel) systems, thus it is not just for ThreadRipper – with EPYC systems likely showing a far higher improvement too.

In this article we test NUMA performance; please see our other articles on:

Native Performance

We are testing native performance using various instruction sets: AVX512, AVX2/FMA3, AVX to determine the gains the new instruction sets bring.

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		NUMA 2-nodes	UMA single-node	Comments

	Native Integer (Int32) Multi-Media (Mpix/s)	965 [+2.8%]	938	The ‘lightest’ workload should show some NUMA overhead but we can only manage 3% here.
	Native Long (Int64) Multi-Media (Mpix/s)	312 [+2.3%]	305	With a 64-bit integer workload the improvement drops to 2%.
	Native Quad-Int (Int128) Multi-Media (Mpix/s)	10.9 [=]	10.9	Emulating int128 means far increased compute workload with NUMA overhead insignificant.
	Native Float/FP32 Multi-Media (Mpix/s)	997 [+1.2%]	985	Again no measured improvement here.
	Native Double/FP64 Multi-Media (Mpix/s)	562 [+1%]	556	Again no measured improvement here.
	Native Quad-Float/FP128 Multi-Media (Mpix/s)	27 [=]	26.85	In this heavy algorithm using FP64 to mantissa extend FP128 we see no improvement.
Fractals are compute intensive with few memory accesses – mainly to store results – thus we see a maximum of 3% improvement with NUMA support with the rest insignificant. However, this is a simple 2-node system – bigger 4/8-node systems would likely show bigger gains.

	Crypto AES256 (GB/s)	27.1 [+139%]	11.3	AES hardware accelerated is memory bandwidth bound thus NUMA support matters; even in this 2-node system we see a over 2x improvement of 139%!
	Crypto AES128 (GB/s)	27.4 [+142%]	11.3	Similar to above we see a massive 142% improvement by allocating memory on the right NUMA node.
	Crypto SHA2-256 (GB/s)	32.3 [+50%]	21.4	SHA is also hardware accelerated but operates on a single input buffer (with a small output hash value buffer) and here out improvement drops to 50%, still very much significant.
	Crypto SHA1 (GB/s)	34.2 [+56%]	21.8	Similar to above we see an even larger 56% improvement for supporting NUMA.
	Crypto SHA2-512 (GB/s)	6.36 [=]	6.35	SHA2-256 is not hardware accelerated (AVX2 used) but heavy compute bound thus our improvement drops to nothing.
Finally in streaming algorithms we see just how much NUMA support matters: even on this 2-note system we see over 2x improvement of 140% when working with 2 buffers (in/out). When using a single buffer our improvement drops to 50% but still very much significant. TR needs NUMA suppport to shine.

	SGEMM (GFLOPS) float/FP32	395 [114%]	184	As with crypto, GEMM benefits greatly from NUMA support with an incredible 114% improvement by allocating the (3) buffers on the right NUMA nodes.
	DGEMM (GFLOPS) double/FP64	183 [131%]	79	Changing to FP64 brings an even more incredible 131%.
	SFFT (GFLOPS) float/FP32	11.6 [86%]	6.25	FFT also shows big gains from NUMA support with 86% improvement just by allocating the buffers (2+1 const) on the right nodes.
	DFFT (GFLOPS) double/FP64	10.6 [112%]	5	With FP64 again increases
	SNBODY (GFLOPS) float/FP32	479 [=]	483	Strangely N-Body does not benefit much from NUMA support with no appreciable improvement.
	DNBODY (GFLOPS) double/FP64	189 [=]	191	With FP64 workload nothing much changes.
As with crypto, buffer heavy algorithms (GEMM, FFT, N-Body) greatly benefit from NUMA support with performance doubling (86-131%) by allocating on the right NUMA nodes; in effect TR needs NUMA in order to perform better than a standard Ryzen!

	Blur (3×3) Filter (MPix/s)	2090 [+71%]	1220	Least compute brings highest benefit from NUMA support – here it is 71%.
	Sharpen (5×5) Filter (MPix/s)	886 [=]	890	Same algorithm but more compute brings the improvement to nothing.
	Motion-Blur (7×7) Filter (MPix/s)	494 [=]	495	Again same algorithm but even more compute again no benefit.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	720 [=]	719	Using two buffers does not seem to show any benefit either.
	Noise Removal (5×5) Median Filter (MPix/s)	116 [=]	117	Different algorithm keeps with more compute means no benefit either.
	Oil Painting Quantise Filter (MPix/s)	40.3 [=]	40.7	Using the new scatter/gather in AVX2 does not help matters even with NUMA support.
	Diffusion Randomise (XorShift) Filter (MPix/s)	1880 [+90%]	982	Here we have a 64-bit integer workload algorithm with many gathers not compute heavy brings 90% improvement.
	Marbling Perlin Noise 2D Filter (MPix/s)	397 [=]	396	Heavy compute brings down the improvement to nothing.
As with other SIMD tests, low compute algorithms see 70-90% improvement from NUMA support; heavy compute algorithms bring the improvement down to zero. It all depends whether the overhead of accessing other nodes can be masked by compute; in effect TR seems to perform pretty well.

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

It is clear that ThreadRipper needs NUMA support in applications – just like any other SMP system today to shine: we see over 2x improvement in bandwidth-heavy algorithms. However, in compute-heavy algorithms TR is able to mask the overhead pretty well – with NUMA bringing almost no improvement. For non NUMA supporting software the UMA mode should be employed.

Let’s remember we are only testing a 2-node system, here, a 4+ node system is likely to show higher improvements and with EPYC systems stating at 1-socket 4-node we can potentially have common 4-socket 16-node systems that absolutely need NUMA for best performance. We look forward to testing such a system as soon as possible 😉

AMD Threadripper Review & Benchmarks – CPU 16-core Performance

By Adrian Silasi | 11th August 2017 - 8:26 pm |12th September 2017 Reviews

3 Comments

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.

In this article we test CPU core performance; please see our other articles on:

Hardware Specifications

We are comparing the top-of-the-range Threadripper (1950X) with HEDT competition (Intel SKL-X) as well as normal desktop solutions (Ryzen, Skylake) which also serves to compare HEDT with the “normal” desktop solution.

CPU Specifications	AMD Threadripper 1950X	Intel 9700X (SKL-X)	AMD Ryzen 1700X	Intel 6700K (SKL)	Comments
Cores (CU) / Threads (SP)	16C / 32T	10C / 20T	8C / 16T	4C / 8T	Just as Ryzen, TR has the most cores though Intel has just announced new SKL-X with more cores.
Speed (Min / Max / Turbo)	2.2-3.4-3.9GHz (22x-34x-39x) [note ES sample]	1.2-3.3-4.3GHz (12x-33x-43x)	2.2-3.4-3.9GHz (22x-34x-39x) [note ES sample]	0.8-4.0-4.2GHz (8x-40x-42x)	SKL has the highest base clock but all CPUs have similar Turbo clocks
Power (TDP)	180W	150W	95W	91W	TR has higher TDP than SKL-X just like Ryzen so may need a beefier cooling system
L1D / L1I Caches	16x 32kB 8-way / 16x 64kB 8-way	10x 32kB 8-way / 10x 32kB 8-way	8x 32kB 8-way / 8x 64kB 8-way	4x 32kB 8-way / 4x 32kB 8-way	TR and Ryzen’s instruction caches are 2x data (and SKL/X) but all caches are 8-way.
L2 Caches	16x 512kB 8-way (8MB total)	20x 1MB 16-way (20MB total)	8x 512kB 8-way (4MB total)	4x 256kB 8-way (1MB total)	SKL-X has really pushed the boat out with a 1MB L2 cache that dwarfs all other CPUs.
L3 Caches	4x 8MB 16-way (32MB total)	13.75MB 11-way	2x 8MB 16-way (16MB total)	8MB 16-way	TR actually has 2 sets of 2 L3 caches rather than a combined L3 cache like SKL/X.
NUMA Nodes	2x 16GB each	no, unified 32GB	no, unified 16GB	no, unified 16GB	Only TR has 2 NUMA nodes

Thread Scheduling and Windows

Threadripper’s topology (4 cores in each CCX, with 2 CCX in one node and 2 nodes) makes things even more compilcated for operating system (Windows) schedulers. Effectively we have a 2-tier NUMA SMP system where CCXes are level 1 and nodes are level 2 thus the scheduling of threads matters a lot.

Also keep in mind this is a NUMA system (2 nodes) with each node having its own memory; while for compatibility AMD recommends (and the BIOS defaults) to “UMA” (Unified) “interleaving across nodes” – for best performance the non-interleaving mode (or “interleaving across CCX”) should be used.

What all this means is that you likely need a reasonably new operating system – thus Windows 10 / Server 2016 – with a kernel that has been updated to support Ryzen/TR as Microsoft is not likely to care about old verions.

Native Performance

We are testing native arithmetic, SIMD and cryptography performance using the highest performing instruction sets (AVX2, AVX, etc.). Ryzen/TR support all modern instruction sets including AVX2, FMA3 and even more like SHA HWA (supported by Intel’s Atom only) but has dropped all AMD’s variations like FMA4 and XOP likely due to low usage.

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

	Native Dhrystone Integer (GIPS)	447 [-2%]	454	226	186	TR can keep up with SKL-X and scales well vs. Ryzen.
	Native Dhrystone Long (GIPS)	459 [+1%]	456	236	184	An Int64 load does not change results.
	Native FP32 (Float) Whetstone (GFLOPS)	352 [+30%]	269	184	107	Finally TR soundly beats SKL-X by 30% and scales well vs. Ryzen.
	Native FP64 (Double) Whetstone (GFLOPS)	295 [+32%]	223	154	89	With a FP64 work-load the lead inceases slightly.
Unlike Ryzen which soundly dominated Skylake (albeit with 2x more cores, 8 vs. 4), Threadripper does not have the same advantage (16 vs. 10) thus it can only beat SKL-X in floating-point work-loads where it is 30% faster, still a good result.

	Native Integer (Int32) Multi-Media (Mpix/s)	918 [-22%]	1180	535	527	With AVX2/FMA SKL-X is just too strong, with TR 22% slower.
	Native Long (Int64) Multi-Media (Mpix/s)	307 [-29%]	435	161	191	With Int64 AVX2 TR is almost 20% slower than SKL-X.
	Native Quad-Int (Int128) Multi-Media (Mpix/s)	7 [+30%]	5.4	3.6	2	This is a tough test using Long integers to emulate Int128 without SIMD and here TR manages to be 30 faster!
	Native Float/FP32 Multi-Media (Mpix/s)	996 [=]	1000	518	466	In this floating-point AVX2/FMA vectorised test TR manages to tie with SKL-X.
	Native Double/FP64 Multi-Media (Mpix/s)	559 [-10%]	622	299	273	Switching to FP64 SIMD code, TR is now 10% slower than SKL-X.
	Native Quad-Float/FP128 Multi-Media (Mpix/s)	27 [+12%]	24	13.7	10.7	In this heavy algorithm using FP64 to mantissa extend FP128 but not vectorised – TR manages a 12% win.
In vectorised AVX2/FMA code we see TR lose in most tests, or tie in one – and only shine in emulation tests not using SIMD instruction sets. Intel’s SIMD units – even without AVX512 that SKL-X brings – are just too strong for TR just as we saw Ryzen struggle against normal Skylake.

	Crypto AES-256 (GB/s)	27.1 [-21%]	34.4	14	15	All CPUs support AES HWA – but TR/Ryzen memory is just 2400Mt/s vs 3200 that SKL-X enjoys (+33%) thus this is a good result; TR seems to use its channels pretty effectively.
	Crypto AES-128 (GB/s)	27.4 [-18%]	33.5	14	15	Similar to what we saw above TR is just 18% slower which is a good result; unfortunately we cannot get the memory over 2400Mt/s.
	Crypto SHA2-256 (GB/s)	32.2 [+2.2x]	14.6	17.1	5.9	Like Ryzen, TR’s secret weapon is SHA HWA which allows it to soundly beat SKL-X over 2.2x faster!
	Crypto SHA1 (GB/s)	34.2 [+30%]	26.4	17.7	11.3	Even with SHA HWA, the multi-buffer AVX2 implementation allows SKL-X to beat TR by 16% but it still scores well.
	Crypto SHA2-512 (GB/s)	6.34 [-41%]	10.9	3.35	4.38	SHA2-512 is not accelerated by SHA HWA (version 1) thus TR has to use the same vectorised AVX2 code thus is 41% slower.
TR’s secret crypto weapon (as Ryzen) is SHA HWA which allows it to soundly beat SKL-X even with 33% less memory bandwidth; provided software is NUMA-enabled it seems TR can effectively use its 4-channel memory controllers.

	Black-Scholes float/FP32 (MOPT/s)	436 [+35%]	322	234.6	129	In this non-vectorised test TR bets SKL-X by 35%. The choice for financial analysis?
	Black-Scholes double/FP64 (MOPT/s)	366 [+32%]	277	198.6	109	Switching to FP64 code,TR still beats SKL-X by over 30%. So far so great.
	Binomial float/FP32 (kOPT/s)	165 [+2.46x]	67.3	85.6	27.25	Binomial uses thread shared data thus stresses the cache & memory system; we would expect TR to falter – but nothing of the sort – it is actually over 2.5x faster than SKL-X leaving it in the dust!
	Binomial double/FP64 (kOPT/s)	83.7 [+27%]	65.6	45.6	25.54	With FP64 code the situation changes somewhat – TR is only 27% faster but still an appreciable lead. Very strange not to see Intel dominating this test.
	Monte-Carlo float/FP32 (kOPT/s)	91.6 [+42]	64.3	49.1	25.92	Monte-Carlo also uses thread shared data but read-only thus reducing modify pressure on the caches; TR reigns supreme being 40% faster.
	Monte-Carlo double/FP64 (kOPT/s)	68.7 [+34%]	51.2	37.1	19	Switching to FP64, TR is just 34% faster but still a good lead
Intel should be worried: across all financial tests, 64-bit or 32-bit floating-point workloads TR soundly beats SKL-X by a big margin that even a 16-core version may not be able to match. But should these tests be vectorisable using SIMD – especially AVX512 – then we would fully expect Intel to win. But for now – for financial workloads there is only one choice: TR/Ryzen!!!

	SGEMM (GFLOPS) float/FP32	165 [?]	623	240.7	268	We need to implement NUMA fixes here to allow TR to scale.
	DGEMM (GFLOPS) double/FP64	75.9 [?]	216	102.2	92.2	We need to implement NUMA fixes here to allow TR to scale.
	SFFT (GFLOPS) float/FP32	16.6 [-51%]	34.3	8.57	19	FFT is also heavily vectorised but stresses the memory sub-system more; here TR cannot beat SKL-X and is 50% slower – but scales well against Ryzen.
	DFFT (GFLOPS) double/FP64	8 [-65%]	23.18	7.6	11.13	With FP64 code, the gap only widens with TR over 65% slower than SKL-X and little scaling over Ryzen.
	SNBODY (GFLOPS) float/FP32	456 [-22%]	587	234	272	N-Body simulation is vectorised but has many memory accesses to shared data – and here TR is only 22% slower than SKL-X but again scales well vs Ryzen.
	DNBODY (GFLOPS) double/FP64	173 [-2%]	178	87.2	79.6	With FP64 code TR almost catches up with SKL-X
With highly vectorised SIMD code TR cannot do as well – but an additional issue is that NUMA support needs to be improved – F/D-GEMM shows how much of a problem this can be as all memory traffic is using a single NUMA node.

	Blur (3×3) Filter (MPix/s)	1470 [-6%]	1560	775	634	In this vectorised integer AVX2 workload TR does surprisingly well against SKL-X just 6% slower.
	Sharpen (5×5) Filter (MPix/s)	617 [-10%]	693	327	280	Same algorithm but more shared data used sees TR now 10%, more NUMA optimisations needed.
	Motion-Blur (7×7) Filter (MPix/s)	361 [-6%]	384	192	154	Again same algorithm but even more data shared now TR is 6% slower.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	570 [-6%]	609	307	271	Different algorithm but still AVX2 vectorised workload – TR is still 6% slower.
	Noise Removal (5×5) Median Filter (MPix/s)	106 [+35%]	78.3	57.3	34.9	Still AVX2 vectorised code but TR does far better, it is no less than 35% faster than SKL-X!
	Oil Painting Quantise Filter (MPix/s)	37.8 [-17%]	45.8	20	18.1	TR does worst here, it is 17% slower than SKL-X but still scales well vs. Ryzen.
	Diffusion Randomise (XorShift) Filter (MPix/s)	1260 [?]	4260	1160	2280	This 64-bit SIMD integer workload is a problem for TR but likely NUMA issue again as not much scaling vs. Ryzen.
	Marbling Perlin Noise 2D Filter (MPix/s)	420 [-45%]	777	175	359	TR really does not do well here but does scale well vs. Ryzen, likely some code optimisation is needed.

As TR (like Ryzen) supports most modern instruction sets now (AVX2, FMA, AES/SHA HWA) it does well but generally not enough to beat SKL-X; unfortunately the latter with AVX512 can potentially get even faster (up to 100%) increasing the gap even more.

While we’ve not tested memory performance in this article, we see that in streaming tests (e.g. AES, SHA) – even more memory bandwidth is needed to feed all the 16 cores (32 threads) and being able to run the memory at higher speeds would be appreciated.

NUMA support is crucial – as non-NUMA algorithms take a big hit (see GEMM) where performance can be even lower than Ryzen. While complex server or scientific software won’t have this problem, most programs will not be NUMA aware.

Software VM (.Net/Java) Performance

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

Environment: Windows 10 x64, latest Intel drivers. .Net 4.7.x (RyuJit), Java 1.8.x. Turbo / Dynamic Overclocking was enabled on both configurations.

VM Benchmarks		AMD Threadripper 1950X	Intel 9700X (SKL-X)	AMD Ryzen 1700X	Intel 6700K (SKL)	Comments

	.Net Dhrystone Integer (GIPS)	111 [+88%]	59	61.5	29	.Net CLR integer performance starts off very well with TR 88% faster than SKL-X an incredible result! This is not a fluke as Ryzen scores incredibly too.
	.Net Dhrystone Long (GIPS)	62.9 [+3%]	61	41	29	TR cannot match the same gain with 64-bit integer, but still just about manages to beat SKL-X.
	.Net Whetstone float/FP32 (GFLOPS)	193 [+82%]	106	103	50	Floating-Point CLR performance is pretty spectacular with TR (like Ryzen) dominating – it is no less than 82% faster than SKL-X!
	.Net Whetstone double/FP64 (GFLOPS)	225 [+67%]	134	111	63	FP64 performance is also great with TR 67% faster than SKL-X an absolutely huge win!
It’s pretty incredible, for .Net applications TR – like Ryzen – is king! It is pretty incredible that is is between 60-80% faster in all tests (except 64-bit integer). With more and more applications (apps?) running under the CLR, TR (like Ryzen) has a bright future.

	.Net Integer Vectorised/Multi-Media (MPix/s)	195 [+38%]	141	92.6	53.4	In this non-vectorised test, TR is almost 40% faster than SKL-X not as high as what we’ve seen before but still significant.
	.Net Long Vectorised/Multi-Media (MPix/s)	192 [+34%]	143	97.6	56.5	With 64-bit integer workload this time we see no changes.
	.Net Float/FP32 Vectorised/Multi-Media (MPix/s)	626 [+27%]	491	347	241	Here we make use of RyuJit’s support for SIMD vectors thus running AVX/FMA code; Intel strikes back through its SIMD units but TR is a comfortably 27% faster than it.
	.Net Double/FP64 Vectorised/Multi-Media (MPix/s)	344 [+14%]	301	192	135	Switching to FP64 SIMD vector code – still running AVX/FMA – TR’s lead falls to 14% but it is still a win!
Taking advantage of RyuJit’s support for vectors/SIMD (through SSE2, AVX/FMA) allows SKL-X to gain some traction – TR remains very much faster up to 40%. Whatever the workload, it seems TR just loves it.

	Java Dhrystone Integer (GIPS)	1000 [+16%]	857			JVM integer performance is only 16% faster on TR than SKL-X – but a win is a win.
	Java Dhrystone Long (GIPS)	974 [+26%]	771			With 64-bit integer workloads, TR is now 26% faster.
	Java Whetstone float/FP32 (GFLOPS)	231 [+48%]	156			With a floating-point workload TR increases its lead to a massive 48%, a pretty incredible result.
	Java Whetstone double/FP64 (GFLOPS)	183 [+14%]	160			With FP64 workload the gap reduces way down to 14% but it is still faster than SKL-X.
Java performance is not as incredible as we’ve seen with .Net, but TR is still 15-50% faster than SKL-X – no mean feat! Again if you have Java workloads, then TR should be the CPU of choice.

	Java Integer Vectorised/Multi-Media (MPix/s)	200 [+45%]	137			The JVM does not support SIMD/vectors, thus TR uses its scalar prowess to be 45% faster.
	Java Long Vectorised/Multi-Media (MPix/s)	186 [+33%]	139			With 64-bit vectorised workload Ryzen is still 33% faster.
	Java Float/FP32 Vectorised/Multi-Media (MPix/s)	169 [+69%]	100			With floating-point, TR is a massive 69% faster than SKL-X a pretty incredible result.
	Java Double/FP64 Vectorised/Multi-Media (MPix/s)	159 [+59%]	100			With FP64 workload TR’s lead falls just a little to 59% – a huge win over SKL-X.
Java’s lack of vectorised primitives to allow the JVM to use SIMD instruction sets (aka SSE2, AVX/FMA) gives TR (like Ryzen) free reign to dominate all the tests, be they integer or floating-point. It is pretty incredible that neither Intel CPU can come close to its performance.

TR (like Ryzen) absolutely dominates .Net and Java benchmarks with CLR and JVM code running much faster than the latest Intel SKL-X – thus current and future applications running under CLR (WPF/Metro/UWP/etc.) as well as server JVM workloads run great on TR. For .Net and Java code, TR is the CPU to get!

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

It may be difficult to decide whether AMD’s design (multiple CCX units, multiple dies/nodes on a socket) is “cool” and supporting it effectively is not easy for programmers – be they OS/kernel or application – but when it works it works extremely well! There is no doubt that Threadripper can beat Skylake-X at the same cost (approx 1,000$) though using more coress just as its little (single-die) brother Ryzen.

Scalar workloads, .Net/Java workloads just fly on it – but highly vectorised AVX2/FMA workloads only perform competitively; unfortunately once AVX512 support is added SKL-X is likely to dominate effectively these workloads though for now it’s early days.

It’s multiple NUMA node design – unless running in UMA (unified) mode – requires both OS and application support, otherwise performance can tank to Ryzen levels; while server and scientific programs are likely to be so – this is a problem for most applications. Then we have its dual-CCX design which further complicate workloads, effectively being a 2nd NUMA level; we can see inter-core latencies being 4 tiers while SKL-X only has 2 tiers.

In effect both platforms will get better in the future: Intel’s SKL-X with AVX512 support and AMD’s Threadripper with NUMA/CCX memory optimisations (and hopefully AVX512 support at one point). Intel are also already launching newer versions with more cores (up to 18C/36T) while AMD can release some server EPYC versions with 4 dies (and thus up to 32C/64T) that will both push power envelopes to the maximum.

For now, Threadripper is a return to form from AMD.

SiSoftware Sandra Titanium (2018) Released: Brand-new benchmarks, hardware support

Broad Operating System Support

Processor Overall Index

GPGPU Overall Index

Video/Graphics Overall Index

Memory/Cache Overall Index

Disk Overall Index

Overall (2018) Computer Index

Key features of Sandra Titanium

What is “Ryzen2” ZEN+?

Hardware Specifications

Core Topology and Testing

Native Performance

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

What is “Ryzen2” ZEN+?

Hardware Specifications

Native Performance

Software VM (.Net/Java) Performance

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

What is AVX512?

Native SIMD Performance

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

What is NUMA?

Native Performance

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

What is “Threadripper”?

Hardware Specifications

Thread Scheduling and Windows

Native Performance

Software VM (.Net/Java) Performance

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

Recent Posts

Recent Comments

Archives

Categories

Meta

SiSoftware Sandra Titanium (2018) Released:
Brand-new benchmarks, hardware support