I think my main disagreement with this well established line of reasoning is that a small CPU with dedicated SRAM can have a very low (2 cycle) latency on a very wide (eg 1024 bit) memory bus … so sure running a typical application workload tuned for a few shared memory cores will not improve much. But the raw MIPS/FLOPS per sq mm is much higher and with LLM we have a helper that can adapt to this unusual constraint.

So not general apps, nor pure pipeline DSP tasks that map onto a GPU. But I reckon there’s a lot of ground in between that is open for colonisation.

btw https://bil-lang.org is inspired by Occam style CSP and grafts that into Go … so yes a fast scheduler to overlap at the process level and a way to guide LLM via strict chan and par structure