3 ms·

> It does for ara but not for all other implementations I could get my hands on (which all have a VLEN of 128 or 256, so relatively small). I generally would e

> It does for ara but not for all other implementations I could get my hands on (which all have a VLEN of 128 or 256, so relatively small). I generally would expect it to have no effect, because it's difficult to base scheduling/forwarding decisions off a register value. Though for Ara2, given your other post, it sounds like it's really just a 512-bit vector processor that pretends to be 4096-bit, in which case, it can probably adapt to VL changes. > Yeah, but there you can just use multiple LMUL=1 vrgathers I never considered LMUL>1 - I've always been talking about LMUL=1. > I think most lookup table uses of vrgather fit within 128 or 256 bits, 4 byte lut is greate for character matching. Ideally yes, but the problem is that there's no way to actually do just this under RVV. According to spec, vrgather must consider the full vector, regardless of VL. In other words, if your VLMAX is 4096b, so is your lookup table. And this is a major criticism I have about RVV in general. They tout support up to 65536-bit vectors, however the spec includes aspects which are difficult to scale to large vectors. IMO, SVE2/2.1 does a much better job.

camel-cdr 3y ago
> Though for Ara2, given your other post, it sounds like it's really just a 512-bit vector processor that pretends to be 4096-bit, in which case, it can probably adapt to VL changes. I think they use a larger register file to reduce sceduling overhead and memory latency. > According to spec, vrgather must consider the full vector, regardless of VL. In other words, if your VLMAX is 4096b, so is your lookup table. Interesting I didn't know that. I suppose large LMUL implementations would need to tag vector registers with their vl to make this work or take more cycles if it goes outside of a certain range.
- RaisingSpear 3y ago
  > I suppose large LMUL implementations would need to tag vector registers with their vl to make this work Again, I'm only considering LMUL=1 here. You'd need to also tag how tail elements are handled; tail undisturbed probably won't work, so it'd only work with tail agnostic, and if the processor always sets tail elements to -1. It'd also be more complicated with LMUL>1, since the processor would have to check the tagged VL for all registers in the group. And having scheduling depend on multiple register values is going to be problematic, but it's probably doable if high performance isn't a major concern. In general, it's wrong to think of VL meaning "vector length". It's more accurate to think of it as an additional mask such that mask=(1<<vl)-1
  - camel-cdr 3y ago
    Sorry I used the wrong word, I meant VLEN instead of LMUL.
    - RaisingSpear 3y ago
      Ah that makes more sense. It's easy to get confused with RVV, given all the acronyms and config options. Despite it's "RISC" background, I find it much more complex and confusing than AVX and SVE.

camel-cdr 3y ago

> Though for Ara2, given your other post, it sounds like it's really just a 512-bit vector processor that pretends to be 4096-bit, in which case, it can probably adapt to VL changes. I think they use a larger register file to reduce sceduling overhead and memory latency. > According to spec, vrgather must consider the full vector, regardless of VL. In other words, if your VLMAX is 4096b, so is your lookup table. Interesting I didn't know that. I suppose large LMUL implementations would need to tag vector registers with their vl to make this work or take more cycles if it goes outside of a certain range.

RaisingSpear 3y ago
> I suppose large LMUL implementations would need to tag vector registers with their vl to make this work Again, I'm only considering LMUL=1 here. You'd need to also tag how tail elements are handled; tail undisturbed probably won't work, so it'd only work with tail agnostic, and if the processor always sets tail elements to -1. It'd also be more complicated with LMUL>1, since the processor would have to check the tagged VL for all registers in the group. And having scheduling depend on multiple register values is going to be problematic, but it's probably doable if high performance isn't a major concern. In general, it's wrong to think of VL meaning "vector length". It's more accurate to think of it as an additional mask such that mask=(1<<vl)-1
- camel-cdr 3y ago
  Sorry I used the wrong word, I meant VLEN instead of LMUL.
  - RaisingSpear 3y ago
    Ah that makes more sense. It's easy to get confused with RVV, given all the acronyms and config options. Despite it's "RISC" background, I find it much more complex and confusing than AVX and SVE.