Re:$30M Raised to Redo the CPU
by librasteve on Wednesday November 11, 2026 @11:55AM
(#50455593)
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
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.