TR Forums

http://wccftech.com/intel-inverse-hyper-threading-skylake/

The concept here is sort of like VISC, taking multiple cores and getting them to appear as a single one, the opposite of what hyperthreading does, so that each core can work on the same software thread.

The following benchmark is a result of the SPEC CPU2006 suite courtesy of Heise.de. The first 4 points on the x axis represent physical cores, and the next 4 represent logical cores. As you can see, single threaded performance has taken an absolutely huge jump from the Haswell counterpart to Skylake. Infact, the performance doesn’t increase as more threads are activated. It actually goes down. This is a trend that is the exact opposite of the Haswell counterpart in which performance increases as more threads come online. The reason why this could be happening is because all 4 physical cores are already powering the single thread so as more threads come online, software inefficiency results in a declining trend.


This obviously means that there is going to be an absolutely, absolutely massive boost in performance of single threaded applications in which a Skylake processor is used. This is pretty huge folks. Also (caution: opinion), I suspect, part of Intel’s “Global Shortage” has something to do with the fact that they have yet to reveal the biggest selling point of the Skylake processor to the consumers. Which go a long way in exponentially increasing demand.

Not sure I believe it yet, seems like something Intel would shout from the rooftops at the first reviews, but...I guess we'll see soon enough with IDF starting. I hope they're not just seeing Turbo Boost in that graph or something.

Let's run with there being "something new" present and that a random SpecINT benchmark isn't completely madeup.

Here's another option: Skylake actually does have AVX-512 support available in some flavor that isn't being advertized right now. The performance delta in single-core is due to AVX-512 being turned one and ramped up to maximum clockspeeds... considering they are getting scaling of 2.4x, the doubled AVX-512 + higher turboboost speeds might do the trick.

Now, as more cores get turned on, the very big power requirements for AVX-512 require Skylake to downclock quite a bit, so by the time all cores are turned on, we see an advantage over Haswell but nowhere near a 2x or greater advantage.

I'm not saying that's what is actually happening, but it's a hypothesis that conforms to the observed performance in that graph and it doesn't require any sort of exotic "inverse hyperthreading" magic to do it.

chuckula wrote:

Let's run with there being "something new" present and that a random SpecINT benchmark isn't completely madeup.

Here's another option: Skylake actually does have AVX-512 support available in some flavor that isn't being advertized right now. The performance delta in single-core is due to AVX-512 being turned one and ramped up to maximum clockspeeds... considering they are getting scaling of 2.4x, the doubled AVX-512 + higher turboboost speeds might do the trick.

Now, as more cores get turned on, the very big power requirements for AVX-512 require Skylake to downclock quite a bit, so by the time all cores are turned on, we see an advantage over Haswell but nowhere near a 2x or greater advantage.

I'm not saying that's what is actually happening, but it's a hypothesis that conforms to the observed performance in that graph and it doesn't require any sort of exotic "inverse hyperthreading" magic to do it.

That was my first thought, that they're just seeing the higher clock speeds of single core operations at play. I thought that the generational gap shouldn't be that big in turbo boost, but AVX-512 could be an explanation.

This sounds like the computer science equivalent of turning lead into gold...

It's worth noting that both CPUs on that graph have the same base and turbo frequencies. Also, this result has not been borne out by already published reviews of Skylake that test single-threaded performance (so it's not "free" - if it's real, applications would have to specifically support it).

On that note, I wonder if we're gonna hear anything about TSX tomorrow?

(I started writing this before the AVX-512 propositions appeared because I spent a while refreshing my memory on TSX)

That article is pretty misleading; they're taking a block diagram of SoftMachine's VISC core design and showing it with a graph of Skylake benchmarks, then implying that the two are somehow related. That's pretty darned far-fetched if you ask me. There is almost certainly a much more mundane explanation for the benchmark results.

It is an interesting concept though -- essentially ganging together multiple cores to make a smaller number of wider cores when presented with a suitable workload. I suspect the benefit (or lack thereof) would be very application specific though; if there was enough additional ILP available in typical code to make this approach a clear win, we would've seen more wide-core designs by now.

This is completely true and skylake also has morphcores! Intel just decided to launch without telling anyone this!!!!!

