Intel Could Develop its own big.LITTLE x86 Adaptation

[btarunr]

big.LITTLE is an innovation by ARM, which seeks to minimize power-draw on mobile devices. It is a sort of heterogeneous multi-core CPU design, in which a few "big" high-performance CPU cores work alongside a few extremely low-power "little" CPU cores. The idea here is that the low-power cores consume much lesser power at max load, than the high-performance cores at their minimum power-state, so the high-performance cores can be power-gated when the system doesn't need them (i.e. most of the time).

Intel finds itself with two distinct x86 implementations at any given time. It has low-power CPU micro-architectures such as "Silvermont," "Goldmont," and "Goldmont Plus," etc., implemented on low-power product lines such as the Pentium Silver series; and it has high-performance micro-architectures, such as "Haswell," "Skylake," and "Coffee Lake." The company wants to take a swing at its own heterogeneous multi-core CPU, according to tech stock analyst Ashraf Eassa, with the Motley Fool.



Codenamed "Lakefield," this chip combines "Ice Lake" high-performance cores with "Tremont" low-power cores. The "Ice Lake" micro-architecture is expected to power Intel's 10th generation Core processors, and succeeds both "Coffee Lake" and "Cannon Lake." The "Tremont" micro-architecture, on the other hand, succeeds the current "Goldmont Plus" micro-architecture. This chip could have a great many potential applications with high-end notebooks and 2-in-1s, in which the device can benefit from the battery-life of low-power SoC based devices, and the high-end performance when needed.

A chip like this would need popular operating systems to be redesigned to be aware of the asymmetry. That would involve changes to the kernel scheduler, so it could know which threads to send to which cores. Given that Intel's 10 nm process, on which "Ice Lake" is based, is scheduled for a 2019-20 roll-out, "Lakefield" chip may not see a launch this year.

View at TechPowerUp Main Site

 

[seronx]

Anyone want to guess the core counts?

2 ICL Cores
3 TNT Cores

My 0.2 cents~

 

[n-ster]

Nice, this could be pretty awesome if well implemented

 

[Darmok N Jalad]

Maybe it would help with efficiency, but I could also see this as a cost-saving solution by offering more cores for less die space. I think most users don’t need these 6+ core CPUs anyway, but they would certainly appreciate better battery life. Considering recent news, Intel may soon be competing with Qualcomm and Apple in the mobile market more than ever. A 4C big.little chip would probably have some advantages in ultra-thin laptops.

Also, the SD835 already uses big.LITTLE, so perhaps the Windows scheduler is already ready for an Intel version?

 

[Vya Domus]

Don't know what to say , Qualcomm ,ARM and others have years of experience with this architecture already. Intel doesn't have a good track record with mobile SoCs.

 

[_JP_]

Oh look, innovation.
This could turn up to be interesting, H-series cores (35W) mixed with regular cores (65W).
As for Kernel rework, the logic should be there, since both Linux and Windows knows what ARM cores are.

 

[iO]

Uhm, what? The tweet doesnt mention a big.Little concept in the slightest.
Only the integration of Atoms power management of C-States into the Core series...

 

[Vayra86]

Wow Intel, you are so creative, so late to the party and you seem so desperate lately.

Maybe you should release another roadmap, so we understand what you really want to do now.

 

[FreedomEclipse]

Anyone want to guess the core counts?

2 ICL Cores
3 TNT Cores

My 0.2 cents~

TNT?? Thats a pretty dynamite setup

 

[R0H1T]

Maybe it would help with efficiency, but I could also see this as a cost-saving solution by offering more cores for less die space. I think most users don’t need these 6+ core CPUs anyway, but they would certainly appreciate better battery life. Considering recent news, Intel may soon be competing with Qualcomm and Apple in the mobile market more than ever. A 4C big.little chip would probably have some advantages in ultra-thin laptops.

Also, the SD835 already uses big.LITTLE, so perhaps the Windows scheduler is already ready for an Intel version?

I don't know anything about that but Intel isn't competing in that space ever again, they blew tens of billions of dollars in that hole. They sure as hell wouldn't wanna bleed another ten, or more.
The most profitable phone makers are all vertically integrated players like Apple, Samsung, Huawei with the possible exception of BBK electronics & Xiaomi, who have a very low cost base & get by largely using viral marketing & flash sales.

Also a touch of irony here as Intel(?) & many other enthusiasts derided big little as a joke & basically laughed at the idea of many cores in a mobile, a tonne of irony I'd say.

 

[TheoneandonlyMrK]

