4 ms·

Which CPU vendor would you switch to? Although Meltdown is (mostly) an Intel bug, all the main CPU vendors, including AMD and ARM, are affected by Spectre, whi

Which CPU vendor would you switch to? Although Meltdown is (mostly) an Intel bug, all the main CPU vendors, including AMD and ARM, are affected by Spectre, which is what this particular discussion is about.

gaius 9y ago
Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance
- mhandley 9y ago
  The problem is that spectulative execution is fundamental to performance in systems that have conditionals. With memory latencies being ~100ns, and a 3GHz core, you waste 300 cycles every time you need to load the conditional from RAM, and maybe 50 cycles if you need to load it from L3 cache. Branch prediction is generally pretty accurate, so avoiding that penalty is crucial if you want to go fast. Now, maybe it is possible to reduce use of indirect branches . C++ for example, is pretty gratuitous in that respect. But in the end, most software is going to perform a lot slower without speculative execution. I don't think that's a price worth paying. What will happen is the CPU vendors will fix meltdown (which should never have happened) and Spectre 2. Sharing the branch history buffer between contexts is something that fundamentally can be avoided, in the same way we can tag TLB entries with the PCID on recent hardware. In the long run, the real issue is Spectre 1. Using software to contain untrusted software in the same address space is fundamentally hard with speculative execution. After all the fuss has died down, that's where we'll see innovative software techniques. It's already starting to happen, if you look at the webkit changes (scroll down to Branchless Security Checks): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
- coldtea 9y ago
  >Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. No, what it matters is understanding the issue. And the issue has no "shenanigans". All vendors suffer from Spectre (and some non-Intel models from Meltdown too), but more importantly, none of these was done "on purpose" which is the definition of a shenanigan. >If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance Whatever.
  - gaius 9y ago
    none of these was done "on purpose" which is the definition of a shenanigan. The “shenanigans” are that it has become acceptable practice to cut corners on security to improve benchmarks. Maybe speculative execution is just a thing that shouldn’t be done? People computed perfectly well before it. Itanium isn’t impacted by Meltdown so Intel is capable of it.
    - sniglom 9y ago
      Intel is discontinuing Itanium. One of the reasons it didn't go well was probably due to the way it was designed.
    - netheril96 9y ago
      So, how do you propose we punish them with the market power? Abandon all products with CPUs in?
    - coldtea 9y ago
      >The “shenanigans” are that it has become acceptable practice to cut corners on security to improve benchmarks. Nobody "cut corners". Those were unexpected bugs that took more than a decade for someone to even discover, not some deliberate decision to sacrifice security for performance. >Maybe speculative execution is just a thing that shouldn’t be done? No, it should 100% be done. >People computed perfectly well before it. Perfectly slowly too. >Itanium isn’t impacted by Meltdown so Intel is capable of it. Itanium tanked.
- shaki-dora 9y ago
  What you're advocating amounts to exposing users to possible harm, hoping that users that are harmed then act to punish Intel. That is not just a convoluted scheme with no chance of effect, it is also morally reprehensible. You're willfully harming people for reasons almost entirely outside their control and expertise. Imagine the coast guard letting people drown "because that's what happens if you buy a cheap boat". Except these people didn't buy cheap boats: Intel is quite obviously the default option, and usually more expensive in case where there actually are alternative. And we haven't even gotten into the difficulty in making moral judgements about Intel's past behavior that led to these problems. Considering these bugs have existed for decades without being exposed, I would tend to think the pitchforks might just be an overreaction. There's a scale that goes intent to harm > accepting harm > accepting the possibility of harm (gross negligence) > not anticipating the risk of harm (negligence). One should calibrate one's outrage to it.
  - gaius 9y ago
    That is not just a convoluted scheme with no chance of effect, it is also morally reprehensible Oh please. If company X sells cars with defective brakes, we don’t change the entire country’s speed limit just in case - it is 100% on the manufacturer to make it right.
