Hacker News Reader

Comment by cenamus | Hacker News Reader

And if not, why did they introduce severe bugs for a tiny performance improvement?

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.

IBM Stretch had branch prediction. Pentium in the early 1990s had it. It's a huge win with any pipelining.

> Does Branch Privilege Injection affect non-Intel CPUs?

> No. Our analysis has not found any issues on the evaluated AMD and ARM systems.

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

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.

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.

The issue is with indirect branches. Most branches are direct ones.

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.

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?

A modern processor pipeline is dozens of cycles deep. Without branch prediction, we would need to know the next instruction at all times before beginning to fetch it. So we couldn’t begin fetching anything until the current instruction is decoded and we know it’s not a branch or jump. Even more seriously, if it is a branch, we would need to stall the pipeline and not do anything until the instruction finishes executing and we know whether it’s taken or not (possibly dozens of cycles later, or hundreds if it depends on a memory access). Stalling for so many cycles on every branch is totally incompatible with any kind of modern performance. If you want a processor that works this way, buy a microcontroller.

> If you want a processor that works this way, buy a microcontroller.

The ARM Cortex-R5F and Cortex-M7, to name a few, have branch predictors as well, for what it’s worth ;)

You can still have a static branch predictor. That has surprisingly good coverage. I'm not saying this is a great idea, just pointing it out.

But branch prediction doesn't necessarily need complicated logic. If I remember correctly (it's been 20 years since I read any papers on it), the simple heuristic "all relative branches backwards are taken, but forward and absolute branches are not" could achieve 70-80% performance of the state-of-the-art implementations back then.

Do you mean overall or localized to branch prediction? Assuming all of that is true, you're talking about a 20-30% performance hit?

Reply on news.ycombinator.com