4 ms·

So it's modular. This is normally considered a good thing. It means you don't have to pay for features you don't need. The ISA is open so there's no greedy co

So it's modular. This is normally considered a good thing. It means you don't have to pay for features you don't need. The ISA is open so there's no greedy corporation trying to upsell you. I mean there's an implementation and die area cost for each extension but it's not being set at an artificial level by a monopolist.

Symmetry 7mo ago
It's a good thing in many cases but not if you're going to be running applications distributed as binaries. Maybe if we go the Gentoo route of everybody always recompiling everything for their own system?
- snvzz 7mo ago
  Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.
  - pseudohadamard 7mo ago
    RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.
    - adgjlsfhk1 7mo ago
      RVA23 (and RVA20 before it) aren't an admission that Risc-V got it wrong. It's a necessary step to make Risc-V competetive in the desktop space as opposed to micro-controllers where the flexibility is hugely valuable.
      - brucehoult 7mo ago
        Rubbish. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
    - orangeboats 7mo ago
      "Making everything optional" is for the embedded space. As for general purpose processors, RISC-V has always had the idea of profiles (mandatory set of extensions). Just look at the G extension, which mandated floating point, multiply/division, atomics, ... things that you expect to see on user-facing general-purpose processors. > the belated admission that maybe we shouldn't have everything as optional extras That's why I disagree with the above claim. (1) The optionality is a feature of RISC-V and it allows RISC-V to shine on different ecosystems. The desktop isn't everything. (2) RISC-V has always addressed the fear of fragmentation on the desktop by using profiles.
    - brucehoult 7mo ago
      There is nothing "belated" about it. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
NetMageSCW 7mo ago
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.
- fancyfredbot 7mo ago
  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).
  - LeFantome 7mo ago
    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.
    - janwas 7mo ago
      (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?
      - 7mo ago
pseudohadamard 7mo ago
There's a good chance you're actually paying more for the features you don't need. Preparing an EUV mask set costs something like 30 million dollars (that figure may be out of date, i.e. it could be more now). So instead of a single mask set with everything on the device, whether you need it or not, you're paying $30 million for each special-snowflake variant. This is why vendors do a one-size-fits-all version of many of their products and then disable the extra functionality for the cheaper market segments, because it's much, much cheaper than making separate reduced-functionality devices.

Symmetry 7mo ago

It's a good thing in many cases but not if you're going to be running applications distributed as binaries. Maybe if we go the Gentoo route of everybody always recompiling everything for their own system?

snvzz 7mo ago
Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.
- pseudohadamard 7mo ago
  RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.
  - adgjlsfhk1 7mo ago
    RVA23 (and RVA20 before it) aren't an admission that Risc-V got it wrong. It's a necessary step to make Risc-V competetive in the desktop space as opposed to micro-controllers where the flexibility is hugely valuable.
    - brucehoult 7mo ago
      Rubbish. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...
  - orangeboats 7mo ago
    "Making everything optional" is for the embedded space. As for general purpose processors, RISC-V has always had the idea of profiles (mandatory set of extensions). Just look at the G extension, which mandated floating point, multiply/division, atomics, ... things that you expect to see on user-facing general-purpose processors. > the belated admission that maybe we shouldn't have everything as optional extras That's why I disagree with the above claim. (1) The optionality is a feature of RISC-V and it allows RISC-V to shine on different ecosystems. The desktop isn't everything. (2) RISC-V has always addressed the fear of fragmentation on the desktop by using profiles.
  - brucehoult 7mo ago
    There is nothing "belated" about it. The "G" extension for everything you want to run shrink-wrapped binaries on a standard OS has been there since the May 7 2014 "User Level ISA, Version 2.0", which is before RISC-V started to be promoted outside of Berkeley e.g. at Hot Chips 26 in August 2014, and the first RISC-V workshop in January 2015 in Monterey. The name "G" has morphed into now (along with the C extension) being called "RVA20", which led to "RVA22" and "RVA23", but the principle is unchanged. "An integer base plus these four standard extensions (“IMAFD”) is given the abbreviation “G” and provides a general-purpose scalar instruction set. RV32G and RV64G are currently the default target of our compiler toolchains." pp 4-5 in https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-54.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

NetMageSCW 7mo ago

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.

fancyfredbot 7mo ago
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).
- LeFantome 7mo ago
  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.
  - janwas 7mo ago
    (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?
    - 7mo ago

pseudohadamard 7mo ago

There's a good chance you're actually paying more for the features you don't need. Preparing an EUV mask set costs something like 30 million dollars (that figure may be out of date, i.e. it could be more now). So instead of a single mask set with everything on the device, whether you need it or not, you're paying $30 million for each special-snowflake variant. This is why vendors do a one-size-fits-all version of many of their products and then disable the extra functionality for the cheaper market segments, because it's much, much cheaper than making separate reduced-functionality devices.