Well, NUVIA has to first design something with a competitive advantage over Intel's chips, then they have to manufacture it and then they have to sell it. Those are three separate and hard problems.

With the first problem, they can simplify things considerably by paying an ARM tax. The RISC-V tax is less ($0) but then it offers them less as well. If they design their own ISA, well, good luck with that. Also, clouds like tweaks, so one size won't fit all.

With the second problem, there's fab space to be had for sufficient coin. But there's more to manufacturing than filling out a webform and sending a tape with a check.

If they can get past the first two hurdles and actually deliver silicon which is significantly better than Intel's then marketing to the big clouds should be the least problematic.

Gonna take some money and time. Gulati left Google in March.

This is why I think they plan to develop some patentable IP, and get acqui-hired in the end. Its just too daunting a task to get to real silicon for a startup, given the costs of 7nm.

An alternative would be to take a major cloud on as an investor+customer. If they can deliver a truly cloud worthy CPU, it will have a market and especially if a major cloud is already a customer.

This investor+customer approach has a history. Yahoo did this with Google (search) and Apple did this with Adobe (laser printers).

How different is a "cloud worthy" CPU from a regular server CPU? And if there is a difference, is it big enough worth spending 270M $ on it? Double that for 3nm? Maybe! I honestly don't know, but I would suspect AMD and Intel are already hard at work figuring out what the cloud vendors like.

If they could shed historical ballast that the established vendors cannot get rid of due to compatibility constraints, it would make sense. But they need to be compatible x86 or ARM (maybe RISC-V) anyway, or else you're talking about boiling the ocean.

Same thing. It's just that neither ARM nor any of its architecture licensees have yet designed a server CPU which, for lack of a better term, is cloud worthy or this opportunity wouldn't exist. They're certainly phone worthy and car worthy. But if you look at the big XEON chip specs, that's what NUVIA has to match and then Intel+AMD will also keep moving the line markers along.

NUVIA can't do everything and be everything because they're a startup. They have to make choices. I'm incapable of thinking they'd choose anything but ARMv8. Transmeta learned that x86 is really hard and then you get to compete with Intel. RISC-V is incomplete and I haven't heard much from Esperanto of late.

So I think they're going to build a cloud worthy ARMv8 chip. There's a lot of historical ballast to be shed in just getting rid of x86. Indeed, I think that is both their market opportunity and their market risk.

I don't think the world revolves around Spectre, Meltdown and MDS but designing a microarchitecture that makes them impossible would be gain a lot of market good will.

But at the end of the day, they have outperform Intel.

The cloud CPU might be very different from regular server CPU.

For one example, if there are many workloads reading same shared resource, the CCPU (Cloud CPU) can use that to reduce access overhead. Even the program might be a shared resource - you can easily run several dozens of copies simultaneously in vectored fashion.

This might be exploited even further - the queueing operations, for example, can be transformed into parallel scans, yielding less than 1 clock cycle for a synchronization on the work queue.

Etc.

Cray tried similar things to somewhat good results with their Athlon-pin-compatible accelerators. But I think we can do and get more.

> hard problems

Understatement of the year. The number of man hours Intel has sunk into optimizing each of these boggles the mind. And this is coming from someone who worked there for 2 years.

Maybe I am naive but Intel has a lot of legacy baggage, perhaps a design from scratch can make it simpler.

Can you share some insights on those optimizations?

You missed the OS support for the architecture.

Scheduler models for LLVM as well. It surprises me that RISC-V chips have been avoiding this.

I still want to see the mill cpu in silicon. It sounds too good to be true.

I feel like to succeed here, you need to make an offering that can immediately run either a mainline Linux kernel or a totally open fork (with the intent of getting committed to mainline) and making sure all the major toolchains can build and run on it.

Unless there's a minimum friction to migrate, most companies won't make the effort even if they can save a few $100 per server. It takes me back to Intel's VLIW attempt with Itanium/EPIC. Even when they got compilers up to snuff, too many high end tasks (video encoding) either required special instructions or were written in assembly that couldn't easily be ported to EPIC instructions.

Clever name, simultaneously looking like NVIDIA but sounding like Via resurrected.

I saw the VIA in there. Didn't make the connection to nVidia. It felt like it invoked VIA and NUMA.

It made me wonder if it was a VIA spinoff; maybe licensing some of the interdependently developed x86_64 IP they bought with Cyrix from the entire Via C6 era.

It just reminds me of a female contraceptive device.

Via still exists. Maybe they could have gone with Nucyrix? Although that kind of sounds like a prescription drug.

I think Via owns all the IP for Cyrix. If there's no partnership here, I wonder if VIA is going to hit them with a trademark dispute.

