I made Bil as a way to try and break that - built on Go (and LLVM) under BSD. Quite easy to run up a simple scheduler for any new architecture particularly if they are an LLVM target.
There's also XMOS[2] that appears to have morphed quite far from the original concept but is still focused on parallelism.
The challenge for both is that it's really hard to carve out a decent sized space alongside regular CPUs and GPUs. They can't compete with CPUs on single core performance, and so far can't compete with GPUs on concurrency. Both seemed to try to carve out space in embedded / low powered systems. XMOS seems to have somewhat succeeded (at least they're still alive), while Parallella/Adapteva failed.
Cache coherency is hardly a waste too. For general purpose compute you need at least some mechanism to exchange messages between cores so the transistor budget is needed. It wasn't convincingly demonstrated that CC is worse than alternatives.
I accept that modern day CPUs have co-evolved with modern compiler backends to be highly dependent on OoO - but the case of the many small CPU folks is that for a large class of performance hungry algorithms there are ways to distribute the workload efficiently over many parallel CPUs with no shared memory. In this case then there is a trade off of "does each CPU do OoO and take more die area" vs. "does each CPU NOT do OoO and take less die area" with proportionately more total datapath throughput per mm2.
I submit that for this class of problem, zero or very little OoO is the optimum. In the fag packet designs I have done it looks to me that a 2 dispatch integer pipeline with a small I-cache is fully capable of filling a 32-bit FP datapath (double pass if you want f64, four f16 per cycle) and in turn that can saturate a 256-bit SRAM unified on chip main memory bus. And, of course, the shorter the pipe to flush and the less deep the main memory latency then good things happen.
Realistically in most applications you can get far more processing power than you need because of clock speeds, modern architectures, transistor budgets etc.
A disposable vape can have an arm cortex m0 that runs at 24 mhz and a $1 pi pico can have a dual core m0 that can run at 133 mhz to 200 mhz.
If you want raw math you can use SIMD or a GPU model and if you need single core power you need out of order execution to hide the memory latency, because that's the real bottleneck for the last 30 years.
These multiple tiny cpu core models just don't make sense to solve any real problem and they create a lot with their complexity and latency trying to communicate with each other.
There just isn't some bizarre niche that needs more math instructions with less power consumption. People have all they need even without being efficient. If someone needs more they turn to writing actual optimized software.
The only algorithms that do not care about memory latency are the digital processing algorithms and the like (which include things like video/audio compression and decompression), where there is a continuous stream of incoming data, which must be processed.
Otherwise, whenever you have to read a previously unused memory location from an address that is not predictable by the hardware prefetcher, you must pay the latency penalty.
There are only 2 ways to hide the memory latency, by doing something else while you must wait the arrival of data. You can either execute instructions taken from elsewhere from the current thread, which is OoO and which requires a lot of complex hardware to find which instructions may be executed, or you can use either fine-grained multi-threading or simultaneous multi-threading, where either the programmer or the compiler have taken care to prepare a lot of independent concurrent threads, so that the hardware may execute any instructions from a thread that is not the current one, without having to search and analyze the instructions, to find their dependencies at run-time.
Because this is much easier for programmers, OoO is preferred for CPUs. Where the cost per core must be minimized, FGMT or SMT with a very large number of threads is preferred, like in GPUs.
In the parent article it is said that they will not use OoO, but nothing is said about multi-threading. If neither OoO nor FGMT/SMT are used, the result is a special-purpose processor, not a general-purpose processor, i.e. a processor whose use is restricted to DSP-like algorithms, because otherwise its execution units would stay idle almost all the time.
I have browsed briefly through the documentation of the programming language mentioned in the announcement, but it does not appear to have many features relevant for concurrent programming, not even of the level of the Occam language, which was used for Transputers.
The only unusual feature that I see, is a Fork/Drop thing, which works exactly like reference counts, except that instead of passing references to an object, copies to that objects are passed, which is an optimization that may be useful in a concurrent program, but it is something that can be done by a compiler, without being visible in the programming language.
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
https://bil-lang.org is a more explicit language that imo is needed for coders (or LLMs) to grapple with hammering algorithms onto a CPU array. But AI is a big lever to overcome this historic barrier.