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

51–60 of 64 posts

Re: Intel details Skymont

#51

Post by gary_0 »

adgjlsfhk1 wrote: post #47
gary_0 wrote: post #39

Earlier quoted context omitted.

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

For sqrt() on x86_64 and gcc/clang, yes. But functions like fmod() are generally more instructions. And as for trig functions like sin(), AFAIK most compilers will always use a function call, because the x86 trig instructions don't have good speed/accuracy compared to a modern stdlib.

And YMMV when it comes to other arch's and compilers (and -fmath settings).

Re: Intel details Skymont

#52

Post by dur-randir »

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?

Based on their the current performance, anyone who need it.

Re: Intel details Skymont

#53

Post by MobiusHorizons »

giladvdn wrote: post #33

How do these modern Atoms compare to the Apple ARM chips? Does Apple make something comparable in terms of power/performance?

The competitor would be the efficiency cores on the M-series chips. I don’t know how well they compare though. Apple doesn’t have any skus with only efficiency cores afaik. If they did it would be something like the Apple Watch, but since arm has had big.LITTLE architecture for many years there was no need to have chips with only efficiency cores to achieve efficiency.

Re: Intel details Skymont

#55

Post by vlovich123 »

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

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…

Branches that are hard to predict should be “hand-optimized” through specially written code, compiler intrinsics/annotations, or profile guided feedback to tell the compiler to emit the conditional using unconditional branchless instructions like cmov. Expecting a CPU to detect this at runtime may be asking it to do too much.

Re: Intel details Skymont

#56

Post by phire »

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

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…

> Not having loop handling does seem off

I do agree. The fact that those uop queues are already there and Intel isn't using them as a loop buffer does make me ask questions. Have they just not gotten around to it? Have they decided its not worth the power savings? Maybe they are aiming for simplicity?

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

The thing is, any time the branch predictor has at least one correct prediction, the decode throughput doubles to 6 IPC. And if it gets two correct predictions in a row, the IPC triples to 9.

I'm not sure how many cycles the "execute both sides of the branch" would save on a misspredict, but your basic blocks would need to be very short and the prediction accuracy would need to be very low (like, 50% or lower) before it can actually out-preform the leapfrogging decoder approach on those sequences of code.

> but if you just synthetically insert a split some distance down, you may be misaligned with the actual instruction stream

It only inserts the splits after decoding, so they will always be at the correct alignment.

Re: Intel details Skymont

#57

Post by pclmulqdq »

vlovich123 wrote: post #55
pclmulqdq wrote: post #45

Earlier quoted context omitted.

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…

Branches that are hard to predict should be “hand-optimized” through specially written code, compiler intrinsics/annotations, or profile guided feedback to tell the compiler to emit the conditional using unconditional branchless instructions like cmov. Expecting a CPU to detect this at runtime may be asking it to do too much.

That necessitates executing both sides fully. Very often, those are "business logic" branches that are very long, and you would only prefer to cover branch mispredict penalty.

Re: Intel details Skymont

#58

Post by pclmulqdq »

phire wrote: post #56
pclmulqdq wrote: post #45

Earlier quoted context omitted.

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…

> Not having loop handling does seem off I do agree. The fact that those uop queues are already there and Intel isn't using them as a loop buffer does make me ask questions. Have they just not gotten around to it? Have they decided its not worth the power savings? Maybe they are aiming for simplicity? > However, a large amount of comparative wall time in code is spent on sequences of a short piece of code and a branc…

50% is about as bad as you can get without code that is specifically pathological - that is random guessing.

Re: Intel details Skymont

#59

Post by jorvi »

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…

> or potentially more users switch to an x86-excluded (and, more importantly, third-party excluded) platform (Mac).

Or much more likely, Windows ARM.

Post reply on HN