it could make sense if they went extreme with two small cores in every mainstream Sku ,their effieciency and battery life could then be within reach at least of an allway's on Qualcom based pc, i wonder what die space would be required for that.
two or maybe one low power core could easily prop up stand by , and in some cases media use ,making systems more battery friendly.

 

[newtekie1]

And when they release the 4-Core version of it, they'll have floods of people saying the little cores "aren't real cores!"

 

[Darmok N Jalad]

I don't know anything about that but Intel isn't competing in that space ever again, they blew tens of billions of dollars in that hole. They sure as hell wouldn't wanna bleed another ten, or more.
The most profitable phone makers are all vertically integrated players like Apple, Samsung, Huawei with the possible exception of BBK electronics & Xiaomi, who have a very low cost base & get by largely using viral marketing & flash sales.

Also a touch of irony here as Intel(?) & many other enthusiasts derided big little as a joke & basically laughed at the idea of many cores in a mobile, a tonne of irony I'd say.

I’m not taking about smartphones. I’m taking about WOA laptops and Apple potentially leaving Intel entirely. WOA is not much of a threat today, but when Apple does something, it makes waves. If they can actually push ARM into their desktop environment, I could see Qualcomm and Samsung trying something similar for WOA machines and Chromebooks. Right now, WOA is a novelty, but imagine if they could produce a SOC where emulated performance isn’t so bad?

 

[R0H1T]

I’m not taking about smartphones. I’m taking about WOA laptops and Apple potentially leaving Intel entirely. WOA is not much of a threat today, but when Apple does something, it makes waves. If they can actually push ARM into their desktop environment, I could see Qualcomm and Samsung trying something similar for WOA machines and Chromebooks. Right now, WOA is a novelty, but imagine if they could produce a SOC where emulated performance isn’t so bad?

That makes sense but emulation will always be slower, wrt running native apps. Also porting apps, to ARM, will be a lengthy process even if Apple & MS are both going down that road, since x86 has a rich legacy behind it.

 

[Fiery]

One potential issue about pairing up a set of Ice Lake "big" cores and a set of Tremont "little" cores is the ISA difference. Ice Lake supports AVX1, AVX2 and AVX-512, while Tremont supports none of those. If a process starts a thread that uses AVX, and the OS scheduler pushes the thread from an Ice Lake core to a Tremont core, the process will crash. It would be great to know how Intel is planning to mitigate that. One workaround could be if Intel simply disables any special x86 extensions on the Ice Lake cores to make the ISA balanced across the big and little cores. Another solution might be if Intel kept AVX supported on the big cores, but implemented a special trick to make sure only such software could use AVX that is prepared to run on mixed-ISA processors.

 

[R0H1T]

One potential issue about pairing up a set of Ice Lake "big" cores and a set of Tremont "little" cores is the ISA difference. Ice Lake supports AVX1, AVX2 and AVX-512, while Tremont supports none of those. If a process starts a thread that uses AVX, and the OS scheduler pushes the thread from an Ice Lake core to a Tremont core, the process will crash. It would be great to know how Intel is planning to mitigate that. One workaround could be if Intel simply disables any special x86 extensions on the Ice Lake cores to make the ISA balanced across the big and little cores. Another solution might be if Intel kept AVX supported on the big cores, but implemented a special trick to make sure only such software could use AVX that is prepared to run on mixed-ISA processors.

I'd like to think that a(ny) workload using AVX would prevent the big cores from being parked, though there's also the case of IGP & that'd be a bigger worry IMO. This would also force Intel to perhaps go the MCM route, or full 3d stacking (packaging?) like they're planning post EMIB.

 

[Fiery]

I'd like to think that a(ny) workload using AVX would prevent the big cores from being parked

It's not quite as simple, unless Intel opts for clustered switching. And even still, what if a process with optional AVX support starts up at the small cores, detects the presence of AVX on the small cores (it will be "unsupported" there), and skips using its AVX codepath. While on another case when the same process gets launched on an AVX-capable big core, it will perform better with its AVX codepath. Either way, OS scheduling will become a nightmare if the ISA is not homogenous across the different "size" cores.

 

[R0H1T]

It's not quite as simple, unless Intel opts for clustered switching. And even still, what if a process with optional AVX support starts up at the small cores, detects the presence of AVX on the small cores (it will be "unsupported" there), and skips using its AVX codepath. While on another case when the same process gets launched on an AVX-capable big core, it will perform better with its AVX codepath. Either way, OS scheduling will become a nightmare if the ISA is not homogenous across the different "size" cores.

The OS scheduler, in this case, would prevent the program from switching to big cores, or vice versa. Isn't this how laptops work with a dGPU & IGP?

