Intel Could Develop its own big.LITTLE x86 Adaptation

[R0H1T]

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.

Like bug said, not every software will need to be modified & those which do should have MS & Intel working with them.

Definitely interesting to see where this leads up to, also what comes after Goldmont Plus & whether Atom will ever get parity with Core.

 

[Fiery]

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.

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.

 

[bug]

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.

Obviously each architecture presents its own challenges. But you get the gist.

 

[Fiery]

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

 

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

 

[Fiery]

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.

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.

 

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

 

[seronx]

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

 

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

 

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

 

[xorbe]

They should have called it Montlake ...

 

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