This is kind of a solution in search for a problem. RISC-V will grow only if people find some value in it. If it solves their actual problems in ways that other architectures can't.

▲

hylaride 2 hours ago | parent [-]

Yeah, the primary reason RISC-V exists is political (the desire to have an "open source" CPU architecture). As noble as that may be, it's not enough to get people or companies to use (or even manufacture!) it. It'll either be economical (costs) and/or performance (including efficiency) that drives people.

It took ARM decades to get to where it is, and that involved a long stint in low-margin niche applications like embedded or appliances where x86 was poorly suited due to head and power consumption.

▲

cmrdporcupine an hour ago | parent [-]

I don't think that's the primary reason there's momentum there. The reason is to avoid ARM licensing fees and IP usage restrictions.

I think you'll see ever more accelerating RISC-V adoption in China if the United States continues on its "cold war" style mentality about relations with them.

That said we're a long long way from Actually Existing RISC-V being at performance parity with ARM64, let alone x86.

	▲	sylware an hour ago \| parent [-]
		Yep, licensing fee and IP usage restrictions is a massive decision point on some silicon markets. The other massive point: RISC-V integrates a lot of CPU "we know now" in a very elegant "sweet spot". And it is not china only, the best implementations are US, and RISC-V is a US/berkley initiative re-centered in switzerland for "neutrality" reasons. If good large RISC-V implementations do reach TMSC silicon process (5GHz), some markets won't even look at arm or x86 anymore. And there is the ultimate "standard ISA" point: assembly written code then become very appropriate, hence strong de-coupling from all those, very few, backdoor injecting compilers. On many of my personal projects, I don't bother anymore: I write RISC-V assembly which I run with a small x86_64 interpreter, that with a very simple pre-processor and assembler, aka SDK toolchain complexity close to 0 compared to the other abominations. And I think the main drawback is: big mistakes will be made, and you must account for them.