It's definitely a nightmare but it can work, provided the scheduler prevents a program from jumping to big/little cores which lack specific instructions sets. A number of programs will also need to be updated so that they don't crash the system, doing the switch.

 

[Fiery]

The OS scheduler, in this case, would prevent the program from switching to big cores, or vice versa. Isn't this how laptops work with a dGPU & IGP?

It's definitely a nightmare but it can work, provided the scheduler prevents a program from jumping to big/little cores which lack specific instructions sets. A number of programs will also need to be updated so that they don't crash the system, doing the switch.

How could the OS scheduler know which thread of which process uses (at the moment or is planning to use in the future) a certain x86 ISA extension? When a process starts a thread, it cannot and wouldn't notify the OS scheduler about its plans.

 

[R0H1T]

How could the OS scheduler know which thread of which process uses (at the moment or is planning to use in the future) a certain x86 ISA extension? When a process starts a thread, it cannot and wouldn't notify the OS scheduler about its plans.

It doesn't have to be the OS scheduler, the program could query the kernel which'd direct the OS scheduler to prevent switching the program to the other set of cores. The OS scheduler's role would be to prevent other cores from firing up if the kernel detects the instructions, like AVX or SHA, a program is currently using aren't present on them. If the program isn't using these (other) instructions, then the kernel would allow the switch.

 

[bug]

I'm just going to notice that, as much as big.LITTLE does a wonderful job of throwing bigger numbers at those that by cores by the pound, Apple usually has ARM implementation beat in battery life. Without needing big.LITTLE. Qualcomm used to be pretty good matching big.LITTLE designs with their in-house, traditional designs.

 

[TheoneandonlyMrK]

I'm just going to notice that, as much as big.LITTLE does a wonderful job of throwing bigger numbers at those that by cores by the pound, Apple usually has ARM implementation beat in battery life. Without needing big.LITTLE. Qualcomm used to be pretty good matching big.LITTLE designs with their in-house, traditional designs.

Not surprisingly ,Arm makes cores to adapt the others adapt atm cores to their uses, perhaps you hint at the solution ,a couple of arm cores could work alongside bit x86 one's that could be easier to adjust the os for.

 

[R-T-B]

I'm just going to notice that, as much as big.LITTLE does a wonderful job of throwing bigger numbers at those that by cores by the pound, Apple usually has ARM implementation beat in battery life. Without needing big.LITTLE. Qualcomm used to be pretty good matching big.LITTLE designs with their in-house, traditional designs.

I'm actually not much a fan of big.LITTLE.

There were some serious growing pains with it. Not to mention the ISA issues mentioned above.

Frankly, I don't see intel handling this well. I think this is something we should view with skepticism rather than embrace.

 

[Fiery]

It doesn't have to be the OS scheduler, the program could query the kernel which'd direct the OS scheduler to prevent switching the program to the other set of cores. The OS scheduler's role would be to prevent other cores from firing up if the kernel detects the instructions, like AVX or SHA, a program is currently using aren't present on them. If the program isn't using these (other) instructions, then the kernel would allow the switch.

You cannot expect existing software to be modified to work properly on big.LITTLE systems. It should work out of the box, and with minimal performance impact. Of course, as I've mentioned up there, there're possible workarounds to make sure existing software works with no AVX support, and updated/patched software can utilize AVX on big.LITTLE as well. It will be an interesting thing to see what path Intel chooses.

 

[bug]

I'm actually not much a fan of big.LITTLE.

There were some serious growing pains with it. Not to mention the ISA issues mentioned above.

Frankly, I don't see intel handling this well. I think this is something we should view with skepticism rather than embrace.

Oh, I will give Intel credit for the time being. It's a tech, it would be surprising if they dismissed it out of hand. I was just saying, imho it's not the only way to fix the power drain issue and probably not one of the better ones either. As always, let's wait and see.

You cannot expect existing software to be modified to work properly on big.LITTLE systems. It should work out of the box, and with minimal performance impact. Of course, as I've mentioned up there, there're possible workarounds to make sure existing software works with no AVX support, and updated/patched software can utilize AVX on big.LITTLE as well. It will be an interesting thing to see what path Intel chooses.

Well, not software as in each and every application out there. But you do need new drivers (which Intel should take care of) and probably some level of support from the OS. In the past Microsoft has been more than happy to oblige when Intel needed support for HDCP, arcane features for 4k UHD playback and other crap, I don't see why they won't do the work this time.

Edit: Think about Ryzen: besides some scheduling tweaks in Windows, no software needed updates to work fine with AMD's CCX design. And even then AMD stated Windows' schduler was pretty much fine already.