4 ms·

The argument for RISC instructions (in high performance architectures) is that the faster decode makes up for the increase in instruction count. The problem is

The argument for RISC instructions (in high performance architectures) is that the faster decode makes up for the increase in instruction count. The problem is that a faster decode has a practical ceiling on how much faster it's going to make your processor, and it's much lower than 3x. If your workload is bottlenecked on an inner loop that got 3x larger in instruction count, no 15% improvement in decode performance is going to save you.

jolmg 5y ago
I don't know what the design goals of RISC-V were, but I would guess performance is not the key goal or at least not the only goal. It makes more sense that ease of implementation is a more important goal, if they want to make adoption easy. That's another argument for favoring RISC over CISC.
monocasa 5y ago
If that's the case, you can always stick a uop cache in after the decoder.
snvzz 5y ago
Amount of instructions matters much less if they can be fused into more complex instructions before execution. RISC-V was designed with hindsight on fusion, thus it has more opportunities for doing it, and doing it at a lower cost. And, due to the very high code density RISC-V has, the decoder can do its job while not having to look at a huge window.
- saagarjha 5y ago
  Ok, but where it the chip that can fuse these?
theresistor 5y ago
To everyone who's saying "But macro-fusion!" in response, see my comment here: https://news.ycombinator.com/item?id=29421107 https://news.ycombinator.com/item?id=29421107
userbinator 5y ago
Larger caches won't help much either; there's an old article I remember that compares the efficiency of various ARM, x86, and one MIPS CPU, and while x86 and ARM were neck-and-neck, the MIPS was dead last in all the comparisons despite having more cache than the others. RISC-V is very similar to MIPS.
- snvzz 5y ago
  Larger caches, as seen in Apple's M1 L1, are one of many tools to deal with bad code density. RISC-V might, at first glance, look similar to MIPS, but it leads in code density among the 64 bit architectures.
  - User23 5y ago
    > [RISC-V] leads in code density among the 64 bit architectures. You keep baldly asserting this in virtually all of your very many replies here, with a vague appeal to your own authority, but you haven't shown anything. Given that the submission is precisely an example of bad code density, if you're really here in the service of intellectual curiosity then please show instead of just telling.
    - brucehoult 5y ago
      No argument from authority is needed. Anyone is free to download the disk images for a large body of software such as the same versions of Ubuntu or Fedora, and compare the binary sizes -- using the "text" output from "size" command, not raw disk files as there are also things such as debugging info in there. Here's an example, using (ironically) the GMP library itself. https://news.ycombinator.com/item?id=29423324 https://news.ycombinator.com/item?id=29423324 Here we see riscv64 significantly smaller than the other 64 bit ISAs aarch64 (28.1%) and x86_64 (36.5%), and beaten by a smaller margin by 32 bit ARM Thumb2 (-17.0%) Anyone can check the sizes of bash, perl, emacs ... whatever they want ... themselves, without relying on the word of anyone here.
      - astrange 5y ago

jolmg 5y ago

I don't know what the design goals of RISC-V were, but I would guess performance is not the key goal or at least not the only goal. It makes more sense that ease of implementation is a more important goal, if they want to make adoption easy. That's another argument for favoring RISC over CISC.

monocasa 5y ago

If that's the case, you can always stick a uop cache in after the decoder.

snvzz 5y ago

Amount of instructions matters much less if they can be fused into more complex instructions before execution. RISC-V was designed with hindsight on fusion, thus it has more opportunities for doing it, and doing it at a lower cost. And, due to the very high code density RISC-V has, the decoder can do its job while not having to look at a huge window.

saagarjha 5y ago
Ok, but where it the chip that can fuse these?

theresistor 5y ago

To everyone who's saying "But macro-fusion!" in response, see my comment here: https://news.ycombinator.com/item?id=29421107 https://news.ycombinator.com/item?id=29421107

userbinator 5y ago

Larger caches won't help much either; there's an old article I remember that compares the efficiency of various ARM, x86, and one MIPS CPU, and while x86 and ARM were neck-and-neck, the MIPS was dead last in all the comparisons despite having more cache than the others. RISC-V is very similar to MIPS.

snvzz 5y ago
Larger caches, as seen in Apple's M1 L1, are one of many tools to deal with bad code density. RISC-V might, at first glance, look similar to MIPS, but it leads in code density among the 64 bit architectures.
- User23 5y ago
  > [RISC-V] leads in code density among the 64 bit architectures. You keep baldly asserting this in virtually all of your very many replies here, with a vague appeal to your own authority, but you haven't shown anything. Given that the submission is precisely an example of bad code density, if you're really here in the service of intellectual curiosity then please show instead of just telling.
  - brucehoult 5y ago
    No argument from authority is needed. Anyone is free to download the disk images for a large body of software such as the same versions of Ubuntu or Fedora, and compare the binary sizes -- using the "text" output from "size" command, not raw disk files as there are also things such as debugging info in there. Here's an example, using (ironically) the GMP library itself. https://news.ycombinator.com/item?id=29423324 https://news.ycombinator.com/item?id=29423324 Here we see riscv64 significantly smaller than the other 64 bit ISAs aarch64 (28.1%) and x86_64 (36.5%), and beaten by a smaller margin by 32 bit ARM Thumb2 (-17.0%) Anyone can check the sizes of bash, perl, emacs ... whatever they want ... themselves, without relying on the word of anyone here.
    - astrange 5y ago