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

RISC-V Is Sloooow

marcin.juszkiewicz.com.pl

Post reply on HN
Print view View original

381–390 of 397 posts

Re: RISC-V Is Sloooow

#381

Post by [deleted] »

NetMageSCW wrote: post #308
LeFantome wrote: post #192

Earlier quoted context omitted.

First, x86-64 also has “extensions” such as avx, avx2, and avx512. Not all “x86-64” CPUs support the same ones. And you get things like svm on AMD and avx on Intel. Remember 3DNow? X86-64 also has “profiles” which tell you what extensions should be available. There is x86-64v1 and x86-64v4 with v2 and v3 in the middle. RVA23 offers a very similar feature-set to x86-64v4. You do not end up with a mess of extensions. Y…

>Anybody can build a RISC-V chip. You do not need permission. No, anybody can’t build a RISC-V chip. That’s the same mistake OSS proponents make. Just because something is open source doesn’t mean bugs will be found. And just because bugs are found doesn’t mean they will be fixed. The vast majority of people can’t do either. The number of people who can design a chip implementation of the RISC-V ISA is much, much sma…

[deleted]

Re: RISC-V Is Sloooow

#382

Post by LeFantome »

NetMageSCW wrote: post #308
LeFantome wrote: post #192

Earlier quoted context omitted.

First, x86-64 also has “extensions” such as avx, avx2, and avx512. Not all “x86-64” CPUs support the same ones. And you get things like svm on AMD and avx on Intel. Remember 3DNow? X86-64 also has “profiles” which tell you what extensions should be available. There is x86-64v1 and x86-64v4 with v2 and v3 in the middle. RVA23 offers a very similar feature-set to x86-64v4. You do not end up with a mess of extensions. Y…

>Anybody can build a RISC-V chip. You do not need permission. No, anybody can’t build a RISC-V chip. That’s the same mistake OSS proponents make. Just because something is open source doesn’t mean bugs will be found. And just because bugs are found doesn’t mean they will be fixed. The vast majority of people can’t do either. The number of people who can design a chip implementation of the RISC-V ISA is much, much sma…

> anybody can’t build a RISC-V chip

Yes, they can. My point is that nobody needs to give you permission. You can pretend that does not matter but China is about to educate us about what this means rather dramatically in the next few years.

And India is building RISC-V chips. And Europe is building RISC-V chips. Tenstorrent started in Canada (building RISC-V chips).

> the number who can get or own a FAB to manufacture the chips

Really? Almost nobody owns fabs and yet there are a multitude of chip makers. Getting access to a fab requires only money. It has nothing to do with the ISA or your skills. TSMC can make RISC-V chips just fine and already do. In some places, like China, RISC-V chips may be at the front of the line.

> The number of people who can design a chip implementation of the RISC-V ISA

Anybody can build a RISC-V chip. Build one yourself: https://github.com/tscheipel/HaDes-V

Every electrical engineer is going to know how to design a RISC-V chip. But you could also be an intelligent garbage man and design a RISC-V chip in your spare time using only open source materials. You can even tape it out.

https://tinytapeout.com/

"But that is only a 32 bit microcontroller!", you might say. Sure. But the skills to build RISC-V are going to propogate. Of course, that does not mean that everybody in the world is going to figure out how to build chips. That is clearly not my point. They will still be built primarily by a select few. But that is not unique to RISC-V by any stretch. In fact, less so.

The hard part about building a chip from scratch is not the ISA. You think that a world-class engineer working with ARM64 or amd64 today cannot design a RISC-V chip? That is like saying a carpenter building oak cabinets lacks the skills to make them with maple.

And since it is the same amount of work to start fresh regardless of ISA, why not start with RISC-V?

Except you do not have to start fresh with RISC-V because there are many, and will be many, many more, open designs to study and start with. Here is a 64 bit chip that implements the very latest RISC-V vector extensions:

https://github.com/tenstorrent/riscv-ocelot

Which, by the way, means that although most won't, anybody can build a RISC-V chip.

The RISC-V world will look like ARM. Most chip makers will license the core design off somebody else. But there will be more of those "somebody elses" to choose from. And there will be more people who choose to design their own silicon. Meta just bought Rivos. What for do you think? And they did not have to talk to ARM about it.

Re: RISC-V Is Sloooow

#383

Post by LeFantome »

pseudohadamard wrote: post #243
newpavlov wrote: post #114

Earlier quoted context omitted.

>Misaligned loads and stores are Zicclsm Nope. See https://github.com/llvm/llvm-project/issues/110454 which was linked in the first issue. The spec authors have managed to made a mess even here. Now they want to introduce yet another (sic!) extension Oilsm... It maaaaaay become part of RVA30, so in the best case scenario it will be decades before we will be able to rely on it widely (especially considering that RVA23…

