6 ms·

What are we supposed to draw from those graphs? The AMD part is already much slower than the intel part.

bearjaws 7y ago
I mean, a 15% reduction in effective computation is not nothing just because AMDs CPUs aren't faster. The 8700k has 2 less cores and costs ~$100 more, so now it is not a very compelling purchase if you plan to turn mitigations on. Many people bought the 8700k for a level of performance, that they now need to compromise for: 1) higher performance, small chance of exploits, 2) lower performance and less exploits. This dilemma did not exist until this year, and now everyone is paying for it, besides Intel.
- Skunkleton 7y ago
  The point is that it isn't comparable. It is likely that one of the reasons that the measured intel parts are so much faster is because of insecure optimizations. It would have been a much more interesting comparison to start from two SKUs with similar performance.
  - deleted 7y ago
    [deleted]
  - AnthonyMouse 7y ago
    Isn't that what they've done? The 6800K had been slightly faster than the 2700X, now it's significantly slower. The 8700K had been significantly faster than the 2700X, now it's slightly slower (and yet more expensive). The same for the 7980XE and the 2990WX.
  - Dylan16807 7y ago
    > It is likely that one of the reasons that the measured intel parts are so much faster is because of insecure optimizations. I doubt it. The cost of workarounds is probably far worse than the time saved from using unsafe methods.
- tschwimmer 7y ago
  I wonder if there's a sort of 'herd immunity' effect that would reduce your risk of not running the mitigations. Since the assumption is that this class of exploit is known and patched, it might be less attractive for exploit makers to target. Given that, you can actually disable the mitigation to get the performance back without suffering a breach. I wouldn't do this at a data center or a nuclear powerplant, but for personal workloads like gaming this might be an okay tradeoff.
  - CogitoCogito 7y ago
    This is basically one of the arguments why Linux doesn't have as many exploits. If Linux were in more widespread usage, then more focus would be put on exploiting it and hence running it without e.g. anti-virus or other mechanisms would be more dangerous. So Linux's relative market share might protect it more than many security choices in the OS. (I don't want to claim that any of the reasoning here is true, but I just wanted to point out the parallel to what you're saying.)
  - scandinavian 7y ago
    Well, it remains to be seen if someone can even mount and attack against firefox or chrome. The researchers (RIDL) only managed ~1byte/s against a detached spidermonkey engine, with the old high-resolution timer enabled (these have been removed). They were not able to mount an attack against chrome. I have my doubts that we will ever see attempts at widespread exploitation against browsers. So not running mitigations for personal use/gaming would probably be absolutely fine.
    - szbalint 7y ago
      Google attempted to fix Chrome against Spectre but gave up, so what you're saying about no feasible attack is not true. See: https://v8.dev/blog/spectre https://v8.dev/blog/spectre > we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. Are there many other security issues that are easier to exploit with potentially higher impact? Sure. Does this mean that Spectre is fixed or can be mitigated in software? No. It's a bit like the formerly theoretical timing attacks against TLS: attacks only get better.
- isatty 7y ago
  I do have that CPU but I bought it because it was really close to the X series chips (feature wise) without the extra dime.
robbyt 7y ago
I wonder what other optimizations Intel have made, which could be potential security threats some day...

I mean, a 15% reduction in effective computation is not nothing just because AMDs CPUs aren't faster. The 8700k has 2 less cores and costs ~$100 more, so now it is not a very compelling purchase if you plan to turn mitigations on. Many people bought the 8700k for a level of performance, that they now need to compromise for: 1) higher performance, small chance of exploits, 2) lower performance and less exploits. This dilemma did not exist until this year, and now everyone is paying for it, besides Intel.

Skunkleton 7y ago
The point is that it isn't comparable. It is likely that one of the reasons that the measured intel parts are so much faster is because of insecure optimizations. It would have been a much more interesting comparison to start from two SKUs with similar performance.
- deleted 7y ago
  [deleted]
- AnthonyMouse 7y ago
  Isn't that what they've done? The 6800K had been slightly faster than the 2700X, now it's significantly slower. The 8700K had been significantly faster than the 2700X, now it's slightly slower (and yet more expensive). The same for the 7980XE and the 2990WX.
- Dylan16807 7y ago
  > It is likely that one of the reasons that the measured intel parts are so much faster is because of insecure optimizations. I doubt it. The cost of workarounds is probably far worse than the time saved from using unsafe methods.
tschwimmer 7y ago
I wonder if there's a sort of 'herd immunity' effect that would reduce your risk of not running the mitigations. Since the assumption is that this class of exploit is known and patched, it might be less attractive for exploit makers to target. Given that, you can actually disable the mitigation to get the performance back without suffering a breach. I wouldn't do this at a data center or a nuclear powerplant, but for personal workloads like gaming this might be an okay tradeoff.
- CogitoCogito 7y ago
  This is basically one of the arguments why Linux doesn't have as many exploits. If Linux were in more widespread usage, then more focus would be put on exploiting it and hence running it without e.g. anti-virus or other mechanisms would be more dangerous. So Linux's relative market share might protect it more than many security choices in the OS. (I don't want to claim that any of the reasoning here is true, but I just wanted to point out the parallel to what you're saying.)
- scandinavian 7y ago
  Well, it remains to be seen if someone can even mount and attack against firefox or chrome. The researchers (RIDL) only managed ~1byte/s against a detached spidermonkey engine, with the old high-resolution timer enabled (these have been removed). They were not able to mount an attack against chrome. I have my doubts that we will ever see attempts at widespread exploitation against browsers. So not running mitigations for personal use/gaming would probably be absolutely fine.
  - szbalint 7y ago
    Google attempted to fix Chrome against Spectre but gave up, so what you're saying about no feasible attack is not true. See: https://v8.dev/blog/spectre https://v8.dev/blog/spectre > we quickly discovered that software mitigation of all possible leaks due to Spectre was infeasible. Are there many other security issues that are easier to exploit with potentially higher impact? Sure. Does this mean that Spectre is fixed or can be mitigated in software? No. It's a bit like the formerly theoretical timing attacks against TLS: attacks only get better.
isatty 7y ago
I do have that CPU but I bought it because it was really close to the X series chips (feature wise) without the extra dime.

robbyt 7y ago

I wonder what other optimizations Intel have made, which could be potential security threats some day...