5 ms·

RISC-V cores are about 4 years behind ARM. So most they are most suitable for embedded systems and single board computers at the moment. At the lower end they

RISC-V cores are about 4 years behind ARM. So most they are most suitable for embedded systems and single board computers at the moment. At the lower end they have a big advantage as they can reach similar performance as Arm at half the silicon which translates into 4x lower price at similar volume of production. But for high-end chips you will not see this difference. SiFive has caught up about 2 years each year. So I suspect it will not work 3-4 years before RISC-V can compete with Arm desktop computers. Competing with Apple will take much longer. But such perspectives kind of miss the point. Then beauty of RISC-V is that it can be used in all sorts of specialized hardware such as accelerators. You may be able to program AI engines or maybe even some kind of graphics card with RISC-V instructions in the future.

zozbot234 4y ago
If anything, a more streamlined frontend matters more at the high-end, because it enables more scalable decode letting you extract increased parallelism out of the code. Better use of your frontend complexity budget also makes it easier to use things like fused microinsn sequences, or the RISC-V compressed insn set which brings code density on par with x86 (an outstanding result for such a clean design) for both RV32 and RV64. This is pretty much what we see going from x86 to ARM, and RISC-V only goes further in the same direction.
- seoaeu 4y ago
  Decode doesn't take up much space in a high-end processor. Even if your architecture's decoder doesn't "scale" as well, you can just throw a bunch more transistors at it to get performance. That said, I doubt there's many CPU designers unhappy about a simpler ISA...
  - imtringued 4y ago
    If macro op fusion is viable then there are more opportunities to throw more transistors at it to get more performance.
    - saagarjha 4y ago
      It's not yet clear if macro-op fusion will really be a thing.
      - kragen 4y ago
        Hmm, I'm no expert on the subject, but I had heard that CMP/Jcc and TEST/Jcc macro-op fusion has been critical to i386 and amd64 performance, for both Intel and AMD processors, for about 15 years?
        saagarjha 4y ago
        Those are "simple" fusions that processor do perform productively. The thing with RISC-V is that a lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" except nobody is really doing that kind of fusion right now, so it's not clear if this is even feasible.
        kragen 4y ago
        Hmm, not even the Allwinner D1 or the SiFive P650? In https://news.ycombinator.com/item?id=29423006 https://news.ycombinator.com/item?id=29423006 Bruce Hoult says SiFive has been doing macro-op fusion in one case since the 7-series, and I think he's the one that implemented it. In https://news.ycombinator.com/item?id=29444322 https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://arxiv.org/abs/1607.02318 https://arxiv.org/abs/1607.02318. Surprisingly, those present "shootout" results that are really just "effective dynamic instruction" counts and "dynamic byte" counts, ending in a "design proposal"; they don't seem to have simulated macro-op fusion at RTL level, much less in an FPGA or a MOSIS run.
        brucehoult 4y ago
        Certainly I didn't implement it, that was Andrew Waterman. I'm not a hardware person. I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible. There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the following instruction(s). There is a full 32 bits for that data path already, so that has zero effect on the back end (except just removing an instruction). SLLI/{SRLI,SRAI} pairs is probably another.

zozbot234 4y ago

If anything, a more streamlined frontend matters more at the high-end, because it enables more scalable decode letting you extract increased parallelism out of the code. Better use of your frontend complexity budget also makes it easier to use things like fused microinsn sequences, or the RISC-V compressed insn set which brings code density on par with x86 (an outstanding result for such a clean design) for both RV32 and RV64. This is pretty much what we see going from x86 to ARM, and RISC-V only goes further in the same direction.

seoaeu 4y ago
Decode doesn't take up much space in a high-end processor. Even if your architecture's decoder doesn't "scale" as well, you can just throw a bunch more transistors at it to get performance. That said, I doubt there's many CPU designers unhappy about a simpler ISA...
- imtringued 4y ago
  If macro op fusion is viable then there are more opportunities to throw more transistors at it to get more performance.
  - saagarjha 4y ago
    It's not yet clear if macro-op fusion will really be a thing.
    - kragen 4y ago
      Hmm, I'm no expert on the subject, but I had heard that CMP/Jcc and TEST/Jcc macro-op fusion has been critical to i386 and amd64 performance, for both Intel and AMD processors, for about 15 years?
      - saagarjha 4y ago
        Those are "simple" fusions that processor do perform productively. The thing with RISC-V is that a lot of the design rides on "oh we're just going to combine all the very RISC instructions into macro-ops to catch up to what ARM is doing" except nobody is really doing that kind of fusion right now, so it's not clear if this is even feasible.
        kragen 4y ago
        Hmm, not even the Allwinner D1 or the SiFive P650? In https://news.ycombinator.com/item?id=29423006 https://news.ycombinator.com/item?id=29423006 Bruce Hoult says SiFive has been doing macro-op fusion in one case since the 7-series, and I think he's the one that implemented it. In https://news.ycombinator.com/item?id=29444322 https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fusion-finalV2.pdf https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://arxiv.org/abs/1607.02318 https://arxiv.org/abs/1607.02318. Surprisingly, those present "shootout" results that are really just "effective dynamic instruction" counts and "dynamic byte" counts, ending in a "design proposal"; they don't seem to have simulated macro-op fusion at RTL level, much less in an FPGA or a MOSIS run.
        brucehoult 4y ago
        Certainly I didn't implement it, that was Andrew Waterman. I'm not a hardware person. I think macro-op fusion (with a few exceptions) is useful only on a narrow set of mid-range cores. High end cores want to split everything up (RISC-V comes pre-split), while low end cores want to use as little hardware as possible. There are a few exceptions, for example combining a LUI or AUIPC into a full 32 bit constant with the following instruction(s). There is a full 32 bits for that data path already, so that has zero effect on the back end (except just removing an instruction). SLLI/{SRLI,SRAI} pairs is probably another.