3 ms·

It's not tiny. Speculative execution usually makes code run 10-50% faster, depending on how many branches there are

by bloppe 1y ago

bee_rider 1y ago
Yeah… folks who think this is just some easy to avoid thing should go look around and find the processor without branch prediction that they want to use. On the bright side, they will get to enjoy a much better music scene, because they’ll be visiting the 90’s.
- wbl 1y ago
  IBM Stretch had branch prediction. Pentium in the early 1990s had it. It's a huge win with any pipelining.
- yencabulator 1y ago
  > Does Branch Privilege Injection affect non-Intel CPUs? > No. Our analysis has not found any issues on the evaluated AMD and ARM systems.
titzer 1y ago
That's a vast underestimate. Putting in lfence before every branch is on the order of 10X slowdown.
- grumbelbart2 1y ago
  There is of course a slight chicken-egg-thing here: If there was no (dynamic) branch prediction, we (as in compilers) would emit different code that is faster for non-predicting CPUs (and presumably slower for predicting CPUs). That would mitigate a bit of that 10x.
  - anyfoo 1y ago
    A bit. I think we've shown time and time again that letting the compiler do what the CPU is doing doesn't work out, most recently with Itanium.
- thesz 1y ago
  The issue is with indirect branches. Most branches are direct ones.
autoexec 1y ago
How much improvement would there still be if we weren't so lazy when it comes to writing software. If we were working to get as much performance out of the machines as possible and avoiding useless bloat instead of just counting on the hardware to be "good enough" to handle the slowness with some grace.
cenamus 1y ago
Of course I know that. But if the fix for this bug (how many security holes have ther been now in Intel CPUs? 10?) brings only a couple % performance loss, like most of the them so far, how can you even justify that at all? Isn't there a fundamental issue in there?

It's not tiny. Speculative execution usually makes code run 10-50% faster, depending on how many branches there are

by bloppe 1y ago

It's not tiny. Speculative execution usually makes code run 10-50% faster, depending on how many branches there are

Yeah… folks who think this is just some easy to avoid thing should go look around and find the processor without branch prediction that they want to use. On the bright side, they will get to enjoy a much better music scene, because they’ll be visiting the 90’s.

wbl 1y ago
IBM Stretch had branch prediction. Pentium in the early 1990s had it. It's a huge win with any pipelining.
yencabulator 1y ago
> Does Branch Privilege Injection affect non-Intel CPUs? > No. Our analysis has not found any issues on the evaluated AMD and ARM systems.

titzer 1y ago

That's a vast underestimate. Putting in lfence before every branch is on the order of 10X slowdown.

grumbelbart2 1y ago
There is of course a slight chicken-egg-thing here: If there was no (dynamic) branch prediction, we (as in compilers) would emit different code that is faster for non-predicting CPUs (and presumably slower for predicting CPUs). That would mitigate a bit of that 10x.
- anyfoo 1y ago
  A bit. I think we've shown time and time again that letting the compiler do what the CPU is doing doesn't work out, most recently with Itanium.
thesz 1y ago
The issue is with indirect branches. Most branches are direct ones.

autoexec 1y ago

How much improvement would there still be if we weren't so lazy when it comes to writing software. If we were working to get as much performance out of the machines as possible and avoiding useless bloat instead of just counting on the hardware to be "good enough" to handle the slowness with some grace.

cenamus 1y ago

Of course I know that. But if the fix for this bug (how many security holes have ther been now in Intel CPUs? 10?) brings only a couple % performance loss, like most of the them so far, how can you even justify that at all? Isn't there a fundamental issue in there?