4 ms·

> The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Earlier A

> The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Earlier Arm versions had compressed instructions (Thumb) but ARM64 dispensed with it for (likely) performance reasons. > earlier-mentioned improvements due to it being a clean, from-scratch redesign RISC-V appeared in 2010 and ARM64 which was a complete redesign was announced in 2011 > 20% improvement in performance per watt Citation? Reality is that there isn't a RISC-V core you can buy today with the performance of the leading Arm designed cores. Apple could probably architect one but no evidence that RISC-V would give better performance for application cores.

zozbot234 5y ago
> Reality is that there isn't a RISC-V core you can buy today with the performance of the leading Arm designed cores There's plenty of ARM cores in other performance classes. It's easy to compare like for like and see what the gain is (in area and power) for similarly-fabbed and similarly-architected chips.
- klelatti 5y ago
  If its easy then please provide the comparison to support your 20%! Otherwise it's just speculation.
hajile 5y ago
> Earlier Arm versions had compressed instructions (Thumb) but ARM64 dispensed with it for (likely) performance reasons. That's apples and oranges. To use thumb, you have to switch modes on the chip. You can't mix and match them and I think you can't even have both types in flight at the same time (I might be wrong there). Each RISC-V compressed instruction is tagged as a short instruction, so no mode switching is needed (though the total number of possible compressed instructions is reduced as a result of the tag). Compressed instructions have a full-sized counterpart that they (theoretically) expand into, so once you get past the decoder, there is only one instruction type. This is also interesting in how it affects fused instructions. A lot of people say that instructions X and Y could be fused into instruction Z instead, but if X and Y have 16-bit versions, then you basically get the same length as the 32-bit instruction Z. Cache pressure is interesting too. x86 is something like 15% more dense than ARMv8. This matters because cache size matters for power, complexity, and cycles. Even without fused instructions and other "necessary optimizations", comparisons show RISC-V code to be around 15% more dense than x86. This means that RISC-V effectively holds around 30-35% more instructions in the same sized I-Cache. This means that 24kb I-Cache in RISC-V would have about the same hit rate as 32kb of I-Cache in ARMv8 (assuming equally accurate predictors and prefetchers). Alternatively, someone could implement that same 128kb and enjoy a higher hit rate and gain throughput by avoiding reaching out to L2 cache (which is 5-10x slower). We may not know the absolute performance limit of RISC-V yet, but these kinds of details seem to indicate that the limits may well be higher than ARMv8/9.
- klelatti 5y ago
  My point was that Arm was completely familiar with the concept and took a conscious decision not to include it in Arm64. I am absolutely certain that they would have tested various approaches before coming to this decision. I agree 100% that there are interesting pros and cons from a performance perspective but you have no actual evidence that it gives performance gains anywhere near the numbers being quoted. I love RISC-V for many reasons but prefer to have debates grounded in evidence on things like performance.
  - hajile 5y ago
    > My point was that Arm was completely familiar with the concept and took a conscious decision not to include it in Arm64. I am absolutely certain that they would have tested various approaches before coming to this decision. I don't think there is any evidence to back up this assertion. A major goal was the ability to run both 32-bit and 64-bit code on the same machine. A requirement for this is a more unified decoder. A decoder that uses variable instruction length is a very different design. Even if it were more performant, it would likely have not been considered due to other design considerations.
    - klelatti 5y ago
      Sure Arm didn’t test alternative approaches before launching a brand new 64 bit architecture. Sounds entirely reasonable. (Actually I have a video somewhere of Richard Grisenthwaite discussing this precise decision). And Aarch32 compatibility made it impossible to design a variable width decoder for Arm64. Of course. You’re making performance claims on the basis of a back of an envelope analysis with no actual evidence to back it up. As I said RISC-V is great but claims like this need to be backed up with actual evidence.
      - hajile 5y ago
        If backward compatibility is king, the only analysis needed would be "dual decoders is too complex". There seems to be a conceit here where ARM designers must have made all the right choices and anyone who disagrees is just wrong. Even if some analysis was done, that doesn't mean everything is always considered or that the tradeoffs made are the best ones. If you have a link, I'd love to watch. In any case, Intel is using the SiFive P550 for their upcoming Horse Creek platform. The P550 beats A75 in spec power for both float and int performance while using less than half of the die area (I'm more dubious on that last claim because I'm not completely sold on feature parity). Their stated performance actually puts P550 more in line with A76 for performance. At 8.65/GHz, that's close to i9-10900K at 11.08/GHz though far from A14 at 21.1/GHz (those numbers from Anandtech). That's plenty fast enough to show that the RISCV architecture choices performs well. If they are accurate about the die savings, that's undoubtedly a huge boost in performance per watt too. https://arstechnica.com/gadgets/2021/06/sifives-brand-new-p550-is-one-of-the-worlds-fastest-risc-v-cpus/ https://arstechnica.com/gadgets/2021/06/sifives-brand-new-p5... https://www.anandtech.com/show/16780/intel-to-create-riscv-development-platform-with-sifive-p550-cores-on-7nm-in-2022 https://www.anandtech.com/show/16780/intel-to-create-riscv-d...

