Meltdown and the temptation of switching to Ryzen for my new home machine

January 15, 2018

Back in November, I put together a parts list for my still hypothetical new home Linux machine. At the time I picked an Intel CPU because Intel is still the top in single-core performance, especially when you throw in TDP; the i7-8700 is clearly superior to the Ryzen 7 1700, which is the last (or first) 65W TDP Ryzen. Then two things happened. The first is my new office workstation turned out to be Ryzen-based and it appears to work fine, run cool (actually cooler than my current machines, and seems quiet from limited testing. The second is Meltdown and to a lesser extent Spectre.

Mitigating Meltdown on Intel CPUs costs a variable and potentially significant amount of performance, depending on what your system is doing; a CPU bound program is only minorly affected, but something that interacts with the OS a lot has a problem. AMD CPUs are unaffected. AMD Zen-based CPUs, including Ryzens, are also partly immune to the branch predictor version of Spectre (from here) and so don't take a performance hit from mitigations for them.

(Currently, current Intel CPUs also cause heartburn for the retpoline Spectre mitigation, because they'll speculate through return instructions. This will apparently be changed in a microcode update, which will likely cost some performance.)

Almost the entire reason I was selecting an Intel CPU over a Ryzen was the better single-core performance; with more cores, everyone agrees that Ryzens are ahead on workloads that parallelize well. But it seems likely that Meltdown will throw away at least part of that advantage on at least some of the workloads that I care about, and anyway things like Firefox are becoming increasingly multi-threaded (although not for a while for me). There still are areas where Intel CPUs are superior to Ryzens, but then Ryzens have advantages themselves, such as supporting ECC (at least to some degree).

All of that is fine and rational, but if I'm being honest I have to admit that it's not the only reason. Another reason is that I plain don't like Intel's behavior. For years, Intel has taken advantage of lack of real competition to do things like not offer ECC in desktop CPUs or limit desktop CPUs to only four cores (it's remarkable how the moment AMD came along with real competition, Intel was able to crank that up to six cores and may go higher in the next generation). Meltdown provides a convenient reason or at least justification to spit in Intel's eye.

With all of that said, I don't know if I'm actually going to go through with this idea. A hypothetical Ryzen build is somewhat more expensive and somewhat more irritating than an Intel one, since it needs a graphics card and has more RAM restrictions, and it's at least possible that Intel will soon come out with new CPUs that do better in the face of Meltdown and Spectre (and have more cores). For the moment I'm probably just going to sit on my hands (again) and see how I like my new work desktop (when I turn the new machine into my work desktop).

(My home machine hasn't started exploding yet, so the path of least resistence and least effort is to do nothing. I'm very good at doing nothing.)


Comments on this page:

By -dsr- at 2018-01-15 10:01:14:

This spring, AMD will make Zen APUs (CPU + GPU) available. The R5 2400G looks like a nice desktop part: 4c/8t, 3.6-3.9 GHz, $170. It should drive 4K 60Hz displays, but with about 1/4 the performance of gaming systems. In other words, lots of performance for a non-gaming desktop.

If you need a new system around summer time, that should be widely available and have appropriate drivers available.

By cks at 2018-01-15 11:09:14:

Unfortunately, I'm not very interested in the currently announced Zen APUs because they seem targeted at the lower end. One attraction of Intel's integrated GPUs to me is that you can get their high end desktop CPUs with them; you don't have to choose between a good CPU and integrated graphics the way AMD appears to be going.

(And for me, 'good CPU' is a higher priority.)

By Twirrim at 2018-01-15 13:21:37:

Just a quick point of possible clarification around AMD, to quote the researchers:

"However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.

The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data.

However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed"

The researchers position seems to be that "everything we need is right there, and appears to be exploitable, we just haven't quite figured out the timing trick." This makes me somewhat twitchy!

That said, kernel devs seem generally happy with having protection turned off for AMD, and depending on your workload it could be more than enough to catapult AMD to the lead.

Written on 15 January 2018.
« Our small tools for running commands on multiple machines
You could say that Linux is AT&T's fault »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jan 15 01:58:53 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.