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

171–180 of 196 posts

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

#171

Post by kllrnohj »

fanf2 wrote: post #120
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 article has several paragraphs discussing how the decode width of x86 front ends is limited by the need to discover instruction boundaries, which in turn limits the useful issue width. Big ARM cores have much larger decode width than x86 cores, so they don’t need SMT to keep their execution units busy. ISA doesn’t matter any more because all the CISCiest CISCs and the RISCiest RISCs have been discarded (except f…

> Big ARM cores have much larger decode width than x86 cores

Not in general they don't. Apple's does, and Qualcomm's newest Snapdragon X Elite also does. But most big ARM cores don't have larger decode widths than x86 cores. The Cortex-A78 is a 4-wide decode, same as the majority of x86 CPUs on the market. ARM's latest & greatest Cortex X2 is only a 5-wide decode, it only just finally surpassed the original Zen design (4-wide).

Also Zen 5 bumps to an 8-wide decode, the same as what Apple & Qualcomm's best ARM chips can do.

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

#172

Post by hajile »

The_Colonel wrote: post #161
hajile wrote: post #158

Earlier quoted context omitted.

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

Thumb-2, Neon, VFPv4-D16, VFPv4 are mandatory instruction extension sets for ARM64, but there are also optional, widely implemented extensions like AES and SVE. Ain't nothing "reduced" about the ARM CPUs' instruction sets anymore. > In contrast, pretty much everything on ARM64 integer spec is going to execute in just a cycle or two. integer spec is the keyword here. ARM CPUs these days implement much more than intege…

ARM64 threw out the book and started over. Stuff like Thumb-2 or VFPvX are for legacy ISA. There aren't variable instruction lengths and NEON is baked into the core of the ISA.

AES in ARM (and x86 as this was after their attempt to be more RISC-like) was designed to be RISC. A CISC approach would have just ONE instruction that would take the data pointer and number of rounds then do everything at one time. In contrast, x86 and ARM use a couple simple setup instructions, then an AES round instruction (1-2 cycles) that gets called repeatedly then a couple more finalizing instructions.

If you look at the code on any machine, something like 95+% of it is integer code. Integers are fundamental and everything else is a performance optimization.

The float/vector pipeline is a different thing, but it still takes a RISC appoach. 1-5 cycles for most things, a few are 6-7, and a couple like divide and some types of sqrt can take up to a dozen or so cycles (there's a reason they are avoided). This all happens in its own separate pipeline with its own scheduler. All the ideas of being superscalar and avoiding bubbles apply here too. Even the worst case is a far cry from CISC chips where instructions could take dozens or even hundreds of cycles.

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

#173

Post by throwaway2037 »

BitPirate wrote: post #88
IvanAchlaqullah wrote: post #5

It's always interesting to see decades old papers, sometimes published with little to no fanfares, suddenly becomes "state of the art" because hardware have become powerful enough. For example Z-buffers[1]. It's used by 3d video games. When it's first published on paper, it's not even the main topic of the paper, just some side notes because it requires expensive amount of memory to run. Turn out megabytes is quite c…

The EEVDF scheduling algorithm is also a good example. Designed back in 1995 and it's the default process scheduler of Linux now.

I never heard about this before your post.

Wiki tells me: >

Ref: https://en.wikipedia.org/wiki/Earliest_eligible_virtual_dead...

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

#174

Post by bhouston »

tasty_freeze wrote: post #68
bhouston wrote: post #58

Earlier quoted context omitted.

Lisp and Smalltalk and BASIC (to name a few) were popular languages before the JVM that used GC.

When I was in high school, I wrote a Z80 disassembler in BASIC and printed out the entire TRS-80 Model 3 ROM on a thick stack of fan folded greenline paper. I spent a lot of free time figuring out what was what and commenting the code by pen in the right margin. The (string) garbage collector was amazingly frugal and correspondingly slow. Because the garbage collector typically ran only when memory was critically low…

Your description closely matches what is described here: https://en.wikipedia.org/wiki/Garbage_collection_(computer_s...

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

#175

Post by bayindirh »

Dylan16807 wrote: post #151
bayindirh wrote: post #149

Earlier quoted context omitted.

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.

I have written that comment from a datacenter tenant, not as an owner. Of course a proper datacenter providing colo services should have fat pipes to backbone carriers. What I meant is this processor is an overkill just for serving webpages. It makes sense as a virtualization host, or an HPC worker node, software defined storage node or any use case which can flex its muscles. Serving HTML files is not one of them, though.

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

#176

Post by paulmd »

Dylan16807 wrote: post #108
paulmd wrote: post #62

Earlier quoted context omitted.

Regardless though why would it potentially being higher in newer architectures be viewed as a good thing?

> Regardless though why would it potentially being higher in newer architectures be viewed as a good thing? Because SMT getting faster is a nearly free side-effect. We didn't add extra units to speed up SMT at the cost of single-thread speed. We added extra units to speed up the single thread, and they just happened to speed up SMT even more (at least for the purpose of this theoretical). That's better than speeding…

this doesn't seem to reflect the reality of the way hardware is actually being added to the cores, where Zen5 features a fourth ALU which is only useful to a single thread in the low-single-digits.

https://old.reddit.com/r/hardware/comments/1ee7o1d/the_amd_r...

this isn't adding more units to speed up single-thread and SMT being a nice "incidental" gain, this is actively targeting wide architectures that have lots of pipeline bubbles for SMT to fill.

and that's fine, but it's also a very different dynamic than, eg, apple silicon, where the focus is running super deep speculation and reordering on a single thread.

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

#177

Post by pcwalton »

protomolecule wrote: post #105
pcwalton wrote: post #80

Earlier quoted context omitted.

Another example is Rust's borrow checker, which has roots in substructural type system papers from decades earlier. Many academics considered substructural type systems dead (killed by GC, more or less) until Rust resurrected the idea by combining it with some new ideas from C++ of the time.

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

Move semantics and rvalue references. It was clear that within C++11 there was a substructural type system struggling to get out.

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

#178

Post by JonChesterfield »

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.

Lots of water in data centers these days. Works fine. I think the fear about that lost to the utility some years ago.

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

#179

Post by JonChesterfield »

crest wrote: post #115
fulafel wrote: post #101

Earlier quoted context omitted.

SMT could use a lot more benchmarking investigations. Intuitively having more tasks working on the same problem at half speed should have a memory usage cost, are apps commonly using more memory for no speed gain when using SMT? In a lot of published benchmarks it seems most apps don't noticeably benefit in executions peed.

SMT also allows the cores to hide memory latency by executing the other thread(s). Taken to the extreme end this would give you a barrel CPU.

Push the hyperthread count up higher and you have enough stuff to do while waiting on memory that branch prediction doesn't matter as much. Could call it a GPU.

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

#180

Post by JonChesterfield »

jiggawatts wrote: post #164
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…

We're entering the era of "kilo cores" in the same way computing entered the era of kilobytes in the 1940s. If you consider a tightly-coupled rack of servers with GPUs to be one machine, then we're well into the hundreds of kilocores. I found it entertaining having a debate with someone here on HN who just couldn't grok the concept that it's possible to serve something the size of Wikipedia from a single server. That…

Is that actually true, or only that you can serve it from one server behind a lot of servers named CDN?
Post reply on HN