Tag Archives: Phoronix

Ryzen 9 3900X vs. Ryzen 9 3950X vs. Core i9 9900KS In Nearly 150 Benchmarks

This week our AMD Ryzen 9 3950X review sample finally arrived and so we’ve begun putting it through the paces of many different benchmarks. The first of these Linux tests with the Ryzen 9 3950X is looking at the performance up against the Ryzen 9 3900X and Intel Core i9 9900KS in 149 different tests.

The Ryzen 9 3950X is AMD’s new $749 USD processor just below the Threadripper 3960X. The 3950X offers sixteen cores / 32 threads with a 3.5GHz base clock and 4.7GHz maximum turbo clock. Over the 3900X at $499 is four extra cores / eight threads, a 300MHz lowering of the base clock, 100MHz higher maximum boost clock, and larger L1 and L2 caches while both of these Zen 2 processors share the same TDP of 105 Watts.

The Core i9 9900KS meanwhile is currently retailing for $649+ USD and is the classic eight cores / sixteen threads, 4.0GHz base frequency, 5.0GHz turbo frequency, and has a 127 Watt TDP.

Given it’s been several weeks since the Ryzen 9 3950X launched with the first reviews, let’s jump straight to our Linux data with this article being quite straight-forward to getting out the data right away.

The systems were run with the Corsair Force MP600 2TB NVMe SSD, 2 x 8GB DDR4-3600 Corsair memory, and were running a daily snapshot of Ubuntu 20.04 LTS. Given this long-term support release of Ubuntu 20.04 is coming up, for this round of testing we did the tests using that stack with the Linux 5.4 kernel.

149 tests (including various sub-test options) were run for this article on the three processors. As you can see, the Ryzen 9 3950X dominates quite well. Only in the single-threaded tests or those not scaling out to 32 threads saw some competition… (All the individual graphs of the highlighted results to follow.) As shown in previous articles, even the Ryzen 9 3900X pretty much kicks around the Core i9 9900KS.

Leading on the performance-per-dollar is the Ryzen 9 3900X at $499 USD, but even the Ryzen 9 3950X at $749 USD is generally delivering better value than the Core i9 9900KS at $649 USD. Only in cases like web browser performance, Intel’s OSPray software, x264 video encode, and other select cases was there performance-per-dollar of the i9-9900KS beating out the Ryzen 9 3950X.

Now let’s look at some of these results in more detail.

Ryzen CPUs On Linux Finally See CCD Temperatures, Current + Voltage Reporting

AMD --

One of the few frustrations with the AMD Ryzen CPU support on Linux to date has been besides the often delayed support for CPU temperature reporting has been the mainline kernel not supporting voltage readings and other extra sensors. But that is finally changing with the “k10temp” driver being extended to include current and voltage reporting plus CCD temperature reporting on Zen 2 processors.

There has been the out-of-tree Zenpower driver and other efforts to provide this information on Linux but hasn’t been officially backed by AMD and not mainlined in the kernel, thus greatly reducing the exposure to potential users. But now the k10temp driver is finally being extended to include these extra information outputs.

Linux HWMON maintainer Guenter Roeck has been working on these driver improvements to k10temp. Besides some code improvements, the new patches support reporting Core Complex Die (CCD) temperatures on Zen 2 processors. Additionally, for Ryzen CPUs (Zen 1 included) are core/SoC current and voltage information.

With this for current Ryzen 3000 series processors the patched k10temp Linux driver should expose Vcore, VSoc, Tdie, Tctl, Tccd1, Tccd2, Icore, and Isoc outputs.

Guenter posted these patches to the kernel mailing list. He’s looking for more testing on these k10temp improvements before he will queue them up for mainline kernel inclusion… Thus if you are hoping to see this work for the upcoming Linux 5.6 cycle, you better start doing some testing on AMD CPUs ASAP and pass along your findings (and, yes, I’ll be joining in on this testing party). Regardless of whether it happens for Linux 5.6 or takes another cycle, at least these driver improvements are now happening and hopefully moving forward AMD engineers will be able to make more proactive contributions.

Intel’s Mitigation For CVE-2019-14615 Graphics Vulnerability Obliterates Gen7 iGPU Performance

Yesterday we noted that the Linux kernel picked up a patch mitigating an Intel Gen9 graphics vulnerability. It didn’t sound too bad at first but then seeing Ivy Bridge Gen7 and Haswell Gen7.5 graphics are also affected raised eyebrows especially with that requiring a much larger mitigation. Now in testing the performance impact, the current mitigation patches completely wreck the performance of Ivybridge/Haswell graphics performance.

The vulnerability being discussed and analyzed this week is CVE-2019-14615. This CVE still hasn’t been made public over 24 hours later (though there are the Intel SA-00314 details for this disclosure), but from going through kernel patches and other resources, it certainly caught our interest right away and have been benchmarking it since yesterday evening. The CVE-2019-14615 vulnerability amounts to a new information disclosure issue due to insufficient control flow in certain data structures. Local access is required for exploiting this control flow issue in the hardware, but it’s not yet known/published if say WebGL within web browsers could exploit this issue. This is a hardware issue with all operating systems being affected. Our testing today, of course, is under Linux.

