Friday, April 6th 2018

Intel Could Develop its own big.LITTLE x86 Adaptation

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.
Source: Ashraf Eassa (Twitter)
Add your own comment

36 Comments on Intel Could Develop its own big.LITTLE x86 Adaptation

#26
Fiery
FinalWire / AIDA64 Developer
bugEdit: 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.
Well, if Ryzen had one CCX with AVX support and another CCX in the same CPU package with no AVX support, that whole thing would've gone down a whole differently :) Big.LITTLE is not a huge issue on its own, since Windows already supports big.LITTLE processors since Windows 8.1. But previous (existing) big.LITTLE processors always feature homogenous ISA across the small and big cores.
Posted on Reply
#27
bug
FieryWell, if Ryzen had one CCX with AVX support and another CCX in the same CPU package with no AVX support, that whole thing would've gone down a whole differently :) Big.LITTLE is not a huge issue on its own, since Windows already supports big.LITTLE processors since Windows 8.1. But previous (existing) big.LITTLE processors always feature homogenous ISA across the small and big cores.
Obviously each architecture presents its own challenges. But you get the gist.
Posted on Reply
#28
Fiery
FinalWire / AIDA64 Developer
bugObviously each architecture presents its own challenges. But you get the gist.
Yes, of course. I'm only arguing, or trying to point the spotlight on the fact that this issue (different ISA cores in the same system) raises such a challenge that cannot be mitigated by the OS alone. You cannot patch only Windows to solve the issue. It will either work smoothly because Intel cripples the Ice Lake cores by disabling their AVX+AVX2+AVX512 capabilities, to make sure the ISA becomes homogenous; or existing software won't be able to utilize AVX without patching them. Or maybe a 3rd solution...?

BTW, patching existing software may just be impossible with many software IMHO, considering the fact that a big.LITTLE AVX implementation would require major changes in a way how software manages computation threads and explicit thread affinity. You cannot just launch a thread in a mixed-ISA system and rely on the OS to figure out which CPU core can execute the instructions coming up in that computation thread. You need to explicitly iterate through the available CPU cores, detect which one supports AVX, AVX2 or AVX512, and launch a suitable thread on each core by assigning the thread explicitly to that particular CPU core. Otherwise a thread running AVX code may be re-assigned by the OS scheduler to a non-AVX-capable core, etc. etc. Nightmare, really, especially if you have a simple software that only detects AVX capability once, and then just launches an AVX computation task without hassling with thread affinity and other ISA awareness.
Posted on Reply
#29
bug
Yeah, I don't think big.LITTLE is about different ISAs on the same die. It's always the same ARMv7/v8, just with different implementations.
Posted on Reply
#30
Fiery
FinalWire / AIDA64 Developer
bugYeah, I don't think big.LITTLE is about different ISAs on the same die. It's always the same ARMv7/v8, just with different implementations.
That (no AVX support across all cores) would simplify everything immensely, but then the big cores wouldn't be Ice Lake, but only crippled Ice Lake or "Ice Lake Lite". Intel would need to trash most of their ISA-related efforts that they've done since cca. 2007. I also personally cannot see Intel manufacturing a different Ice Lake core just for the big.LITTLE project, just to save die space by omitting the AVX FMA units and replacing them with SSE4 FP units. So if Intel decides to disable AVX+AVX2+AVX512, the underlying hardware would still be able to support it. That would open the door for a special solution to having a cake and eating it too :) Which I imagine would work as a new CPUID bit that would indicate that a certain core in a big.LITTLE system has additional ISA features, but only those software can utilize it that are already patched and prepared to work in such a special situation (of heterogenous ISA). Existing or legacy software would detect AVX+AVX2+AVX512 support using the classic method of existing CPUID bits, and for them the CPU would report no AVX support. No AVX, no crash. But patched software would still be able to exploit the additional ISA features.
Posted on Reply
#31
bug
If they find a way to emulate AVX using other standard instructions, I think they'd be good. It would be (possibly painfully) slow, but that's a low-power core.
Anyway, that's for Intel to figure out, I don't think we need to worry about it here on TPU.
Posted on Reply
#32
seronx
FreedomEclipseTNT?? Thats a pretty dynamite setup
Tremont is TNT
+/*TODO: implement topdown metrics, base metrics interface same as SNC */
+x86_pmu.cpu_events = tnt_events_attrs;
+
+pr_cont("Tremont events, ");
+break;

initconst const u64 tnt_hw_cache_event_ids

tnt in the patch is Tremont.
Posted on Reply
#33
renz496
"big.LITTLE is an innovation by ARM"

honestly i dare to bet they got the idea of big.LITTLE after looking at nvidia "ninja core" inside tegra 3.
Posted on Reply
#34
Steevo
Honestly I expected Zen to have at least two short pipeline, small cache, really high frequency cores, but the amount of scheduling and handoff performance drop, as well the logic to support it may prevent this idea from reaching silicon, plus the ability to fine grain the active core logic and clock speed.
Posted on Reply
#35
xorbe
They should have called it Montlake ...
Posted on Reply
#36
cyneater
I had this idea about 10 years ago.

Have 2 x atom cores in a core2 duo.

Then after some research etc looked like it might be possible.
Found out about arm and some mips chips with similar setups.
Posted on Reply
Add your own comment
Dec 20th, 2024 01:23 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts