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

41–50 of 64 posts

Re: Intel details Skymont

#41

Post by wffurr »

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…

Classic disrupting yourself from below. A little late now that ARM chips from both Apple and now Qualcomm (maybe?) have caught up, but the second best time is now.

I give it 2 more releases max before Intel drops heterogeneous cores and only ships the -Mont architecture.

Re: Intel details Skymont

#42

Post by cptskippy »

gary_0 wrote: post #21
Dalewyn wrote: post #16

Earlier quoted context omitted.

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.

RISC-V is disrupting ARM's low end, the pace it's occupied safely for decades. As RISC-V matures, it will move upstream along the same path that ARM did. The difference is that it will be easier to move because the transition to ARM is demonstrating that companies don't need to be locked to a particular ISA.

Re: Intel details Skymont

#43

Post by CJefferson »

clausecker wrote: post #34
CJefferson wrote: post #9

Earlier quoted context omitted.

-ffast-mast does a whole bunch of things, which I wish people's didn't so commonly combine. For example, I think the things it does which are sensible for most people are: * Rounding subnormals to zero * Disabling signed zeroes * Disables support for 'trapping' (throwing SIGFPE) Then there are the 'middle' things, which annoy some people: * Allow associative operations, and things like sqrt(x y)=sqrt(x) sqrt(y), exp(…

For me, the most important part is -fno-math-errno which allows the compiler to ignore that libm functions are allowed to set errno. This is perfectly safe (unless you rely on that rarely known side effect) and is usually the one flag I explicitly set.

You are absolutely right, I forgot one of the most important things piled into -ffast-math!

Re: Intel details Skymont

#44

Post by BearOso »

wffurr wrote: post #41
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…

Classic disrupting yourself from below. A little late now that ARM chips from both Apple and now Qualcomm (maybe?) have caught up, but the second best time is now. I give it 2 more releases max before Intel drops heterogeneous cores and only ships the -Mont architecture.

Agreed. We've seen this before. Pentium M -> Core.

Re: Intel details Skymont

#45

Post by pclmulqdq »

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…

Oh, I thought the uop queues were uop caches when I looked at the diagram. Not having loop handling does seem off, but I guess with long loops they will just alternate between the decoders.

The whole 99% branch prediction thing is sort of misleading - most branches are loops taken for a constant amount of time, so most are perfectly predictable, and most others are error checks which are also easy to predict. However, a large amount of comparative wall time in code is spent on sequences of a short piece of code and a branch that is hard to predict. Without hyperthreading, I would assume that decoding both sides of the branch would actually help a lot in these circumstances. It sounds like Intel is possibly capable of doing that.

The synthetic basic blocks are also an interesting idea given how hard it is to figure out where an x86 instruction boundary is. It's easy to split a basic block when you have a branch going to that basic block, but if you just synthetically insert a split some distance down, you may be misaligned with the actual instruction stream. That can be self-synchronizing at points, but it's hard.

Re: Intel details Skymont

#46

Post by _ugfj »

kristianp wrote: post #3

So Skymont is the architecture of the Efficiency core of Lunar lake: https://www.anandtech.com/show/21425/intel-lunar-lake-archit... It's so new that the Wikipedia page hasn't been written yet, it still redirects to the old usage of the codename as the previous name of Cannon Lake. Or it should redirect to a Lunar Lake page: https://en.wikipedia.org/?title=Skymont_(microarchitecture)&...

[flagged]

Re: Intel details Skymont

#47

Post by adgjlsfhk1 »

gary_0 wrote: post #39
clausecker wrote: post #34

Earlier quoted context omitted.

For me, the most important part is -fno-math-errno which allows the compiler to ignore that libm functions are allowed to set errno. This is perfectly safe (unless you rely on that rarely known side effect) and is usually the one flag I explicitly set.

And the primary benefit of doing that is so the compiler can inline math functions like sqrt() as a tiny number of instructions (on modern CPUs) instead of having to call the standard C function, which is much slower.

> as a tiny number of instructions

specifically 1

Re: Intel details Skymont

#49

Post by pclmulqdq »

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

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

In all seriousness, the main advantage of the P cores is the wider vector datapath. They are much more set up for loopy "grunt work" like matrix math. Web serving probably doesn't need a P core, for example.

Re: Intel details Skymont

#50

Post by adgjlsfhk1 »

Wait, did they only fix subnormals on the E-cores or did they fix them on the P cores also? It would be really weird if they only fixed this on the E-cores, but I haven’t seen anything saying that Redwood Cove fixed this issue.
Post reply on HN