With the Intel Gen9 graphics mitigation it’s resorting to clearing all execution unit (EU) state at each context switch. That patch was merged to mainline right away and quickly backported to the stable series seeing new point releases. All is fairly well there (including minimal performance impact, as to be shown in this article) but with the Gen7/Gen7.5 mitigation is where the situation becomes quite messy.

The Gen7 graphics mitigation is much larger across two patches and relies upon a custom EU kernel being called prior to every context restore for clearing EU and URB resources. (Gen8 Broadwell graphics is already protected from a prior workaround.) With these patches for Gen7 graphics generation not being merged to mainline and the patch noting that “more analysis is performance on the performance implications,” we expected the graphics performance to take a hit but we didn’t expect it to be as dramatic as what we’re seeing!

First of all, for the very common Gen9 graphics that is basically found on all current Intel PCs besides Gen11 Icelake, the performance hit is indeed minimal… In just some Java 2D micro-benchmarks of its OpenGL pipeline were there any measurable hits to the performance. The Gen9 performance overall had no real impact from its clearing of EU state between context switches. The Gen9 graphics testing was done on an Intel Core i9 9900KS system and using Linux 5.5 Git from yesterday/today during which the mitigation was applied. So that’s all dandy, but when it comes to Gen7 graphics is where there is a major problem:

With this Haswell Core i7 4790K benchmarking, the Java text rendering performance saw its performance even drop like crazy — not to mention the huge hits to various OpenGL games. Granted, not many games run nicely going back to Haswell/Ivybridge era. But the open-source continuation of Enemy Territory saw its frame-rate more than halved with its mitigation. With all of the other games tested were very sizable hits to the frame-rates.

When taking the geometric mean of the i7-4790K, the mitigated results for this new vulnerability saw the HD Graphics 4600 performance drop down to 58% the performance prior to mitigating this single vulnerability.

But this is just the teaser data, continue on for more details on not only the Core i7 4790K but also having re-tested the Core i7 3770K after being shocked at the CVE-2019-14615 mitigation hit for Gen7.

A Slew Of ACO Optimizations For The Radeon Vulkan Driver Landed In Mesa 20.0


The Valve-backed ACO compiler back-end that is optionally used by the RADV Radeon Vulkan driver has continued growing in popularity with Linux gamers and also has continued maturing a lot for Mesa 20.0 that is due out later this quarter.

On top of the work that has merged already for ACO since its original mainlining in Mesa 19.3, optimizations and fixes are aplenty for ACO with RADV come Mesa 20.0.

Merged yesterday were instruction combining improvements for ACO that can particularly benefit Navi/GFX10 but also older generations. With the combining work, the number of instructions used when compiling shaders for popular games dropped by about 2.4%.

Separately merged were patches that have been around for about two months on uniform boolean optimizations. This helps a very tiny bit in the slightly smaller code size.

This and other ACO work will make for fun Mesa 20.0 testing shortly. Mesa 20.0 should be hitting its release candidate / feature freeze around the end of January and ideally releasing as stable about one month later, pending any blocker bugs pushing back the release for any significant amount of time.

The Time Namespace Appears To Finally Be On-Deck For The Mainline Linux Kernel


Back in 2018 a time namespace was proposed for the Linux kernel and now in 2020 it looks like this kernel functionality will be merged for mainline, likely with the upcoming Linux 5.6 cycle.

A few hours ago the time namespace patches were queued in the timers/core Git branch ahead of the Linux 5.6 merge window opening at the start of February.

The time namespace allows for per-namespace offsets to the system monotonic and boot-time clocks. The time namespace is suited for Linux containers usage for allowing the date/time to be changed within a container and for adjusting clocks within a container following restoration from a checkpoint/snapshot.

The patch introducing the time namespace further explains:

For many users, the time namespace means the ability to changes date and time in a container (CLOCK_REALTIME). Providing per namespace notions of CLOCK_REALTIME would be complex with a massive overhead, but has a dubious value.

But in the context of checkpoint/restore functionality, monotonic and boottime clocks become interesting. Both clocks are monotonic with unspecified starting points. These clocks are widely used to measure time slices and set timers. After restoring or migrating processes, it has to be guaranteed that they never go backward. In an ideal case, the behavior of these clocks should be the same as for a case when a whole system is suspended. All this means that it is required to set CLOCK_MONOTONIC and CLOCK_BOOTTIME clocks, which can be achieved by adding per-namespace offsets for clocks.

A time namespace is similar to a pid namespace in the way how it is created: unshare(CLONE_NEWTIME) system call creates a new time namespace, but doesn’t set it to the current process. Then all children of the process will be born in the new time namespace, or a process can use the setns() system call to join a namespace.

Following that initial patch are many follow-up patches as part of this series for making other elements of the Linux kernel timing code namespace aware and properly exposing the namespaced times. Tests are also included as part of this big rework.