3 ms·

And we're back to you wanting all RVV implementors to make the same performance vs size/cost trade-offs when the whole point of it is that different implementor

And we're back to you wanting all RVV implementors to make the same performance vs size/cost trade-offs when the whole point of it is that different implementors have the freedom to make the trade-offs that make sense for their target markets -- and you have the freedom to buy them or not buy them, depending on whether they fit your needs. There is not a single vendor who has to address all markets and use-cases, there will be dozens of them, all using a common ISA and all (sensibly witten) software will run everywhere, at varying levels of performance and cost.

dzaima 2y ago
It's not so much that I want that, more that it's a basic and requirement for fixed-width usages, and is easily attained by aarch64 & x86. Whereas RVV's potential of tradeoffs clearly interferes with that. And if hardware making bad tradeoffs for fixed-width usages ever makes it to general-purpose usage to any significance, RVV as a whole would end up being required to be considered as not fit for fixed-width stuff (outside of extremely important & well-funded things where people can afford to add manual tuning for each separate funky CPU, but it's a pretty safe bet that most developers won't have every single piece of RISC-V hardware.. especially that which they would hate). Without reasonable performance guarantees, "RVV can imitate NEON" is as useful of a statement as "base RV64G without any extensions at all can imitate NEON". It's just stating that it's a turing-complete system.
- brucehoult 2y ago
  And, once again, I point out that X280 is not intended for general-purpose usage. It's for special purpose stuff, and I'm sure fits what NASA wants in their space PIC64 chip very well. In the specific case of the SG2380, the 16 P670 cores are there for general-purpose use, with the 4 X280s for specialised uses. And, again, even at 1 element per cycle, using vrgather is significantly faster than not using it and using the dual-issue scalar side instead. AND at short NEON or AVX vector lengths the X280 is single-cycle for vrgather *anyway*.
  - dzaima 2y ago
    If what camel-cdr in another comment here said is correct, the single-cycle vrgather wouldn't apply to anything not written specifically for X280 as I doubt anything anywhere is attempting to use LMUL=1/2 for 128-bit or 256-bit vrgather. But, sure, X280 might not be intended for general-purpose usage. Still pretty sure that won't stop people from trying. And it's far from impossible, and, to some extent even reasonable, for future hardware to be intended for general-purpose usage while still disadvantaging fixed-width. And, for a good number of fixed-width SIMD usages, the alternative might not necessarily be "do everything exactly as with SIMD but in scalar registers with one instruction per would-be-SIMD-element"; namely, SWAR could be utilized, some shifts/rotates/bswap/multiplies used in place of shuffles, entirely different algorithms used, and you wouldn't need to duplicate computation for something like a cumulative sum/xor that on SIMD would've been implemented as log2(n) slides. I've had a good number of cases where some fixed-width x86 SIMD thing is only marginally faster than the scalar baseline. I'm not saying this is some utter massive disaster that'll kill RVV; but vrgather definitely, as-is, is pretty inadequate for many things that it can actually do purely due to forcibly having both operands have the same LMUL and having only that as the cap on the table size; and it is unquestionably possible (though not guaranteed, and maybe even unlikely) that in the future software will be expected to handle funky-tradeoff hardware, which'd suck for software developers.
    - brucehoult 2y ago
      I will agree with you on one thing. Having `vrgather` use the same `LMUL` for both operands is not ideal. It's natural, of course, for permutations, where the actual data is in the lookup table and the indexes are the permutation, but not for other uses where the indexes are the data and the table is a table. Having the table ignore `vl` is also ugly. The proper solution would, I think, be to have duplicate `vtype` and `vl` CSRs that are set up by a different `vsetvl2` instruction. It would be seldom-enough used to dispense with the opcode-expensive immediate form and only take the type from a register, making it a cheap I-type instruction. This would also solve the problem of table and indexes having different element sizes that prompted the late creation of the `vrgather16` instruction and imposition of the artificial 65536 bit limit on `VLEN` in RVV 1.0 and foreshadowing of a potential future `vrgather32`.

dzaima 2y ago

It's not so much that I want that, more that it's a basic and requirement for fixed-width usages, and is easily attained by aarch64 & x86. Whereas RVV's potential of tradeoffs clearly interferes with that. And if hardware making bad tradeoffs for fixed-width usages ever makes it to general-purpose usage to any significance, RVV as a whole would end up being required to be considered as not fit for fixed-width stuff (outside of extremely important & well-funded things where people can afford to add manual tuning for each separate funky CPU, but it's a pretty safe bet that most developers won't have every single piece of RISC-V hardware.. especially that which they would hate). Without reasonable performance guarantees, "RVV can imitate NEON" is as useful of a statement as "base RV64G without any extensions at all can imitate NEON". It's just stating that it's a turing-complete system.

brucehoult 2y ago
And, once again, I point out that X280 is not intended for general-purpose usage. It's for special purpose stuff, and I'm sure fits what NASA wants in their space PIC64 chip very well. In the specific case of the SG2380, the 16 P670 cores are there for general-purpose use, with the 4 X280s for specialised uses. And, again, even at 1 element per cycle, using vrgather is significantly faster than not using it and using the dual-issue scalar side instead. AND at short NEON or AVX vector lengths the X280 is single-cycle for vrgather *anyway*.
- dzaima 2y ago
  If what camel-cdr in another comment here said is correct, the single-cycle vrgather wouldn't apply to anything not written specifically for X280 as I doubt anything anywhere is attempting to use LMUL=1/2 for 128-bit or 256-bit vrgather. But, sure, X280 might not be intended for general-purpose usage. Still pretty sure that won't stop people from trying. And it's far from impossible, and, to some extent even reasonable, for future hardware to be intended for general-purpose usage while still disadvantaging fixed-width. And, for a good number of fixed-width SIMD usages, the alternative might not necessarily be "do everything exactly as with SIMD but in scalar registers with one instruction per would-be-SIMD-element"; namely, SWAR could be utilized, some shifts/rotates/bswap/multiplies used in place of shuffles, entirely different algorithms used, and you wouldn't need to duplicate computation for something like a cumulative sum/xor that on SIMD would've been implemented as log2(n) slides. I've had a good number of cases where some fixed-width x86 SIMD thing is only marginally faster than the scalar baseline. I'm not saying this is some utter massive disaster that'll kill RVV; but vrgather definitely, as-is, is pretty inadequate for many things that it can actually do purely due to forcibly having both operands have the same LMUL and having only that as the cap on the table size; and it is unquestionably possible (though not guaranteed, and maybe even unlikely) that in the future software will be expected to handle funky-tradeoff hardware, which'd suck for software developers.
  - brucehoult 2y ago
    I will agree with you on one thing. Having `vrgather` use the same `LMUL` for both operands is not ideal. It's natural, of course, for permutations, where the actual data is in the lookup table and the indexes are the permutation, but not for other uses where the indexes are the data and the table is a table. Having the table ignore `vl` is also ugly. The proper solution would, I think, be to have duplicate `vtype` and `vl` CSRs that are set up by a different `vsetvl2` instruction. It would be seldom-enough used to dispense with the opcode-expensive immediate form and only take the type from a register, making it a cheap I-type instruction. This would also solve the problem of table and indexes having different element sizes that prompted the late creation of the `vrgather16` instruction and imposition of the artificial 65536 bit limit on `VLEN` in RVV 1.0 and foreshadowing of a potential future `vrgather32`.