This is a "build it and they will come" project.
It's not a "we put the inner loop of ML entirely in hardware" project. That would make more sense technically. You could cram a lot of little independent neural net inference units on one chip. But if it was pitched that way, the questions would be "Why isn't NVidia doing this", and "After you do it, what keeps NVidia from doing it". There are lots of people pitching "AI chips", with modest success.
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.)
I don't think they were saying it was a bad idea, though they may have been suggesting it is a bad investment.
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.
Alt: What if it's a "let's build a kickass thing because we wanna, and see how far we can take it" project?
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).
Exactly. I think these days raising $30m for anything AI-related (this counts) is the equivalent of getting into YC 15 years ago. The bar at this level is "this is kinda cool" not "this is a totally sound business plan that is likely to succeed barring adverse acts of God".
The $30m will get spent in no time if they're patenting as they go along, btw.
Yes, plus what they're proposing is more like a GPU in a CPU jacket?
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 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.
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.
I heard somewhere that a major problem with the PS3 cell was it had a very limited local memory for its programs and data, which meant the host (main) cpu had to constantly moved memory back and forth from main memory to individual cell memory.
Aren’t we still bandwidth limited on ai? IOW you can make the most efficient computer you want, it’s still getting the data to it that’s the hard part.
One niche application which impressed me was the use of the TILE-Gx in Mikrotik's CCR routers. I used one for a good few years and you really got a lot of performance (provided your setup was suitably parallelizable) for very little outlay and a tiny power expenditure.
Nvidia bought the architecture and killed it, which kind of proves your point.
Before the advent of Rust all code was written with mutable aliasing by default in mind which has lead to the proliferation of single threaded code. Now that Rust code is mutable xor shared by default it is easy to copy data into scratchpads without risking invalidation and the tree based borrow checking model also ensures that you can split algorithms into independent tasks automatically.
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.
They spent way too long procrastinating, with zero silicon after decades of work.
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
Yeah, but RISC-V came out of RISC-1,2,3,4; it didn't magically appear our of nowhere. "RISC-V was developed in 2010 at the University of California, Berkeley as the fifth generation of RISC processors created at the university since 1981".
RISC-V intentionally contained almost no innovation of any kind. The whole point was to have the most boring, standard RISC design imaginable, without anything clever in it. That's what you want for introducing students to their first RISC architecture, and also as a basis for doing computer architecture or CPU fabrication research: on zero-overhead loops, compressed instruction sets, scalable vector instruction sets, IoT machine learning, indium gallium zinc oxide thin-film transistors printed on kapton, zero-knowledge virtual machines, or whatever.
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.
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.
By my reckoning you can build about 256 small fast CPUs each with 16kiB RAM and IO on an M4 die area. Most of a modern CPUs gates are wasted on out of order execution and cache coherency.
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.
Maybe what was missing as the llms to be honest to get these kind of architectures to work as you can have it run optimisations loop against hardware like this.
yeah well there's a perennial problem of needing innovative languages to get this to work (Vine?) vs. the temptation to package this sw with chips and become a closed technology
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.
Also Parallella[1]. I have two of their 16 (+ 2 ARM cores) core demonstration units sitting in a box somewhere. They were fun, and I'm sad they didn't get much further - I think they did get a 64 core version done, but the longer term goal was a 4096 core grid. You could directly access the memory in each core, and there was a predictable cycle count to do so based on location in the grid, so you could write algorithms that'd run in lock-step if you wanted.
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.
Out of order execution is not a waste. Itanium learned that the hard way.
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.
hmmm - not sure I can agree with that. lets say we both subscribe to David Hennessy approach to quantitative CPU performance design. then depends on the workload.
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.
You can not agree or 'submit for this class of problem' all you want, but the fact is that now and for a long time getting the most math instructions out of the smallest die size doesn't seem to be a problem.
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 reason for the existence of OoO is that the latency of a memory read is much greater than the executions of tons of instructions.
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.
Until you find a way to speed up sequential computation using parallel processing (show what NC = P?) there will always be a need for singular beefy cores.
This feels a decade late. I don't really see the value prop for customers in 2026 (or realistically, 2030+). Let's say I'm willing to rewrite all my software to a language that compiles down into interaction nets. Why don't I use HVM2 instead and buy GPUs from Nvidia? If I just want to use an exotic architecture, AMD is shipping dataflow processors at scale today, and they'll license related IP. And if I just want a massively parallel architecture to run my existing ML code on, I could just rent google cloud TPUs instead.
Who's the customer that wants an exotic architecture on an old process node running a custom programming language half a decade from now?
because rewriting your software is easy now, there are plenty of examples of Language Models looking at the architecture in front of them and recompiling themselves, their inference engine and harnes for faster inference on it or whatever their need may be
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
If software stacks and compatibility didn't matter, AMD GPUs would be in nearly the same demand as Nvidia's. But we know they aren't and that's despite the fact that porting between GPUs is much easier than what we're talking about here.
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
A point that stopped being relevant as soon as it was proven possible, I don't know what kind of validation you need to see about exotic hardware being easier to develop for, but being slower to pick that up doesn't change the viability of the exotic hardware built on more available nodes now that there are examples of it being easier to run things on
Language models are efficient because they are trained with millions of examples that don't exist for newer architectures, and they are still mediocre to bad on stuff where they hadn't been trained
As a programmer, I always wanted a cpu which instead of having n 64 bit registers, had a single register with 2^m bits, which could be split in arbitrary length sub registers, not all the same size, and could be treated as an array of bits, or a swar machine
That's a fun idea! RV32E is 512 bits of general-purpose registers, RV32I is 1024, and RV64I is 2048. AVX-512's ZMM registers total 16384 bits. So you could have, say, a 4096-bit register which you could access as any of 13 different sizes, from 1 bit up to 4096.
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?
An use of SIMD in x86 is fast ram copy/filling by sending all Avx register to ram with one instruction.
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.
That's fascinating! I've always wondered about whether there has ever been a cpu or if it'd be too difficult to build, that has 2 bit run-length registers. 1st bit -> value, 2nd bit -> has next. For processing arbitrary length data. Any size integer or string. It's not without a cost of course, but I find the idea of having a single atomic datatype of any length kind of nice.
I think you could probably adapt the SERV design to do this. You'd end up with a tiny but kinda slow core,
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.
Similar to my thoughts about having memory being bit addressable instead of being forced at byte boundaries. I am aware that this is inefficient but we have seen CPUs for example do byte addressing even thought they actually read words.
New CPU architectures have lived and died by supporting existing software, with Rosetta on Apple Silicon being an example of it working and Itanium an example of it falling apart.
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.
I'm guessing it will be easier with all of these automated (LLM) porting efforts. Also, there can be a middle-ish ground like GPUs where only portions of the program are written in CUDA and exposed via some higher-level API.
I always wonder where will x86 be in 10 or 20 years time. As data paths widen for SIMD, how many can they possibly cram , such as more generations of wider and wider groups of instruction with different opcodes and characteristics.
Do you remember the 1990s everlasting arguments about RISC vs CISC? There were so many arguments (online and magazines) saying that "soon" RISC would eat CISC. And yet, it never happened. I'll be dead before the demise of x86. More likely: The computing landscape will get more complex. Probably ARM will become a legitimate competitor to x86 outside of handheld computing, and RISC V will become a legitimate competitor to ARM for single board and handheld computing.
You are right! I didn't think about about Mac desktops. I was thinking that ARM is a second class citizen for Linux and Win32. X86 is still king there, but that will slowly change.
I think you are confusing CISC with specialized instructions. We just ask 3 questions to decide if something is CISC or RISC. 1. Are the instructions 32 bit wide? 2. Can the instruction only operate on registers? 3. Does it use microcoded, multi-cycle state machines for basic instructions?
That's not the usual way to discuss CISC or RISC (and ARM fails two of the three questions anyways).
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?
What about putting a million 6502s or 65816 or maybe a 32 bit address capable on single die ? Surely a million of them would get more done than a single modern X86 or ARM for a lot less power and price ?
That would be about 3 billion transistors and a 7800X3D is apparently about 6.5 billion transistors, but there are lots of problems.
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.
"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?
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.
> it is the compiler to use it that is the hard hard part
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.
> CUDA is a huge reason NVidia is so big right now. Their GPUs are broadly similar to AMD. Their software libraries are better.
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.
I think we all have projects and ideas like this that go back decades. In my case, it's the BitGrid, which is a theoretical sea of look up tables that are clocked in alternating phases like a chessboard, to eliminate race conditions and the need to worry about timing.
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.
This is above my pay grade but since LLMs have become the 24/7 code writers, I started to wonder if our processing architecture could see much more innovation. I see light-enabled processing, analog processing and other headlines on posts/YouTube. Most are focused on inference though. But there is also the need to run generated code on cheaper, efficient chips.
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.
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)
}
}
This other version can run in parallel, but only because the algorithm was deliberately written that way:
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
}
}
So the programmer still has to think about parallelism; the language just removes the need for threads and locks.
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?
Bom dia, it's my understanding that there is no runtime. The hardware does all of the graph rewrites. If you look at their 'On Interaction Nets' post [1], it seems that part of the pitch is that many programs can be written 'naturally' and still parallelize well.
I think RISC-V is intended to be a simpler-to-implement processor that can also be used as a compilation target for existing languages, b/c it still shares many properties of x86/ARM (e.g. pointers, memory addresses, etc.). I don't think Tendrils' chips are intended necessarily to be able to run existing code, but instead will require Vine to be able to program for their chips.
Other than that, I don't think there's much relation between the two.
Have you seen the new CPU architecture? It's on Mill. It's literally on Transputer. It's on Rock with Sun. It's literally on AMULET. You can probably find it on Itanium. Dude it's on Tesla. It's a CDC STAR original. It's on E1. You can program it on E1. You can go to E1 and program it. Get onto E1 right now. Go to E1. Dive into E1. You can E1 it. It's on E1. E1 has it for you. E1 has it for you.
In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.
Really would like to understand how the mill got going and how anyone can see it progressing at this point. I know folks are working on it on the side but it's just bleh now.
The chip might be great but they really need to rework their overview blurb. I'm no CPU designer but even I know every single thing they mention like it's bold, new 'think different' stuff, hasn't been a 'new idea' since at least the 1990s. For example:
> 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.
My first thought was: $30 million that's not a lot for a project of that size.
> Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel.
Additionally they try to make a hyper parallel cpu? that seems like it would be hard to program. If they can make it easy to program parallelism it may be interesting. But perhaps they will just reinvent the Lisp machine.
I'm quite interested to see how this evolves. But part of me is still being sad, because hardware is rarely the bottleneck these days - as opposed to software.
> 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.
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.
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.
> Sources say that the company is already discussing a fast follow-up raise that would potentially value the firm at more than $1 billion. Neither round has previously been reported. Benchmark declined to comment.
"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.
This is a "build it and they will come" project. It's not a "we put the inner loop of ML entirely in hardware" project. That would make more sense technically. You could cram a lot of little independent neural net inference units on one chip. But if it was pitched that way, the questions would be "Why isn't NVidia doing this", and "After you do it, what keeps NVidia from doing it". There are lots of people pitching "AI chips", with modest success.
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.)
Being a dead end doesn't mean the idea was bad, things both fail and succeed for complex reasons. This is a tired trope.
I don't think they were saying it was a bad idea, though they may have been suggesting it is a bad investment.
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.
Alt: What if it's a "let's build a kickass thing because we wanna, and see how far we can take it" project?
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).
Exactly. I think these days raising $30m for anything AI-related (this counts) is the equivalent of getting into YC 15 years ago. The bar at this level is "this is kinda cool" not "this is a totally sound business plan that is likely to succeed barring adverse acts of God".
The $30m will get spent in no time if they're patenting as they go along, btw.
Yes, plus what they're proposing is more like a GPU in a CPU jacket?
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!
This has been done before: https://en.wikipedia.org/wiki/Xeon_Phi
> 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.
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.
I heard somewhere that a major problem with the PS3 cell was it had a very limited local memory for its programs and data, which meant the host (main) cpu had to constantly moved memory back and forth from main memory to individual cell memory.
Aren’t we still bandwidth limited on ai? IOW you can make the most efficient computer you want, it’s still getting the data to it that’s the hard part.
"Because we patented it."
One niche application which impressed me was the use of the TILE-Gx in Mikrotik's CCR routers. I used one for a good few years and you really got a lot of performance (provided your setup was suitably parallelizable) for very little outlay and a tiny power expenditure.
Nvidia bought the architecture and killed it, which kind of proves your point.
Before the advent of Rust all code was written with mutable aliasing by default in mind which has lead to the proliferation of single threaded code. Now that Rust code is mutable xor shared by default it is easy to copy data into scratchpads without risking invalidation and the tree based borrow checking model also ensures that you can split algorithms into independent tasks automatically.
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.
Tilera has tried and failed with a somewhat similar approach. [https://en.wikipedia.org/wiki/Tilera]
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.
Hmm. The story over at https://millcomputing.com/ always looked compelling.
Pitchbook shows it as "Out of Business" since 2019.
They spent way too long procrastinating, with zero silicon after decades of work.
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?
Yeah, but RISC-V came out of RISC-1,2,3,4; it didn't magically appear our of nowhere. "RISC-V was developed in 2010 at the University of California, Berkeley as the fifth generation of RISC processors created at the university since 1981".
Also, RISC-V is not particularly innovative or groundbreaking. It's a standard Von Neumann CPU optimised for simplicity and modularity.
The Mill was (is?) a much bigger swing, with much bigger problems to solve in getting to production.
RISC-V intentionally contained almost no innovation of any kind. The whole point was to have the most boring, standard RISC design imaginable, without anything clever in it. That's what you want for introducing students to their first RISC architecture, and also as a basis for doing computer architecture or CPU fabrication research: on zero-overhead loops, compressed instruction sets, scalable vector instruction sets, IoT machine learning, indium gallium zinc oxide thin-film transistors printed on kapton, zero-knowledge virtual machines, or whatever.
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.
> 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.
This could be wrong, but https://tracxn.com/d/companies/mill-computing/__5BCN3HKJOoke... says they raised US$100k in debt, and https://www.crunchbase.com/organization/mill-computing-inc says You Have Been Blocked but apparently told Google they were pre-seed funding. https://pitchbook.com/profiles/company/169749-55#funding claims that they raised US$3.2M (US$1.2M in angel funding in 02004 and US$2M in a seed round in 02016). I looked for press releases about funding rounds and didn't find any.
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.
By my reckoning you can build about 256 small fast CPUs each with 16kiB RAM and IO on an M4 die area. Most of a modern CPUs gates are wasted on out of order execution and cache coherency.
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.
so reinventing the transputer?
unfinished business
Maybe what was missing as the llms to be honest to get these kind of architectures to work as you can have it run optimisations loop against hardware like this.
yeah well there's a perennial problem of needing innovative languages to get this to work (Vine?) vs. the temptation to package this sw with chips and become a closed technology
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.
For sure, we need some sensible target for this to work with enough information to be able to generate performant code.
Lots of small computers in a grid sounds like GreenArrays by Chuck Moore. His language of choice is FORTH, or more recently arrayForth.
Also Parallella[1]. I have two of their 16 (+ 2 ARM cores) core demonstration units sitting in a box somewhere. They were fun, and I'm sad they didn't get much further - I think they did get a 64 core version done, but the longer term goal was a 4096 core grid. You could directly access the memory in each core, and there was a predictable cycle count to do so based on location in the grid, so you could write algorithms that'd run in lock-step if you wanted.
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.
[1] https://parallella.org/
[2] https://en.wikipedia.org/wiki/XMOS
Out of order execution is not a waste. Itanium learned that the hard way.
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.
hmmm - not sure I can agree with that. lets say we both subscribe to David Hennessy approach to quantitative CPU performance design. then depends on the workload.
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.
You can not agree or 'submit for this class of problem' all you want, but the fact is that now and for a long time getting the most math instructions out of the smallest die size doesn't seem to be a problem.
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 reason for the existence of OoO is that the latency of a memory read is much greater than the executions of tons of instructions.
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.
Until you find a way to speed up sequential computation using parallel processing (show what NC = P?) there will always be a need for singular beefy cores.
This feels a decade late. I don't really see the value prop for customers in 2026 (or realistically, 2030+). Let's say I'm willing to rewrite all my software to a language that compiles down into interaction nets. Why don't I use HVM2 instead and buy GPUs from Nvidia? If I just want to use an exotic architecture, AMD is shipping dataflow processors at scale today, and they'll license related IP. And if I just want a massively parallel architecture to run my existing ML code on, I could just rent google cloud TPUs instead.
Who's the customer that wants an exotic architecture on an old process node running a custom programming language half a decade from now?
because rewriting your software is easy now, there are plenty of examples of Language Models looking at the architecture in front of them and recompiling themselves, their inference engine and harnes for faster inference on it or whatever their need may be
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
If software stacks and compatibility didn't matter, AMD GPUs would be in nearly the same demand as Nvidia's. But we know they aren't and that's despite the fact that porting between GPUs is much easier than what we're talking about here.
its honestly just network effects at this point
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
No that proves the point. It took the invention of LLMs and agentic software development for AMD to fix their drivers.
A point that stopped being relevant as soon as it was proven possible, I don't know what kind of validation you need to see about exotic hardware being easier to develop for, but being slower to pick that up doesn't change the viability of the exotic hardware built on more available nodes now that there are examples of it being easier to run things on
Language models are efficient because they are trained with millions of examples that don't exist for newer architectures, and they are still mediocre to bad on stuff where they hadn't been trained
They are also good at TDD loops. With good enough testing harnesses and simulators, they can get things done quickly.
> because rewriting your software is easy now
Doesn’t really matter how easy rewriting something is, it’s still a waste of time if it brings no value.
What dataflow processors is AMD shipping?
The XDNA NPU is a small dataflow processor. Originally derived from xilinx IP.
Is this a joke? No one uses HVM2, and hasn't been touched in years. It's a single one-off prototype that some guy made.
As a programmer, I always wanted a cpu which instead of having n 64 bit registers, had a single register with 2^m bits, which could be split in arbitrary length sub registers, not all the same size, and could be treated as an array of bits, or a swar machine
That's a fun idea! RV32E is 512 bits of general-purpose registers, RV32I is 1024, and RV64I is 2048. AVX-512's ZMM registers total 16384 bits. So you could have, say, a 4096-bit register which you could access as any of 13 different sizes, from 1 bit up to 4096.
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?
This seems to be very close to RVV in terms of expressive power. The operations are going to be map,fold,filter
Don't forget scan! You know. Prefix sum.
An use of SIMD in x86 is fast ram copy/filling by sending all Avx register to ram with one instruction.
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.
You want RAM?
How to make a chip designer's life a living hell 101.
That's fascinating! I've always wondered about whether there has ever been a cpu or if it'd be too difficult to build, that has 2 bit run-length registers. 1st bit -> value, 2nd bit -> has next. For processing arbitrary length data. Any size integer or string. It's not without a cost of course, but I find the idea of having a single atomic datatype of any length kind of nice.
I think you could probably adapt the SERV design to do this. You'd end up with a tiny but kinda slow core,
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.
Similar to my thoughts about having memory being bit addressable instead of being forced at byte boundaries. I am aware that this is inefficient but we have seen CPUs for example do byte addressing even thought they actually read words.
I thought greenarrays was incredibly cool. (144 native-forth cores on a chip)
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.
New CPU architectures have lived and died by supporting existing software, with Rosetta on Apple Silicon being an example of it working and Itanium an example of it falling apart.
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.
I'm guessing it will be easier with all of these automated (LLM) porting efforts. Also, there can be a middle-ish ground like GPUs where only portions of the program are written in CUDA and exposed via some higher-level API.
> 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 always wonder where will x86 be in 10 or 20 years time. As data paths widen for SIMD, how many can they possibly cram , such as more generations of wider and wider groups of instruction with different opcodes and characteristics.
Do you remember the 1990s everlasting arguments about RISC vs CISC? There were so many arguments (online and magazines) saying that "soon" RISC would eat CISC. And yet, it never happened. I'll be dead before the demise of x86. More likely: The computing landscape will get more complex. Probably ARM will become a legitimate competitor to x86 outside of handheld computing, and RISC V will become a legitimate competitor to ARM for single board and handheld computing.
> Probably ARM will become a legitimate competitor to x86 outside of handheld computing
Err..
Are Apple Silicon and Nvidia Vera and Amazon Graviton are considered illegitimate or non-competitors for some reason?
You are right! I didn't think about about Mac desktops. I was thinking that ARM is a second class citizen for Linux and Win32. X86 is still king there, but that will slowly change.
I mean it did kinda happen. x86 is pretty much the only surviving CISC. Everything else that has come since 80s or 90s has been RISC.
arm is very much a cisc, arm iphones have instructions that correspond to speeding up JavaScript hot paths (FJCVTZS)
Also some GPU instructions are several times more complex than the most complex cisc instruction from the 90s.
I think you are confusing CISC with specialized instructions. We just ask 3 questions to decide if something is CISC or RISC. 1. Are the instructions 32 bit wide? 2. Can the instruction only operate on registers? 3. Does it use microcoded, multi-cycle state machines for basic instructions?
That's not the usual way to discuss CISC or RISC (and ARM fails two of the three questions anyways).
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?
I still don't really get why people are obsessed over RISC as an antagonist of CISC.
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.
for starters... drop ballast
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?
What about putting a million 6502s or 65816 or maybe a 32 bit address capable on single die ? Surely a million of them would get more done than a single modern X86 or ARM for a lot less power and price ?
That would be about 3 billion transistors and a 7800X3D is apparently about 6.5 billion transistors, but there are lots of problems.
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.
This is my first time hearing about Vine - https://vine.dev/ I have to say the landing page is terrible, at least show an example of the language.
They've announced a playground [1] recently on their Discord.
[1] https://vine.run/
https://www.technewsworld.com/story/lessons-learned-from-tra...
Is their "interaction net" approach to computation related to Gerald Sussman's propagators in any way?
From the URL:
"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?
I think thats a poor example (either that, or less charitably, they're scamming investors).
They just described a common superscalar optimization thats been done since the 90s.
It makes a million times more sense when given the context it's found in https://vine.dev/docs/features/conditions
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.
Woke up this morning to the thought "I stated it backwards". I.e. the `a < b` and `a >= b` should be swapped.
Isn't this basically a GPU?
Yep, and they're probably simulating/emulating their CPU design on GPUs already.
> This requires moving beyond the notion of shared mutable memory and linear instruction sequences.
Sure looks like it.
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.
> it is the compiler to use it that is the hard hard part
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.
> CUDA is a huge reason NVidia is so big right now. Their GPUs are broadly similar to AMD. Their software libraries are better.
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.
Not necessarily, there are other kinds of accelerator designs like dataflow architectures or systolic arrays.
I think we all have projects and ideas like this that go back decades. In my case, it's the BitGrid, which is a theoretical sea of look up tables that are clocked in alternating phases like a chessboard, to eliminate race conditions and the need to worry about timing.
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.
This is above my pay grade but since LLMs have become the 24/7 code writers, I started to wonder if our processing architecture could see much more innovation. I see light-enabled processing, analog processing and other headlines on posts/YouTube. Most are focused on inference though. But there is also the need to run generated code on cheaper, efficient chips.
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.
Am I missing something?
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:
This other version can run in parallel, but only because the algorithm was deliberately written that way:
So the programmer still has to think about parallelism; the language just removes the need for threads and locks.
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?
The factorial can be calculated using a Taylor series, whose individual terms can be calculated and summed in parallel.
Bom dia, it's my understanding that there is no runtime. The hardware does all of the graph rewrites. If you look at their 'On Interaction Nets' post [1], it seems that part of the pitch is that many programs can be written 'naturally' and still parallelize well.
[1] https://tendrils.co/blog/2026-04-26/on-inets
1985: Inmos - Transputer
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
Become the revenger of the philosophy "the right thing" if you can inherit the legacies given by interaction nets.
Vine sounds like it has a similar philosophy to Bend [1]. I'm sure it would be possible to compile Bend to run on one of these chips as well.
[1] https://bend-lang.com/
Wasn't that what RISCV was supposed to do? apologies, dumb question
I think RISC-V is intended to be a simpler-to-implement processor that can also be used as a compilation target for existing languages, b/c it still shares many properties of x86/ARM (e.g. pointers, memory addresses, etc.). I don't think Tendrils' chips are intended necessarily to be able to run existing code, but instead will require Vine to be able to program for their chips.
Other than that, I don't think there's much relation between the two.
How will this be better than RISC V?
Who do you expect to answer? It's a tiny future product announcement, it neither exists, nor is it a Show HN from someone involved
a man can dream
Have you seen the new CPU architecture? It's on Mill. It's literally on Transputer. It's on Rock with Sun. It's literally on AMULET. You can probably find it on Itanium. Dude it's on Tesla. It's a CDC STAR original. It's on E1. You can program it on E1. You can go to E1 and program it. Get onto E1 right now. Go to E1. Dive into E1. You can E1 it. It's on E1. E1 has it for you. E1 has it for you.
In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.
Really would like to understand how the mill got going and how anyone can see it progressing at this point. I know folks are working on it on the side but it's just bleh now.
$30M to either do nothing at all, or change the world.
The chip might be great but they really need to rework their overview blurb. I'm no CPU designer but even I know every single thing they mention like it's bold, new 'think different' stuff, hasn't been a 'new idea' since at least the 1990s. For example:
> 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.
My first thought was: $30 million that's not a lot for a project of that size.
Additionally they try to make a hyper parallel cpu? that seems like it would be hard to program. If they can make it easy to program parallelism it may be interesting. But perhaps they will just reinvent the Lisp machine.
How do I get people to give me $30 M to work on nonsense?
Step 1. Stop calling it nonsense.
Didn’t Apple already do this?
This feels like a bad use of the UK Sovereign AI Fund.
I'm quite interested to see how this evolves. But part of me is still being sad, because hardware is rarely the bottleneck these days - as opposed to software.
So they used a new and unknown language Vine.
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.
it’s the Transputer again, or the Emotion Engine again, depending on how old you are
This is amazing!
> Sources say that the company is already discussing a fast follow-up raise that would potentially value the firm at more than $1 billion. Neither round has previously been reported. Benchmark declined to comment.
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!
According to article, his brother Jack is now on the board, and a general partner of Benchmark.
Maybe now the cpu arena is a patent graveyard instead of a patent minefield, some fresh developments can appear.
There is also https://en.wikipedia.org/wiki/XMOS which was funded by people behind the transputer.
FTA:
"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.
Let's not call it a CPU if it doesn't have SoTa single threaded performancr
let's re-do the OS too. we only need about 10 syscalls. authorization is totally backwards (look how android runs a user per process).
Was about time we had another Transmeta.
Bet you they will turn into yet another ML accelerator company within the year.
TL;DR: it's basically Niagara/GreenArrays/etc again.
Not sure why this one will succeed where its forebears didn't.
They already got the UK government to give them some taxpayer money. Success accomplished, now it’s just mai tais on the beach.