Thoughts on Skymont Slides | Hacker News Reader

Thoughts on Skymont Slides

chipsandcheese.com

36 pointsingve9 comments

A low power core that’s 9-way for decode and 8-way for issue? Did we solve some basic thing that made very wide architectures more feasible? Or addressed the diminishing returns to wider issue? It took Intel about 10 years to go from 3-way issue in the P6 to 4-way in Conroe. But in the last decade we’re up to 8-way in an Atom CPU!

I'm not entirely sure about the backend, but for the frontend Intel has come up with a 'split decoder'. Essentially, Skymont will have 3x 3-wide decoders working in parallel on different parts of the instruction stream. I have no idea how they find points to perform load-balancing between these clusters (outside of taken branches), but the 2x3-wide setup in Gracemont seems to work like a charm after some improvements over Tremont which debuted the split decoder scheme.

> This scheme appeared with Tremont, where it could only switch decoders at taken branch boundarie and Gracemont improves load balancing between the two decode clusters by automatically switching, instead of relying on taken branches. That helps performance in very long unrolled loops, which could get stuck on one decode cluster on Tremont. When we tested with longer loop lengths, we didn’t see any drop off in Gracemont’s instruction throughput:

- https://chipsandcheese.com/2021/12/21/gracemont-revenge-of-t...

Well back in the P6 to Conroe timespan we had that detour for more Ghz with P4 that turned out badly where probably assumed wider issue wouldn't be an issue when you increased the clockrate.

Also back in those days 32bit x86 with it's anemic 8 GP registers (and stack-based-fpu) it was hard to avoid any dependencies w/o trying to calculate memory positions, nowadays we have 64bit x86 with 16 GP registers and separated FPU XMM registers (compilers can leave much more in memory and registers are probably far easier to do dependency resolution on).

Oh and a theory could be that JS,Java,C#,Rust,etc code with lots of non-taken safety barriers(out of bounds, type-tests,etc) has probably been analyzed and been found to be a prime candidate for parallell issue.

38% int IPC gain, 68% float IPC gain. This could be the "Conroe Moment" 2.0.

3x3 clustered decoder, 8 ALU units, and 4x128 vector units. This really is a quiet exciting architecture.

All this complexity, impressive, but still feels misguided. Nearly ten years ago Sun/Oracle put out the SPARC T7 that had 256 threads on a chip (October 26, 2015). x86 just managed that with the AMD Epyc 9754 (Jun 13, 2023).

How did they do that at 20 nm instead of 5nm ? Simpler cores.

Trying to improve single-threaded performance is really just adding epicycles and we need to just move onto more cores. Most of the time your CPU is just waiting, otherwise there wouldn't be all this focus on boost frequencies.

Slow it down it's reliably fed, get rid of the power throttling, because then it's not needed. Less surface area for bugs or attacks. An army of ants is a powerful thing.

Our software ecosystem doesn't work well with an army of ants. I think we'd need a paradigm shift to get there.

Also, FWIW, Xeon Phi hit 244 threads in 2012 and 256 threads in 2016, although it used 4 threads/core.

The Phi is was many-core and not multi-core. It's a much harder paradigm to wrap your mind around. I do recommend learning about it for the new perspective. Try TIS-1000 by Zachtronics.

And we're still running desktop programs that rely on single-threaded performance, remember that the Python GIL removal project only got up to speed in the past year(s) and that's not even mentioning a bunch of other workloads and legacies.

Sparc development could focus on servers and many of those tasks were easy to parallelize so of course they went for cores once they couldn't keep up on the frequency race (esp when selling expensive machines).

>all this focus on boost frequencies

doesn't this mean more single thread performance is wanted/needed?

Reply on news.ycombinator.com