Read on Twitter
Modern computing comes down to one question: Is it better to fight a dozen really simple CPUs or one really complex one? https://twitter.com/la_rainette/status/1390300170668019719">https://twitter.com/la_rainet...
I suspect we are at a CISC-vs-RISC moment again: CPUs are so horrendously complex that the transistors would be better spent on more but simpler CPUs.
It’s much easier today to have software running in parallel on multiple CPUs than in the ‘80s when we risibly tried to get everyone to code in Occam.
For example, independent parallel operations in embedded system are pretty much inherent in the design.
And graphics has long been software running on multiple simple CPUs (there can be literally thousands in a graphics card) and there’s even a thing called GPGPU now, where number crunching apps are run on the graphics card (including 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="🙄" title="Gesicht mit rollenden Augen" aria-label="Emoji: Gesicht mit rollenden Augen"> crypto mining https://abs.twimg.com/emoji/v2/... draggable="false" alt="😬" title="Grimasse schneidendes Gesicht" aria-label="Emoji: Grimasse schneidendes Gesicht">).
And complex CPUs cost a lot more than just transistors: features like branch prediction are behind hardware security vulnerabilities where critical data (like cryptographic keys) can be leaked. https://en.m.wikipedia.org/wiki/Spectre_(security_vulnerability)">https://en.m.wikipedia.org/wiki/Spec...
You can see from the desktop PC world that complex CPUs are running out of steam: the trend is more more CPU cores per chip, which makes the problem even worse because of shared memory.
Access to shared memory has to be, uh, shared. Which means that CPUs trying to access it at the same time are slowed down. To fix this CPUs get cache memory to keep frequently used copies, but keeping all the copies in sync is a total nightmare of complexity.
And for embedded systems this multi-core shared memory model can be lethal (literally so if a safety critical system). How long code takes to run depends on what memory access patterns there are with code running on another core.
Code can slow down or speed up radically (quite normal to vary by a third slower) if that pattern changed. That has a huge effect on real-time scheduling which can cause real world systems to fail - and intermittently enough to escape detection in testing.
In short: it’s all a mess.
“Add little to little and there will be a big pile” -Ovid
“Add little to little and there will be a big pile” -Ovid
