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

141–150 of 196 posts

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

#141

Post by ribit »

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…

While I understand the argument, it would also be good to see some empirical evidence. So far all x86 built need more power to reach the same performance level as ARM. Of course, Apple is still the outlier.

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

#142

Post by dehrmann »

toast0 wrote: post #83
bee_rider wrote: post #8

Earlier quoted context omitted.

I sometimes wonder if there’s an academic career hidden in there for an engineer: go to the library and read what the CS folks were publishing on physical papers, maybe there are some ideas that can actually be implemented now that weren’t practical back then.

Heck. Look at 10 year old product launch PRs from big tech. Anything that Google launched 10 years ago and killed, but seems like a good idea today is probably also easier to do. And if you look 5-10 years before that, you can find the Yahoo launch PR where they did the same thing ;p

I always like to point out Wordle for nailing the timing. Some version of it has been viable since 2000, mass smart phone adoption helped with how it spread, but it could have been viable in 2010. What it did was landed at the right moment.

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

#143

Post by CoastalCoder »

CoastalCoder wrote: post #41
Terr_ wrote: post #33

Earlier quoted context omitted.

In a series of books by David Brin [0] there is a galaxy-wide institution known as the library, and civilizations regularly mine its millions of years of data for suddenly-relevant-again techniques and technologies. I remember one bit where a species had launched some tricky fleet-destroying weapon to surprise their enemies with esoteric physics, only to have it reversed against them, possibly because the Librarian t…

Mind editing that to give a spoiler alert?

Hey, could someone clarify why all the downvotes?

I'd have thought asking for a spoiler alert would be pretty acceptable.

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

#144

Post by mjevans »

phire wrote: post #94
eyegor wrote: post #46

Earlier quoted context omitted.

I think it just predicts 2 branches per cycle instead of 1. So it can evaluate the result of n+2 ahead of time instead of only n+1 (typical branch prediction). How this works without wrecking the L1 cache, I'm not sure. It seems like the lookahead past n+1 would make cache evictions much more likely, so maybe I'm missing something here. > Zen 5 can look farther forward in the instruction stream beyond the 2nd taken b…

> 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.

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

#145

Post by scns »

chrisbrandow wrote: post #15
findthewords wrote: post #10

Earlier quoted context omitted.

Yes, "read 10 year old papers as a source of ideas ripe for commercialization" IS common advice in universities.

A post-doc in my chemistry lab had the saying, “two weeks in the lab will save you a day in the library”

Weeks of work can save hours of planning.

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

#146

Post by Dylan16807 »

bayindirh wrote: post #93
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…

Serving web pages is cheap. You’ll probably hit network I/O limits before you saturate the cores. I wonder what about its HPC performance. I think cooling this won’t be big problem, but might be wet one, requiring DLC after a certain point.

> 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, which means it's still the same I/O per core.

But those numbers are crazy overkill for web serving anyway. If you wanted to allocate about a gigabit per core, with 512 cores across two CPUs, using PCIe 5 to be conservative, you'd need at total of... 16 lanes, for a single 400gb/s card you can buy today.

(This is assuming you mean the I/O from the server to the network. If you're talking about I/O outside the server, then upgrade your switches. Using denser servers doesn't increase your network load, it lets you take the same load and send it to fewer racks. You're already handling the total data somewhere.)

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

#147

Post by samatman »

CoastalCoder wrote: post #143
CoastalCoder wrote: post #41

Earlier quoted context omitted.

Mind editing that to give a spoiler alert?

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

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

#149

Post by bayindirh »

Dylan16807 wrote: post #146
bayindirh wrote: post #93

Earlier quoted context omitted.

Serving web pages is cheap. You’ll probably hit network I/O limits before you saturate the cores. I wonder what about its HPC performance. I think cooling this won’t be big problem, but might be wet one, requiring DLC after a certain point.

> 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 bandwidth limits before you saturate a processor like this while serving web pages, unless you're sitting on a big exchange point or the backbone router is not in the next system hall. A single socket Epyc system has 128 PCIe lanes and 12 channel memory. A complete overkill for such a job unless you serve millions, and only have a basement to put your servers with some very fat network pipes.

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

#150

Post by touisteur »

bayindirh wrote: post #93
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…

Serving web pages is cheap. You’ll probably hit network I/O limits before you saturate the cores. I wonder what about its HPC performance. I think cooling this won’t be big problem, but might be wet one, requiring DLC after a certain point.

As for zen3 and zen4, it's been a pleasure to work with good vectorization perf, and it seems they've been doing avx512 'right', at least for HPC I know.

Add to that the 12 channels of DDR per socket and the quite generous cache, and once you've swallowed the need to buy 24 sticks for 2 sockets, these things are beautiful beasts, at what Intel has taught us, a very reasonable price (ask you OEM for prices, public prices on CPUs are nuts).

Post reply on HN