upvote
The two authors also have a very different definition of what "high-end" means.

Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero seems to think that anything larger than a "dirt cheap microcontroller" is high-end.

People shouldn't take this the wrong way, but the VexRISC-V cores in Baochip are not "high-end". They are basically as low-end as you can get while still meeting the modern definition of "application core". And that doesn't matter, because being high-end application SoC is not Baochip's design criteria. These cores are actually pretty decent for Baochip's criteria.

The VexRISC-V are implementing the exact style of "classic-RISC" microarchitecture that RISC-V is optimised for. It's basically the optimal niche for RISC-V, before any of the problems start showing up.

I don't think I've ever seen anyone express the opinion that RISC-V can't easily cover the "dirt cheap microcontroller" to "low-end application processor" range, even stretching up into "mid-range application processor". Just that it's really fighting an uphill battle if it ever wants to compete with high-end application processors (and that it's going to struggle in the low-range/mid-range application market because of that).

reply
The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion.

And RISC-V is just starting here with shoestring design and fab budget. Wait till all engineering teams really adopt it like Tenstorrent and NextSilicon and so on.

reply
> really crazy optimizations that they are doing

Any examples of this?

reply
Here are a few random things I know of:

* Tenstorrent Ascalon has a neat optimization for certain LMUL>1 SIMD operations. LMUL=2 effectively unrolls the SIMD operation making it read two SIMD registers from every source and write two SIMD registers to the destination. There are however some instructions where LMUL=2 only needs to write to one registers, those are narrowing instructions (e.g. 64-bit to 32-bit truncation) and comparisons (which write to a LMUL=1 register with packed bits). When those SIMD instructions have to .vx form, which means one argument comes from a GPR, they now only need to write one SIMD register and need to read two SIMD registers. This matches what regular SIMD instructions need and because the silicon for the execution is much cheaper than register file ports, Ascalon can exexute these instructions in a single operation. So you can compare twice as many SIMD elements against a scalar, then you can against another SIMD register.

* Ventana (now under Qualcomm) talked a tiny bit about their fetch-block-optimizer and something that sounded like a L1i-trace cache. The fetch-block-optimizer would go to certain hot L1i entries and "optimize" them, with agressive instruction fusion including fusion of non-adjacent instructions.

* NextSilicon: Idk any details yet, but they said they handled RVC without increasing latency and that they've found a good solution for implement RVV and especially LMUL, which is a challange in out-of-order designs.

* OpenXiangShan: The fastes open-source CPU, is working on doing 2-ahead instruction fetch (the thing Zen5 added).

Now that being said, Ventana was bought by Qualcomm, we know the RISC-V team is still alive, but who knows if we'll ever see anything from that outside of Qualcomm?

The Tenstorrent Ascalon devboard is way behind schedule and on 12nm TSMC instead of a 4nm node the processor was designed for and is now supposed to clock at 1.38GHz. Though I think the delay has more to do with TT management problems then with the actual design.

While the scalar part of OpenXiangShan looks really good, the RVV imolementation is currently basically unusable. They want to have fix for the problems until the end of the year, but we'll have to see.

reply
How do you keep up with such information? Any sources you could recommend? Closest I know would be SemiAnalysis
reply
There aren't ones that wouldn't be served better by ARM

The improvement is entirely "we don't have to pay ARM"

reply
> The huge number of companies building RISC-V chips and really crazy optimizations that they are doing in all kinds of spaces are a very real counterweight to your notion.

I assume this is addressing

> and since all the RISC-V SBCs I'm aware of have significantly worse performance and efficiency than comparably priced ARM SBCs.

If so, could you point at specific SBCs that beat ARM SBC perf?

reply
> Personally I don't see the benefit of this since you're going to have to recompile your software anyway

The benefit is a unified toolchain. Make a chip, get the entire software toolchain for free.

In the past if you made your own chip you had to write your own assembler, compiler, debugger, etc. Many manufacturers forked gcc but of course it's still a lot of work and the license isn't great (for them, not the user).

This universal compiler toolchain is massive benefit for both the chip makers and the end user.

reply
Different RISC-V dialects might as well be as different from each other as English is from German. Sure, the cognates, family the resemblance, and common(-ish) alphabet make some things easier, but if you're shipping a manual, you still need to do it both in English and auf Deutsch unless you rely on machine translation.

So it is with the family of mutually incomprehensible ISAs called RISC-V.

reply
Yeah I know this mess in PowerPC. There is IBM Power, there is MPC5xx ISA, there is VLE and and several other dialects. Some processors are doing those some doing others, some needs bit to signal if program runs VLE... just crazy chaos.
reply