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

RISC-V Vector Primer

github.com

Post reply on HN
Print view View original

21–23 of 23 posts

Re: RISC-V Vector Primer

#21

Post by shash »

actionfromafar wrote: post #17
camel-cdr wrote: post #13

Earlier quoted context omitted.

The name, yes, but going by name is a bad idea as the V in AVX also stands for Vector. BTW, you'll be disappointed if you think of the P extension as something like SSE/AVX. The target for it is way lower power/perf, like a stripped-down MMX. My point was about the underlying hardware implementation, specifically: > "As shown in Figure 1-3, array processors scale performance spatially by replicating processing elemen…

Stripped down MMX? What's left then I wonder? :-D

As sibling said, stripped down in the sense it doesn’t have dedicated registers. In terms of supported functions it’s somewhere close to MMX.

I don’t personally like it because it still ends up with all the headache of building most of a vector subsystem (data path, functional units,…) while _only_ pretty much reducing one special vector file.

Re: RISC-V Vector Primer

#22

Post by shash »

camel-cdr wrote: post #13
shash wrote: post #9

Earlier quoted context omitted.

It _is_ RISC-V Vector extensions, so a very specific ISA in mind at the very least. There's another extension (not ratified I think) called Packed SIMD for RISC-V, but this isn't about that.

The name, yes, but going by name is a bad idea as the V in AVX also stands for Vector. BTW, you'll be disappointed if you think of the P extension as something like SSE/AVX. The target for it is way lower power/perf, like a stripped-down MMX. My point was about the underlying hardware implementation, specifically: > "As shown in Figure 1-3, array processors scale performance spatially by replicating processing elemen…

> The name, yes, but going by name is a bad idea as the V in AVX also stands for Vector.

Now I get your point after reading more of the linked page. Yes. It is very implementation specific.

One of the things about RVV (and in general any vector ISA) is that the data path can be different enough between different implementations such that specific rules of thumb for hand tuning most probably won’t carry over. As you say it is true of even sufficiently advanced SIMD architectures like AVX.

Re: RISC-V Vector Primer

#23

Post by Narishma »

camel-cdr wrote: post #18
actionfromafar wrote: post #17

Earlier quoted context omitted.

Stripped down MMX? What's left then I wonder? :-D

That was a bit overblown, due to my lack of knowlage about MMX. It has a lot more things than MMX. But the core idea behind the P extension was to reuse the GPRs to do SIMD operations with little additional implementation cost. The spec is currently all over the place, the best reference is currently probably the WIP intrinsics documentation: https://github.com/topperc/p-ext-intrinsics/blob/main/source... P is not me…

> But the core idea behind the P extension was to reuse the GPRs to do SIMD operations with little additional implementation cost.

I think ARMv6 had something similar, before they went with proper SIMD in v7.

Post reply on HN