4 ms·

I 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 C

by ww520 6y ago

I 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 ago
  This 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 ago
  That'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 ago
You 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."
deleted 6y ago
[deleted]

by ww520 6y ago

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 ago
This 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 ago
That'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 ago

You 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."

deleted 6y ago

[deleted]