3 ms·

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 yo

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.

pixelesque 2mo ago
> really crazy optimizations that they are doing Any examples of this?
- PunchyHamster 2mo ago
  There aren't ones that wouldn't be served better by ARM The improvement is entirely "we don't have to pay ARM"
  - zephen 2mo ago
    > 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."
    - sylware 2mo ago
      I guess this would be orders of magnitude more horrible with x86_64?
      - zephen 2mo ago
        Hard to know at this point. In the past ARM sued people for daring to think about implementing ARM compatible computers. (Even university research projects.) Of course, in the more distant past, AMD and Intel sued each other a lot. But there have been a dozen or so x86 market entrants. I think the competition has just been brutal. So, with either one, you could, of course, do a clean-sheet design and hope you don't get sued. Since ARM has historically only sold IP, they are incredibly jealous of their monopoly for that ISA. Of course, the flip side of it is that if you have enough money, and you beg and grovel enough, you can probably do what you want with their code. Except, of course, when you can't. Or rather, maybe you can, but they will try really hard to stop you. For example, Qualcomm, an architecture licensee who had purchased the rights to basically make whatever the fuck ARM they wanted, purchased a startup named Nuvia that also had an architecture license, and started using Nuvia's designs. ARM sued, just because. They were shut down in court, but the message is clear. They are very aggressive. Seriously, who needs that shit? Semiconductor market windows are tight enough as it is, and ARM has always acted like "Nice chip you've got there, buddy; shame if you haven't dotted your i's anc crossed your t's on the licensing." At least with Intel or AMD, you're probably only looking at patent lawsuits, and you could probably do a decent job on a low end machine with techniques that were known 20 years ago. You could do the same with ARM, of course, but they will sue you just because, to see if they can make you run out of money.
        sylware 2mo ago
        Allright, you did describe a monstruous IP mine-field. No way anybody could reasonably use anything else than RISC-V.
        zephen 2mo ago
        Bleeding edge processor development is always going to be a patent minefield, even for RISC-V. Most patents are broad enough to cover more than one architecture. But there are now several RISC-V IP vendors, and ARM can't possibly shut them all down, and companies can develop IP in-house, so there are lots of different designs already out there. So, at this point, developing a RISC-V processor provides a certain amount of safety in numbers, kind of like swimming in a school of fish, while developing an ARM compatible processor paints a target on your back. Developing a low-end x86 processor wouldn't attract any legal attention either, but now that the RISC-V ecosystem is big enough, why bother? Decoding all those instructions might be a lot of extra work for no real market share gain. Developing a high-end x86 processor would probably attract careful scrutiny of exactly how you managed to get that performance and whether you violated any patents to do that. Again, that the same sort of patent scrutiny would happen with bleeding edge RISC-V, but certainly, a fast x86 processor would be higher on the priority list of the Intel and AMD legal departments.
        sylware 2mo ago
        Then RISC-V would need something like they did for open source software (in countries with barbaric IP), some sort of pool of defensive IP. Because, if you look at the current trajectory of RISC-V micro-architectures: they will be competitive, so current hardware big tech will try hard to shut them down. If they are already at Zen3 performance... I run Zen2 and it's already beyond than enough (I miss AVX512 extensions though, hope we'll get often RVA cache line vector instructions on RISC-V). Look at qualcomm already buying what seems to be a very good RISC-V microarchitecture, wonder what they will do to it (usually, they let it die slowly forcing their good engineers to work on something else). The right way(TM) would be for ARM to "drop its ISA" and become a microarchitecture designer able to decode and run RISC-V ISA. Intel and AMD should too. The world would be basically competing micro-archs all with high compatibility at machine code level. And it seems nobody has been addressing the elephant in the room: x86 is an horrible ISA for a modern CPU, much more worse than RISC-V/ARM. It is only because AMD/Intel throw tons of money with tons of brains to make that horrible ISA performant AND because they are hogging the production capacity of the best silicon process. There is zero wonders here.
- camel-cdr 2mo ago
  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.
  - philipportner 2mo ago
    How do you keep up with such information? Any sources you could recommend? Closest I know would be SemiAnalysis
    - rjzzleep 2mo ago
yjftsjthsd-h 2mo 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. 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?
- simcop2387 2mo ago
  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 https://youtu.be/vSKA6thLI1U?t=993
  - amaranth 2mo ago
    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.

