Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V Is Inevitable: State of the Union Keynote Argues

eetimes.com

Post reply on HN
Print view View original

121–130 of 142 posts

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#121

Post by snvzz »

tliltocatl wrote: post #112
ltbarcly3 wrote: post #65

Why can't anyone build a performant RISC-V cpu? The SpacemiT K3 seems to be the fastest available right now, and it's basically a joke. https://www.phoronix.com/review/spacemit-k3-pico-itx/3 I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.

> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance. RISC-V is an objectively bad ISA design (a resell of MIPS dropping some of the most ominous features, then trying fix the code density issue with billions of extensions), but x86 is way worse and it didn't prevent Intel from making performant implementations. And RISC-V is…

>trying fix the code density issue with billions of extensions

Not sure what you're on about.

By the time the spec was first ratified (2019), RV64GC was already the densest 64bit ISA, and it's not even close.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#122

Post by ColdStream »

pantalaimon wrote: post #9
ColdStream wrote: post #2

It was a decent little talk this one. Now that we are seeing RVA23 chips available we are starting to at least see a lot of software packages actively compiled for the platform. They aren't optimized much at all but they do run. I am cautiously optimistic about the future of RISC-V. It is likely to start biting at the heals of ARM in another 5 years or so, and having no licensing fees makes it very attractive in that…

We still have to see a RISC-V implementation that comes even close to the performance of ARM

They are still a LONG way from parity in terms of performance per watt. Best I have seen is about 1/6th as efficient. But this seems to be an issue of no current chips are what you would consider even remotely high end in terms of the groups working on them and the manufacturing nodes they are using.

But there is a lot of progress in space and it appears to be picking up pace. The only issue is that it risks becoming very fragmented.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#123

Post by brucehoult »

aarroyoc wrote: post #11
modulovalue wrote: post #8

I'm working on making SIMD better in Dart. Dart supports RISC-V as a target architecture for compilation, but I'm not really excited about figuring out how to map the wasm-SIMD-style primitives to RISC-V's RVV and so I don't really plan to look into it at all. This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"? that one can use to do…

There are several RISC-V machines. In the microcontroller world it's becoming more and more usual, but those won't have RVV. SpacemiT K3 based machines are probably your best bet when it comes to RISC-V processors with SIMD support. There are several manufacturers: Milk-V with the Jupiter II, Sipeed, Banana Pi, ...

The THead C906 core is full Linux-capable but is microcontroller-adjacent and has an early draft version of RVV that is different in details but has the same flavour (and at least some code is binary-compatible with RVV 1.0). Recent GCCs RVV intrinsics compile to either RVV 1.0 or the 0.7 draft (named XTHeadVector now) so if you're programming at that level they're compatible. Milk-V Duo starts at $3 for a tiny board with a 1.0 GHz C906 running Linux, a 700 MHz microcontroller config C906 (no MMU etc), and 64 MB RAM. Well, I paid $3 ... then they were $5 for several years and now I see $11 at arace.tech. There are also 256MB and 512MB versions, with the larger one also having an Arm A53 core.

That's actually got full 128 bit SIMD with all data types supported up to 64 bit int and FP.

You can also buy bare CV1800B and SG200x chips (Sophgo bought original designer Cvitek and enhanced the design)

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#124

Post by brucehoult »

ykonstant wrote: post #78
modulovalue wrote: post #8

I'm working on making SIMD better in Dart. Dart supports RISC-V as a target architecture for compilation, but I'm not really excited about figuring out how to map the wasm-SIMD-style primitives to RISC-V's RVV and so I don't really plan to look into it at all. This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"? that one can use to do…

>This is mostly because their approach to SIMD is so different, but also because I can't test it at all. Are there any RISC-V "machines"? that one can use to do something useful or fun with that someone here could recommend? I would also be interested in RISC-V emulators etc.

QEMU. Docker, using QEMU under the hood, there automatically with Docker Desktop on Mac & Windows, install QEMU yourself on Linux and configure binfmt_misc to use it.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#125

Post by brucehoult »

panick21_ wrote: post #62
crote wrote: post #52

Earlier quoted context omitted.

> And you cant rewritte 50 years of C in Rust You don't have to. Google already showed that the vast majority of memory safety bugs are in newly-written C code. Stop writing new C code (which the industry already seems to be moving towards) and the problem will eventually solve itself - even with plenty of C code still around. Besides, very few (if any) pieces of code have been around for anywhere close to 50 years.…