deleted 9y ago
[deleted]

gaius 9y ago

Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance

mhandley 9y ago
The problem is that spectulative execution is fundamental to performance in systems that have conditionals. With memory latencies being ~100ns, and a 3GHz core, you waste 300 cycles every time you need to load the conditional from RAM, and maybe 50 cycles if you need to load it from L3 cache. Branch prediction is generally pretty accurate, so avoiding that penalty is crucial if you want to go fast. Now, maybe it is possible to reduce use of indirect branches . C++ for example, is pretty gratuitous in that respect. But in the end, most software is going to perform a lot slower without speculative execution. I don't think that's a price worth paying. What will happen is the CPU vendors will fix meltdown (which should never have happened) and Spectre 2. Sharing the branch history buffer between contexts is something that fundamentally can be avoided, in the same way we can tag TLB entries with the PCID on recent hardware. In the long run, the real issue is Spectre 1. Using software to contain untrusted software in the same address space is fundamentally hard with speculative execution. After all the fuss has died down, that's where we'll see innovative software techniques. It's already starting to happen, if you look at the webkit changes (scroll down to Branchless Security Checks): https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-for-webkit/ https://webkit.org/blog/8048/what-spectre-and-meltdown-mean-...
coldtea 9y ago
>Agreed, but it almost doesn’t matter: what matters is sending the signal that shenanigans will be punished by the market. No, what it matters is understanding the issue. And the issue has no "shenanigans". All vendors suffer from Spectre (and some non-Intel models from Meltdown too), but more importantly, none of these was done "on purpose" which is the definition of a shenanigan. >If devs do anything it should be learning to write software that doesn’t depend on speculative execution for performance Whatever.
- gaius 9y ago
  none of these was done "on purpose" which is the definition of a shenanigan. The “shenanigans” are that it has become acceptable practice to cut corners on security to improve benchmarks. Maybe speculative execution is just a thing that shouldn’t be done? People computed perfectly well before it. Itanium isn’t impacted by Meltdown so Intel is capable of it.
  - sniglom 9y ago
    Intel is discontinuing Itanium. One of the reasons it didn't go well was probably due to the way it was designed.
  - netheril96 9y ago
    So, how do you propose we punish them with the market power? Abandon all products with CPUs in?
  - coldtea 9y ago
    >The “shenanigans” are that it has become acceptable practice to cut corners on security to improve benchmarks. Nobody "cut corners". Those were unexpected bugs that took more than a decade for someone to even discover, not some deliberate decision to sacrifice security for performance. >Maybe speculative execution is just a thing that shouldn’t be done? No, it should 100% be done. >People computed perfectly well before it. Perfectly slowly too. >Itanium isn’t impacted by Meltdown so Intel is capable of it. Itanium tanked.
shaki-dora 9y ago
What you're advocating amounts to exposing users to possible harm, hoping that users that are harmed then act to punish Intel. That is not just a convoluted scheme with no chance of effect, it is also morally reprehensible. You're willfully harming people for reasons almost entirely outside their control and expertise. Imagine the coast guard letting people drown "because that's what happens if you buy a cheap boat". Except these people didn't buy cheap boats: Intel is quite obviously the default option, and usually more expensive in case where there actually are alternative. And we haven't even gotten into the difficulty in making moral judgements about Intel's past behavior that led to these problems. Considering these bugs have existed for decades without being exposed, I would tend to think the pitchforks might just be an overreaction. There's a scale that goes intent to harm > accepting harm > accepting the possibility of harm (gross negligence) > not anticipating the risk of harm (negligence). One should calibrate one's outrage to it.
- gaius 9y ago
  That is not just a convoluted scheme with no chance of effect, it is also morally reprehensible Oh please. If company X sells cars with defective brakes, we don’t change the entire country’s speed limit just in case - it is 100% on the manufacturer to make it right.

deleted 9y ago

[deleted]