Join for quick access. Enter your email below and we'll send confirmation plus sign you up to our newsletter.
By submitting your information, you confirm you are aged 16 or over,
have read our
Privacy Policy
and agree to the
Terms & Conditions. Geographical rules apply.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
You are now subscribed
Your newsletter sign-up was successful
Join the club
Get full access to premium articles, exclusive features and a growing list of member rewards.
An account already exists for this email address, please log in.
AMD's Inception Fix Causes Up to 54% Performance Drop
A week ago, news about AMD's Inception vulnerability broke, and the first deep dive into the performance impact of mitigations has been published. Linux-centric Phoronix has just uploaded eight pages of test results. Using an AMD Epyc 7763 (Zen 3) based system, running Linux (of course), the site tested a plethora of apps and tabulated before and after-patching results. Depending on workload, you might not see much difference — however, some tasks were up to 54% slower on a patched system.
For the above table we looked at some of the worst results, as well as some of the test results from more-familiar apps like 7zip, Blender, and Firefox. Those three familiar apps don't suffer too much from the AMD Inception mitigations. Of the three, compression app 7zip seems to be the most affected — but how long do you spend de-compressing files in an average day?
Much more serious performance consequences are observed in applications that work on databases, code compilation, engineering, and image processing. The worst result we saw, with MariaDB, shows database operations were severely impacted on a patched Epyc system.
(Image credit: Phoronix)
If you head over to Phoronix for a closer look at the data and a wider selection of results you will see that the results sometimes show more than just the AMD Inception mitigation being 'off' or 'on'. There will be up to three levels of patching with different configurations — some with purely kernel-based mitigations, others with the newest microcode, and another with the most secure Indirect Branch Prediction Barrier (IBPB) mitigation. Please note that IBPB was frequently (but not always) shown to be the worst performer of all mitigations. The default AMD Linux mitigation is 'safe RET mode'.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
Mark Tyson is a news editor at Tom's Hardware. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.
No mention of the significant performance increases between the two tests? That seems very weird.
The '-xx%' values are where rates (something per second) have decreased, a performance decrease.
The '+xx%' values are where time has increased (seconds taken to do something), also a performance decrease.
Also note that the MariaDB 11 / 4096 clients on IBPB is the big outlier : using safe RET with firmware is a smaller hit, and other DB benches showed far less of an impact. More than likely, a piece of MariaDB code does something that triggers huge number of branch jumping, triggering a lot of overhead, and that may be fixed in a future release - I wouldn't be surprised if Intel's latest mitigation didn't cause similar performance lisses.
The penalty seems very workload dependent and averages a lot less than 54%.
It seems like it hurts I/O performance a bit like the early spectre fix, which was bad for some games with my large cache 5775c. I have no way of knowing if something similar will happen with the X3D, but I'd look for it to maybe happen with some games that favor that chip over the similar one with regular cache if and when gaming benchmarks for these mitigations come out.
Personally I turned off that spectre mitigation for gaming. Not that these current mitigations should be off for servers, but if you are the only one you are knowingly putting at risk it is your chip, your choice.
Also note that the MariaDB 11 / 4096 clients on IBPB is the big outlier : using safe RET with firmware is a smaller hit, and other DB benches showed far less of an impact. More than likely, a piece of MariaDB code does something that triggers huge number of branch jumping, triggering a lot of overhead, and that may be fixed in a future release - I wouldn't be surprised if Intel's latest mitigation didn't cause similar performance lisses.
I would like to see them benchmark these same software six months from now, with all updates applied. It's possible that a workaround can be done at the software level, and some of that performance loss is mitigated. I mean, MariaDB developers won't just sit still when a firmware cuts half of its performance, right?
If there was ever a reason to upgrade a socketed CPU, this may be it. It could be a win-win for both AMD and the customer. The same applies to Intel. (no, it won't be free or be covered by a class action suit if there is any sanity in this world.). New CPU would be inherently faster and would have all known hardware issues fixed.
Interesting but how would this effect a server user or an average zen3 user? Is the vulnerability worth patching at the performance loss?
Do you use anything on something called the world wide internets? If so you use things that all of these vulnerabilities can exploit. And the servers serving you these exploits and more is what puts them at risk.
Is it worth patching? All depends on what you have to lose and how much you need performance: No money, no credentials/identity worth stealing, or activities of interest to other parties and only the need for max FPS in lame shooting title of the day? Then no, you have nothing to worry about. Otherwise, well, again, it all depends.
If there was ever a reason to upgrade a socketed CPU, this may be it. It could be a win-win for both AMD and the customer. The same applies to Intel. (no, it won't be free or be covered by a class action suit if there is any sanity in this world.). New CPU would be inherently faster and would have all known hardware issues fixed.
