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:

An "Epic win" outcome for these people would likely be exit to a leading chip maker, about a decade out from today.

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.

Failure would likely be a fire sale into some giant IP portfolio (hopefully not a patent troll... that would be tragic).

i.e. A worthwhile endeavour, in any scenario, for those building the thing.

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.