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

Intel details Skymont

chipsandcheese.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Intel details Skymont

#21

Post by gary_0 »

Dalewyn wrote: post #16
metadat wrote: post #8

Earlier quoted context omitted.

Is ARM really that special? Why do you believe this is the case?

ARM is special in that it's the only potential, realistic competitor to x86 left in the entire industry. RISC-V? Only if you're a zealot breathing fumes for life energy, at least as things stand today.

The interesting thing about RISC-V is that there are like 10 billion RISC-V microcontrollers out there that otherwise would have been ARM. So ARM has been moving into the PC/server space while RISC-V pushes in from behind, at the opposite end of the line from x86.

Re: Intel details Skymont

#22

Post by ithkuil »

phire wrote: post #13
pclmulqdq wrote: post #2

It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores? Also, Intel was definitely onto something with the split decoders IMO. The x86 instruction set hurts to decode 8-wide in a single thread, but most code is branchy and loopy, so you only hurt in this configuration if loops are really big. Tight loops come from the uop cache, and branchy c…

> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigg…

If the branch predictor to predict branches ahead it needs to know where the branches instructions are. Is there a mini decoder tasked to just decode the instruction stream just enough to handle the variable length instructions and figure out where the branches are? Or am I fundamentally misunderstanding how branch prediction works (which likely I am)?

Re: Intel details Skymont

#25

Post by phire »

ithkuil wrote: post #22
phire wrote: post #13

Earlier quoted context omitted.

> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigg…

If the branch predictor to predict branches ahead it needs to know where the branches instructions are. Is there a mini decoder tasked to just decode the instruction stream just enough to handle the variable length instructions and figure out where the branches are? Or am I fundamentally misunderstanding how branch prediction works (which likely I am)?

There seems to be a very common misconception about branch prediction, that its only job is to predict the direction of the branch.

In reality, the problem is so much deeper. The instruction fetch stage simply can't see the branch at all. Not just conditional branches, but unconditional jumps, calls and even returns too.

Even a simple 5 stage "classic RISC" pipeline takes a full two cycles to load the instruction from memory and decode before it can see it, and your instruction fetch stage has already fetched two incorrect instructions (though many RISC implementations cheat with an instruction cache fetch that takes half a cycle, and then adding a delay slot).

In one of these massive out-of-order CPUs, the icache fetch might take multiple cycles, (then length decoding on x86), so it might take 4 or 5 cycles before the instruction could possibly be decoded. And if you are decoding 4 instructions per cycle, that's 20 incorrect instructions fetched from icache.

To actually continue fetching without any gaps, the branch predictors needs to predict:

1. The location of the branch

2. The type of branch, and (for conditional branches) if it's taken or not.

3. The destination of the branch

Re: Intel details Skymont

#26

Post by phire »

soulbadguy wrote: post #20
phire wrote: post #13

Earlier quoted context omitted.

> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigg…

I fancy myself of having a good understanding of modern uarch. But i have to agree with @Marthinwurer. This branch predictor structure with parallel predictor and fake branch address is quite wild. Do you know how this compare to what AMD/AppleM/Qualcom is doing ? This seems super effective, but seems pretty power hungry as opposed to just increasing the chase size and predictor precision. Plus i would assume it make…

I'm pretty sure the patten of allowing the branch predictor to run ahead is pretty common.

At least, it's common to have multi-level branch predictors that take a variable number of cycles to return a result, and it makes a lot of sense to queue up predictions so they are ready when the decoder gets to that point.

But I doubt the idea of parallel decoders makes any sense out side of x86's complex variable length instructions.

It (probably) makes sense on x86 because x86 cores were already spending a bunch of power on instruction decoding and the uop cache.

> Plus i would assume it makes the cost of miss-predict even higher.

It shouldn't increase the miss-predict cost by too much.

The new fetch address will bypass the branch-prediction queue and feed directly into one of the three decoders. And previous implementations already have a uop queue between the decoder and re-name/dispatch. It gets flushed and the first three uops should be able to cross it in a single cycle.

Re: Intel details Skymont

#27

Post by gpderetta »

soulbadguy wrote: post #20
phire wrote: post #13

Earlier quoted context omitted.

> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigg…

I fancy myself of having a good understanding of modern uarch. But i have to agree with @Marthinwurer. This branch predictor structure with parallel predictor and fake branch address is quite wild. Do you know how this compare to what AMD/AppleM/Qualcom is doing ? This seems super effective, but seems pretty power hungry as opposed to just increasing the chase size and predictor precision. Plus i would assume it make…

It is actually probably cheaper than the alternative of attempting to decode at all possible instruction boundaries in parallel!

Re: Intel details Skymont

#28

Post by apples_oranges »

srg0 wrote: post #23

Slightly offtopic. What would you suggest as an introductory text on modern CPU architectures?

I would start with a college/university course on the topic, there should be tons of slides and lectures available for free. And only after knowing basic concepts and common approaches I would look for some recent documents, probably they can be downloaded from Intel and other chip makers. But I would say that it all depends on where you are starting from and how deep you want to go.

Re: Intel details Skymont

#29

Post by gpderetta »

phire wrote: post #13
pclmulqdq wrote: post #2

It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores? Also, Intel was definitely onto something with the split decoders IMO. The x86 instruction set hurts to decode 8-wide in a single thread, but most code is branchy and loopy, so you only hurt in this configuration if loops are really big. Tight loops come from the uop cache, and branchy c…

> Tight loops come from the uop cache, and branchy code gets 3-way decoding. First, there is no uop cache on the "mont" cores. Second, Intel aren't decoding both sides of the branch. That wouldn't actually help much, as modern branch predictors are correct well over 99% of the time. It would be a waste of silicon and power to have an extra decoder producing work which simply decoded most of the time, and an even bigg…

Thanks, that's a nice explanation. I hadn't looked in details of how the multiple decoders in the *monts worked. Relying on branches and prediction to find the instruction boundaries is quite a nifty trick.

Re: Intel details Skymont

#30

Post by ithkuil »

phire wrote: post #25
ithkuil wrote: post #22

Earlier quoted context omitted.

If the branch predictor to predict branches ahead it needs to know where the branches instructions are. Is there a mini decoder tasked to just decode the instruction stream just enough to handle the variable length instructions and figure out where the branches are? Or am I fundamentally misunderstanding how branch prediction works (which likely I am)?

There seems to be a very common misconception about branch prediction, that its only job is to predict the direction of the branch. In reality, the problem is so much deeper. The instruction fetch stage simply can't see the branch at all. Not just conditional branches, but unconditional jumps, calls and even returns too. Even a simple 5 stage "classic RISC" pipeline takes a full two cycles to load the instruction fro…

ok that makes much more sense how; thanks!

follow up question: if the branch is predicted to not be taken, why does the predictor have to use resources to record its location and the destination?

Post reply on HN