Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

chipsandcheese.com

Post reply on HN
Print view View original

121–130 of 196 posts

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#121

Post by gpderetta »

Szpadel wrote: post #3

that's probably bad idea but I would like to learn why: why when we have a conditional branch we cannot just fetch and prepare instructions for both possible branches and then discard the incorrect one? is this that much harder or there are other reasons that makes this not worth it

Divergence. On an OoO pipeline fetch might be ahead of retire by hundreds of instructions. That's dozen of branches, and if each causes execution to speculatively fork, it wouldn't scale.

You could potentially do it only for predicted "unpredictable" branches. Now the tradeoff is wasted power and execution units for dead work and so far the tradeoff was just not worth it.

Some form of this has been experimented with. In the late '90 SPRC experimented with scouting threads and as mentioned else thread the Efficient Intel cores can fetch (but not execute) across branches.

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#122

Post by gpderetta »

branko_d wrote: post #21
swatcoder wrote: post #13

Earlier quoted context omitted.

Because it's rare for a branch result to be random. The compiler/runtime/cpu/etc can often guess which result is more likely, and correctly not do the extra work in the first place, and so that's usually the better strategy than spending silicon and heat on the wrong answer just in case. I think a lot of people don't have an intuition about how accurate branch prediction can be, but if you look at your own code, you'…

> it's rare for a branch result to be random How rare, though? QuickSort has fundamentally unpredictable branches, and it’s a pretty widely used algorithm. Binary search, B-trees also come to mind.

Qsort can be implemented branchless by converting the branch into a data dependency.

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#123

Post by manojlds »

The_Colonel wrote: post #75
AceJohnny2 wrote: post #37

Earlier quoted context omitted.

Also in Vinge's Deepness in the Sky, there aren't really "programmers" as we know them anymore, but "programmer-archeologists" that just search the archives for code components to reuse.

That's pretty much what any (decent) programmer does today as well. You first search your code base to see if the application already does something like it, if not, whether there is a published library. Where this starts to fail is the idea that connecting those already written peaces together is easy.

..And then ask an LLM for code

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#124

Post by jeltz »

teaearlgraycold wrote: post #90
ksec wrote: post #74

It will be interesting to see the SMT performance, I am expecting this would provide benefits and be further refined in future generation. With Zen5c we get 192 Core or 384vCPU. We should be getting 256 Core with Zen 6c next year. Which means on a Dual Socket 1U Server, that is a potential of 512 Core with 1024 vCPU. Whatever Web App Scaling issues we had in 2014 could now fit into a single server, assuming we someho…

Web app scaling issues are usually around database latency.

But database performance is also a lot about CPU and RAM speed plus concurrent use of those resources.

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#125

Post by pezezin »

toast0 wrote: post #86
kmeisthax wrote: post #66

Earlier quoted context omitted.

The vulnerability is speculative execution, not branch prediction. The branch predictor is the thing you have to trick to force the processor to speculatively execute code in the victim program. Furthermore you also need a valid timing source to read out the results of the speculative execution. As for how to stop that, short of boiling the ocean[0], you don't. Speculative execution is so valuable for performance tha…

> Speculative execution is so valuable for performance that a computer without it is completely unusable. If you really want a processor without it, buy an old first-gen Pentium. Pentiums have branch prediction and speculative execution. You need to go back to i486 if you don't want speculative execution. Most of the socket 5/7 processors from other makers also had branch predictors and speculative execution, but not…

According to Wikipedia, the original Pentium had branch prediction, but speculative execution was first implemented by the Pentium Pro: https://en.wikipedia.org/wiki/P6_(microarchitecture)#Feature...

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#126

Post by kllrnohj »

emn13 wrote: post #44
orf wrote: post #31

Earlier quoted context omitted.

If the size of the data is small, a linear search through a contiguous array is going to be far faster than anything more complex.

Yep; though we'd have to test a few cases to figure out what the cutoffs are here, and if there's any middle ground left for a divide-and-conquer strategy. It's also definitely going to depend on the cost of the hash function and comparison function - for something like strings, where those can be quite expensive, binary search probably has a better chance of applicability than for guid's say.

For things with non-trivial comparison functions you're all but certainly better off with those in something else like a hashmap. After all, the more expensive the compare, the more expensive the sort & reordering that a binary search requires. And then for trivial comparison objects, binary searching is still slower even at "huge" sizes like 10,000. It's really hard to find a good use of binary searching an array on modern CPUs.

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#127

Post by im3w1l »

adrian_b wrote: post #104
im3w1l wrote: post #59

I still ahve no idea what a 2-ahead branch predictor is.

You can better start by reading the old research papers linked in the article. In general, the older research papers suppose that the reader knows much less about such subjects, because they were still much more niche knowledge at that time.

Okay, so a "block" is a sequence of instructions that can be executed from top to bottom, i.e. only the last instruction may be a jump.

A 2-ahead branch predictor is a branch predictor that predicts not which block to run next after the current one, but rather, which block should be run after that one.

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#129

Post by protomolecule »

masklinn wrote: post #112
protomolecule wrote: post #105

Earlier quoted context omitted.

"with some new ideas from C++ of the time" Could you elaborate on that?

I assume it's the deterministic, implicit, synchronous, single-use destructor. Affine logic only says what you're able to do with a value, it doesn't say anything about what happens when that value goes out of scope.

Hmm, that's possible

Re: Zen 5's 2-ahead branch predictor: how a 30 year old idea allows for new tricks

#130

Post by gpderetta »

pezezin wrote: post #125
toast0 wrote: post #86

Earlier quoted context omitted.

> Speculative execution is so valuable for performance that a computer without it is completely unusable. If you really want a processor without it, buy an old first-gen Pentium. Pentiums have branch prediction and speculative execution. You need to go back to i486 if you don't want speculative execution. Most of the socket 5/7 processors from other makers also had branch predictors and speculative execution, but not…

According to Wikipedia, the original Pentium had branch prediction, but speculative execution was first implemented by the Pentium Pro: https://en.wikipedia.org/wiki/P6_(microarchitecture)#Feature...

The wiki is wrong or at least misleading. Branch prediction is a form of speculative execution.

Even 486 (and possibly 386) had branch prediction (although a trivial one).

P6 was a huge deal because it added out of order execution.

Edit: I guess it is a matter of semantics: in the classical 5 stage in order RISC, instructions after the speculated branch are fetched, decoded, etc, but they won't reach the execution stage before the speculation is resolved, so only the branch is technically "executed" speculatively at the fetch stage. So there is less state to unwind, compared to a true OoO machine that can run ahead.

Post reply on HN