How Do Spectre/Meltdown Fixes Affect The Linux Kernel? (phoronix.com) 29
"Using the newly minted Linux 4.19 feature code, fresh benchmarks were carried out looking at the performance cost of Spectre/Meltdown/Foreshadow mitigations on Intel Xeon v. AMD EPYC CPUs," writes an anonymous Slashdot reader:
Workloads affected by these CPU vulnerabilities mainly deal with I/O and frequent kernel calls while CPU bound tests are still found to be minimally impacted. When toggling these mitigations on Linux 4.19, Intel Xeon CPUs were found to be 10~15% slower with the default kernel while AMD EPYC CPUs dropped to about 5% slower.
Re: (Score:3, Insightful)
Indeed. And this partially explained why Intel was ahead of AMD speed-wise. They played fast and loose and f*** the customer.
Re:EPYC problem (Score:5, Informative)
The only problem with AMD processors is they don't implement transactional memory operations.
I can understand your concern if you need this for research, but as an optimization, transactional memory has so far proved pretty underwhelming. [vt.edu]
Re:EPYC problem (Score:4, Informative)
The only problem with AMD processors is they don't implement transactional memory operations.
Aside some very specific use cases, transactional memory does not offer much in terms of performance. Moreover, transactional memory helps a lot with Timing Side Channel Attacks against the kernel. For example: https://www.blackhat.com/docs/... [blackhat.com]
Re: (Score:1)
On the plus-side, they have far better CPU-CPU interconnect than Intel and always had.
Re: (Score:1)
AMD doesn't even make true multi core CPUs. It's just a bunch of half cores glued together with a hackneyed bus to connect them. I will stick with Intel because they have true multi core CPUs where the cores are all full cores and directly tied together as one CPU.
Re: Haven't noticed much (Score:4)
Basically, this completely erases Intel's single thread advantage over AMD. I am sure that Intel will fix their speculative execution blunders in some future processor generation, I suspect it can be fixed without any slowdown, just re-engineering and maybe a bunch more transistors in the cache and dispatch logic. But by the time Intel does fix it AMD will already be shipping 7nm processors. So I don't see Intel getting back into the high end processor lead any time soon.
It's a one-two-three whammy for Intel. Almost starting to feel sorry for them. Almost.
Re: (Score:2)
The slow downs are from klunky software fixes, as soon as they engineer new chip design to mitigate this, they can get the speed back if they're skilled.
Re: (Score:3)
So I don't see Intel getting back into the high end processor lead any time soon.
Why are you implying they aren't in the lead? Users can chose optimised code paths at the expense of security. We do this all the time and the trade off is in terms of risk vs reward. Just like when you log into your online bank instead of walking to the branch and manually doing your banking you make the same trade-off.
Users don't need to run Spectre / Meltdown mitigations, not only from a choice point of view, but also because the risk profile is so incredibly low for the vast majority of use cases it doe
Re: (Score:2)
What are you talking about. The CPU still performs exactly what they selected. The user chooses to run expensive code that mitigates security vulnerabilities that don't affect most use cases.
Personally I don't have any Spectre / Meltdown mitigations enabled. The security tradeoff isn't worthwhile. Plus if I really wanted security I would print off my packets on the printer, carry them to the computer on the other end of the internet and scan them in again. But ... lag.
Re: (Score:2)
Try compiling a few editions of a popular database server every day. You'll notice.
Re: (Score:3)
Where's the BeOS port you promised us in 1997?
Talk to me about OpenSSH not the kernel (Score:2)