RISC-V truly is the RyanAir of processors: Oh, you want FP maths? That's an optional extra, did you check that when you booked? And was that single or double-precision, all optional extras at an extra charge. Atomic instructions, that's an extra too, have your credit card details handy. Multiply and divide? Yeah, extras. Now, let me tell you about our high-end customer options, packed SIMD and user-level interrupts,…

RyanAir is the least expensive right? And it still gets you there?

I would be ok with that if it was a valid analogy.

It is valid in microcontroller land. There, the chip and the software are provided by the same party. So you can select for exactly the RISC-V features you need and save yourself some silicon. That sounds like a win to me.

At the application level, like a server or a desktop, that would be a disaster because I get my hardware and software from different people. How do the software guys know what hardware to target? Well, that is exacly why RVA23 exists.

What does RVA23 mean? It is the RISC-V "Application" profile. It allows you to build software to a single hardware target and trust that hardware makers will target the same proifle. RVA23 is like saying x86-64v4. Both are simple names for a long list of extensions (flags) and assumptions that you expect the hardware to honour. So, when Ubuntu 26.04 says it requires RVA23, it means that all the software built on it can assume those features. No a la carte.

The reason RVA23 is geting so much attention is that it has essentially the same feature set as modern ARM64 or x86-64. Software will be able to target this profile for a long time. There may be a new profile in a few years time, like RVA30, but hardware that implements that will still run RVA23 software (just as x86-64v4 hardware will run x86-64v1 software). Hardware built for profiles before RVA23 may be missing features modern applications expect.

I guess you could say that RVA23 is British Airways Business Class.

If you really want to support hardware designed before RVA23, almost everything you would want to run pre-built software on supports RVA20. And again, your RVA20 stuff will run fine on RVA23 hardware (but with fewer features--like no vectors). So maybe no in-flight meal, but it will get you there.

Re: RISC-V Is Sloooow

#384

Post by LeFantome »

fancyfredbot wrote: post #331
NetMageSCW wrote: post #312

Earlier quoted context omitted.

But that means a port of Linux can’t be to RISC-V, it has to be to a specific implementation of RISC-V, or if sufficient (which seems still debatable) to a specific common RISC-V profile.

You can target the minimum instruction set and it'll run everywhere. Albeit very slowly. Perhaps you use a fat binary to get reasonable performance in most cases. This isn't easy but it can be done (and it is being done on x86, despite constantly evolving variations of AVX).

Interestingly, RISC-V vector extensions are variable length.

So, you can compile your RISC-V software to require the equivalent of AVX and it will run on whatever size vectors the hardwre supports.

So, on x86-64, if I write AVX2 software and run it on AVX512 capable hardware, I am leaving performance on the table. But if I write software that uses AVX512, it will not run on hardware that does not support those extensions (flags).

On RISC-V, the same binary that uses 256 bit vectors on hardware that only supports that will use 512 bit vectors on hardware that supports it, or even 1024 bit vectors on hardware like the A100 cores of the SpacemiT K3.

So, I guess X86-64 is is the RyanAir of processors.

Re: RISC-V Is Sloooow

#385

Post by LeFantome »

Findecanor wrote: post #380
pseudohadamard wrote: post #243

Earlier quoted context omitted.

RISC-V truly is the RyanAir of processors: Oh, you want FP maths? That's an optional extra, did you check that when you booked? And was that single or double-precision, all optional extras at an extra charge. Atomic instructions, that's an extra too, have your credit card details handy. Multiply and divide? Yeah, extras. Now, let me tell you about our high-end customer options, packed SIMD and user-level interrupts,…

I don't agree with that comparison. RyanAir is about exploiting consumers, with bait-and-switch and shitty terms and conditions. RISC-V's modularity is about giving choice to hardware designers, so they can pick and choose just those features that their solution needs, and even allow for custom extensions. RISC-V's modularity is for academia. 1) for education, where students learn/use/work on simple processors, 2) fo…

Extensiosn are not just for academia. If I am building a microcontroller to control the storage media I am selling (eg. hard drives), why do I need to implement a bunch of features I am not going to use? What about my flow rate monitor? Or my pacemaker?

In some of these, less silicon means less power means more better. Like that last example.

Re: RISC-V Is Sloooow

#386

Post by userbinator »

snvzz wrote: post #378
userbinator wrote: post #372

Earlier quoted context omitted.

Here is your "better data": https://web.eece.maine.edu/~vweaver/papers/iccd09/ll_documen...

From 2017, it predates RISC-V first ratified spec. Currently, RISC-V holds the crown of code density in both 64 and 32 bit. On 32bit, thumb2 is a little behind. On 64bit, x86-64 is not even close, and ARMv8/v9 are even worse.

