8 ms·
I'm really curious how they envision this working, given the different instruction sets between the main core and the small cores. That seems like a bit of a n
by Twirrim 6y ago
I'm really curious how they envision this working, given the different instruction sets between the main core and the small cores. That seems like a bit of a nightmare to handle on the OS side of things, unless you turn things in to a two tier environment somehow, and require software (users?) to explicitly opt-in to the small cores somehow.
- ericlewis 6y agoI have seen ARM chips with co-processors that work similarly
- Twirrim 6y agoSure big.LITTLE chips have been around for a while. But my understanding is the instruction set is identical between the cores, they just operate at different speeds. That in itself must be a fun balancing act for the scheduler. To clarify my concerns (I haven't dug in to the specific instruction set differences): Assume the main core supports AVX2 and the smaller cores don't. Which core do you execute the code on? Which one will get you the best performance per watt? How do you account for that in the OS scheduler? What do you want to optimise for? If your code is compiled for AVX2, it'll fail on the small cores unless it does continuous runtime checking (which is expensive, but given processes can migrate between cores, presumably necessary).
- AnotherGoodName 6y agoNo they usually pair different architectures and it will crash if the OS doesn't catch and handle the invalid instruction error the CPU will throw. https://medium.com/@jaddr2line/a-big-little-problem-a-tale-of-big-little-gone-wrong-e7778ce744bb https://medium.com/@jaddr2line/a-big-little-problem-a-tale-o...
- johntb86 6y agoThat's not usual, that's just Samsung's incompetence.
- deleted 6y ago[deleted]
- brigade 6y agoAs mentioned in your link, that's ultimately against ARM's requirements for big.LITTLE and was due to buggy Samsung patches. A fixed kernel only exposes the subset of features available on all CPUs.
- deleted 6y ago[deleted]
- est31 6y agoHow does the scheduler know which process will use CPU instructions that the small cores don't support? Will it just try it out and then move the process to the higher support core if it detects an error?
- AnotherGoodName 6y ago>How does the scheduler know which process will use CPU instructions that the small cores don't support? I don't see that as required? If you catch the illegal instruction signal that CPUs throw you can just run it on the other CPU since the instruction counter would not have incremented. There's a delay in the catch and retry on the other CPU but i don't see the big deal here?
- mtklein 6y agoI once ran into the same sort of issue with this very chip, in that the little A55 cores supported half-float compute, while the big Mongoose cores didn't. Seriously a pain.
- jlouis 6y agoYou do the same with fp. First floating point instruction traps and the process is then flagged as needing fp. This is then used in the context switch to also include fp instructions. The advantage is you avoid storing fp registers unless you are going to use them. That flag could easily determine what you can run where.
- gsliepen 6y agoIt's not so much the speeds that differ, but the micro-architecture. The big cores are typically out-of-order cores with a large amount of cache, to get as many instructions as possible per cycle. The SMALL cores are in-order cores with a small amount of cache. These have a lower IPC, but they also use much less energy per instruction compared to the big cores.
- simias 6y agoCan you give an example? I've seen ARM chips with co-processors with different features (like no MMU for instance) but not a completely different instruction set. Besides in my experience in these configurations the OS doesn't really do much with the other core, it's generally left to specific applications to have code explicitly meant to run on it, there's no automatic scheduling. Unless you think about embedded co-processors that are generally here to control a complex subsystem (like video processing or something like that, arguably GPUs fit in that description) but in general those aren't handled like real CPU cores at the OS level, they have dedicated drivers or userland libraries dedicated to a specific purpose. Something tells me that if Intel wants this architecture to be popular they'll have to work on a tighter and more transparent integration, otherwise this is going to end up like the Cell. It's a pretty interesting approach though, I'm genuinely curious to see how that's going to end up working.
- russdill 6y agoGo look at a modern automotive SoC. R5s, M3s, A72s, M4s, custom arch for real time, DSP, etc. All in one chip.
- simias 6y agoI'm very familiar with some of these chips but my point still stands, in my experience it generally requires tailor-made software to really benefit from these architectures. If these Intel CPUs are meant to be general purpose I wonder how that's going to work out.
- jdsully 6y agoSeems like the OS could solve it easily by trapping on undefined operation exceptions and retrying on the big core. If it still works simply mark the process as big core only.
- londons_explore 6y agoYou could take this idea further... Trap the undefined instructions, and dynamically replace them with a jump to emulation code if running on a little core. Then let the OS and software folks do a systemwide profile to find out which bits of code most frequently run on which cores. Then configure the compiler not to output any instructions not available on the little cores for code which usually runs on the little cores.
- jacques_chester 6y ago> Trap the undefined instructions, and dynamically replace them with a jump to emulation code if running on a little core. This was more or less what VMware pioneered to deal with privileged instructions. I expect there are thickets of patents involved, even if the earliest have expired. But it's likely there is or would be some licensing agreement. Disclosure: I work for VMware, though not in VMs per se. Speaking for myself only.
- jdsully 6y agoThis is how FPU emulation worked back in the 8086-386 days. Any patents are long expired or invalidated with prior art.
- garmaine 6y agoNo, unfortunately not. Only if you implement it exactly as it was done back in the day for FPUs. Any deviation and you might run into a more recent patent that covers some aspect of a later implementation, maybe even something seemingly obvious or necessary. This is why it is called a patent “minefield.”
- 6y ago
- Gravityloss 6y agoWhat's the user and developer experience, do programs need to be recompiled? Are the extra cores meant to typically run something like the JVM so no recompilation is needed?
- sesuximo 6y agoI doubt you will need to recompile, although doing so is often a good idea as new compilers can use new instructions/optimizations. I’d bet money that the different ISAs are full x86 and a subset of x86 which is a great idea. X86 has a lot of old instructions that almost No one uses. Perhaps the small cores will trap and move to process to the big core if it uses an old instruction.
- firethief 6y agoI don't see how the cost of supporting outmoded instructions would be significant. The decoder is a tiny proportion of the die, and not a bottleneck at all. Obsolete instructions that can't be translated to the same uops everything else uses are already microcoded anyway. I'd bet the instruction set difference is mainly level of SIMD support. Sunny Cove will have AVX2, Tremont won't have enough execution units to go wider than SSE2.
- deleted 6y ago[deleted]
- kllrnohj 6y ago> I’d bet money that the different ISAs are full x86 and a subset of x86 You don't even need to bet, it's in the article: "Both SKUs will feature one big ‘Sunny Cove’ CPU core, along with four little ‘Tremont’ Atom CPU cores" It's a different uArch, but the same ISA. The extension support would be the only concern here, which is super minor.
- sesuximo 6y agoGuess that makes it very good bet ;)
- NortySpock 6y agoI was going to joke about Intel "discovering the big.LITTLE architecture" until you said different instruction sets. It will be interesting to hear how they hope that will work out...
- est31 6y agoI think in this instance "instruction set" means "set of supported instructions" instead of "architecture".
- CountSessine 6y agoSure but that’s still a nuisance from the point of view of OS scheduling. You can’t transparently move a process from a big core to a little core or vice versa the way you can with big.little.
- mlyle 6y agoNo, but it can be a small nuisance: you can leave a process eligible to run on any core until it faults for an illegal instruction; then you pin it to the big core.
- rkangel 6y agobig.LITTLE kind of is different instruction sets though - full ARM vs thumb.
- wtallis 6y agoThe full ARM vs Thumb split never had anything to do with big.LITTLE, and was dropped with AArch64.
- CountSessine 6y agoARMv7 and ARMv 8 are full-on thumb2. Big.little has nothing to do with ARM vs thumb.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- mackman 6y agoIBM did this with the PowerPC chips used in the Playstation 3. It was a development headache but part of that was the low power cores were extremely limited... no shared memory so you had to DMA data over and double buffer. They ran mighty fast though. It was a lot like programming a DSP really. If this is anything like that I would expect only some workloads to be pushed to the small cores in a similar way to the way stuff is pushed to GPU today. Frameworks will pop up to make it easier for developers but it will be rough at the get-go.
- rbanffy 6y agoThe Cell was very different, and horrendously hard to program. The SPUs had no direct access to memory and had to be fed via DMA transfers coordinated from the PPUs.
- wtallis 6y agoYeah, there was no way to pretend the Cell was anything close to a traditional SMP design. But Intel's Lakefield and Arm's big.LITTLE are very much meant to be treated as SMP systems, with just a few tweaks on top to deal with/take advantage of the fact that they're not completely symmetrical. That means the CPU designers actually have to be more careful about what functional differences they allow to creep in.
- rbanffy 6y agoI'm assuming the difference in supported instructions will have to be very minimal. OSs will need to be careful not to move a process from one core to another that supports a subset of the instruction set it was expecting.
- masklinn 6y ago> IBM did this with the PowerPC chips used in the Playstation 3 It was a completely different situation, the Cell's SPE were vector coprocessors, they were a completely different architecture than the PPE but they were also interacted with explicitly from the PPE.
- fortran77 6y agoIt's an interesting architecture. We already do this in a way between CPU and GPU. Let the compilers and language libraries figure it out.
- deleted 6y ago[deleted]
- ww520 6y agoI would imagine the difference between the instruction sets of the two CPU types is small since the small CPU is Atom which is not too different from the main CPU. The program machine code can be scanned when loaded to look for specific assembly opcodes to determine the required capability of the CPU to execute it on. The code with instructions not fitted for Atom will be sent to the main CPU only. Edit: Just a thought. The OS can install an illegal-opcode exception handler. When a process is first run on the small CPU, the unsupported opcode will raise the exception. The exception handler can simply set the processor affinity of the process to the main CPU and put it to sleep. The OS will handle it like it normally would - putting the process in the run queue of the affined processor.
- jlebar 6y ago> The program machine code can be scanned when loaded to look for specific assembly opcodes to determine the required capability of the CPU to execute it on. That works as a heuristic, but it's not perfect, since JITs and self-modifying code are a thing. I expect the chip will raise a fault and the OS will move the process.
- aarongolliver 6y agoThis is one of the things we tried when I worked (2011-12) at Intel on QuickIA [0] (dual socket, Atom on one side Xeon on the other). One of my first projects was to write a vectorized matrix multiplication that could only run on the Xeon, so we could demo the fault-to-big-core behavior. [0] https://www.neotextus.net/hpca12.pdf https://www.neotextus.net/hpca12.pdf (I think the "3.2 QuickIA Software Support" section is interesting, if nearly a decade old by now)
- ww520 6y agoThat's true. The code could be modified on the fly after the scanning so it's good to have a last ditch illegal-opcode exception and let the OS catch the exception to migrate the process.
- kllrnohj 6y agoYou would only need to do that scanning if the program had hard requirements like it was compiled to assume AVX512 support was present. Which is going to be extremely rare, since that would already mean an x86 program that's highly non-portable. Runtime detection would be the only actual concern here, but you can easily just advertise the common baseline. As in, just pretend the sunny cove core doesn't support AVX512. The only problem then becomes the big core is potentially slower than it could be, but given how rare things like AVX512 is in typical desktop applications will anyone actually care? EDIT: Oh, and this appears to be what they're basically doing. Even though Sunny Cove itself supports AVX-512, it's being disabled in this application: "One thing we can confirm in advance – the Sunny Cove does not appear to be AVX-512 enabled."
- api 6y agoThe fact that it's heterogenous kills it for me. Remember the Cell Broadband Engine? You could get some pretty crazy performance out of that thing, but nobody used the execution units because the instruction set was different. GPUs get away with it because they are really a completely different kind of processor, but even there GPU processing is under-utilized for this reason. It's really a pain.
- imtringued 6y agoGPUs are underutilized because most workloads simply are not suitable for GPUs. It has nothing to do with the instruction set.
- dathinab 6y agoMy guess is the little cores are mainly for OS background jobs and a view applications which explicitly opt. for it. Also while they have different instructions sets they don't have a different arch, i.e. they have a "shared base" of instructions which likely are good enough for many background applications. Like updaters, downloaders, background mail fetching programs etc. In the end it fits in with their "always connected" approach. Through I'm still somewhat skeptical about the "always connected" approach. Like even in many first world countries always connected is just not a think for many users. Even on phones it not fully given through much more then on laptops.
- rzzzt 6y agoThere was a proof-of-concept "smart network adapter" done by either Intel or MS (don't remember the exact details), which allowed finishing the download of a large file, or receiving emails while the host computer was asleep. I'd imagine tasks like these are well suited for the smaller cores.
- monocasa 6y agoA lot of game consoles have this model too. PS3, PS4, Wii, and WiiU off the top of my head run pretty complex operations on the I/O processor even when the main system is off.
- garmaine 6y agomacOS does this. Calls it a “power nap.”
- dogma1138 6y agoPower nap is when your computer periodically wakes up you are switching power states it’s not exactly the same thing.
- masklinn 6y agoThe big.LITTLE concept was announced in 2011. It's not the concept of using differently sized cores which is odd, it's using cores with different instruction sets.