4 ms·

Unfortunately, RISCV is really a mess right now, the Vector extensions are horrible. Amusingly, LoongArch has better Linux support than RISCV right now too... W

Unfortunately, RISCV is really a mess right now, the Vector extensions are horrible. Amusingly, LoongArch has better Linux support than RISCV right now too... Would've definetly been nice to see them adopt RISCV though. ISAs are fragmented enough as is.

camel-cdr 3y ago
> the Vector extensions are horrible How so?
- luyu_wu 3y ago
  They're horribly fragmented (there's many ISA extensions that accomplish the same thing from different companies), and thus a headache to deal with for any compiler (which is why the compiler support sucks).
  - camel-cdr 3y ago
    There is one standard vector extension, and one company that released two chips with a non standard pre ratification version of the extension. It was released almost two years before the first rvv 1.0 hardware became available at the end of last year. Without out it, we wouldn't have had any hardware at all. rvv 1.0 has quite good upstream compiler support already, and before that the t-head had custom compilers that supported their rvv 0.7.1 version of the vector extension. Now upstream gcc supports it as an alternative codegen target as well, so you can write rvv 1.0 vector instrinsics and compile those to the thead rvv 0.7.1 implementation. I'm not aware of any company that plans to release a non rvv 1.0 rvv implementation.
    - sylware 3y ago
      Each time somebody is spitting on risc-v vector extension, it is the same false argument of fragmentation, and each time somebody fixes it with the real truth (pre-ratification of some vendors). Arm/x86 fan boys?
      - janwas 3y ago
        "Real truth" and "fan boys"? Let's have some facts: there are indeed a boatload of extensions, though perhaps not (yet) to the V extension itself. T-HEAD [1], Ventana's ternary op [2], Sifive also has a couple [3], including "Xsfvfwmaccqqq", one of at least four completely different matmul variants. In particular for the latter, I would say fragmentation is an absolutely valid concern at the moment. [1]: https://github.com/T-head-Semi/thead-extension-spec https://github.com/T-head-Semi/thead-extension-spec [2]: https://github.com/ventanamicro/ventana-custom-extensions/releases https://github.com/ventanamicro/ventana-custom-extensions/re... [3]: https://www.sifive.com/documentation https://www.sifive.com/documentation
        camel-cdr 3y ago
        T-Head also has their own matmul extensions, but t-head, SiFive, Andes, Rivos, IMB, ... have all people working on the risc-v integrated matrix extension spec. The vendors presented their own matmul extensions, but none of them solve all problems that the integrated matrix extension should solve. Most importantly binary compatibility across vector lengths. The last to meeting presented alternatives that would satisfy that requirement. It will however take some time to decide on and experiment with the best design. I agree that this can turn out messy, so far I haven't seen anyone, outside of vendor libraries, use the t-head or SiFive matmul extensions in open source code. Ventanas ternary op and similar will hopefuly consolidate on the cmov extension.
        sylware 3y ago
        At some point we will get a matmul extension which fit- a good set of compromises/use cases. (there are still people thinking there will be no tradeoff). cmov extension? Like on x86?
        janwas 3y ago
        I agree the situation changes if there is a single new spec, this is why I wrote "at the moment". Do you have any insight on when it's finished/ widely available? I'd guess two years?
        3y ago

camel-cdr 3y ago

> the Vector extensions are horrible How so?

luyu_wu 3y ago
They're horribly fragmented (there's many ISA extensions that accomplish the same thing from different companies), and thus a headache to deal with for any compiler (which is why the compiler support sucks).
- camel-cdr 3y ago
  There is one standard vector extension, and one company that released two chips with a non standard pre ratification version of the extension. It was released almost two years before the first rvv 1.0 hardware became available at the end of last year. Without out it, we wouldn't have had any hardware at all. rvv 1.0 has quite good upstream compiler support already, and before that the t-head had custom compilers that supported their rvv 0.7.1 version of the vector extension. Now upstream gcc supports it as an alternative codegen target as well, so you can write rvv 1.0 vector instrinsics and compile those to the thead rvv 0.7.1 implementation. I'm not aware of any company that plans to release a non rvv 1.0 rvv implementation.
  - sylware 3y ago
    Each time somebody is spitting on risc-v vector extension, it is the same false argument of fragmentation, and each time somebody fixes it with the real truth (pre-ratification of some vendors). Arm/x86 fan boys?
    - janwas 3y ago
      "Real truth" and "fan boys"? Let's have some facts: there are indeed a boatload of extensions, though perhaps not (yet) to the V extension itself. T-HEAD [1], Ventana's ternary op [2], Sifive also has a couple [3], including "Xsfvfwmaccqqq", one of at least four completely different matmul variants. In particular for the latter, I would say fragmentation is an absolutely valid concern at the moment. [1]: https://github.com/T-head-Semi/thead-extension-spec https://github.com/T-head-Semi/thead-extension-spec [2]: https://github.com/ventanamicro/ventana-custom-extensions/releases https://github.com/ventanamicro/ventana-custom-extensions/re... [3]: https://www.sifive.com/documentation https://www.sifive.com/documentation
      - camel-cdr 3y ago
        T-Head also has their own matmul extensions, but t-head, SiFive, Andes, Rivos, IMB, ... have all people working on the risc-v integrated matrix extension spec. The vendors presented their own matmul extensions, but none of them solve all problems that the integrated matrix extension should solve. Most importantly binary compatibility across vector lengths. The last to meeting presented alternatives that would satisfy that requirement. It will however take some time to decide on and experiment with the best design. I agree that this can turn out messy, so far I haven't seen anyone, outside of vendor libraries, use the t-head or SiFive matmul extensions in open source code. Ventanas ternary op and similar will hopefuly consolidate on the cmov extension.
        sylware 3y ago
        At some point we will get a matmul extension which fit- a good set of compromises/use cases. (there are still people thinking there will be no tradeoff). cmov extension? Like on x86?
        janwas 3y ago
        I agree the situation changes if there is a single new spec, this is why I wrote "at the moment". Do you have any insight on when it's finished/ widely available? I'd guess two years?
      - 3y ago