Someday someone is gonna make a bunch of money selling CPUs implementing a WASM VM ("death of javascript") and/or lambda calc (Reduceron) in hardware.

Wasm itself doesn’t have any environment functions that would allow things like managing page tables or networking. I think that what you might see is a RISC-V JIT with a ring-0 Wasm runtime compiled to native. Kind of like https://github.com/nebulet/nebulet, probably

The interesting thing about WASM is that it's an amazing representation[1] to translate from; certainly much more attractive than binary translation from a legacy ISA (maintaining the illusion of the original ISA carry a substantial tax). As thus, it allows you freedom to innovate something radically different, like TRIPS/EDGE radical.

I'd much rather translate from that than create the compiler backend and the entire toolchain.

[1] It's not perfect alas, as there are still many things the compiler knows that is lost in translation, such as the complete static alias sets of memory operations, true range limits on values, etc. For some of this we burn power today trying to (re-) discover at run-time (like the memory disambiguator).

Oh there's still a lot of work to do before it's possible, but things like WASM pthreads, gc, etc are moving along.

We really are just reinventing Java, aren't we? (Perhaps better, with hindsight)

https://en.wikipedia.org/wiki/Java_processor

I think this too, when I read about WASM. It seems to be tackling the same problem that java was created to solve. Namely, a platform independent VM for running applications (applets) in the browser.

I, for one, would appreciate an explanation of how WASM differs from the original JVM, if someone has a moment.

Controversial opinion alert! Java Bytecode is an awful design. It's obvious if you study it that it was never designed as a compiler intermediate. Instead it was a fairly trivial byte code machine for which JITting was an afterthought. The bytecode "verification" is such a difficult problem that it lead to multiple articles and originally had a sequence of security holes.

The JVM is also very far from language independent. Good luck making an efficient mapping for any language that doesn't look like Java.

WASM in contrast is designed explicitly for JITting, in fact, one-pass JITting is possible. The data structures maps well to the compiler backend. The representation is restricted in ways to avoid requiring expensive analysis, most notoriously, no arbitrary branching.

JVM bytecode is significantly higher level, and comes with support for type reflection, garbage collection, etc. Whereas WASM doesn't include any of that. Which makes it simpler and more lightweight, but means that anything which needs that functionality has to do it itself.

If you're looking for technical details about the virtual machines themselves it's easier to just read their documentation.

If you're looking for what WASM does differently resulting in the JVM not being a good fit it's mostly around browser integration. WASM runs as part of the browser, designed so that the same VM running the JavaScript portions of a page can run the WASM portions without enormous modification. It's also more tightly coupled with the data model of the browser but it doesn't have full direct access to everything, still better than ferrying everything to a second VM.

As for why people are so excited to use it outside of the browser it probably has to do with the level of support and investment around engines like V8 and that it's not designed for a particular language.

If I were starting a new chip company I would be working on FPGA coprocessors. You get the economies of scale of producing a single chip but a lot of extra efficiency/sales by marketing it as customizable hardware (which most large buyers of chips increasingly want).

It’s a transitional step between the current mass market mode of chip productions selling one size fits all, and the way the market is heading towards task specialized hardware.

Wasm isn't an instruction set and it doesn't replace javascript because it must communicate through javascript, so I wouldn't count on it.

This is mostly hype, but I am guessing they will adopt an accelerator approach for modern server computing in a data center. There are a few canonical computing pattern inside modern data center:

Data crunching Fungible is already on that

Distributed services a lot of fan in and fan out some kind of chips that can combine IO networking and moderate general computing instructions can be useful

Massive code data storage

Catching servers?

Overall, I see no reason to take AMD Intel heads on... It's not necessarily anyway, no one needs a third x86 player. We want to have true architecture disruptor...

I really hope this is a RISC-V play of some sort. Otherwise I don't see how they can win. Apple does better ARM than anyone. Given the level of investment, nobody is going to out-Apple Apple in this area. Beefy, cheap, power efficient, legacy-free RISC-V, now that's something I'd be interested in.

Doesn't really matter to the server market what Apple is doing unless they start selling it.

That's true. But there are other strong competitors if you want to ship ARM into the datacenter. And crucially they are already selling to the likes of AWS, where you can go right now and spin up an ARM instance using their products. It's incredibly difficult to get something like AWS to depend on a product by a startup which could go out of business tomorrow.

Would be interesting if they'll develop totally new micro architecture and ISA from scratch.

ok, let's see what they bring to the table

Ugh that name

Nybody want to

NUke them from high orbit?

I have a feeling that its a CPU designed with side-channel attacks in mind. Could be Intel, could be ARM.