> 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.
technically no : a GPU is basically multiple core running the very same program, with the only distinction being caused by a distinct identifier per core.
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.
I wish them success, if only to keep everyone on their toes (the biggest change the MPU industry has seen in the last ten years is switching to the _slightly_ less bloated aarch64), but if I have to sit through the 10s animation on their homepage ever again I'm throwing my phone at the wall. Give me a whitepaper.
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 even 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?
> 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."
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?
With that context, this example is a minimal example for explaining `and` short circuits and `&` does not. I.e. the `a < b < c is equivalent to (a < b) & (b < c)` is just explaining the logical behavior (with even more verbose equivilant logic after), not showing off how this particular example will parallelize better as part of introing the basic conditional operator set.
This exists to allow you to control whether parallel computation should happen or if it should resolve the first condition before wasting parallel compute to resolve the nth condition(s). E.g. imagine something like `isEven(x) & len(factor(x) > 2` vs `isEven(x) and len(factor(x) > 2`.
I haven't read through the rest of everything to see if they have anything interesting compared to other parallel computation solutions, I just know this example isn't going to help answer that one way or the other.
It depends on the scale of the computation. An Out Of Order CPU can allready exploit some parallelism at the instruction level. Multicore is parallelism at the procedure level.
>Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel.
Sounds like tweaking a gpu so it can be used like a cpu. There are some proof of concepts running unix on a gpu, along with some toy projects like gameboy emulators. I think an Nvidia engineer even tried to see if they could get linux working which helps explore what is deficient. And there is this https://github.com/robertcprice/nCPU .
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.
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. US$30M is a much more plausible budget.
The Alpha left out byte and halfword memory access instructions, and ARM left out halfword access instructions; both had to correct the omission later. I said RISC-V was determined not to repeat "what they saw as the blunders of past designs", so it had those from the beginning.
That's one of the more visible innovations -- or should I say "deviations from common practice" -- but I don't think it's the most important one.
I think the most important good one is that it takes "register" renaming seriously. Calls start with a belt that only contains the arguments, for example, and that's done through the magic of renaming. Loops do something similar (they are a lot like calls on the Mill).
I believe there were lots of important bad ones: explicit speculation (super interesting but unlikely to work well), separating memory mapping and memory protection, having "dirty" flags in the cache at the byte level (to minimize writebacks), two PCs moving in opposite directions, very "interesting" encoding, two encoding levels: a general encoding shared between all implementations and many implementation-specific encodings via an installer/converter/loader/JIT, novel protection hierarchy mechanism, backing the renaming mechanism with a more compact representation of older values that aren't likely to be reused soon, automatic spill/restore of that to/from memory, ...
They came up with an interesting compromise between exposed pipelines and guaranteed repeatable execution for loads ("drop the value from this load onto the belt in n cycles").
If you desperately want a high performance implementation that doesn't use out of order execution then the Mill has a lot of good ideas... but an out of order execution implementation is much safer and is not nearly as scary as people think (in terms of complexity, gate count, frequency loss). Mill does not seem to be easy to implement as OOO which means it would have to work as an architecture with only in-order implementations, which sounds like a guaranteed dead end for the future of the architecture.
Maybe you can have a decoder that runs ahead and converts everything to something that isn't so full of relative value references (like the loads) -- and then bolt that onto a fairly standard OOO engine?
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".
Yes, plus what there are 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.
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.
> 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.
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.
But models can just ingest large parts of the documentation into their context window, write the code based on that (which they'd likely be surprisingly good at, adapting to the entirely different memory mechanics and so on using just a handful examples) and test+iterate on it until it produces the expected results (which they can compare against a regular implementation) and performs well.
> 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.
With AI today, it's completely possible that it can't change the economics of being able to write software which can fully utilize new and novel architectures affordably.
So essentially it's gambling $30M on a coin toss that a clanker can magically fix something that hasn't worked the last 200 times we tried it.
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.
This is a big misunderstanding of languages and multi-threading. First, plenty of languages including C++ have a const keyword, rust is just const by default, so that doesn't enable anything new through the language. Even marking something const doesn't enable anything new, it's just convenient safety.
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.
I have a 64-node chunk of an NCube/10 that I was able to reverse engineer enough to get up and running! That thing is everything you could want in a 1980s supercomputer, it has a great architecture.
Oh, nice. Stanford had a 64-node NCube at one point. They got it from an oil company, which found it not useful. The case was a 1 meter cube, with slots for 16 huge boards, each with 64 CPUs. Only one board was present. One CPU was broken, and the architecture was such that you were then limited to 32 CPUs for a job.
Other than a chess program, it was unused. It was shipped off to some other school.
Same machine, with one broken CPU? Few of those things were made, so it might be.
This one came from Caltech, and was just a bare board (but thought to be working). I had to make a backplane and case for it, and then reverse engineer the serial protocol to build a USB-to-NCube adapter. I've only managed to get code running on a single CPU, but it's on my todo list to try multi-node.
"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 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 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
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.
161 comments
[ 0.20 ms ] story [ 103 ms ] threadBut 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.
here they can do multiple programs
In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.
Err..
Are Apple Silicon and Nvidia Vera and Amazon Graviton are considered illegitimate or non-competitors for some reason?
Nvidia Vera and Amazon Graviton are both primarily Linux platforms.
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?
Not sure why this one will succeed where its forebears didn't.
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!
"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.
With that context, this example is a minimal example for explaining `and` short circuits and `&` does not. I.e. the `a < b < c is equivalent to (a < b) & (b < c)` is just explaining the logical behavior (with even more verbose equivilant logic after), not showing off how this particular example will parallelize better as part of introing the basic conditional operator set.
This exists to allow you to control whether parallel computation should happen or if it should resolve the first condition before wasting parallel compute to resolve the nth condition(s). E.g. imagine something like `isEven(x) & len(factor(x) > 2` vs `isEven(x) and len(factor(x) > 2`.
I haven't read through the rest of everything to see if they have anything interesting compared to other parallel computation solutions, I just know this example isn't going to help answer that one way or the other.
It depends on the scale of the computation. An Out Of Order CPU can allready exploit some parallelism at the instruction level. Multicore is parallelism at the procedure level.
Sounds like tweaking a gpu so it can be used like a cpu. There are some proof of concepts running unix on a gpu, along with some toy projects like gameboy emulators. I think an Nvidia engineer even tried to see if they could get linux working which helps explore what is deficient. And there is this https://github.com/robertcprice/nCPU .
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 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. US$30M is a much more plausible budget.
Huh? LB(U) / LH(U)
https://www.sigarch.org/distance-based-isa-for-efficient-reg...
I think the most important good one is that it takes "register" renaming seriously. Calls start with a belt that only contains the arguments, for example, and that's done through the magic of renaming. Loops do something similar (they are a lot like calls on the Mill).
I believe there were lots of important bad ones: explicit speculation (super interesting but unlikely to work well), separating memory mapping and memory protection, having "dirty" flags in the cache at the byte level (to minimize writebacks), two PCs moving in opposite directions, very "interesting" encoding, two encoding levels: a general encoding shared between all implementations and many implementation-specific encodings via an installer/converter/loader/JIT, novel protection hierarchy mechanism, backing the renaming mechanism with a more compact representation of older values that aren't likely to be reused soon, automatic spill/restore of that to/from memory, ...
They came up with an interesting compromise between exposed pipelines and guaranteed repeatable execution for loads ("drop the value from this load onto the belt in n cycles").
If you desperately want a high performance implementation that doesn't use out of order execution then the Mill has a lot of good ideas... but an out of order execution implementation is much safer and is not nearly as scary as people think (in terms of complexity, gate count, frequency loss). Mill does not seem to be easy to implement as OOO which means it would have to work as an architecture with only in-order implementations, which sounds like a guaranteed dead end for the future of the architecture.
Maybe you can have a decoder that runs ahead and converts everything to something that isn't so full of relative value references (like the loads) -- and then bolt that onto a fairly standard OOO engine?
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).
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.
With AI today, it's completely possible that it can't change the economics of being able to write software which can fully utilize new and novel architectures affordably.
So essentially it's gambling $30M on a coin toss that a clanker can magically fix something that hasn't worked the last 200 times we tried it.
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.
Same machine, with one broken CPU? Few of those things were made, so it might be.
[1] https://vine.run/
"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.
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 leverage the compute
Doesn’t really matter how easy rewriting something is, it’s still a waste of time if it brings no value.
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.
Other than that, I don't think there's much relation between the two.