Can you show me that research? Also, nothing new in C is just not happening, there is massive amounts of things that will not switch for decades. Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it. And your new code in whatever language is also safe. Also it helps with debugging. Also it helps you enforce security constraints on higher level. C…

> Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it

You don't even need a new core. Fil-C makes regular old (and new) C code memory-safe. You can use it for individual apps on your existing OS, or Filip Pizło has been making an entire distro work with it ... libc, bash, ssh ... everything. He's got web browsing working and at the moment is working on LibreOffice. Many things work as-is, most things require very minor patches (which he's upstreaming).

Unlike Rust, there is no "unsafe" escape hatch (and it's not needed).

Follow https://x.com/filpizlo for progress.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#126

Post by brucehoult »

pjmlp wrote: post #30
0x000xca0xfe wrote: post #18

Earlier quoted context omitted.

Chinese companies are really into RISC-V and China both builds and uses a lot of smartphones, I'm very sure we won't have to wait 20 years for regular users installing apps on RISC-V hardware.

It still requires Android to care about RISC-V, plenty of NDK stuff. https://developer.android.com/ndk/guides/abis Then OSes like HarmonyOS and HarmonyOS NEXT aren't even that relevant outside China. Finally the chips have to deliver in performance, to actually provide good mobile devices.

> Finally the chips have to deliver in performance, to actually provide good mobile devices

There were still, as recently as 2025, new smartphones being released with only Arm A53 cores from 2012. Low end, obviously, but equally obviously there is a market for them.

RISC-V SoCs passed that performance mark in 2021 and shipping SBCs are currently at the Arm A76 RK3588/Pi 5 level. In flagship phones that was the Samsung Galaxy S10 generation, but there are still today a lot of budget phones using A76 as the primary cores (usually with some A55s too).

Cores are available for licensing up to around the Cortex-X3 level. Someone just has to be interested enough to put them in an SoC.

It's a business question now, not a technology one.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#127

Post by brucehoult »

Tostino wrote: post #59
crote wrote: post #53

Earlier quoted context omitted.

That all depends on their current licensing terms, doesn't it? Besides, ARM-to-RISC-V doesn't require a full redesign. Plenty of components are going to stay more-or-less the same, the big change is the instruction decoder. Chip developers have done far more drastic redesigns while staying with the same ISA - just look at the history of x86. I think the bigger question is: does Apple want to go through another binary…

Look into Apple's ARM licensing terms. They are very generous to apple.

We have no idea at all what the terms are.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#128

Post by brucehoult »

ltbarcly3 wrote: post #65

Why can't anyone build a performant RISC-V cpu? The SpacemiT K3 seems to be the fastest available right now, and it's basically a joke. https://www.phoronix.com/review/spacemit-k3-pico-itx/3 I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.

> Why can't anyone build a performant RISC-V cpu?

"They" can, and are. Many "they"s.

> I'm starting to get the feeling that there is something fundamentally broken in the RISC-V specification that fundamentally limits performance.

Then you are at loggerheads with many legendary ISA and chip designers.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#129

Post by pjmlp »

timhh wrote: post #119
pjmlp wrote: post #94

Earlier quoted context omitted.

The problem is that with LLVM, GCC, CUDA, Vulkan, POSIX, V8 and co, there will be lots of new C and C++ getting written as well. Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++. There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to ta…

There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want. V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I…

Why not? There are many cases where it matters, also routine CVEs show how well tested they are in practice.

Re: RISC-V Is Inevitable: State of the Union Keynote Argues

#130

Post by pjmlp »

leoc wrote: post #81
sph wrote: post #39

Earlier quoted context omitted.

Is there an outpouring of hardware offer for CHERI? I'm a random nobody, but I'm sitting on this design for a message-passing platform that can only truly perform in a world where processes live in a single address space, which requires CHERI hardware to be feasible (or secure) at all. CHERI would open many doors in operating system design and security, and it's stagnant because it's not a real thing yet, there's no…

Right: it's not clear whether the availability of some $300 US CHERI SBCs would be enough to carry CHERI to glory, but it would obviously generate a significant pop of awareness, support and grassroots activity. For their part the antis could then transition seamlessly from "nobody wants it lol" to "all these enthusiasts are so annoying and out of touch with reality lol" as is traditional. Instead, AFAICT, the CHERI…

Mid-level technical staff don't push hardware out the door for major OS vendors, unless it is something their management already cares about.
Post reply on HN