You've shown absolutely zero evidence.

"Maybe if I keep repeating it, it'll be true."

Re: RISC-V Is Sloooow

#387

Post by janwas »

LeFantome wrote: post #384
fancyfredbot wrote: post #331

Earlier quoted context omitted.

You can target the minimum instruction set and it'll run everywhere. Albeit very slowly. Perhaps you use a fat binary to get reasonable performance in most cases. This isn't easy but it can be done (and it is being done on x86, despite constantly evolving variations of AVX).

Interestingly, RISC-V vector extensions are variable length. So, you can compile your RISC-V software to require the equivalent of AVX and it will run on whatever size vectors the hardwre supports. So, on x86-64, if I write AVX2 software and run it on AVX512 capable hardware, I am leaving performance on the table. But if I write software that uses AVX512, it will not run on hardware that does not support those extens…

(Personal opinion) I get the impression that RISC-V-related discussions often lack of awareness of prior work/alternatives. A large amount of (x86) software actually uses our Highway library to run on whatever size vectors and instructions the CPU offers.

This works quite well in practice. As to leaving performance on the table, it seems RVV has some egregious performance differences/cliffs. For example, should we use vrgather (with what LMUL), or interesting workarounds such as widening+slide1, to implement a basic operation such as interleaving two vectors?

Re: RISC-V Is Sloooow

#388

Post by camel-cdr »

janwas wrote: post #387
LeFantome wrote: post #384

Earlier quoted context omitted.

Interestingly, RISC-V vector extensions are variable length. So, you can compile your RISC-V software to require the equivalent of AVX and it will run on whatever size vectors the hardwre supports. So, on x86-64, if I write AVX2 software and run it on AVX512 capable hardware, I am leaving performance on the table. But if I write software that uses AVX512, it will not run on hardware that does not support those extens…

(Personal opinion) I get the impression that RISC-V-related discussions often lack of awareness of prior work/alternatives. A large amount of (x86) software actually uses our Highway library to run on whatever size vectors and instructions the CPU offers. This works quite well in practice. As to leaving performance on the table, it seems RVV has some egregious performance differences/cliffs. For example, should we us…

> For example, should we use vrgather (with what LMUL), or interesting workarounds such as widening+slide1, to implement a basic operation such as interleaving two vectors?

Use Zvzip, in the mean time:

zip: vwmaccu.vx(vwaddu.vv(a, b), -1, b), or segmented load/store when you are touching memory anyways

unzip: vsnrl

trn1/trn2: masked vslide1up/vslide1down with even/odd mask

The only thing base RVV does bad in those is register to register zip, which takes twice as many instructions as other ISAs. Zvzip gives you dedicated instructions of the above.

Re: RISC-V Is Sloooow

#389

Post by janwas »

camel-cdr wrote: post #388
janwas wrote: post #387

Earlier quoted context omitted.

(Personal opinion) I get the impression that RISC-V-related discussions often lack of awareness of prior work/alternatives. A large amount of (x86) software actually uses our Highway library to run on whatever size vectors and instructions the CPU offers. This works quite well in practice. As to leaving performance on the table, it seems RVV has some egregious performance differences/cliffs. For example, should we us…

> For example, should we use vrgather (with what LMUL), or interesting workarounds such as widening+slide1, to implement a basic operation such as interleaving two vectors? Use Zvzip, in the mean time: zip: vwmaccu.vx(vwaddu.vv(a, b), -1, b), or segmented load/store when you are touching memory anyways unzip: vsnrl trn1/trn2: masked vslide1up/vslide1down with even/odd mask The only thing base RVV does bad in those is…

Looks like the ratification plan for Zvzip is November. So maybe 3y until HW is actually usable? That's a neat trick with wmacc, congrats. But still, half the speed for quite a fundamental operation that has been heavily used in other ISAs for 20+ years :(

Great that you did a gap analysis [1]. I'm curious if one of the inputs for that was the list of Highway ops [2]?

[1]: https://gist.github.com/camel-cdr/99a41367d6529f390d25e36ca3... [2]: https://github.com/google/highway/blob/master/g3doc/quick_re...

Re: RISC-V Is Sloooow

#390

Post by snvzz »

userbinator wrote: post #386
snvzz wrote: post #378

Earlier quoted context omitted.

From 2017, it predates RISC-V first ratified spec. Currently, RISC-V holds the crown of code density in both 64 and 32 bit. On 32bit, thumb2 is a little behind. On 64bit, x86-64 is not even close, and ARMv8/v9 are even worse.

You've shown absolutely zero evidence. "Maybe if I keep repeating it, it'll be true."

I am sure you are capable of running a compiler and/or running `size` on Ubuntu binaries.
Post reply on HN