[deleted]
Intel details Skymont
11–20 of 64 posts
Re: Intel details Skymont
#12[deleted]
Re: Intel details Skymont
#13It 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 bigger waste to have two extra decoders.
Intel's actual approach is way more clever; They run the branch predictor ahead of the decoders by at least 3 branches (probably more). The branch predictor can spit out a new prediction every cycle, and it just plops them on a queue.
Each of the three decoders pops a branch prediction off the queue and starts decoding there. At any time, all three decoders will each be decoding a different basic block. A basic block that the branch predictor has predicted that the program counter is about to flow through. The three decoders are leap frogging each other. The decoding of each basic block is limited to a throughput of three instructions per cycle, but Skymont is decoding three basic blocks in parallel.
The decoded uops get pushed onto three independent queues, and the re-namer/dispatcher merges these three queues back together in original program order before dispatching to the backend. Each decoder can only push three uops per cycle onto its queue, but the re-namer/dispatcher can pull them off a single queue at the rate of 9 uops per cycle. The other two queues will continue to fill up while one queue is being drained.
The branch prediction result will always land on an instruction boundary, so this design allows the three decoders to combine their efforts and maintain a throughput of 9 uops per cycle, as long as the code is branchy enough. It works on loops too, as far as I'm aware, intel doesn't even have a loop stream buffer on this design; The three decoders will be decoding the exact same instructions in parallel for loop bodies.
But Intel have a neat trick to make this work even on code without branches or loops. The branch predictor actually inserts fake branches into the middle of long basic blocks. The branch predictor isn't actually checking an address to see if it has a branch. Instead it predicts the gap between branches, and they simply have a limit for the size of those gaps. Looks like that limit for Skymont is 64 bytes (was previously 32 bytes for Crestmont)
Re: Intel details Skymont
#14TIL rounding denormals to zero is what -ffast-math actually does.
I also learned from experience that -ffast-math only enables the FTZ/DAZ optimization on the main thread, at least on Linux/X86. I don’t know if its universal or this has changed since I debugged it ~5-6 years ago, but that proved to be a bit hard to get to the bottom of since I immediately suspected the big CPU spike when the volume was set very low was caused by denormals, yet we were using the —ffast-math gcc flag.
Re: Intel details Skymont
#15It 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…
I did the math and even on current 13900k/14900k chips each E-core is roughly equivalent to a stock Skylake 6700k core.
Re: Intel details Skymont
#16Earlier quoted context omitted.
> With E cores like this, who needs P cores? Because, presumably, the P-cores are even beefier. Intel and AMD are still trying to gain time on the slow march to ARM (particularly Apple) catching up. Both of their long term strategies seem to differ (AMD edging back into ARM itself, Intel being a little more close lipped), but they can't lose their one major edge (raw performance) or potentially more users switch to a…
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.
Re: Intel details Skymont
#17It 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…
Thank you for that explanation, I was confused as to what was happening with the multiple decoders. That's a wild way to implement a processor front end.
Re: Intel details Skymont
#18It 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…
The two generation old Gracemont already beat Skylake [0]. Skymont can beat Raptor Cove [1] (The big core that was paired with Gracemont).
[0]: https://www.anandtech.com/show/16881/a-deep-dive-into-intels...
[1]: https://www.anandtech.com/show/21425/intel-lunar-lake-archit...
Re: Intel details Skymont
#19More cores and memory channels+bandwidth would have been nice.
Re: Intel details Skymont
#20It 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…
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 makes the cost of miss-predict even higher.