Comment by whateverboat

6 hours ago

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.

> 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?

  • Take a look at some of the really new ones, like the Milk-V Jupiter 2 based around the SpaceMIT K3[0]. Single core is still lacking but the multi-core isn't all that far behind a pi5 (350 vs 900 single core and 1700 vs 2100 multicore in a geekbench beta version).

    And I will note that the other poster didn't say they beat it, just that there are lots of chips being built. I'd imagine that the cores on the tenstorrent cards would blow all the other arm cores out of the water if you could run the benchmarks on them directly, given the much higher core speeds and memory bandwidth etc.

    [0] https://youtu.be/vSKA6thLI1U?t=993

    • The multicore is only close because the RISC-V one has twice as many cores and uses twice as much power. That would suggest the RISC-V cores are getting around pi3 levels of performance which is a decade old and losing badly as perf/W.

> really crazy optimizations that they are doing

Any examples of this?

  • 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.

  • There aren't ones that wouldn't be served better by ARM

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

    • > There aren't ones that wouldn't be served better by ARM

      Sure there are. If you want to do weird and wacky stuff, try to do it with an ARM and see how fast you get shut down.

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

      No, it's "we don't have to beg and grovel, or pay ARM."

      2 replies →