I am surprised the article doesn't talk about Intel CPU performance degradation due to speculative timing attack workarounds. The bugs are more severe on Intel CPUs and as such, Intel CPUs took a much bigger performance hit.
This is a hidden thing that seems to always go under the radar.
My Intel i7 4790k has lost at least 40% speed since I originally bought it, and for years, I always thought that Intel machines were getting slower without any actual proof whereas AMD machine I returned to after years just felt as fast as ever.
Now with microcode updates and similar getting more coverage, I'm certain that this is what it is.
AMD's partner program is meh, where as Intel is really partner focused - if anything breaks, I can get a replacement shipped to me in advanced the next day for ~3-5 years (component depending), but I am seeing much more demand for AMD as of late.
If I remove the Intel microservice dll from my windows system folder then I get my 41x back, but there's been no documentation forthcoming. Just finding out why speeds were nerfed required lots of research.
Having said that I can see that Asus may have finally released the required motherboard update for this. Updating requires me to reset everything by hand, as Asus doesn't let me simply back up settings - they are invalidated between bios versions. Between that and eating CPUs if using XMP, it's the worst motherboard I ever bought.
https://www.asus.com/us/Motherboards/ROG-STRIX-X99-GAMING/He...
Needless to say my days of building Intel systems are over.
The only solution was to prevent the os from loading the bad microcode at boot - I'm guessing that's what removing those .dlls does.
This was incredibly sloppy work by Asus.
So yeah, eating CPUs.
The chipset was the Broadwell EP. VCCSA ran at ~1.33, when the maximum should have been 1.25. Also VCCIO was 1.25, when it'd run happily at 1.096v.
Point taken was to go through every single voltage setting and research safe ranges, not trust auto for _anything_. There were changes in the CPU memory controllers around this time, and that's what caused the CPU to die when unsafe voltages were applied; Asus' XMP settings for my 4x8=32GB 3200 Trident Z DDR4s (17-18-18-36) turned them to mush.
I don't have a degree in electrical engineering; it seems like Asus wanted you to have one.
Looking back I'm discovering more details... and another guy who experienced essentially the same, with others backing up the instability of the platform: https://forums.anandtech.com/threads/my-6850x-just-died-just...
Whilst I want to move over to AMD, I'd like my current 6850k to last longer as my son's computer. It seems like I won the silicon lottery with my old 2600k that he's currently using though; running fixed 4.4ghz which is a very nice upgrade from the stock 3.4ghz.
The original article in this thread is music to my ears - for AM4, just add a great cooler and away we go. It's tempting to upgrade both computers at the same time.. which kind of wrecks my hand me down thing, but I'm sure the 6850k got degraded by 3 weeks on the bad settings as I've had lots of issues with it (unlike the 2600k).
(Final edit: Thus my disdain for Asus' inability to back up BIOS settings on this board when performing BIOS updates like I should now to get my overclock back, unlike others I've had; if I miss even a single one of the voltage settings, I can expect it to fry the CPU - unless they actually fixed their sh*t in one of the BIOS updates).
I've already gone through one CPU, about 4 months after I built it. Now the whole machine is just dead with no signs of life. I bought a new board assuming the board was bad but maybe I need to test the CPU now...
Agreed though, one of the worst boards I've ever bought and seriously rethinking all Asus purchases in the future.
Pretty sad that mitigations against a largely theoretical attack hurt performance for everyone. Meanwhile people continue to open e-mail attachments with .scr extensions.
My laptop is not high-value so I'd rather just disable that stuff. I once timed a C++ build, with and without Spectre mitigations, and the difference was something like 20%.
Consider the average user. You can remove almost all malware and viruses because they only install and run with user permissions. Without spectre mitigations, it wouldn't be very long before all that malware was installing itself at deeper levels where the only solution is blowing everything away completely.
I'm sure there is also a DRM argument somewhere for people who like that kind of thing.
40% speed reduction does not really count as "anything breaks", does it? Some previously working workloads stopped working.