3 ms·
(As a side-note, can someone who has explored SVE in more detail than I comment on whether it's possible for a big.LITTLE-style implementation to use different
by addaon 6y ago
(As a side-note, can someone who has explored SVE in more detail than I comment on whether it's possible for a big.LITTLE-style implementation to use different vector widths on the big and little cores? One obvious challenge of going to wider vectors on something like the M1 is that you either pay the cost (area and power) for the capability on the small cores, or you lock threads that use those capabilities to big cores, neither of which is ideal. If you could have 128-bit SVE registers on little and 512-bit on big, it would help with that; but it's not clear to me how complex it would be to allow an SVE instruction to be interrupted and restart it on a core with a different vector width. I guess in extremis one could emulate the remainder of the instruction before restart, but eww.)
- thecompilr 6y agoMuch easier would be to break the 512b operation into 4 128b uops on the small cores.
- addaon 6y agoRight. But if you take an interrupt after the two of those three operations, and you want to restart on the big core, what do you do? Disallow interrupts in split operations? Unwind the partially-performed op? Allow the big core to run 128-bit ops to complete this one after restart? Something else?
- ithkuil 6y agoMicro-ops, while require intermediate microarchitectural state, doesn't produce inconsistent architectural state when interrupted. The instruction either retired (produced effects) or didn't, from the POV of the ISA (and thus the kernel and user code)
- addaon 6y agoBut I thought that the SVE extension allowed interrupt and restart of an instruction? The alternative seems like it would lead to potentially very high interrupt latency?
- ithkuil 6y agoI don't know about SVE, just some general principles/thought: you either postpone the serving of the interrupt until the current instruction is done or you throw away progress made in the current instruction. My educated guess is that the latter is most frequently used as a technique. Also traps are caused by the very instruction being executed so you cannot complete the current instruction in all circumstances before vectoring to the trap/interrupt handler.