Adrian Silasi – SiSoftware

SiSoftware Sandra Titanium (2018) SP3a/b Update: Pushing the Limits

By Adrian Silasi | 8th February 2019 - 1:54 am |23rd February 2019 Releases, Updates

Comments Off

Note: This article originally announced SP3a (28.45); it has since been updated to SP3b (28.49).

We are pleased to announce SP3b (version 28.49 for Sandra Titanium (2018) with updated hardware and software support:

Sandra Titanium (2018) Press Release

Sandra has always pushed the limits of hardware, optimising the workload based on the capablities of the device (compute performance, memory/storage size, etc.) ensuring that both low-end devices and high-end devices are used to their best of their capability.

This new version pushes the workload even higher with better scaling across all GPGPU benchmarks allowing low-end devices to work (e.g. integrated graphics, emulation on CPU) and high-end professional GPGPU accelerators with very fast, very large memory.

GPGPU Benchmarks

All Benchmarks: increased workload size on all benchmarks to up to maximum device capacity.
FP16/half optimisations for AMD Vega and Radeon VII (vectorisation)*
FP16/half optimisations for nVidia Volta/Turing (half2) [CUDA 10]
Workgroup and workload optimisations for AMD Vega and Radeon VII*
Updated DirectX and OpenGL compute to match CUDA and OpenCL
Resolved “out of memory” issues on low-end hardware**
Resolved long running time of CPU test-paths (that the GPGPU test paths are checked against) by enabling SIMD implementation (FFT/GEMM)**

Note: At this time we have not personally tested Radeon VII to confirm improvements.

Note2: Applies to SP3b update.

Hardware Support

Intel Core v8/9 Mobile (Whiskylake, Amberlake) support

Reviews using Sandra 2018 SP3a/b

Ranker Hardware Results

nVIDIA GeForce GTX 1660 Ti Max-Q Design

Note: FP64 rate on Radeon VII is 1/4 not 1/8 as stated in some places. FP16 rate is 2x with vectorisation, 1x with scalar.

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

Download Sandra Lite

nVidia Titan V/X: FP16 and Tensor CUDA Performance

By Adrian Silasi | 25th January 2019 - 12:53 am |25th January 2019 Reviews

Comments Off

What is FP16 (“half”)?

FP16 (aka “half” floating-point) is the IEEE lower-precision floating-point representation that has recently begun to be supported by GPGPUs for compute (e.g. Intel EV9+ Skylake GPU, nVidia Pascal/Turing) and soon by CPUs (BFloat16). While originally meant for mobile devices in order to reduce memory and compute requirements – it also allows workstations/servers to handle deep neural-network workloads that have exploded in both size and compute power.

While not all algorithms can use such low precision and thus may require parts to use normal precision, nevertheless FP16 can still be used in many instances and thus needs to be implemented and benchmarked.

In addition we see the introduction of specialised compute engines that specifically support FP16 (and not higher precision like FP32/FP64) like “Tensor Engines”.

What are “Tensors”?

A tensor engine (hardware accelerator) is a specialised processing unit that accelerates matrix multiplication in hardware, in this case the latest nVidia GPGPU architectures (Pascal/Turing). While the former was targeted to workstations (Titan), the latter powers all consumer (series 2000) graphics cards – thus it has entered the mainstream. In addition, the speed restrictions (e.g. Maxwell FP16 processing speed was limited to 1/64 FP32 speed) have been lifted.

While it is used in other algorithms, it is intended to be used to accelerate neural networks (so called “AI”) that are now being used in mainstream local workloads like image/video processing (scaling, de-noising, etc.), games (anti-aliasing, de-noising when using with ray-tracing, bots/NPCs, procedural world-building, etc.).

In this article we are investigating both FP16/half performance vs. standard FP32 as well as the performance improvement when using tensors.

nVidia Titan X : Pascal GPGPU performance in CUDA and OpenCL

FP16/half Performance

We are testing GPGPU performance of the GPUs in CUDA as it supports both FP16/half operations and tensors; hopefully both OpenCL and DirectX will also be updated to support both FP16/half (compute) and tensors.

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

Environment: Windows 10 x64, latest nVidia drivers (Jan 2019). Turbo / Dynamic Overclocking was enabled on all configurations.

For image processing, Titan V brings big performance increases from 50% to 4x (times) faster than Titan X a big upgrade. If you are willing to drop to FP16 precision, then it is an extra 50% to 2x faster again – while naturally FP16 is not really usable on the X. With potential 8x times better performance Titan V powers through image processing tasks.

Processing Benchmarks		nVidia Titan X FP32	nVidia Titan X FP16/half	nVidia Titan V FP32	nVidia Titan V FP16/half	Comments

	Mandel (Mpix/s)	17.82	0.244	22.68	33.86 [+49%]	In a purely compute-heavy algorithm FP16 can bring 50% improvement.
When F16 precision is sufficient, compute heavy algorithms improve greatly on the unlocked Titan V; we see that on the previous Titan X FP16 is not worth using as its performance is way too low.

	Black-Scholes (MOPT/s)	11.32	0.726	18.57	37 [+99%]	B/S benefits greatly from FP16 both through decreased memory storage and low precision compute.
	Binomial (kOPT/s)	2.38	2.34	4.2	4.22 [+1%]	Binomial requires higher precision for the results to make sense thus sees almost no benefit.
	Monte-Carlo (kOPT/s)	5.82	0.137	11.92	12.61 [+6%]	M/C also uses thread shared data but read-only but still requires higher precision.
For financial workloads, FP16 is generally too low and most parts of the algorithm do need to be performed in FP32; we can still use FP16 as data storage but the heavy compute sees little benefit. When FP16 can be deployed as in B/S then we see far higher performance benefits.

	GEMM (GFLOPS)	6	0.191	11	15.8 [+44%] / 42 Tensor [+4x]	Here we see the power of the tensor cores – in FP16 Titan V is 4 times faster! Normal compute is still almost 50% faster a good result.
	FFT (GFLOPS)	0.227	0.078	0.617	0.962 [+56%]	FFT also benefits from FP16 due to reduced memory pressure.
	NBODY (GFLOPS)	5.72	0.061	7.79	8.25 [+6%]	N-Body simulation needs some parts in FP32 thus does not benefit as much.
The new Tensor cores show their power in FP16 GEMM – we see 4x (times) higher performance than in FP32 which can go a long way in making neural network processing much faster not to mention 1/2 memory size requirement of FP32.

	Blur (3×3) Filter (MPix/s)	18.41	1.65	27	27.53 [+2%]	Surprisingly 3×3 does not seem to benefit much from FP16 processing performance.
	Sharpen (5×5) Filter (MPix/s)	5	0.618	9.29	14.66 [+58%]	Same algorithm but more shared brings over 50% performance improvement.
	Motion-Blur (7×7) (MPix/s)	5.08	0.332	9.48	14.39 [52%]	Again same algorithm but even more data shared also brings around 50% better performance.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	4.8	0.316	9	13.36 [+48%]	Still convolution but with 2 filters – similar 50% improvement.
	Noise Removal (5×5) Median Filter(MPix/s)	37.14	7.4	112.5	207.37 [+84%]	Median filter benefits greatly from FP16 processing, it’s almost 2x faster.
	Oil Painting Quantise Filter (MPix/s)	12.73	28	42.38	141.8 [+235%]	Without major processing, quantisation benefits even more from FP16, it’s over 3x faster.
	Diffusion Randomise (XorShift) Filter (MPix/s)	21	6.43	24.14	24.58 [+2%]	This algorithm is 64-bit integer heavy thus shows almost no benefit.
	Marbling Perlin Noise 2D Filter (MPix/s)	0.305	0.49	0.8125	2 [+148%]	One of the most complex and largest filters, FP16 makes it over 2.5x faster.
FP16/half brings huge performance improvement in image processing as long as the results are acceptable – again some parts have to use higher precision (FP32) in order to prevent artifacts. Convolution can be implemented through matrix multiplication thus would benefit even more from Tensor core hardware acceleration.

Final Thoughts / Conclusions

FP16/half support when unlocked can greatly benefit many algorithms – if the lower precision is acceptable: in general performance improves by about 50% – though in some cases it can reach 200%.

When using the new Tensor cores – performance improves hugely: in GEMM we see 4x performance improvement (vs. FP32). It thus makes great sense to modify algorithms (like convolution) to use matrix multiplication and thus the Tensor cores – which will greatly accelerate image processing and neural networks. With the new nVidia 2000 series – this kind of performance is available in the mainstream right now and is pretty amazing to see.

Expect to see similar hardware accelerator units from both GPGPUs and soon CPUs with AVX512-VNNI as well as FP16 processing support (BFloat16) that will allow multi-core wide-SIMD CPUs to be competitive.

SiSoftware Sandra Titanium (2018) SP3 Update

By Adrian Silasi | 24th January 2019 - 7:43 pm |26th January 2019 Releases, Updates

Comments Off

We are pleased to announce SP3 (version 28.40 for Sandra Titanium (2018) with updated hardware and software support:

Sandra Titanium (2018) Press Release

GPGPU Benchmarks:

Enable FP16/half support in CUDA benchmarks*
Enable low-precision FP32 shader support in DirectX Compute benchmarks
Enable Tensor support for CUDA/GEMM/FP16

Note: FP16 is already supported by the OpenCL and DirectX compute benchmarks.

GPGPU Processing, Video Shader Benchmarks:

FP16/half-precision performance* (if supported) is included in the aggregate scores. This better reflects the performance of new GPGPUs that natively support FP16/half processing.
Tensors code-path used by default where applicable.

Note: FP16 is supported by all benchmarks: DirectX, OpenGL, OpenCL and now CUDA.

Reviews using Sandra 2018 SP3

nVidia Titan V/X: FP16 and Tensor CUDA Performance

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

Download Sandra Lite

Intel Core i9 9900K CofeeLake-R Review & Benchmarks – CPU 8-core/16-thread Performance

By Adrian Silasi | 21st November 2018 - 12:00 am |22nd November 2018 Reviews

Comments Off

What is “CofeeLake-R” CFL-R?

It is the “refresh” (updated) version of the 8th generation Intel Core architecture (CFL) – itself a minor stepping of the previous 7th generation “KabyLake” (KBL), itself a minor update of the 6th generation “SkyLake” (SKL). While ordinarily this would not be much of an event – this time we do have more significant changes:

Patched vulnerabilities in hardware: this can help restore I/O workload performance degradation due to OS mitigations
- Kernel Page Table Isolation (KPTI) aka “Meltdown” – Patched in hardware
- L1TF/Foreshadow – Patched in hardware
- (IBPB/IBRS) “Spectre 2” – OS mitigation needed
- Speculative Store Bypass disabling (SSBD) “Spectre 4” – OS mitigation needed
Increased core counts yet again: CFL-R top-end now has 8 cores, not 6.

Intel CPUs bore the brunt of the vulnerabilities disclosed at the start of 2018 with “Meltdown” operating system mitigations (KVA) likely having the biggest performance impact in I/O workloads. While modern features (e.g. PCID (process context id) acceleration) could help reduce performance impact somewhat on recent architectures (4th gen and newer) the impact can still be significant. The CFL-R hardware fixes (thus not needing KVA) may thus prove very important.

On the desktop we also see increased cores (again!) now up to 8 (thus 16 threads with HyperThreading) – double what KBL and SKL brought and matching AMD.

We also see increased clocks, mainly Turbo, but this still allows 1 or 2 cores to boost clocks higher than CFL could and thus help workloads not massively threaded. This can improve responsiveness as single tasks can be run at top speed when there is little thread utilization.

While rated TDP has not changed, in practice we are likely to see increased “real” power consumption especially due to higher clocks – with Turbo pushing power consumption even higher – close to SKL/KBL-X.

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

Intel Core i7 9900K CofeeLake-R Review & Benchmarks – Memory Performance
Intel Core i7 8700K CofeeLake Review & Benchmarks – Memory Performance

Hardware Specifications

We are comparing the top-of-the-range Gen 8 Core i9 (9900K) with previous generation (8700K) and competing architectures with a view to upgrading to a mid-range high performance design.

CPU Specifications	Intel i9-9900K CofeeLake-R	Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Comments
Cores (CU) / Threads (SP)	8C / 16T	6C / 12T	8C / 16T	10C / 20T	We have 33% more cores matching Ryzen and close to mainstream SKL-X!
Speed (Min / Max / Turbo)	0.8-3.6-5GHz (8x-36x-50x)	0.8-3.7-4.7GHz (8x-37x-47x)	2.2-3.7-4.2GHz (22x-37x-42x)	1.2-3.3-4.3 (12x-33x-43x)	Single/Dual core Turbo has now reached 5GHz same as 8086K special edition.
Power (TDP)	95W (135)	95W (131)	105W (135)	140W (308)	TDP is the same but overall power consumption likely far higher.
L1D / L1I Caches	8x 32kB 8-way / 8x 32kB 8-way	6x 32kB 8-way / 6x 32kB 8-way	8x 32kB 8-way / 8x 64kB 8-way	10x 32kB 8-way / 10x 32kB 8-way	No change in L1 caches. Just more of them.
L2 Caches	8x 256kB 8-way	6x 256kB 8-way	8x 512kB 8-way	10x 1MB 8-way	No change in L2 caches. Just more of them.
L3 Caches	16MB 16-way	12MB 16-way	2x 8MB 16-way	13.75MB 11-way	L3 has also increased by 33% in line with cores matching Ryzen.
Microcode/Firmware	MU069E0C-9E	MU069E0A-96	MU8F0802-04	MU065504-49	We have a new stepping and slightly newer microcode.

Native Performance

We are testing native arithmetic, SIMD and cryptography performance using the highest performing instruction sets (AVX2, AVX, etc.). CFL supports most modern instruction sets (AVX2, FMA3) but not the latest SKL/KBL-X AVX512 nor a few others like SHA HWA (Atom, Ryzen).

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

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

Spectre / Meltdown Windows Mitigations: all were enabled as per default (BTI enabled, RDCL/KVA enabled, PCID enabled).

Native Benchmarks		Intel i9-9900K CofeeLake-R	Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Comments

	Native Dhrystone Integer (GIPS)	400 [+20%]	291	334	485	In the old Dhrystone integer workload, CFL-R finally beats Ryzen by 20%.
	Native Dhrystone Long (GIPS)	393 [+17%]	296	335	485	With a 64-bit integer workload – nothing much changes.
	Native FP32 (Float) Whetstone (GFLOPS)	236 [+19%]	170	198	262	Switching to floating-point, CFL-R still beats Ryzen by 20% in old Whetstone.
	Native FP64 (Double) Whetstone (GFLOPS)	196 [+16%]	143	169	223	With FP64 nothing much changes.
From integer workloads in Dhrystone to floating-point workloads in Whetstone, CFL-R handily beats Ryzen by about 20% and is also 33-39% faster than old CFL. It’s “king of the hill”.

	Native Integer (Int32) Multi-Media (Mpix/s)	1000 [+74%]	741	574	1590 (AVX512)	In this vectorised AVX2 integer test CFL-R is almost 2x faster than Ryzen
	Native Long (Int64) Multi-Media (Mpix/s)	416 [+122%]	305	187	581 (AVX512)	With a 64-bit AVX2 integer vectorised workload, CFL-R is now over 2.2x faster than Ryzen.
	Native Quad-Int (Int128) Multi-Media (Mpix/s)	6.75 [+16%]	4.9	5.8	7.6	This is a tough test using Long integers to emulate Int128 without SIMD: still CFL-R is fastest.
	Native Float/FP32 Multi-Media (Mpix/s)	927 [+56%]	678	596	1760 (AVX512)	In this floating-point AVX/FMA vectorised test, CFL-R is 56% faster than Ryzen.
	Native Double/FP64 Multi-Media (Mpix/s)	544 [+62%]	402	335	533 (AVX512)	Switching to FP64 SIMD code, CFL-R increases its lead to 612.
	Native Quad-Float/FP128 Multi-Media (Mpix/s)	23.3 [+49%]	16.7	15.6	40.3 (AVX512)	In this heavy algorithm using FP64 to mantissa extend FP128 but not vectorised – CFL-R is 50% faster.
In vectorised SIMD code we know Intel’s SIMD units (that can execute 256-bit instructions in one go) are much more powerful than AMD’s and it shows: Ryzen is soundly beaten by a big 50-100% margin. Naturally it cannot beat its “big brother” SKL-X with AVX512 – which is likely why Intel has not enabled them.

	Crypto AES-256 (GB/s)	17.6 [+9%]	17.8	16.1	23	With AES HWA support all CPUs are memory bandwidth bound; core contention (8 vs 6) means CFL-R scores slightly worse than CFL.
	Crypto AES-128 (GB/s)	17.6 [+9%]	17.8	16.1	23	What we saw with AES-256 just repeats with AES-128.
	Crypto SHA2-256 (GB/s)	12.2 [-34%]	9	18.6	26 (AVX512)	With SHA HWA Ryzen2 powers through but CFL-R is only 34% slower.
	Crypto SHA1 (GB/s)	23 [+19%]	17.3	19.3	38 (AVX512)	Ryzen also accelerates the soon-to-be-defunct SHA1 but the algorithm is less compute heavy allowing CFL-R to beat it.
	Crypto SHA2-512 (GB/s)	9 [+139%]	6.65	3.77	21 (AVX512)	SHA2-512 is not accelerated by SHA HWA, allowing CFL-R to use its SIMD units and be 139% faster.
AES HWA is memory bound and here and CFL-R also enjoys the 3200Mt/s memory – but now feeding 8C / 16T which all contend for the bandwidth. Thus CFL-R does score slighly less than CFL and obviously gets left in the dust by SKL-X with 4 memory channels. Ryzen2 SHA HWA does manage a lonely win but anything SIMD accelerated belongs to Intel.

	Black-Scholes float/FP32 (MOPT/s)	276 [+7%]	207	257	309	In this non-vectorised test CFL-R is just a bit faster than Ryzen2.
	Black-Scholes double/FP64 (MOPT/s)	240 [+10%]	180	219	277	Switching to FP64 code, nothing much changes, CFL-R is 10% faster
	Binomial float/FP32 (kOPT/s)	59.9 [-44%]	47	107	70.5	Binomial uses thread shared data thus stresses the cache & memory system; CFL-R strangely loses by 44%.
	Binomial double/FP64 (kOPT/s)	61.9 [+2%]	44.2	60.6	68	With FP64 code Ryzen2’s lead diminishes, CFL is pretty much tied with it.
	Monte-Carlo float/FP32 (kOPT/s)	56.5 [+4%]	41.6	54.2	63	Monte-Carlo also uses thread shared data but read-only thus reducing modify pressure on the caches; CFL-R is just 4% faster.
	Monte-Carlo double/FP64 (kOPT/s)	44.3 [+8%]	32.9	41	50.5	Switching to FP64 CFL-R increases its lead to 8%.
Without SIMD support, CFL-R relies on its thread count increase (thus matching Ryzen2) to beat Ryzen2 by a small amount and lose in one test. But in a test that AMD used to always win (with Ryzen 1/2) Intel now has the lead.

	SGEMM (GFLOPS) float/FP32	403 [+34%]	385	300	413 (AVX512)	In this tough vectorised AVX2/FMA algorithm CFL-R is 35% faster than Ryzen2
	DGEMM (GFLOPS) double/FP64	269 [+126%]	135	119	212 (AVX512)	With FP64 vectorised code, CFL-R is over 2x faster.
	SFFT (GFLOPS) float/FP32	23.4 [+160%]	24	9	28.6 (AVX512)	FFT is also heavily vectorised (x4 AVX/FMA) but stresses the memory sub-system more CFL-R is over 2x faster.
	DFFT (GFLOPS) double/FP64	11.2 [+41%]	11.9	7.92	14.6 (AVX512)	With FP64 code, CFL-R’s lead reduces to 41%.
	SNBODY (GFLOPS) float/FP32	550 [+96%]	411	280	638 (AVX512)	N-Body simulation is vectorised but many memory accesses to shared data but CFL-R is 2x faster than Ryzen2.
	DNBODY (GFLOPS) double/FP64	172 [+52%]	127	113	195 (AVX512)	With FP64 code CFL’s lead reduces to 50% over Ryzen 2.
With highly vectorised SIMD code CFL-R performs very well – dominating Ryzen2: in some tests it is over 2x faster! Then again CFL did not have any issues here either, Intel is just extending their lead…

	Blur (3×3) Filter (MPix/s)	2270 [+86%]	1700	1220	4540 (AVX512)	In this vectorised integer AVX2 workload CFL-R is amost 2x faster than Ryzen2.
	Sharpen (5×5) Filter (MPix/s)	903 [+67%]	675	542	1790 (AVX512)	Same algorithm but more shared data reduces the lead to 67% still significant.
	Motion-Blur (7×7) Filter (MPix/s)	488 [+61%]	362	303	940 (AVX512)	Again same algorithm but even more data shared reduces the lead to 61%.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	784 [+73%]	589	453	1520 (AVX512)	Different algorithm but still AVX2 vectorised workload means CFL-R is 73% faster than Ryzen 2.
	Noise Removal (5×5) Median Filter (MPix/s)	78.6 [+13%]	57.8	69.7	223 (AVX512)	Still AVX2 vectorised code but CFL-R stumbles a bit here – but it’s still 13% faster.
	Oil Painting Quantise Filter (MPix/s)	43.4 [+76%]	31.8	24.6	70.8 (AVX512)	CFL-R recovers its dominance over Ryzen2.
	Diffusion Randomise (XorShift) Filter (MPix/s)	4470 [+208%]	3480	1450	3570 (AVX512)	CFL-R (like all Intel CPUs) does very well here – it’s a huge 3x faster.
	Marbling Perlin Noise 2D Filter (MPix/s)	614 [+153%]	448	243	909 (AVX512)	In this final test, CFL-R is over 2x faster than Ryzen 2.

Adding 2 more cores brings additional performance gains (not to mention the higher Turbo clock) over CFL which showed big gains over the old SKL/KBL again within the same (rated) TDP. Intel never had any problem with SIMD code (AVX/AVX2/FMA3) beating Ryzen2 by a large margin (now over 2x faster) but now also wins pretty much all tests.

It is consistently 33-40% faster than CFL (8700K) in line with core/speed increases which bodes well for compute-heavy code; streaming performance can be lower due to increase core contention for bandwidth and here faster (though more expensive) memory would help.

No – it cannot beat its “older big brother” SKL-X with AVX512 – not to mention increased core/thread count as well as memory channels, but in some tests it is competitive.

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 (1809), latest drivers. 2MB “large pages” were enabled and in use. Turbo / Boost was enabled on all configurations.

Spectre / Meltdown Windows Mitigations: all were enabled as per default (BTI enabled, RDCL/KVA enabled, PCID enabled).

VM Benchmarks		Intel i9-9900K CofeeLake-R	Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Comments

	.Net Dhrystone Integer (GIPS)	54.3 [-11%]	41	61	52	.Net CLR integer performance starts off well but CFL-R is 10% slower.
	.Net Dhrystone Long (GIPS)	55.8 [-7%]	41	60	54	With 64-bit integers the gap lowers to 7%.
	.Net Whetstone float/FP32 (GFLOPS)	95.5 [-6%]	78	102	107	Floating-Point CLR performance does not change much, CFL-R is still 6% slower than Ryzen2 despite big gain over old CFL/KBL/SKL.
	.Net Whetstone double/FP64 (GFLOPS)	126 [+8%]	95	117	137	FP64 performance allows CFL-R to win in the end.
Ryzen 2 performs exceedingly well in .Net workloads – but CFL-R can hold its own and overall it is not significantly slower (under 10%) and even wins 1 test out of 4.

	.Net Integer Vectorised/Multi-Media (MPix/s)	144 [+30%]	93.5	111	144	Unlike CFL, here CFL-R is 30% faster than Ryzen2.
	.Net Long Vectorised/Multi-Media (MPix/s)	139 [+28%]	93.1	109	143	With 64-bit integer workload nothing much changes.
	.Net Float/FP32 Vectorised/Multi-Media (MPix/s)	499 [+27%]	361	392	585	Here we make use of RyuJit’s support for SIMD vectors thus running AVX/FMA code and CFL-R is 27% faster than Ryzen2.
	.Net Double/FP64 Vectorised/Multi-Media (MPix/s)	274 [+26%]	198	217	314	Switching to FP64 SIMD vector code – still running AVX/FMA – CFL-R is still faster.
We see a big improvement in CFL-R even against old CFL: this allows it to soundly beat Ryzen 2 (which used to win this test) by about 30%, a significant margin. It is possible the hardware fixes (“Meltdown”) are having an effect here.

	Java Dhrystone Integer (GIPS)	614 [+7%]	557	573	877	Java JVM performance starts well with a 7% lead over Ryzen2.
	Java Dhrystone Long (GIPS)	644 [+16%]	488	553	772	With 64-bit integers, CFL-R doubles its lead to 16%.
	Java Whetstone float/FP32 (GFLOPS)	143 [+9%]	101	131	156	Floating-point JVM performance is similar – 9% faster.
	Java Whetstone double/FP64 (GFLOPS)	147 [+6%]	103	139	160	With 64-bit precision the lead drops to 6%.
While CFL-R improves by a good amount over CFL (which itself improved greatly over KBL/SKL) and now beats Ryzen2 by a good margin 7-16%.

	Java Integer Vectorised/Multi-Media (MPix/s)	147 [+30%]	100	113	140	Without SIMD acceleration we still see CFL-R 30% than Ryzen2 in this integer workload.
	Java Long Vectorised/Multi-Media (MPix/s)	142 [+41%]	89	101	152	Changing to 64-bit integer increases the lead to 41%.
	Java Float/FP32 Vectorised/Multi-Media (MPix/s)	91 [-6%]	64	97	98	With floating-point non-SIMD accelerated Ryzen2 is faster.
	Java Double/FP64 Vectorised/Multi-Media (MPix/s)	93 [+3%]	64	90	99	With 64-bit floatint-point precision CFL-R is back on top by just 3%.
With compute heavy vectorised code but not SIMD accelerated, CFL-R is still faster or at least ties with Ryzen2.

CFL-R now beats or at least matches Ryzen2 in VM tests the latter used to easily win. It may not have the lead native SIMD vectorised code allows it – but has no trouble keeping up – unlike its older SKL/KBL “brothers”.

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

While Intel had finally increased core counts with CFL (after many years) in light of new competition from AMD with Ryzen/2 – it still relied on fewer but more powerful (at least in SIMD) cores to compete. CFL-R finally brings core (8 vs 8) and thread (16 vs 16) parity with the competition to ensure domination.

And with few exceptions – that’s what it has achieved – 9900K is the fastest desktop CPU at this time (November 2018) and if you can afford it you can upgrade on the same, old, 200-series mainboards (though naturally 300-series is recommended). The performance improvement (33-40% over 8700K) is pretty significant to upgrade – again if you can afford it – considering it is a “mere refresh”.

The “Meltdown” fixes in hardware are also likely to bring big improvement in I/O workloads – or to be precise – restore the performance loss of OS mitigations (KVA) that have been deployed this year (2018). Still, in very rough terms, now you don’t have to decide between “speed” and “security” – though perhaps KVA should be used by default just in case any CPU (not just Intel) leaks information between user/kernel spaces by a yet undiscovered side-channel vulnerability.

But despite the “i9” moniker – don’t think you’re getting a workstation-class CPU on the cheap: SKL-X not only (still) has more cores/threads and 2x memory channels but also supports AVX512 beating it soundly. It will also be refreshed soon – sporting the same “Meltdown” in-hardware fixes. But again considering the costs (almost 2x) CFL-R is likely the performance/price winner on most workloads.

For now, on the desktop, the 9900K is “king of the hill”!

SiSoftware Sandra Titanium (2018) SP2c Update

By Adrian Silasi | 14th November 2018 - 9:29 pm |24th January 2019 Releases, Updates

Comments Off

We are pleased to announce SP2c (version 28.34 for Sandra Titanium (2018) with updated hardware and software support:

Sandra Titanium (2018) Press Release

Hardware Information
- Ryzen 1/2 & Threadripper: fix crash when Hyper-V / “Windows Core Isolation – Memory Integrity” (VBS) – are enabled
- Ryzen 2 & Threadripper: enabled display of Core temperature, voltage, current, power usage

Reviews using Sandra 2018 SP2c

Intel Core i9 9900K CofeeLake-R Review & Benchmarks – CPU 8-core/16-thread Performance

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

Download Sandra Lite

Black Friday 2018 Deal

Intel Core i7 8700K CofeeLake Review & Benchmarks – UHD 630 GPGPU Performance

By Adrian Silasi | 30th October 2018 - 12:47 am |30th October 2018 Reviews

Comments Off

What is “CofeeLake” CFL?

The 8th generation Intel Core architecture is code-named “CofeeLake” (CFL): unlike previous architectures, it is a minor stepping of the previous 7th generation “KabyLake” (KBL), itself a minor update of the 6th generation “SkyLake” (SKL). As before, the CPUs contain an integrated GPU (with compute support aka GPGPU).

While originally Intel integrated graphics were not much use – starting with SNB (“SandyBridge”) and especially its GPGPU-capable successor IVB (“IvyBridge”) the integrated graphics units made large progress, with HSW (“Haswell”) introducing powerful many compute units (GT3+) and esoteric L4 cache (eDRAM) versions (“CrystallWell) supporting high-end features like FP64 (native 64-bit floating-point support) and zero-copy CPU <> GPU transfers.

Alas, while the features remained, the higher-end versions (GT3, GT4e) never became mainstream and pretty much disappeared – except very high-end ULV/H SKUs with top-end desktop CPUs like 6700K, 8700K, etc. tested here stuck with the low-end GT2 versions. Perhaps nobody in their right mind would use such CPUs without a dedicated external (GP)GPU, it is still interesting to see how the GPU core has evolved in time.

Also let’s not forget that on the mobile platforms (either ULV/Y even H) most laptops/tablets do not have dedicated GPU and rely solely on integrated graphics – and here naturally UHD630 performance matters.

Hardware Specifications

We are comparing the graphics units of to-of-the-range Intel CPUs with low-end dedicated cards to determine whether they are good enough for modest use, especially for compute (GPGPU) use supporting the CPU.

GPGPU Specifications	Intel UHD 630 (8700K)	Intel HD 530 (6700K)	nVidia GT 1030	Comments
Arch Chipset	GT2 / EV9.5	GT2 / EV9	GP108 / SM6.1	UHD6xx is just a minor revision of the HD5xx video core.
Cores (CU) / Threads (SP)	24 / 192	24 / 192	3 / 384	No change in core / SP units.
ROPs / TMUs	8 / 16	8 / 16	16 / 24	No change in ROP/TMUs either.
Speed (Min-Turbo)	350-1200	350-1150	300-1.26-1.52	Turbo speed is only slightly increased.
Power (TDP)	95W	91W	35W	TDP has gone up a bit but nothing major.
Constant Memory	3.2GB	3.2GB	64kB (dedicated)	There is no dedicated constant memory thus a large chunk is available to use (GB) unlike a dedicated video card with very fast but small (kB).
Shared (Local) Memory	64kB	64kB	48kB (dedicated)	Bigger than usual shared/local memory but slow (likely non dedicated).
Global Memory	7GB (of 16GB)	7GB (of 16GB)	2GB	About 50% of main memory can be used as global memory – thus pretty large workloads can be run.
Memory System	DDR4 3200Mt/s 128-bit	DDR4 2533Mt/s 128-bit	GDDR5 6Gt/s 64-bit	CFL can reliably run at faster data rates thus 630 benefits too.
Memory Bandwidth (GB/s)	50	40	48	The high data rate of DDR4 can result in higher bandwidth than some dedicated cards.
L2 Cache	512kB	512kB	48kB	L2 is unchanged and reasonably large.
FP64/double ratio	Yes, 1/8	Yes, 1/8	Yes, 1/32	FP64 is supported and at good ration compared to gimped dedicated cards.
FP16/half ratio	Yes, 2x	Yes, 2x	Yes, 1/64	FP16 is also now supported at twice the rate – again unlike gimped dedicated cards.

Processing Performance

We are testing both OpenCL performance using the latest SDK / libraries / drivers from both Intel and competition.

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

Environment: Windows 10 x64, latest Intel drivers, OpenCL 2.x. Turbo / Boost was enabled on all configurations.

Processing Benchmarks		Intel UHD 630 (8700K)	Intel HD 530 (6700K)	nVidia GT 1030	Comments

	Mandel FP16/Half (Mpix/s)	1150 [+7%]	1070	1660	Thanks to FP16 support we see double the performance over FP32 and thus only 50% slower than dedicated 1030.
	Mandel FP32/Single (Mpix/s)	584 [+9%]	535	1660	630 is almost 10% faster than old 530 but still about 1/3 of a dedicated 1030.
	Mandel FP64/Double (Mpix/s)	151 [+9%]	138	72.8	FP64 sees a similar delta (+9%) but much faster (2x) than a dedicated 1030 due to gimped FP64 units.
	Mandel FP128/Quad (Mpix/s)	7.84 [+5%]	7.46	2.88	Emulated FP128 precision depends entirely on FP64 performance and much better (3x) than gimped dedicated.
UHD630 is about 5-9% faster than 520, not much to celebrate – but due to native FP16 and especially FP64 support it can match or even overtake low-end dedicated GPUs – a pretty surprising result! If only we had more cores, it may actually be very much competitive.

	Crypto AES-256 (GB/s)	1 [+5%]	0.954	4.37	We see a 5% improvement for 630 0 but far lower performance than a dedicated GPU.
	Crypto AES-128 (GB/s)	1.3 [+6]	1.23	5.9	Nothing changes here , we see a 6% improvement.

	Crypto SHA2-256 (GB/s)	3.6 [+3%]	3.5	18.4	In this heavy integer workload, the improvement falls to just 3% – but a dedicated unit would be about 4x faster.
	Crypto SHA1 (GB/s)	8.18 [+2%]	8	24	Nothing much changes here, we see a 2% improvement.
	Crypto SHA2-512 (GB/s)	1.3 [+2%]	1.27	7.8	With 64-bit integer workload, same improvement of just 2% but now the 1030 is about 6x faster!
Nobody will be using integrated graphics for crypto-mining any time soon, we see a very minor improvement in 639 vs old 530, but overall low performance versus dedicated graphics like a 1030 which would be 4-6x faster. We would need 3x more cores to compete here.

	Black-Scholes float/FP32 (MOPT/s)	1180 [+21%]	977	1320	In this FP32 financial workload we see a good 21% improvement vs. old 530. Also good result vs. dedicated 1030.
	Black-Scholes double/FP64 (MOPT/s)	180 [+2%]	175	137	Switching to FP64 code, the difference is next to nothing but better than a gimped 1030.
	Binomial float/FP32 (kOPT/s)	111 [+12%]	99	255	Binomial uses thread shared data thus stresses the internal memory sub-system, and here 630 is 12% faster. But 1/2 the performance of a 1030.
	Binomial double/FP64 (kOPT/s)	22.3 [+4%]	21.5	14	With FP64 code the improvement drops to 4%.
	Monte-Carlo float/FP32 (kOPT/s)	298 [+2%]	291	617	Monte-Carlo also uses thread shared data but read-only thus reducing modify pressure – strangely we see only 2% improvement and again 1/2 1030 performance.
	Monte-Carlo double/FP64 (kOPT/s)	43.4 [+2%]	42.5	28	Switching to FP64 we see no changes. But almost 2x performance over a 1030.
You can run financial analysis algorithms with decent performance on an UHD630 – just as you could on the old 530 – and again better FP64 performance than dedicated – (GT 1030) a pretty impressive result. Naturally, you can just use the powerful CPU cores instead…

	SGEMM (GFLOPS) float/FP32	143 [+4%]	138	685	Using 32-bit precision 630 improves 4% but is almost 1/5 (5 times slower) than a 1030.
	DGEMM (GFLOPS) double/FP64	55.5 [+3%]	53.7	35	With FP64 precision, the delta does not change but now 640 is amost 2x faster than a 1030.
	SFFT (GFLOPS) float/FP32	39.6 [+20%]	33	37	FFT is memory access bound and here 630’s faster DDR4 memory gives it a 20% lead.
	DFFT (GFLOPS) double/FP64	9.3 [+16%]	8	20	We see a similar improvement with FP64 about 16%.
	SNBODY (GFLOPS) float/FP32	272 [+2%]	266	637	Back to normality with this algorithm – we see just 2% improvement.
	DNBODY (GFLOPS) double/FP64	27.7 [+3%]	26.9	32	With FP64 precision, nothing much changes.
The scientific scores are similar to financial ones – except the memory access heavy FFT which greatly benefits from better memory (if that is provided of course) but this a dedicated card (like the 1030) is much faster in FP32 mode but again the 630 can be 2x faster in FP64 mode. Again, you’re much better off using the CPU and its powerful SIMD units for these algorithms.

	Blur (3×3) Filter single/FP32 (MPix/s)	592 [+10%]	536	1620	In this 3×3 convolution algorithm, we see a 10% improvement over the old 530. But about 1/3x performance of a 1030.
	Sharpen (5×5) Filter single/FP32 (MPix/s)	128 [+9%]	117	637	Same algorithm but more shared data reduces the gap to 9%.
	Motion Blur (7×7) Filter single/FP32 (MPix/s)	133 [+9%]	122	391	With even more data the gap remains the same.
	Edge Detection (2*5×5) Sobel Filter single/FP32 (MPix/s)	127 [+9%]	116	368	Still convolution but with 2 filters – still 9% better.
	Noise Removal (5×5) Median Filter single/FP32 (MPix/s)	9.2 [+10%]	8.4	7.3	Different algorithm does not change much still 10% better.
	Oil Painting Quantise Filter single/FP32 (MPix/s)	10.6 [+9%]	9.7	4.08	Without major processing, 630 improves by the same amount.
	Diffusion Randomise (XorShift) Filter single/FP32 (MPix/s)	1640 [+2%]	1600	2350	This algorithm is 64-bit integer heavy thus we fall to the “usual” 2% improvement.
	Marbling Perlin Noise 2D Filter single/FP32 (MPix/s)	550 [+2%]	538	849	One of the most complex and largest filters, sees the same 2% improvement.
For image processing using FP32 precision 630 performs a bit better than usual, 10% faster across the board compared to the old 530 – but still about 1/3 (third) the speed of a dedicated 1030. But if you can make do with FP16 precision image processing, then we almost double performance.

Memory Performance

We are testing both OpenCL performance using the latest SDK / libraries / drivers from both Intel and competition.

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

Environment: Windows 10 x64, latest Intel drivers, OpenCL 2.x. Turbo / Boost was enabled on all configurations.

Memory Benchmarks		Intel UHD 630 (8700K)	Intel HD 530 (6700K)	nVidia GT 1030	Comments

	Internal Memory Bandwidth (GB/s)	36.4 [+21%]	30	38.5	Due to higher speed DDR4 memory, the 630 manages 21% better bandwidth than the 620 – and comparable to a 64-bit bus dedicated card.
	Upload Bandwidth (GB/s)	17.9 [+29%]	13.9	3 (PCIe3 x4)	The CPU<>GPU internal link seems to have 30% more bandwidth – naturally zero transfers are also supported. And a lot better than a dedicated card on PCIe3 x4 (4 lanes).
	Download Bandwidth (GB/s)	17.9 [+35%]	13.3	3 (PCIe3 x4)	Here again we see a good 35% bandwidth improvement.
CFL’s higher (stable) memory speed support improves bandwidth between 20-35% – which is likely behind most benchmark improvement in the compute algorithms above. However, that will only happen if high-speed DDR4 memory (3200 or faster) were to be used – an expensive proposition! eDRAM would greatly help here…

	Global (In-Page Random Access) Latency (ns)	179 [+1%]	178	223	No changes in global latencies in-page showing no memory sub-system improvements.
	Global (Full Range Random Access) Latency (ns)	268 [-19%]	332	244	Due to faster memory clock (even with slightly increased timings) full random access latencies fall by 20% (similar to bandwidth increase).
	Global (Sequential Access) Latency (ns)	126 [-5%]	132	76	Sequential access latencies do fall by a minor 5% as well though.
	Constant Memory (In-Page Random Access) Latency (ns)	181 [-6%]	192	92.5	Intel’s GPGPU don’t have dedicated constant memory thus we see similar performance to global memory.
	Shared Memory (In-Page Random Access) Latency (ns)	72 [-1%]	73	16.6	Shared memory latency is unchanged – and quite slow compared to architectures from competitors like the 1030.
	Texture (In-Page Random Access) Latency (ns)	138 [-9%]	151	220	Texture access latencies do seem to show a 9% improvement a surprising result.
	Texture (Full Range Random Access) Latency (ns)	227 [-16%]	270	242	Just as we’ve seen with global (full range access) latencies, we see the best improvement about 16% here.
	Texture (Sequential Access) Latency (ns)	45 [=]	45	71.9	With sequential access we see no improvement.
Anything to do with main memory access (aka “full random access”) does show a similar improvement to bandwidth increases, i.e. between 16-19% due to higher speed (but somewhat higher timings) main memory. All other access patterns show little to no improvements.

When using higher speed DDR4 memory – as we do here (3200 vs 2533) UHD630 shows a good improvement in both bandwidth and reduced latencies – but otherwise it performs just the same as the old HD520 – not a surprise really. At least you can see that your (expensive) memory investment does not go to waste – with memory bound algorithms showing good improvement.

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

For GPGPU workloads, UHD630 does not bring anything new – it performs similarly to the old HD520. But as CFL can use higher (stable) memory, bandwidth and latencies are improved (when using such higher speed memory) and thus most algorithms do show good improvements. Naturally as long as you can afford to provide such memory.

The surprising support for 1/2 ratio native FP64 support means 64-bit floating-point algorithms can run faster than on a typical low-end graphics card (as despite also supporting native FP64 the ratio is 1/32 vs. FP32 rate) so high accuracy workloads do work well on it. If loss of accuracy is OK (e.g. picture processing) native FP16 support at 2x rate makes such algorithms almost 2x faster and thus within the performance of a typical low-end graphics card (that either don’t support FP16 or their ratio is 1/64!).

As we touched in the introduction – this may not matter on desktop – but on mobile where most laptops/tablets use the integrated graphics any and all such improvements can make a big difference. While in the past the fast-improving EV cores became performance competitive with CPU cores (as there were only 2 ULV ones) – with CFL doubling number of CPU cores (4 vs. 2) it is likely that internal graphics (GPGPU) performance is now too low.

We’re sad that the GT3/GT4 versions are not common-place not to mention the L4/eDRAM which showed so much promise in the HSW days.

But Intel has recently revamped its GPU division and are committed to release dedicated (not just internal) graphics in a few years (2020?) which hopefully means we should see far more powerful GPUs from them soon.

Let’s hope they do see the light-of-day and are not cancelled like the “Phi” GPGPU accelerators (“Knights Landing”) which showed so much promise but somehow never made it outside data centres before sailing into the sunset…

Intel Core i7 8700K CofeeLake Review & Benchmarks – 2-channel DDR4 Cache & Memory Performance

By Adrian Silasi | 29th October 2018 - 1:13 pm |22nd November 2018 Reviews

Comments Off

What is “CofeeLake” CFL?

The 8th generation Intel Core architecture is code-named “CofeeLake” (CFL): unlike previous architectures, it is a minor stepping of the previous 7th generation “KabyLake” (KBL), itself a minor update of the 6th generation “SkyLake” (SKL). The server/workstation (SKL-X/KBL-X) CPU core saw new instruction set support (AVX512) as well as other improvements – these have not made the transition yet.

Possibly due limited competition (before AMD Ryzen launch), process issues (still at 14nm) and the disclosure of a whole host of hardware vulnerabilities (Spectre, Meltdown, etc.) which required microcode (firmware) updates – performance improvements have not been forthcoming. This is pretty much unprecedented – while some Core updates were only evolutionary we have not had complete stagnation before; in addition the built-in GPU core has also remained pretty much stagnant – we will investigate this in a subsequent article.

However, CFL does bring up a major change – and that is increased core counts both on desktop and mobile: on desktop we go from 4 to 6 cores (+50%) while on mobile (ULV) we go from 2 to 4 (+100%) within the same TDP envelope!

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

Hardware Specifications

We are comparing the top-of-the-range Gen 8 Core i7 (8700K) with previous generation (6700K) and competing architectures with a view to upgrading to a mid-range high performance design.

CPU Specifications	Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Intel i7-6700K SkyLake	Comments
L1D / L1I Caches	6x 32kB 8-way / 6x 32kB 8-way	8x 32kB 8-way / 8x 64kB 8-way	10x 32kB 8-way / 10x 32kB 8-way	4x 32kB 8-way / 4x 32kB 8-way	No L1D/I changes, Ryzen’s L1I is twice as big.
L2 Caches	6x 256kB 4-way	8x 512kB 8-way	10x 1MB 16-way	4x 256kB 4-way	No L2 changes, Ryzen’s L2 is twice as big again.
L3 Caches	12MB 16-way	2x 8MB 16-way	2x 8MB 16-way	8MB 16-way	L3 has also increased with no of cores, still behind Ryzen’s dual 8MB L3 caches.
TLB 4kB pages	64 4-way / 64 8-way/ 1536 6-way	64 full-way 1536 8-way	64 4-way / 64 8-way / 1536 6-way	64 4-way / 64 8-way / 1536 6-way	No TLB changes.
TLB 2MB pages	8 full-way / 1536 6-way	64 full-way 1536 2-way	8 full-way / 1536 6-way	8 full-way / 1536 6-way	No TLB changes.
Memory Controller Speed (MHz)	1200-4400	1333-2667	1200-2700	1200-4000	The uncore (memory controller) runs at faster clock due to higher rated clock but not a lot in it.
Memory Data Speed (MHz)	3200	2667	3200	2533	CFL can easily run at 3200Mt/s while KBL/SKL were not as reliable. We could not get Ryzen past 2667 while it does support 2933.
Memory Channels / Width	2 / 128-bit	2 / 128-bit	2 / 128-bit	2 / 128-bit	All have 128-bit total channel width.
Memory Bandwidth (GB/s)	50	42	100	40	Bandwidth has naturally increased with memory clock speed but latencies are higher.
Uncore / Memory Controller Firmware	2.6.2			2.0.0.6	We’re on firmware 2.6.x vs. 2.0.x on old SKL/KBL.
Memory Timing (clocks)	16-16-16-36 6-52-25-12 2T	16-17-17-35 7-60-20-10 2T		16-18-18-36 5-54-21-10 2T	Timings are very much BIOS dependent and vary a lot.

Native Performance

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

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

Spectre / Meltdown Windows Mitigations: all were enabled as per default (BTI enabled, RDCL/KVA enabled, PCID enabled).

Native Benchmarks		Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Intel i7-6700K SkyLake	Comments

	Total Inter-Core Bandwidth – Best (GB/s)	52.5 [-5%]	55.3	86	39.5	Despite just 2 less cores, CFL has only 5% less bandwidth than Ryzen 2.
	Total Inter-Core Bandwidth – Worst (GB/s)	15.5 [+144%]	6.35	25.7	16.1	In worst-case pairs on Ryzen2 must go across CCXes – unlike Intel’s CPUs – thus CFL can muster over 2x more bandwidth in this case.
CFL manages good bandwidth improvement over KBL/SKL – and due to unified design matching Ryzen2 in best case and beating it soundly in worst case.

	Inter-Unit Latency – Same Core (ns)	14.4 [+7%]	13.5	15	16	Surprisingly, Ryzen2 manages lower thread latency when sharing core.
	Inter-Unit Latency – Same Compute Unit (ns)	45 [+12%]	40	75	47	Within the same unit, Ryzen2 is again faster than CFL.
	Inter-Unit Latency – Different Compute Unit (ns)	–	115	–	–	Obviously going across CCXes is slow, about 3x slower which needs careful thread scheduling.
The multiple CCX design still presents some challenges to programmers requiring threads to be carefully scheduled – but we see Ryzen2 with lower latencies for both core and unit a surprising result as usually Intel’s caches are lower latency.

	Aggregated L1D Bandwidth (GB/s)	1630 [+59%]	854	2220	884	Intel’s wide data path L1 caches allow even old SKL to beat Ryzen2 with CFL enjoying 60% more bandwidth.
	Aggregated L2 Bandwidth (GB/s)	571 [-21%]	720	985	329	But Ryzen2’s L2 caches are not only twice as big but also very wide – CFL has 20% less bandwidth.
	Aggregated L3 Bandwidth (GB/s)	327 [-4%]	339	464	243	Ryzen’s 2 L3 caches also provide good bandwidth matching CFL’s unified L3 cache.
	Aggregated Memory (GB/s)	35.6 [+11%]	32.2	70	30.1	Running at 3200Mt’s obviously CFL enjoys higher bandwidth than Ryzen2 at 2667Mt’s but somehow the latter has better efficiency.
Nothing much has changed in CFL vs. old SKL thus while L1 caches are wide and thus fast – the L2, L3 are not as impressive and the memory controller while competitive it does not seem as efficient as Ryzen2 but is more stable at high data rates allowing for higher bandwidth.

	Data In-Page Random Latency (ns)	17.4 (4-11-20) [-73%]	63.4 (4-12-31)	25.5 (4-13-30)	20.4 (4-12-21)	While clock latencies have not changed w.s. old KBL/SKL, CFL enjoys lower latencies due to higher data rates. Ryzen2 has problems here.
	Data Full Random Latency (ns)	53.4 (4-11-42) [-30%]	76.2 (4-12-32)	74 (4-13-62)	63.9 (4-12-34)	Out-of-page clock latencies have increased but still overall lower. Ryzen2 has almost caught up here.
	Data Sequential Latency (ns)	3.8 (4-11-12) [+15%]	3.3 (4-6-7)	5.3 (4-12-12)	4.1 (4-12-13)	With sequential access, Ryzen2 is now faster as CFL’s clock latencies have not changed.
CFL is lucky here as even Ryzen2 still has high latencies in random accesses (either in-page or full range) but manages to be faster with sequential access. Intel will need to improve going forward as clock latencies while good have really not improved at all.

	Code In-Page Random Latency (ns)	8.7 (2-10-21) [-37%]	13.8 (4-9-24)	11.8 (4-14-25)	10.1 (2-10-21)	Code clock latencies also have not changed and again and while Ryzen2 performs a lot better, CFL (even old SKL) manage to be ~35% faster.
	Code Full Random Latency (ns)	59.8 (2-10-48) [-30%]	85.7 (4-14-49)	83.6 (4-15-74)	70.7 (2-11-46)	Out-of-page clock latencies also have not changed and here CFL is 20% faster over Ryzen2.
	Code Sequential Latency (ns)	4.5 (2-4-10) [-39%]	7.4 (4-12-20)	6.8 (4-7-11)	5 (2-4-9)	Ryzen2 is competitive but again CFL manages to be almost 40% faster.
CFL dominates here and enjoys 30-40% less latency over Ryzen2 but the latter has improved a lot in time.

	Memory Update Transactional (MTPS)	54 [+980%]	5	59	35	Finally all top-end Intel CPUs have HLE enabled and working and thus enjoy huge performance increase.
	Memory Update Record Only (MTPS)	38 [+730%]	4.58	59	24.8	Nothing much changes here.

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

CFL’s caches and memory (uncore) sub-systems are unchanged from SKL/KBL and thus provide no surprises, with rock-solid performance at 3200Mt/s with huge bandwidth (needed after all to feed 12 threads) but Ryzen2 has improved a lot over old AMD CPU designs.

With the continuous increase in cores/threads (8/12 in CFL-R) as with Ryzen1/2 but modest DDR4 speed increases (not to mention very high cost), the desktop platforms are likely to see diminishing returns due to core/thread data starvation while the extra cores just cannot be fed by the memory sub-systems. The L2 and L3 caches will need to be improved (widened, larger as with SKL-X) also the now defunct L4/eDRAM cache should re-emerge to mitigate these issues…

Intel Core i7 8700K CofeeLake Review & Benchmarks – CPU 6-core/12-thread Performance

By Adrian Silasi | 26th October 2018 - 4:07 pm |22nd November 2018 Reviews

Comments Off

What is “CofeeLake” CFL?

The 8th generation Intel Core architecture is code-named “CofeeLake” (CFL): unlike previous architectures, it is a minor stepping of the previous 7th generation “KabyLake” (KBL), itself a minor update of the 6th generation “SkyLake” (SKL). The server/workstation (SKL-X/KBL-X) CPU core saw new instruction set support (AVX512) as well as other improvements – these have not made the transition yet.

While this article is a bit late in the day considering the 8700K launched last year – we have now also reviewed the brand-new CofeeLake-R (Refresh) Core i9-9900K and it seems a good time to see what has changed performance-wise for the previous top-of-the-range CPU.

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

Hardware Specifications

We are comparing the top-of-the-range Gen 8 Core i7 (8700K) with previous generation (6700K) and competing architectures with a view to upgrading to a mid-range high performance design.

CPU Specifications	Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Intel i7-6700K SkyLake	Comments
Cores (CU) / Threads (SP)	6C/12T	8C / 16T	10C / 20T	4C / 8T	We have 50% more cores compared to SKL/KBL but still not as much as Ryzen/2 with 8 cores.
Speed (Min / Max / Turbo)	0.8-3.7-4.7GHz (8x-37x-47x)	2.2-3.7-4.2GHz (22x-37x-42x)	1.2-3.3-4.3 (12x-33x-43x)	0.8-4.0-4.2GHz (8x-40x-42x)	Single-core Turbo has increased close to 5GHz (reserved for Special Edition 8086K) way above SKL/KBL and Ryzen.
Power (TDP)	95W (131)	105W (135)	140W (308)	91W (100)	TDP has only increased by 4% and is still below Ryzen though Turbo is comparable.
L1D / L1I Caches	6x 32kB 8-way / 6x 32kB 8-way	8x 32kB 8-way / 8x 64kB 8-way	10x 32kB 8-way / 10x 32kB 8-way	4x 32kB 8-way / 4x 32kB 8-way	No change in L1 caches. Just more of them.
L2 Caches	6x 256kB 8-way	8x 512kB 8-way	10x 1MB 8-way	4x 256kB 8-way	No change in L2 caches. Just more of them.
L3 Caches	12MB 16-way	2x 8MB 16-way	13.75MB 11-way	8MB 16-way	L3 has also increased by 50% in line with cores, but still below Ryzen’s 16MB.
Microcode/Firmware	MU069E0A-96	MU8F0802-04	MU065504-49	MU065E03-C2	We have a new model and somewhat newer microcode.

Native Performance

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

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

Spectre / Meltdown Windows Mitigations: all were enabled as per default (BTI enabled, RDCL/KVA enabled, PCID enabled).

Native Benchmarks		Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Intel i7-6700K SkyLake	Comments

	Native Dhrystone Integer (GIPS)	291 [-13%]	334	485	190	In the old Drystone integer workload, CFL is still 13% slower than Ryzen 2 depite the huge lead over SKL.
	Native Dhrystone Long (GIPS)	296 [-12%]	335	485	192	With a 64-bit integer workload – nothing much changes.
	Native FP32 (Float) Whetstone (GFLOPS)	170 [-14%]	198	262	105	Switching to floating-point, CFL is still 14% slower in the old Whetstone also a micro-benchmark.
	Native FP64 (Double) Whetstone (GFLOPS)	143 [-15%]	169	223	89	With FP64 nothing much changes.
From integer workloads in Dhyrstone to floating-point workloads in Whestone, CFL is still 12-15% slower than Ryzen 2 with its 2 more cores (8 vs. 2), but much faster than the old SKL with 4 cores. We begin to see now why Intel is adding more cores in CFL-R.

	Native Integer (Int32) Multi-Media (Mpix/s)	741 [+29%]	574	1590 (AVX512)	474	In this vectorised AVX2 integer test we see CFL beating Ryzen by ~30% despite less cores.
	Native Long (Int64) Multi-Media (Mpix/s)	305 [+63%]	187	581 (AVX512)	194	With a 64-bit AVX2 integer vectorised workload, CFL is now 63% faster.
	Native Quad-Int (Int128) Multi-Media (Mpix/s)	4.9 [-16%]	5.8	7.6	3	This is a tough test using Long integers to emulate Int128 without SIMD: Ryzen 2 thus wins this one with CFL slower by 16%.
	Native Float/FP32 Multi-Media (Mpix/s)	678 [+14%]	596	1760 (AVX512)	446	In this floating-point AVX/FMA vectorised test, CFL is again 14% faster.
	Native Double/FP64 Multi-Media (Mpix/s)	402 [+20%]	335	533 (AVX512)	268	Switching to FP64 SIMD code, CFL is again 20% faster.
	Native Quad-Float/FP128 Multi-Media (Mpix/s)	16.7 [+7%]	15.6	40.3 (AVX512)	11	In this heavy algorithm using FP64 to mantissa extend FP128 but not vectorised – CFL is just 7% faster but does win.
In vectorised SIMD code we see the power of Intel’s SIMD units that can execute 256-bit instructions in one go; CFL soundly beats Ryzen2 despite fewer cores (7-60%). SKL-X shows that AVX512 brings further gains and is a pity CFL still does not support them.

	Crypto AES-256 (GB/s)	17.8 [+11%]	16.1	23	15	With AES HWA support all CPUs are memory bandwidth bound; unfortunately Ryzen 2 is at 2667 vs CFL/SKL-X at 3200 which means CFL is 11% faster.
	Crypto AES-128 (GB/s)	17.8 [+11%]	16.1	23	15	What we saw with AES-256 just repeats with AES-128.
	Crypto SHA2-256 (GB/s)	9 [-51%]	18.6	26 (AVX512)	5.9	With SHA HWA Ryzen2 similarly powers through hashing tests leaving Intel in the dust; CFL is thus 50% slower.
	Crypto SHA1 (GB/s)	17.3 [-9%]	19.3	38 (AVX512)	11.2	Ryzen also accelerates the soon-to-be-defunct SHA1 but the algorithm is less compute heavy thus CFL is only 9% slower.
	Crypto SHA2-512 (GB/s)	6.65 [+77%]	3.77	21 (AVX512)	4.4	SHA2-512 is not accelerated by SHA HWA, allowing CFL to use its SIMD units and be 77% faster.
AES HWA is memory bound and here CFL comfortably works with 3200Mt/s memory thus is faster than Ryzen 2 with 2667Mt/s memory (our sample); likely both would score similarly at 3200Mt/s. Ryzen 2 SHA HWA allows it to easily beat all other CPUs but only in SHA1/SHA256 – in others the CFL SIMD units win the day.

	Black-Scholes float/FP32 (MOPT/s)	207 [-19%]	257	309	128	In this non-vectorised test CFL cannot match Ryzen 2 and is ~20% slower.
	Black-Scholes double/FP64 (MOPT/s)	180 [-18%]	219	277	113	Switching to FP64 code, nothing much changes, Ryzen 2 is still faster.
	Binomial float/FP32 (kOPT/s)	47 [-56%]	107	70.5	29.3	Binomial uses thread shared data thus stresses the cache & memory system; Ryzen 2 does very well here with CFL almost 60% slower.
	Binomial double/FP64 (kOPT/s)	44.2 [-27%]	60.6	68	27.3	With FP64 code Ryzen2’s lead diminishes, CFL is “only” 27% slower.
	Monte-Carlo float/FP32 (kOPT/s)	41.6 [-23%]	54.2	63	25.7	Monte-Carlo also uses thread shared data but read-only thus reducing modify pressure on the caches; Ryzen 2 also wins this one, CFL is 23% slower.
	Monte-Carlo double/FP64 (kOPT/s)	32.9 [-20%]	41	50.5	20.3	Switching to FP64 nothing much changes, CFL is still 20% slower.
Without SIMD support, CFL loses to Ryzen 2 as we saw with Dhrystone/Whetstone – between 20 and 50%. As we noted before, Intel will still need to add more cores in order to beat Ryzen 2. Still big improvement over the old SKL/KBL as expected.

	SGEMM (GFLOPS) float/FP32	385 [+28%]	300	413 (AVX512)	268	In this tough vectorised AVX2/FMA algorithm CFL is ~30% faster.
	DGEMM (GFLOPS) double/FP64	135 [+13%]	119	212 (AVX512)	130	With FP64 vectorised code, CFL’s lead reduces to 13% over Ryzen 2.
	SFFT (GFLOPS) float/FP32	24 [167%]	9	28.6 (AVX512)	16.1	FFT is also heavily vectorised (x4 AVX/FMA) but stresses the memory sub-system more; here CFL is over 2.5x faster
	DFFT (GFLOPS) double/FP64	11.9 [+51%]	7.92	14.6 (AVX512)	7.2	With FP64 code, CFL’s lead reduces to ~50%.
	SNBODY (GFLOPS) float/FP32	411 [+47%]	280	638 (AVX512)	271	N-Body simulation is vectorised but many memory accesses to shared data but CFL remains ~50% faster.
	DNBODY (GFLOPS) double/FP64	127 [+13%]	113	195 (AVX512)	79	With FP64 code CFL’s lead reduces to 13% over Ryzen 2.
With highly vectorised SIMD code CFL performs well soundly beating Ryzen 2 between 13-167% as well as significantly improving over older SKL/KBL. As long as SIMD code is used Intel has little to fear.

	Blur (3×3) Filter (MPix/s)	1700 [+39%]	1220	4540 (AVX512)	1090	In this vectorised integer AVX2 workload CFL enjoys a ~40% lead over Ryzen 2.
	Sharpen (5×5) Filter (MPix/s)	675 [+25%]	542	1790 (AVX512)	433	Same algorithm but more shared data reduces the lead to 25% still significant.
	Motion-Blur (7×7) Filter (MPix/s)	362 [+19%]	303	940 (AVX512)	233	Again same algorithm but even more data shared reduces the lead to 20%.
	Edge Detection (2*5×5) Sobel Filter (MPix/s)	589 [+30%]	453	1520 (AVX512)	381	Different algorithm but still AVX2 vectorised workload means CFL is 30% faster than Ryzen 2.
	Noise Removal (5×5) Median Filter (MPix/s)	57.8 [-17%]	69.7	223 (AVX512)	37.6	Still AVX2 vectorised code but CFL stumbles a bit here – it’s 17% slower than Ryzen 2.
	Oil Painting Quantise Filter (MPix/s)	31.8 [+29%]	24.6	70.8 (AVX512)	20	Again we see CFL ~30% faster.
	Diffusion Randomise (XorShift) Filter (MPix/s)	3480 [+140%]	1450	3570 (AVX512)	2300	CFL (like all Intel CPUs) does very well here – it’s a huge 140% faster.
	Marbling Perlin Noise 2D Filter (MPix/s)	448 [+84%]	243	909 (AVX512)	283	In this final test, CFL is almost 2x faster than Ryzen 2.

The addition of 2 more cores brings big performance gains (not to mention the higher Turbo clock) over the old SKL/KBL which is pretty impressive considering TDP has stayed the same. With SIMD code (AVX/AVX2/FMA3) CFL has no problem beating Ryzen 2 by a pretty large margin (up to 2x faster) – but any algorithm not vectorised allows Ryzen 2 to win – though not by much 12-20%.

Streaming tests likely benefit from the higher supported memory frequencies that while in theory could be used on the older SKL/KBL (memory overclock) they were not supported officially nor stable in all cases. We shall test memory performance in a forthcoming article.

Software VM (.Net/Java) Performance

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

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

Spectre / Meltdown Windows Mitigations: all were enabled as per default (BTI enabled, RDCL/KVA enabled, PCID enabled).

VM Benchmarks		Intel i7-8700K CofeeLake	AMD Ryzen2 2700X Pinnacle Ridge	Intel i9-7900X SkyLake-X	Intel i7-6700K SkyLake	Comments

	.Net Dhrystone Integer (GIPS)	41 [-33%]	61	52	28	.Net CLR integer performance starts off well over old SKL but still 33% slower than Ryzen 2.
	.Net Dhrystone Long (GIPS)	41 [-32%]	60	54	27	With 64-bit integers nothing much changes.
	.Net Whetstone float/FP32 (GFLOPS)	78 [-24%]	102	107	49	Floating-Point CLR performance does not change much, CFL is still 25% slower than Ryzen despite big gain over old SKL.
	.Net Whetstone double/FP64 (GFLOPS)	95 [-19%]	117	137	62	FP64 performance is similar to FP32.
Ryzen 2 performs exceedingly well in .Net workloads – soundly beating all Intel CPUs, with CFL between 20-33% slower. More cores will be needed for parity with Ryzen 2, but at least CFL improves a lot over SKL/KBL.

	.Net Integer Vectorised/Multi-Media (MPix/s)	93.5 [-16%]	111	144	57	Just as we saw with Dhrystone, this integer workload sees CFL improve greatly over SKL but Ryzen 2 is still faster.
	.Net Long Vectorised/Multi-Media (MPix/s)	93.1 [-15%]	109	143	57	With 64-bit integer workload nothing much changes.
	.Net Float/FP32 Vectorised/Multi-Media (MPix/s)	361 [-8%]	392	585	228	Here we make use of RyuJit’s support for SIMD vectors thus running AVX/FMA code but CFL is still 8% slower than Ryzen 2.
	.Net Double/FP64 Vectorised/Multi-Media (MPix/s)	198 [-9%]	217	314	128	Switching to FP64 SIMD vector code – still running AVX/FMA – CFL is still slower.
We see a similar improvement for CFL but again not enough to beat Ryzen 2; even using RyuJit’s vectorised support CFL cannot beat it – just reduce the loss to 8-9%.

	Java Dhrystone Integer (GIPS)	557 [-3%]	573	877	352	Java JVM performance is almost neck-and-neck with Ryzen 2 despite 2 less cores.
	Java Dhrystone Long (GIPS)	488 [-12%]	553	772	308	With 64-bit integers, CFL does fall behind Ryzen2 by 12%.
	Java Whetstone float/FP32 (GFLOPS)	101 [-23%]	131	156	62	Floating-point JVM performance is worse though, CFL is now 23% slower.
	Java Whetstone double/FP64 (GFLOPS)	103 [-26%]	139	160	64	With 64-bit precision nothing much changes.
While CFL improves markedly over the old SKL and almost ties with Ryzen 2 in integer workloads, it does fall behind in floating-point by a good amount.

	Java Integer Vectorised/Multi-Media (MPix/s)	100 [-12%]	113	140	63	Without SIMD acceleration we see the usual delta (around 12%) with integer workload.
	Java Long Vectorised/Multi-Media (MPix/s)	89 [-12%]	101	152	62	Nothing changes when changing to 64-bit integer workloads.
	Java Float/FP32 Vectorised/Multi-Media (MPix/s)	64 [-34%]	97	98	41	With floating-point non-SIMD accelerated we see a bigger delta of about 30% less vs. Ryzen 2.
	Java Double/FP64 Vectorised/Multi-Media (MPix/s)	64 [-29%]	90	99	41	With 64-bit floatint-point precision nothing much changes.
With compute heavy vectorised code but not SIMD accelerated, CFL cannot keep up with Ryzen 2 and the difference increases to about 30% less. Intel really needs to get Oracle to add SIMD extensions similar to .Net’s new CLR.

Ryzen dominates .Net and Java benchmarks – Intel will need more cores in order to compete; while the additional 2 cores helped a lot, it is not enough!

SiSoftware Official Ranker Scores

Final Thoughts / Conclusions

Due to Core improvement stagnation (4 on desktop, 2 on mobile), Intel had no choice really but increase core counts in light of new competition from AMD with Ryzen/2 with twice as many cores (8) and SMT (Hyper-Threading) as well! While KBL had increased base/Turbo cores appreciably over SKL within the same power envelope, CFL had to add more cores in order to compete.

With 50% more cores (6) CFL performs much better than the older SKL/KBL as expected but that is not enough in non-vectorised loads; Ryzen 2 with 2 more cores is still faster, not by much (12-20%) but still faster. Once vectorised code is used, the power of Intel’s SIMD units shows – with CFL soundly beating Ryzen despite not supporting AVX512 nor SHA HWA which is a pity. AMD still has work to do with Ryzen if it wants to be competitive in vectorised workloads (integer or floating-point).

We now see why CFL-R (CofeeLake Refresh) will add even more cores (8C/16T with 9900K which we review in a subsequent article) – it is the only way to beat Ryzen 2 in all workloads. In effect AMD’s has reached parity performance with Intel in all but SIMD workloads – a great achievement!

Unfortunately (unlike AMD’s AM4 Ryzen) CFL does require new chipset/boards (series 300) which makes it an expensive upgrade for SKL/KBL owners; otherwise it would have been a pretty no-brainer upgrade for those needing more compute power. While the new platform does bring some improvements (USB 3.1 Gen 2 aka 10GB/s, more PCIe lanes, integrated 802.11ac WiFi – at least on mobile) it’s nothing over the competition.

Roll on CofeeLake Refresh and the new CPUs: they are sorely needed…

SiSoftware Sandra Titanium (2018) SP2b Update

By Adrian Silasi | 24th October 2018 - 12:58 am |30th October 2018 Releases, Updates

Comments Off

We are pleased to announce SP2b (version 28.31) for Sandra Titanium (2018) with updated hardware and software support:

Sandra Titanium (2018) Press Release

CPU Benchmarks:
- Multi-Media, .Net Multi-Media, Java Multi-Media: optimised fractal picture size selection for better scaling. Crash fix upon loading large fractals.
- Image Processing: optimised picture size selection for better scaling.
GPGPU Benchmarks:
- Processing (CUDA, OpenCL, DirectX): optimised fractal picture size selection for better scaling. Crash fix upon loading large fractals.
- Image Processing (CUDA, OpenCL, DirectX): optimised picture size selection for better scaling.
GPGPU: improved clock speed reporting (base/boost).

Reviews using Sandra 2018 SP2b

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

Download Sandra Lite

SiSoftware Sandra Titanium (2018) SP2 Update

By Adrian Silasi | 25th September 2018 - 11:12 pm |29th October 2018 Releases, Updates

Comments Off

We are pleased to announce SP2 (version 28.28) for Sandra Titanium (2018) with updated hardware and software support:

Sandra Titanium (2018) Press Release

GPGPU:
- nVidia Series 2000 (Turing) GPGPU support (still on SDK 9.2 for broad compatibility)
- Fixes workgroup sizes for Scientific benchmarks
CPU:
- Support for Intel 9000-Series CPU
- Crypto AES benchmark VAES 512-bit and 256-bit support

Product Reviews

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

Download Sandra Lite