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

151–160 of 196 posts

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

#151

Post by Dylan16807 »

bayindirh wrote: post #149
Dylan16807 wrote: post #146

Earlier quoted context omitted.

> Serving web pages is cheap. You’ll probably hit network I/O limits before you saturate the cores. It's hard to be network I/O bound when serving web pages. Netflix struggles to be network I/O bound when serving video , which is so much bigger and uses so much less processing. Epyc started off with 32 cores on PCIe 3, and quickly moved to 64 cores on PCIe 4. When we hit 256 cores it's probably going to have PCIe 6,…

I mean, we already run NDR Infiniband, and with sometimes multiple cards per host in our data center, so the numbers are not surprising or out of the this world for me... Terabit Ethernet also is easy. Just 10 100gbit fibers. Again, not much either in port count, or in physical space needs (port count is ample, fibers are thin). What I meant is, in a conventional data center, you'll probably hit your allocated bandwi…

I'm assuming a situation where you'd need more than one server and there actually are bottlenecks. If one server per datacenter is enough, with no bottlenecks, then great you're done.

If your actually-kept-busy servers get 20x faster and your allocated bandwidth doesn't, there's a point where your racks are almost empty and you have some issues to address with the datacenter owner.

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

#152

Post by to11mtm »

gpderetta wrote: post #130
pezezin wrote: post #125

Earlier quoted context omitted.

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 st…

according to this thing I found [0] the 486 has a predictor for the branch not taken. Not sure what that means but it looks like it's mostly for the instruction fetch/decode based on other notes. Ironically sounds close to your 5 stage RISC description, extra ironic because 486 is 5 stages too...

P5 has a more 'real' BP but also had the U/V Pipelining.

But yes as far as OoO goes, I think for x86 it was Nx586 first, then PPro (P6), then Cyrix 6x86 [1] and AMD K6 (courtesy of Nextgen tech) the next year.

[0] - https://people.computing.clemson.edu/~mark/330/colwell/case_...

[1] - Worth noting the Cyrix Coma bug, which was a way to express a flaw in the pipeline. https://en.wikipedia.org/wiki/Cyrix_coma_bug

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

#153

Post by CoastalCoder »

samatman wrote: post #147
CoastalCoder wrote: post #143

Earlier quoted context omitted.

Hey, could someone clarify why all the downvotes? I'd have thought asking for a spoiler alert would be pretty acceptable.

> In a series of books by David Brin [0] there is Is a spoiler alert. Also: > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html

Thanks.

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

#154

Post by phire »

mjevans wrote: post #144
phire wrote: post #94

Earlier quoted context omitted.

> It seems like the lookahead past n+1 would make cache evictions much more likely, so maybe I'm missing something here. The frontend is already predicting dozens of branches ahead of what the backend can actually confirm. Looking ahead by one extra branch ahead doesn't really hurt. Also, modern TAGE branch predictors are scary accurate, well above 99% on most code (including unpredictable indirect jumps). Besides, t…

That seems like a good idea against speculation based attacks too; predict within what is at hand, do not cause side effects.

I didn't even notice that advantage. I was just thinking about how it minimised each branch target entry to about 16 bits.

I suspect Apple are also using it as a way predictor. If the BTB points directly to the correct cacheline and each cacheline points to the next way then the only time you need to do a search is on a branch misspredit.

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

#155

Post by teaearlgraycold »

CodesInChaos wrote: post #113
teaearlgraycold wrote: post #90

Earlier quoted context omitted.

Web app scaling issues are usually around database latency.

In my experience, scaling is limited by database throughput , not latency .

Depends. Most apps that are slow have shitty app code with N+1 queries. If you can get past that stage and write good enough app code then eventually you’ll hit database throughout issues.

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

#156

Post by pezezin »

cesarb wrote: post #131
vegabook wrote: post #57

Now all it needs is more memory bandwidth, because those two memory channels on the consumer AM5 socket are pathetic given the compute this will deliver, and especially in comparison with even the most basic ASi. I moved to an M2 Max from a chunky Zen setup and it's a revelation how much the memory bandwidth improvement accelerates intensive data work. Also for heavy-ish multitasking the Zen setup's narrow memory pip…

> because those two memory channels on the consumer AM5 socket There are actually four memory channels in AM5, because DDR5 doubles the number of channels.

But each channel is half the width, so we are back at the same point.

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

#157

Post by hnpl »

I'd love to see the performance data before judging whether it is a good idea. There's no information on the branch prediction penalty of this approach as well.

Anyway, I think the intuition of this approach is to aggressively fetch/decode instructions that might not already in L1 instruction cache / micro-op cache. This is important for x86 (and probably RISC-V) because both have varied instruction length, and just by looking at an instruction cache block, the core wouldn't know how to decode the instruction in the cache block. Both ISAs (x86, RISC-V) require knowing the PC of at least one instruction to start decoding an instruction cache block. So, knowing where the application can jump to 2 blocks ahead helps the core fetching/decoding further ahead compared to the current approach.

This approach is comparable to instruction prefetching, though, instruction prefetching does not give the core information about the starting point.

(High performance ARM cores probably won't suffer from the "finding the starting point" problem because every instruction has the length of 32-bit, so the decoding procedure can be done in parallel without knowing a starting point).

This approach likely benefits front-end heavy applications (applications with hot code blocks scatter everywhere in the binary, e.g., cloud workloads). I wonder if there's any performance benefit/hit for other types of applications.

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

#158

Post by hajile »

The_Colonel wrote: post #111
topspin wrote: post #99

Earlier quoted context omitted.

> Speculative execution is so valuable for performance that a computer without it is completely unusable. Jim Keller's view aligns with this and goes further. My interpretation of his thinking is that predictors and speculation are the only meaningful features of CPUs today. ISA doesn't matter anymore because the power of modern compilers makes high performance software highly portable and all CPUs end up bottlenecke…

This is so annoying about the hype around ARM, for which even smart people fall. Yes, Apple Silicon is good, but it's not because of ARM ISA. I still keep hearing that ARM is RISC which is wrong since the 1990s.

What about ARM64 is not RISC?

RISC was not just about total instructions, but the complexity of those instructions. It's fundamental conceit is that every instruction should ideally take just one cycle to execute. Intel's iAPX432 is one of the most CISCy designs out there and a great case that ISA does matter. It had instructions for stuff like data structures, OOP, and garbage collection. These things could take LOADS of cycles to execute.

In contrast, pretty much everything on ARM64 integer spec is going to execute in just a cycle or two.

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

#159

Post by hajile »

topspin wrote: post #99
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. Jim Keller's view aligns with this and goes further. My interpretation of his thinking is that predictors and speculation are the only meaningful features of CPUs today. ISA doesn't matter anymore because the power of modern compilers makes high performance software highly portable and all CPUs end up bottlenecke…

Look into Intel's iAPX and tell me that ISA doesn't matter. How would you go about making that pile of garbage into something fast?

Most CISC designs died. A large part of x86's survival is because it wasn't exceptionally CISC.

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

#160

Post by fragmede »

fulafel wrote: post #109
twoodfin wrote: post #49

Earlier quoted context omitted.

On the software side, garbage collection was well explored by academia for more than two decades before the JVM brought it to wide commercial adoption ca. 1995.

Not academia, GC (and lots of other PLT) was mature and productized then, just missed by the majority of the industry living the dark ages. In the 90s, enterprisey architecture astronaut cultures went Java/C++ and hackerish cultures went Perl/Python seasoned with C.

given how much C++ underpins the video game industry, I don't think "enterprisey architecture astronaut" is entirely fair to video game programmers
Post reply on HN