Baby & Arches Canyon: Intel Readies Kaby Lake and Apollo Lake NUCs

[tsk]

Quote

As one might expect, Intel is working on a new generation of its NUC small-form-factor systems based on the company’s upcoming Kaby Lake and Apollo Lake microprocessors

Quote

The new systems are expected to hit the market in late 2016 and early 2017 and bring a number of new technologies, which are absent from today’s SFF PCs. In particular, the new systems will support Thunderbolt 3, USB 3.1 (10 Gbps), HDMI 2.0 and the new processors.

NUC Roadmap:

Spoiler

Baby Canyon(Kaby Lake) specs:

Spoiler

Arches Canyon(Apollo Lake) specs:

Spoiler

OP thoughts; Thunderbolt 3 will be included in the i5 and i7 version of the Baby Canyon NUC, which probably means it will support eGPU like the Skull Canyon NUC. 
This could make for some nice gaming systems using these tiny NUCs paired with an eGPU chassis like the Razer Core.

Source; AnandTech through FanlessTech

[MrDynamicMan]

"Baby Canyon." 

Find whoever created that name and burn him alive. 

[ForsakenLive]

On 16/7/2016 at 7:34 AM, MrDynamicMan said:

"Baby Canyon." 

Find whoever created that name and burn him alive. 

It could have been worse.... "Bae Canyon"

[SurvivorNVL]

I can't wait to see the successor to Skull Canyon.  I almost was going to just get that, and a Razer core to replace my old desktop.

[DrM]

honestly the most interesting part of this news is "baby canyon" another 5% increase in ipc with eadch generation. ill get excited if intel make larger improvements, or if they try to drop the price of nucs.

anyways, baby canyon sounds terrifying. im just imaginaing a canyon filled to the brim with babies *shudders*

[patrickjp93]

4 minutes ago, DrM said:

honestly the most interesting part of this news is "baby canyon" another 5% increase in ipc with eadch generation. ill get excited if intel make larger improvements, or if they try to drop the price of nucs.

anyways, baby canyon sounds terrifying. im just imaginaing a canyon filled to the brim with babies *shudders*

Larger improvements will never happen until software catches up, period. There's nothing Intel can do for old software compiled with old instructions that have had "perfect" latencies since Nehalem. Do you know what instruction has been sharing cycles every generation since then? Integer divide. The other SISD instructions have basically remained exactly where they were. Why? They were already down at 1-2 cycles, and that's the lowest they can go, period. Intel doesn't have the advantage ARM does where

 

1) ARM hasn't matched latencies yet with x86 on comparable instructions, and thus each generation it looks like big leaps are being made that can go on forever (we ground to a halt at Sandybridge after a big jump, so clearly big jumps can hit a brick wall, and logically, they will!

 

2) App software is constantly being recompiled by Apple's and Google's servers for Android and iOS to take advantage of new instruction set extensions for custom architectures and ARM's new cores every 8 months. Not to mention the OSes are too.

 

When you're already at the pinnacle and you've invented the vast majority of CPU innovations for the past decade, you eventually run out of unorthodox things to try to keep legacy software afloat. Branch prediction, result forwarding, loop detection, and multi-ALU channeling are already here. Intel's already short-circuiting many parts of the Superscalar pipeline to cover pipeline hazards with result forwarding and branch prediction that's 99% accurate up to a 7-decision-wide branch. It's already detecting certain "small" (35 instructions iirc) loops and cutting off the fetch stage to make them run faster on a dedicated execution circuit. Intel's also using the superscalar engine and having extra resources to look ahead up to 112 instructions ahead to see if it can reorder and move an operation to a different ALU to increase throughput. Legacy software cannot be improved much more when all of the techniques to circumvent the main problem have been exhausted.

 

So what is the main problem? The software doesn't take advantage of the new strength of Intel's modern hardware! This can be from a bad optimization standpoint going on the fact Intel has turned common algorithms into a single instruction and the software is not updated to use these instructions. This would improve a program's cache density, leading to fewer cache misses and thus higher performance. Going further, the software does not use SIMD instructions either which can increase the density of a loop and reduce it to a size detectable by modern loop detectors and get an even bigger increase than just the increased cache density and just the multiplied throughput of that single operation by 2,4,8, or even 16x!

 

There's no point in being bored, and there's no point in being mad at Intel. We need new software. We need new benchmarks. That's just the reality of it all.

[DrM]

1 minute ago, patrickjp93 said:

There's no point in being bored, and there's no point in being mad at Intel. We need new software. We need new benchmarks. That's just the reality of it all.

im not mad at intel or anything. i understand current limitations. i may have worded it badly, but all im saying is that im no longer excited by these new releases

[patrickjp93]

1 minute ago, DrM said:

im not mad at intel or anything. i understand current limitations. i may have worded it badly, but all im saying is that im no longer excited by these new releases

Which should be a tragedy worth getting angry about. We've more than doubled our compute power since Sandy Bridge. What gives game devs?! What gives Microsoft?! Where's their end of the deal?

[awesomeness10120]

2 hours ago, patrickjp93 said:

Which should be a tragedy worth getting angry about. We've more than doubled our compute power since Sandy Bridge. What gives game devs?! What gives Microsoft?! Where's their end of the deal?

Unfortunately, I doubt developers really care about the compute power until there is an easy way to take full advantage of it. They're lazy.

[patrickjp93]

20 minutes ago, awesomeness10120 said:

Unfortunately, I doubt developers really care about the compute power until there is an easy way to take full advantage of it. They're lazy.

OpenMP and intrinsic functions. Done.