RISC-V and Floating-Point

andrepd 5 minutes ago | parent | next [-]

Some of the complexity that comes with this really comes from the complexity of IEEE734 itself, plus the fragmentation of alternatives at lower precision.

I would have loved if the article mentioned the efforts at integrating Posits [0] in risc-v. While IEEE734 compatibility will obviously be necessary for any foreseeable future, it would be nice if the industry could settle on a better alternative which avoids many of the flaws with IEEE floats.

[0] https://github.com/andrepd/posit-rust

▲

Netch 2 days ago | parent | prev [-]

From a bystanderʼs POV it is excessively hard to memorize all the mess with multiple different extensions. The naming style doesnʼt alleviate the task. But this is a typical issue in the whole RISC-V ecosystem.

What Iʼm slightly confused for is that all these extensions, useful for a minor part of applications, arenʼt moved to longer instructions (6-byte).

▲

brucehoult a day ago | parent | next [-]

The average bystander doesn't have to care, just buy a machine implementing the RVA23 profile (standard set of extensions) and be happy.

If you're building your own embedded hardware then you determine what your needs actually are e.g. do you need double precision? half precision? vector?. Then you choose a chip implementing that. Then you copy the ISA string from your chip's documentation to the `-march=` argument for GCC/Clang and be happy.

It's not hard and you don't have to think about it unless you very specifically want to.

▲

fweimer 8 minutes ago | parent | next [-]

How does the average bystander buy a RVA23 machine today?

▲

bjourne an hour ago | parent | prev [-]

The average bystander might want to write high-performance code for their risc-v cpu. Then they must know precisely which instructions are available and what the performance implications of using them are. E.g., the difference between a shared and non-shared fp register file is huge.

▲

rwmj an hour ago | parent | next [-]

For the "average bystander" they're going to buy an OS and compatible hardware, or if they're the average programmer they're going to use a compiler and libraries that solve the problem already for them. Very very few people need to worry about the details.

▲

akarpathy 33 minutes ago | parent [-]

The average programmer still must inform their compiler what to use. Claude Code can assist with this.

	▲	andrepd 4 minutes ago \| parent [-]
		You need Claude Code to copy a string into your config/make file?

▲

panick21_ an hour ago | parent | prev [-]

You think the average person writes performance optmized code?

If you are on that level then you know pretty well what you are targeting. And even then in 99% of cases you just look at the top level profile.

If you do performance analysis for some specific embeded project that is not using a standard profile, then its a bit more work, but hardly impossible.

	▲	bjourne 39 minutes ago \| parent [-]
		Bruh, the "average person" won't buy a riscv-based computer in decades. The average bystander to the riscv project indeed writes high-performance code for their, so far, mostly non-existent or emulated riscv processors.

▲

camel-cdr 2 days ago | parent | prev | next [-]

> From a bystanderʼs POV it is excessively hard to memorize all the mess with multiple different extensions

It's the same for other ISAs.

> What Iʼm slightly confused for is that all these extensions, useful for a minor part of applications, arenʼt moved to longer instructions (6-byte).

Because these instructions don't need it. There will be future >4-byte instructions, for things thay can't resonably be done in 4-bytes, e.g. much larger immediates.

	▲	pclmulqdq 38 minutes ago \| parent [-]
		It's way worse on RISC-V. There are maybe 5 x86 or ARM variants to care about at any given time, even if you want to hyper-optimize your code. RISC-V has a soup of literally 100s of extensions with non-uniform use and support.

▲

rwmj an hour ago | parent | prev [-]

I agree the naming is annoying. However the extensions aren't too hard to understand. They are much more regular than on other architectures. I wrote a deep dive into them here: https://research.redhat.com/blog/article/risc-v-extensions-w...

Also groups of extensions are consolidated into Profiles, so in practice you don't really care about individual extensions. You'll only care that the hardware supports eg RVA23.