$30M Raised to Redo the CPU
tendrils.co
tendrils.co
The history of general-purpose massively parallel machines isn't good. From the Illiac IV to the Playstation 3, there's been dud after dud in this space. You can build them, but the users don't come. This sort of architecture is great if you have some specific problem that parallelizes, such as finite-element analysis or neural networks.
(I've used an NCube, and I kind of liked the Transputer concept. But both were dead ends.)
Personally, I wasn't impressed by the press release. It is so vague that it makes it look like they don't know the history of their field or they are outright ignoring it to make their product sound novel. The former is just as problematic as the latter. There are reasons why parallelization is typically offloaded onto coprocessors and reasons why the introduction of new CPU architectures are rares.
Failure is all but guaranteed---a chip is nothing without a computer-manufacturing-distributing ecosystem, which implies handsomely beating existing CPU/GPU makers, which is practically impossible.
My feeling: It is a worthwhile endeavour, in any scenario, for those building the thing.
- Boom: An "Epic win" outcome for these people would likely be exit to a leading chip maker, about a decade out from today.
- Base: Success would probably look like becoming a mini Texas Instruments type, making specialist CPUs for orgs that can build their own computers around said chip.
- Bust: Failure would likely be a fire sale into some giant IP portfolio (hopefully not a patent troll... that would be tragic).
The $30m will get spent in no time if they're patenting as they go along, btw.
That being said, it is great that people are still attempting to disrupt the hardware space, even if there's dud after dud historically. Got to respect that!
From an armchair commentary perspective, my understanding was that the PlayStation 3's Cell processor had essentially two practical issues:
- It required extra talented software developers to be able to utilize the hardware to its potential.
- Almost all game makers wanted to also target the Xbox and potentially also PC which further discouraged the writing of platform specific code to truly utilize the unique capabilities of the Cell processor.
However, with AI today, it's completely possible that it changes the economics of being able to write software which can fully utilize new and novel architectures affordably.
So perhaps if the a Cell like processor was released today it would be more successful.
The idea of the Cell architecture is that programs were supposed to be organized as an assembly line, with data flowing into a processor in a stream, and coming out the other side after processing. That's a good fit to audio processing.
Each of the seven support processors had only 256KB (not MB) of local RAM, plus a wide long-latency path to the 256MB main memory, the other support processors, and the PowerPC CPU.
That 256KB was the problem. Not enough for a frame. Not enough for a level. Not enough for AAA title games.
That's the problem with the lots of little processors approach. If all the little guys are memory-starved, you can't get much done, except on very regular problems. Finite element analysis and neural nets are the big wins for such architectures. They're not general purpose.
Note that GPUs aren't arrays of isolated CPUs. All units work against the same memory, mostly. They're closer to shared memory multiprocessors.
I'm not complete sold on that one. You will need training material. While there have been impressive results even for architectures/programming languages for which I would not have expected to be much training material to be available, there will be a minimum. I'm afraid for a new architecture unlike everything else, your AI coding assistant won't be of much help.
Nvidia bought the architecture and killed it, which kind of proves your point.
The other problem is that automatic parallelism with the right language is actually easy, but the scheduling cost eats the gains because you cannot launch subtasks in the 100s of nanoseconds timescale.
What's needed is hardware accelerated scheduling within the same process so that you are no longer being slowed down by the software scheduler in the kernel.
Single threaded programs being normal was originally from almost no systems having more than one core or CPU. Then there were few languages that had threading built in. Someone knowledgeable would have to use the OS API to launch threads.
After that threading has mostly come from structures that are already built. There is nothing difficult about copying data if that's what people want to do. There is nothing that says scheduling has to be slow since you can have threads taking data from a queue. None of this has anything to do with rust.
you are no longer being slowed down by the software scheduler in the kernel
This isn't necessary if you just create threads and let them grab data they need, work on it and move on.
Vine is based on interaction nets, so I guess they are doing some kind of parallel graph reduction? Historically the problem with those kinds of architecture is they were used to run languages with poor locality, and the low-level execution model relied on mutation even when the higher-level languages were pure. Dunno how interaction nets address those problems.
Pitchbook shows it as "Out of Business" since 2019.
For comparison, RISC-V started years later and had a tapeout within a year and working silicon available as a commercial product in less than seven years.
2003: Mill computing started
2010: RISC-V project started
2011: RISC-V first tapeout
2017: RISC-V production chips available in the market
2019: Mill computing dead?
The Mill was (is?) a much bigger swing, with much bigger problems to solve in getting to production.
They specifically wanted to avoid the kinds of "quirks" that vendors like Intel and ARM used to make people subject to their patents.
They did try to avoid what they saw as the blunders of past designs, like not leaving enough opcode space for compressed instructions, making instructions conditional, leaving out byte and halfword memory access instructions, having a flags register, having a complicated page table structure, having register windows, having delay slots, etc. None of that was innovative. The actual design of the compressed instruction set and the vector instruction set were innovative, but that came later.
The Mill was the opposite extreme.
Sure, but even so they should have made real chips and iterated on silicon, not just simulations.
It’s the SpaceX rapid iteration development cycle vs NASA waterfall.
Even in 02016, I don't think US$2M was enough to tape out a silicon prototype of a working high-performance CPU. MPW ("shuttle") programs can give you working prototypes for as low as US$3000, but only in process nodes a decade or more behind the state of the art. (This is fine for analog, but for high-performance digital designs it's generally fatal.) US$30M is a much more plausible budget for the multiple rapid-fire tapeouts you need for anything close to a state-of-the-art process.
Huh? LB(U) / LH(U)
https://www.sigarch.org/distance-based-isa-for-efficient-reg...
Profile: https://news.ycombinator.com/user?id=igodard
Presentation: https://www.youtube.com/watch?v=QGw-cy0ylCc
Who's the customer that wants an exotic architecture on an old process node running a custom programming language half a decade from now?
others have made entire OS's or gone back in time reinventing of removal of the OS and just running a single application with its own I/O stack per application
this is a guess that exotic architecture on old nodes means that the hardware can come out now at a lower price - or at least fulfill market needs at the price the market can bare without the delay - all because using exotic architecture is easy now, unstable opaque drivers are no longer an issue, and there is just a need to fulfill compute demands efficiently
this technology to make it easy is only a couple quarters old
the antiquated understanding of “CUDA being sooo stable and AMD drivers not” just takes a while to be revised
hyperscalers are buying AMD GPUs
AMD’s stock has tripled this year based on investment into their driver stack getting better and others realizing they don’t need to wait for AMD to fix their driver stack in order to leverage the compute
Doesn’t really matter how easy rewriting something is, it’s still a waste of time if it brings no value.
Sounds like this is trying to go an order of magnitude further past that, but I'm not particularly optimistic it'll amount to much.
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.
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 signal 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. When you have a continuous stream of input data, you do not need a von Neumann architecture. The execution units could be organized in a systolic array or the like, through which data flows continuously.
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 and for compilers, 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 at 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 object 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
I think the on-chip bus interconnect and ALU are probably going to have some finite width, though. Above that number of bits in an operation, your instructions will get slower. Maybe that's what you have in mind, and you just want to abstract that away?
But I'm thinking more about having multiple logical CPUs, ALUs, or ports working on a single giant register. I think SIMD wastes a lot of hardware.
Example: radix sort needs to calculate a prefix sum. As the sum accumulates, it requires more bits, so the bit length should be adjustable. On x86, you can cast an array of bytes to a uint64_t and calculate eight prefix sums with a single multiplication. But eventually, you run into SWAR lane overflow problems. Ask an AI what this means and how the code works.
We need a CPU designed to handle lane overflow and dynamically adapt bit lengths, so at the start we do more parallel sums with less bits, and as the sum accumulate we increase the bit length gradually. This is just a simple use case. We could store more prefix sums as a periodic sum more deltas.
Besides a lower clock frequency, such a CPU would also have a power consumption, due to a greater total capacitance of the internal nodes.
The number of problems whose solution could be accelerated by such a structure is too low to make it worthwhile.
The latest SIMD instruction sets have a lot of instructions that handle the entire SIMD registers as bit strings, with which many clever algorithms can be implemented, so there is not a lot more that could be done by explicitly partitioning the register file into registers of arbitrary length.
For instance AMD Zen 6 has just introduced a so-called bit-matrix multiplication and bit reversal instruction set extension, which will also be available in future Intel CPUs.
Despite their name of "bit matrix multiplication" which does not suggest much, those instructions (which use either OR reduction or XOR reduction) can implement a great number of bit manipulation techniques, by choosing some appropriate bit string constants for some of the operands (which will mask parts of arbitrary lengths of the bit strings that are combined).
In general, even with the older instruction sets, you can use the SIMD registers as if they would be the concatenation of an arbitrary number of registers of arbitrary lengths.
The only difference from your desired CPU is that you must intercalate in any algorithm many register masking and register copying instructions, which would not be necessary in your desired CPU, because it would remember the current register set configuration with its number of registers and their lengths, until you change it again.
The addition of all the extra instructions needed to simulate a CPU with registers of arbitrary lengths could be done by a compiler or interpreter designed for this.
You'd essentially have a 1 bit processor with a cache that translated groups of bits to whatever memory access width was. CPUs already fill cache lines with transfers wider than registers, so the theory is there.
There's always a sweet spot for bang-for-buck on any tunable size like that. I doubt it is at 1-bit unless you can figure out how to do cache coherency with a few million cores.
I loved the mill architecture (self declared clean sheet cpu).
I thought transmeta had a good chance because they could inline across kernel boundaries.
But none of them was special enough.
Err..
Are Apple Silicon and Nvidia Vera and Amazon Graviton are considered illegitimate or non-competitors for some reason?
Also some GPU instructions are several times more complex than the most complex cisc instruction from the 90s.
To be honest, CISC versus RISC has not been a useful distinction in architecture design for 30 years. Intel managing to make a superscalar CISC processor, the Pentium, should have put to bed any idea that there's a fundamental distinction between CISC and RISC that is useful.
The reality is that RISC isn't a single idea so much as it is a collection of ideas for how to design a microprocessor, and some of those ideas have turned out to be good and some of them have turned out to be bad. Rather than evaluating on the merits of RISC or CISC, we should evaluate on the merits of the embodied ideas. Let's stop trying to view 2020s design decisions based on 1970s models, okay?
It's not like CISC or RISC are architectures like Transformers or Mamba. They're design philosophies with a huge amount of overlap and leeway.
I mean if we look at it from a birds view the difference between the two is fat decoder or slim decoder.
That's not very much to work with.
Subject: x86 evolution for segmentation and paging
https://lore.kernel.org/lkml/CAKSQd8WX6xH7=njcGZNNFe8m1xbyhC... https://sourceware.org/pipermail/binutils/2026-September/151...
no-can-do the legacy-at-any-cost cargo cult crowd will say, of course
but... someone did apparently build it at scale already... so... who knows, eh?
All the best to anyone trying to design a new paradigm of processor, but I'm interested to hear how they'll avoid the pitfalls of their predecessors.
It’s a reasonable bet that LLMs will make translation to other architectures effectively automatic. So that moat may completely disappear.
I couldn't quite follow the diagrams of the theory page, but I'd be willing to bet a very small sum of cash that it'll eventually be something very much like the BitGrid.
"Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences. To make this possible, we’re working in tandem on the open-source language Vine, which has been designed from the beginning to target a new wave of parallel-first architectures."
I wish them well but from their Vine language docs:
"For example, a < b < c is equivalent to (a < b) & (b < c)"
So how do you parallelize that? You can run the first part on 2 cores in parallel, but there is still a single check, a single cache, a single CPU for this to go through to complete the operation, right?
They just described a common superscalar optimization thats been done since the 90s.
Tl;dr: Vine offers explicit versions of short circuiting and non-short circuiting conditions, but non-short circuiting is the default. The above explains that because it uses the `&` operator rather than the `and` operator.
Broken down further: Short circuiting means you can defer computing everything needed to know `c` until you have confirmed you need to know c to answer the comparison chain. If a < b then you might save a ton of work by not needing to ever calculate everything leading up to c. If a >= b then you've now held off even starting to find out what c was until you need to know what c is.
If you have a ton of parallel compute then it's not as big a deal to always compute all 3 in parallel at the same time, even if sometimes a lot of that compute was not needed to answer the question. The upside is you always finish in the shortest amount of time possible, even if c is a ton of work to figure out.
But they are ignoring the basic lesson of "new" CPU designs from Transputer to i432 to Itanium to Transmeta.
A new CPU design is easy, it is the compiler to use it that is the hard hard part.
Looked at another way, CUDA is a huge reason NVidia is so big right now. Their GPUs are broadly similar to AMD. Their software libraries are better.
But good luck to them, perhaps they have some great new idea. We need one.
We're in a wildly different world from the one Itanium got to live in and compilers are something with a super tight automated verification loop that can make LLMs thrive. Add that plus cheap formal verification and I think this concern goes away almost completely.
This was pre-2026 story. CUDA isn't a moat anymore.
Now it's mostly market dynamics: People always ship ad optimize things for Nvidia because it's the most widely used platform, and people buy it because it has the most software.
This is much less of a barrier than it used to be though. Buggy AMD GPU drivers remain a problem though.
The first is that they would spend all their time waiting on memory. If you run a CPU at 5 ghz, you will have 500 cycles before you get the bytes from memory you want.
1% of a modern CPU is running the instructions, the other 99% is trying to keep it busy. You would then need to double the transistor count for cache, but even then you will be waiting on memory for everything that you haven't already used and put in cache. To counter act that you need prefetching so you can get from memory ahead of time etc. This goes on and on until you either build a modern CPU or a modern GPU.
The other problem is that this doesn't solve a problem anyone has. People aren't really clamoring for more raw math or instructions any more. Most of it goes to waste by running scripting languages that run at 1/100th the speed of naive C. Most C runs at 1/100th the speed of a real optimized program. It's as if someone built a super powerful engine and everyone just decided to fly jumbo jets to work instead of using the same cars and less gas.
Then finally there are modern GPUs which already can do one million floating point operations in the time it takes to get a single byte from memory (the single byte is really two cache lines which is the minimum and this also includes the memory not being in the TLB).
It's all memory latency and software optimization. The need for raw math is not a general computing problem any more, it has all been relegated to GPUs.
I couldn't find any parallel constructs in the language. So, as I understand it, it's a regular language that gets compiled into a graph, and the runtime parallelizes the execution of that graph.
This factorial won't run any faster with more cores, since each step depends on the previous one:
fn fat(n: N64) -> N64 {
if n <= 1 {
1
} else {
n * fat(n - 1)
}
}
fn fat(n: N32) -> Nat {
if n == 0 { 1 as Nat } else { prod(1, n) }
}
fn prod(lo: N32, hi: N32) -> Nat {
if lo == hi {
lo as Nat
} else {
let m = (lo + hi) / 2;
let left = prod(lo, m);
let right = prod(m + 1, hi);
left * right
}
}
Also, as the graph grows, sequential dependencies still limit the speedup, and more cores means more data moving between them. How does the hardware deal with that?
I guess these are all really expensive and need VC funding. But perhaps there are existing architectures that allow baking code into silicon, or new architectures for NNs and so on. If costs are low, there is a massive demand coming for code that we want to write and forget - keeps on running on low powered last-mile devices. From factories, farms to home equipment.
2004: Tilera - TILE64
2006: Sony & Toshiba & IBM (STI) - Cell Broadband Engine
2009: GreenArrays - GA144
2012: Adapteva - Parallella
2021: Esperanto Technologies - ET-SoC-1
2024: Inspiresemi - Thunderbird
Other than that, I don't think there's much relation between the two.
In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.
> Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences.
Hey! Sounds like Thinking Machines, that hot new startup out of MIT. Yeah, their Connection Machine was bleeding edge stuff... in 1983 (https://en.wikipedia.org/wiki/Thinking_Machines_Corporation). Look, I get that it's an overview but they need to at least hand-wave at something new and different before talking like it's new and different.
> Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel.
https://www.newcomer.co/p/scoop-benchmark-backs-early-stage
VC is such a meme lmao. What’s next, Sam gonna acquire the company? No product needed!
> Tendrils is answering the question: what if we redo the CPU? Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences. To make this possible, we’re working in tandem on the open-source language Vine, which has been designed from the beginning to target a new wave of parallel-first architectures.
Ten days ago there was a post that linked a Haskell-specialized CPU, please: https://news.ycombinator.com/item?id=50319896
The link to the CPU demo: https://bathtub-01.github.io/technical/ouros-demo/
The Ouros CPU is a dataflow CPU, which means it is very, very scalable. It does not, from what I read there, contain content-addressable memory, which is a bottleneck for dataflow architectures. It supports multithreading from the ground, a parallel Haskell program will be executed very efficiently there.
There was an Id, a dataflow lenient functional programming language. The Id90 version of it was ported to Thinking Machines Connection Machine (then) supercomputer (I believe it was ported to CM-4 and CM-5).
Id90 programs running on Connection Machine demonstrated linear scaling to the available compute and, sometimes, even superlinear scaling - Id90's Content Addressable Memory was implemented in software and when CAM slice become smaller, there were less cache misses. Some of Id90 programs produced so much parallel computations that compiler had to introduce throttling so CAM will not overflow.
Here's a thesis on compilation of lenient functional programming languages to CM-5: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1994/5850.html
I guess it shows that functional programming languages can be efficiently executed through parallel dataflow architectures and that dataflow architectures scale efficiently with compute.
I am putting it all here because I see the same pattern over and over again. People create some new language with some unknown properties (Rust, for example, got Turing-complete type system before being able to control for I/O) instead of first taking Haskell and embed their ideas there or, even, add an extension to play and/or investigate.
In this particular case, they take some Vine programming language instead of Haskell, despite Haskell already having several specialized CPU implementations, including dataflow one, guaranteeing scaling. And Haskell has a pretty mature infrastructure and tons of libraries.
Why? I don't know.
"Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences. To make this possible, we’re working in tandem on the open-source language Vine, which has been designed from the beginning to target a new wave of parallel-first architectures."
Reminds me of the Transputer and Occam. Each transputer had 4 comm links to form a flexible network of processors and Occam supported parallelism. Also one of the first languages to use indentation for block structures.
For a long time I missed their folding editor.
Not sure why this one will succeed where its forebears didn't.