4 ms·
Totally expected, because they need to increase performance and lower battery consumption. Now the extent of taking job from main Intel's CPU and spectrum of po
by Philipp__ 10y ago
Totally expected, because they need to increase performance and lower battery consumption. Now the extent of taking job from main Intel's CPU and spectrum of possibilities of ARM coprocessors are yet to be seen. I can see it doing some hardware related tasks that do not interfere with actual higher stack of macOS and x86 space. But this is all pretty common. This title looks little clickbaity imho.
- throwawayish 10y agoI expect the same. Prior approaches to mixing architectures in one system and actually moving applications at runtime dynamically, as in big.LITTLE, were either far too complex to target or far too inefficient (1). I also don't see a technological enabler here, that would change anything about either. (1) - I can only imagine it with a virtualized ISA ala IBM. Still - even they didn't do that. The capabilities only exist in separation: eg. IBM TIMI allows to move applications across physical processor ISAs, while various clustered virtualization implementations can move live VMs across distinct hosts.
- pertymcpert 10y agobit.LITTLE isn't a mixing of architectures, it's a mixing of micro-architectures. And the fact that big.LITTLE designs are commonly used now, and even Apple adopting their own version of it in their latest SoC is a validation of its benefits.
- throwawayish 10y agoPrior approaches to mixing architectures in one system (and actually moving applications at runtime dynamically, as in big.LITTLE,) were ...