pixelesque 2mo ago

> really crazy optimizations that they are doing Any examples of this?

PunchyHamster 2mo ago
There aren't ones that wouldn't be served better by ARM The improvement is entirely "we don't have to pay ARM"
- zephen 2mo ago
  > 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."
  - sylware 2mo ago
    I guess this would be orders of magnitude more horrible with x86_64?
    - zephen 2mo ago
      Hard to know at this point. In the past ARM sued people for daring to think about implementing ARM compatible computers. (Even university research projects.) Of course, in the more distant past, AMD and Intel sued each other a lot. But there have been a dozen or so x86 market entrants. I think the competition has just been brutal. So, with either one, you could, of course, do a clean-sheet design and hope you don't get sued. Since ARM has historically only sold IP, they are incredibly jealous of their monopoly for that ISA. Of course, the flip side of it is that if you have enough money, and you beg and grovel enough, you can probably do what you want with their code. Except, of course, when you can't. Or rather, maybe you can, but they will try really hard to stop you. For example, Qualcomm, an architecture licensee who had purchased the rights to basically make whatever the fuck ARM they wanted, purchased a startup named Nuvia that also had an architecture license, and started using Nuvia's designs. ARM sued, just because. They were shut down in court, but the message is clear. They are very aggressive. Seriously, who needs that shit? Semiconductor market windows are tight enough as it is, and ARM has always acted like "Nice chip you've got there, buddy; shame if you haven't dotted your i's anc crossed your t's on the licensing." At least with Intel or AMD, you're probably only looking at patent lawsuits, and you could probably do a decent job on a low end machine with techniques that were known 20 years ago. You could do the same with ARM, of course, but they will sue you just because, to see if they can make you run out of money.
      - sylware 2mo ago
        Allright, you did describe a monstruous IP mine-field. No way anybody could reasonably use anything else than RISC-V.
        zephen 2mo ago
        Bleeding edge processor development is always going to be a patent minefield, even for RISC-V. Most patents are broad enough to cover more than one architecture. But there are now several RISC-V IP vendors, and ARM can't possibly shut them all down, and companies can develop IP in-house, so there are lots of different designs already out there. So, at this point, developing a RISC-V processor provides a certain amount of safety in numbers, kind of like swimming in a school of fish, while developing an ARM compatible processor paints a target on your back. Developing a low-end x86 processor wouldn't attract any legal attention either, but now that the RISC-V ecosystem is big enough, why bother? Decoding all those instructions might be a lot of extra work for no real market share gain. Developing a high-end x86 processor would probably attract careful scrutiny of exactly how you managed to get that performance and whether you violated any patents to do that. Again, that the same sort of patent scrutiny would happen with bleeding edge RISC-V, but certainly, a fast x86 processor would be higher on the priority list of the Intel and AMD legal departments.
        sylware 2mo ago
        Then RISC-V would need something like they did for open source software (in countries with barbaric IP), some sort of pool of defensive IP. Because, if you look at the current trajectory of RISC-V micro-architectures: they will be competitive, so current hardware big tech will try hard to shut them down. If they are already at Zen3 performance... I run Zen2 and it's already beyond than enough (I miss AVX512 extensions though, hope we'll get often RVA cache line vector instructions on RISC-V). Look at qualcomm already buying what seems to be a very good RISC-V microarchitecture, wonder what they will do to it (usually, they let it die slowly forcing their good engineers to work on something else). The right way(TM) would be for ARM to "drop its ISA" and become a microarchitecture designer able to decode and run RISC-V ISA. Intel and AMD should too. The world would be basically competing micro-archs all with high compatibility at machine code level. And it seems nobody has been addressing the elephant in the room: x86 is an horrible ISA for a modern CPU, much more worse than RISC-V/ARM. It is only because AMD/Intel throw tons of money with tons of brains to make that horrible ISA performant AND because they are hogging the production capacity of the best silicon process. There is zero wonders here.
camel-cdr 2mo ago
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.
- philipportner 2mo ago
  How do you keep up with such information? Any sources you could recommend? Closest I know would be SemiAnalysis
  - rjzzleep 2mo ago

yjftsjthsd-h 2mo 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. 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?

simcop2387 2mo ago
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 https://youtu.be/vSKA6thLI1U?t=993
- amaranth 2mo ago
  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.