I'm /S erious guys!

Yeah...it'd be nice, but I doubt there's anything here other than a potentially flawed benchmark.

just brew it! wrote:

That article is pretty misleading; they're taking a block diagram of SoftMachine's VISC core design and showing it with a graph of Skylake benchmarks, then implying that the two are somehow related. That's pretty darned far-fetched if you ask me. There is almost certainly a much more mundane explanation for the benchmark results.

I'm betting on El Niño being the cause.

I'm not buying it. From an ILP standpoint I think widening the core would make more sense and is far more feasible.

As it says on the chart, we've been punkte.

/ducks

just brew it! wrote:

I suspect the benefit (or lack thereof) would be very application specific though; if there was enough additional ILP available in typical code to make this approach a clear win, we would've seen more wide-core designs by now.

It's a persistent rumor, but that part always seems to be missing. How much parallelism is present in an application is a sliding scale, and exploiting parallelism in hardware has its boundaries. Theres only so much you can do in hardware to take advantage of that if you happen to be dealing with a task that scales poorly or is inherently serial.

ronch wrote:

I'm not buying it. From an ILP standpoint I think widening the core would make more sense and is far more feasible.

They already cannot fully feed the core with one thread in most cases. Not sure how widening it would help in most cases.

They should have just reversed polarity.

[Joke] I thought AMD already had 'inverse hyperthreading'. How else to explain the "8"-core 8370 being about even with an i3-4330. [/Joke]
http://www.pcper.com/reviews/Graphics-C ... ults-Heavy

The true inverse of hyper threading would simply be speculative execution at the thread level. When a branch is encountered, the entire state is copied so that two instances of the same thread run concurrently but differ in the presumption of how that branch resolved. When the final outcome of that branch is calculated, the entire work of one thread is discarded. The step of discarding work is what makes this technique unattractive to Intel as it requires energy to do those discarded calculations.

I've posted some thoughts on morph core designs before. In summary, a neat technology but something I wouldn't expect in Sky Lake due to the timing of development. (It'd be possible for Intel's next architecture after Kaby Lake and Cannon Lake.)

VISC is another interesting technology but don't jump on to the hype train yet: their simulated quad core chip working as one virtual core only managed to double performance per clock. The optimist will see that doubling of performance but the pessimist will point out that it comes at the cost of >4 times the transistors and 4 times the power consumption. While interesting from an academic stand point, the cost isn't worth the benefit according to Intel's internal design rules. Also doubling performance per clock raises up the question of just what are the clock speeds the chip was running at? The 350 Mhz is the figure I've seen floating around for their dual core hardware though I've seen 500 Mhz at a few place. Thus even though it has very high throughput per clock, architectures like Haswell which can reach 4 Ghz will still ultimately be faster. The other thing is that this wouldn't necessarily appear in an Intel chip: rather AMD is an investor into Soft Machines who is pioneering this technology. Furthermore, some of the diagrams used by Soft Machines bare a resemblance to the how Bulldozer works at a high level. MPR paper (PDF)

What I'd like to have seen with Sky Lake is 4-way Hyperthreading and the ability to dynamically change how many threads simultaneously run concurrently on a core. This would have the benefit of increasing throughput while requiring fewer transistors than morph core or VISC.

Talked to Andreas from C't who seems to have sparked this rumor. He was trying to understand a perf gain that came from another place, mostly 2X ring and LLC bandwidth improving performance in SPEC CPU, and so he speculated about this sort of thing. Clearly is not what's happening with Skylake, though, according to Intel's architects here at IDF.

Damage wrote:

Talked to Andreas from C't who seems to have sparked this rumor. He was trying to understand a perf gain that came from another place, mostly 2X ring and LLC bandwidth improving performance in SPEC CPU, and so he speculated about this sort of thing. Clearly is not what's happening with Skylake, though, according to Intel's architects here at IDF.

Thanks Damage!

Skylake is clearly yet another architecture where there are performance improvements but with the major caveat that software has to be properly written to actually take advantage of the new hardware features. The days of huge free-lunch increases for crappy code are long gone and there isn't any magical fairy dust that can give massive free performance boosts, especially to single-threaded code.