3 ms·
The problem is AMP is very hard to program and debug. In embedded, one core is a scheduler and another is doing some real-time task (like arm BIG.little). In la
by gotaquestion 5y ago
The problem is AMP is very hard to program and debug. In embedded, one core is a scheduler and another is doing some real-time task (like arm BIG.little). In larger automotive heterogeneous compute platform, typically they are all treated as accelerators, or with bespoke Tier-1 integration (or like NVIDIA Xavier). And on top of that, OEMs always want to "reclaim" those spare cycles when the other AMP cores are underutilized, which is nigh impossible to do, so they fall back to symmetric MP. I think embedded is the only place for this to work right now.
EDIT: I'm not an expert in this field but I have been asked to do work in this domain, and this narrow sampling is what I encountered, but I'd like to learn more about tooling and strategies for more generic AMP deployments.
- astrange 5y agoM1 is an AMP design, as is every iPhone SoC. It works well although you’ll be surprised if you try to run an SMP workload on every single core.
- gotaquestion 5y agoYes, I actually said this in my original post: Arm BIG.little works, which is what M1 is, and embedded works well, which are SoCs. It is much more difficult in AMP systems that aren't necessary only the same die, like automotive Tier 1 products.
- astrange 5y agoHmm, I thought big.LITTLE implied that only one of the cores was active at once and all the tasks migrated from one to the other. M1 doesn't do that, all cores can be on all the time and they just start on one of them depending on priority. Why does it have such a horrible name?