Spectre mitigations murder userspace performance
robert.ocallahan.org
Spectre mitigations murder userspace performance
1–10 of 294 posts
Re: Spectre mitigations murder userspace performance
#2`mitigations=off` in your GRUB_CMDLINE_LINUX_DEFAULT to disable Spectre/Meltdown mitigations, in case anyone is wondering. This page has a pretty decent write-up on it: https://leochavez.org/index.php/2020/11/16/disabling-intel-a....
Re: Spectre mitigations murder userspace performance
#3I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware.
I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient code than hardware anyways.
Look at old game consoles (like a regular old PlayStation) and what they were able to render on what today would be laughably slow hardware. They could do it because developers learned the stack inside and out.
I’m hopeful that the emergence of arm as a desktop/server competitor will help in some ways by putting enough pressure on companies like intel to really rethink some of their core stuff, but who knows.
Re: Spectre mitigations murder userspace performance
#4Should we have a debate as to whether or not Spectre mitigations matter for some (or all) desktop computers? I know that, theoretically, I could install a piece of software on my Linux box that is malware and could try to read my memory via those methods, but let's be honest - we're all mostly concerned with servers that run code for dozens or hundreds of different clients.
I'm a foil hat as much as the next - security is of the utmost concern to me, but for once I actually just don't care and would take the performance back on my local dev machine.
Re: Spectre mitigations murder userspace performance
#5Who is ultimately at risk because of Spectre and Meltdown? What additional risks am I taking on by disabling mitigations?
Re: Spectre mitigations murder userspace performance
#6I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…
See: racing the beam
https://www.youtube.com/watch?v=sJFnWZH5FXc
The things they did with 128 bytes of RAM were amazing.
Re: Spectre mitigations murder userspace performance
#7I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…
> I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”.
Turning off speculative execution reduces performance enormously. Yes, code is often less efficient than it could be but "surprise, you need 5x as large of a datacenter because your hardware isn't doing fancy stuff" is not going to be an acceptable thing for any large organization.
Re: Spectre mitigations murder userspace performance
#8I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…
We’re seeing a full frontal assault on Intel by competing computing architectures. Everyone is jockeying to see who is going to have the better next gen architecture. The problem is that in order to start attacking general computing as a problem, you need first customers who buy a lot of chips, and those customers tend to have specific workloads they want accelerated. Now we’re back to designing for customers instead of abstractly making the absolute best chip.
And that’s the reality right? Demand drives innovation it private enterprise is funding it. If you want a chip for the public good, you’d need to fund it with public money and that’s a different dance with the devil.
In short, I think the way that technology is produced is fundamentally customer focused right now.
Re: Spectre mitigations murder userspace performance
#9Should we have a debate as to whether or not Spectre mitigations matter for some (or all) desktop computers? I know that, theoretically, I could install a piece of software on my Linux box that is malware and could try to read my memory via those methods, but let's be honest - we're all mostly concerned with servers that run code for dozens or hundreds of different clients. I'm a foil hat as much as the next - securi…
Unfortunately "install a piece of software" also includes allowing javascript to run in your browser. So the risk may be closer to "clicking a link".
https://www.zdnet.com/article/google-this-spectre-proof-of-c...
Additionally, the passwords and keys on your local dev box are very valuable for further attacks, like supply chain attacks.
Re: Spectre mitigations murder userspace performance
#10I’ve made similar comments in the past but I think we’re just trying to predict too much about what programs are trying to do in hardware. I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”. Most of the real slowdowns anyone has in day to day performance has more to do with inefficient…
> I’d rather have simple hardware that is light on energy requirements and easier to understand. I don’t think software as an industry really has a “this chip isn’t fast enough problem”.
Have you seen how happy people are with M1 machines? That's because it's faster. It's definitely not simpler.
> Most of the real slowdowns anyone has in day to day performance has more to do with inefficient code than hardware anyways.
Not true, especially not for heat. The energy use of on-CPU/on-GPU tasks is more up to the hardware. It might be true for things like network bandwidth though.