zozbot234 5y ago

> Reality is that there isn't a RISC-V core you can buy today with the performance of the leading Arm designed cores There's plenty of ARM cores in other performance classes. It's easy to compare like for like and see what the gain is (in area and power) for similarly-fabbed and similarly-architected chips.

klelatti 5y ago
If its easy then please provide the comparison to support your 20%! Otherwise it's just speculation.

hajile 5y ago

> Earlier Arm versions had compressed instructions (Thumb) but ARM64 dispensed with it for (likely) performance reasons. That's apples and oranges. To use thumb, you have to switch modes on the chip. You can't mix and match them and I think you can't even have both types in flight at the same time (I might be wrong there). Each RISC-V compressed instruction is tagged as a short instruction, so no mode switching is needed (though the total number of possible compressed instructions is reduced as a result of the tag). Compressed instructions have a full-sized counterpart that they (theoretically) expand into, so once you get past the decoder, there is only one instruction type. This is also interesting in how it affects fused instructions. A lot of people say that instructions X and Y could be fused into instruction Z instead, but if X and Y have 16-bit versions, then you basically get the same length as the 32-bit instruction Z. Cache pressure is interesting too. x86 is something like 15% more dense than ARMv8. This matters because cache size matters for power, complexity, and cycles. Even without fused instructions and other "necessary optimizations", comparisons show RISC-V code to be around 15% more dense than x86. This means that RISC-V effectively holds around 30-35% more instructions in the same sized I-Cache. This means that 24kb I-Cache in RISC-V would have about the same hit rate as 32kb of I-Cache in ARMv8 (assuming equally accurate predictors and prefetchers). Alternatively, someone could implement that same 128kb and enjoy a higher hit rate and gain throughput by avoiding reaching out to L2 cache (which is 5-10x slower). We may not know the absolute performance limit of RISC-V yet, but these kinds of details seem to indicate that the limits may well be higher than ARMv8/9.

klelatti 5y ago
My point was that Arm was completely familiar with the concept and took a conscious decision not to include it in Arm64. I am absolutely certain that they would have tested various approaches before coming to this decision. I agree 100% that there are interesting pros and cons from a performance perspective but you have no actual evidence that it gives performance gains anywhere near the numbers being quoted. I love RISC-V for many reasons but prefer to have debates grounded in evidence on things like performance.
- hajile 5y ago
  > My point was that Arm was completely familiar with the concept and took a conscious decision not to include it in Arm64. I am absolutely certain that they would have tested various approaches before coming to this decision. I don't think there is any evidence to back up this assertion. A major goal was the ability to run both 32-bit and 64-bit code on the same machine. A requirement for this is a more unified decoder. A decoder that uses variable instruction length is a very different design. Even if it were more performant, it would likely have not been considered due to other design considerations.
  - klelatti 5y ago
    Sure Arm didn’t test alternative approaches before launching a brand new 64 bit architecture. Sounds entirely reasonable. (Actually I have a video somewhere of Richard Grisenthwaite discussing this precise decision). And Aarch32 compatibility made it impossible to design a variable width decoder for Arm64. Of course. You’re making performance claims on the basis of a back of an envelope analysis with no actual evidence to back it up. As I said RISC-V is great but claims like this need to be backed up with actual evidence.
    - hajile 5y ago
      If backward compatibility is king, the only analysis needed would be "dual decoders is too complex". There seems to be a conceit here where ARM designers must have made all the right choices and anyone who disagrees is just wrong. Even if some analysis was done, that doesn't mean everything is always considered or that the tradeoffs made are the best ones. If you have a link, I'd love to watch. In any case, Intel is using the SiFive P550 for their upcoming Horse Creek platform. The P550 beats A75 in spec power for both float and int performance while using less than half of the die area (I'm more dubious on that last claim because I'm not completely sold on feature parity). Their stated performance actually puts P550 more in line with A76 for performance. At 8.65/GHz, that's close to i9-10900K at 11.08/GHz though far from A14 at 21.1/GHz (those numbers from Anandtech). That's plenty fast enough to show that the RISCV architecture choices performs well. If they are accurate about the die savings, that's undoubtedly a huge boost in performance per watt too. https://arstechnica.com/gadgets/2021/06/sifives-brand-new-p550-is-one-of-the-worlds-fastest-risc-v-cpus/ https://arstechnica.com/gadgets/2021/06/sifives-brand-new-p5... https://www.anandtech.com/show/16780/intel-to-create-riscv-development-platform-with-sifive-p550-cores-on-7nm-in-2022 https://www.anandtech.com/show/16780/intel-to-create-riscv-d...