15 ms·

Not knowledgeable in the area, but from what I gather RISC-V is not as performant as ARM or Intel/AMD. Yes it can run at faster clock speeds due to its simplici

• Someone 5y ago
  I don’t think lack of good multicore designs would be a showstopper for Apple. They have a team that could change that, and can afford to spend a few billions on doing it.
• zozbot234 5y ago
  > but the flip side is that it requires more instructions (and more memory and more cache) to do the same job. The opposite is true. RISC-V has a compressed-instructions extension that makes its code density competitive with x86, ARM64 has nothing like that. Add the earlier-mentioned improvements due to it being a clean, from-scratch redesign and a 20% improvement in performance per watt given similar process node and microarchitecture is very much in the ballpark.
  • lucian1900 5y ago
    The compressed instructions are not fixed length, so decoding in parallel is severely restricted. No high performance RISC-V machine would use that extension.
    • trasz 5y ago
      They are not fixed length (usual instructions are 4 bytes, compressed are 2), but iirc you can easily tell the length using a single bit in the opcode, so it shouldn’t be that bad. It’s much closer to fixed-length than real variable-length, like with x86.
      • lucian1900 5y ago
        Regardless, any amount of variability restricts parallelism. You can’t split the instruction stream ahead of time into equal portions to hand to many separate decoding units.
        • zozbot234 5y ago
          Finding out the insn length is a trivial part of decode, unlike in other architectures. If x86 can profitably use "separate decoding units", RV+C will be able to do it to a far greater extent.
          • lucian1900 5y ago
            It still makes it impossible to trivially parallelise the decoding itself, before even looking at the instructions. x86 CPUs can barely decode in parallel, partly because the outputs of parallel decoders have to be synced up. A RISC-V core to rival the M1 wouldn’t use instruction compression.
            • brucehoult 5y ago
              Yes it would. Wait two to three years and you will see.
        • trasz 5y ago
          Sure you can, you just need, in worst case, twice the decoders.
    • hajile 5y ago
      The situation is VERY different from x86. With x86, the decoding is SERIAL. You must manually inspect every single byte to see how many are chained together for a particular instruction (from 1 to 15). With RISC-V compressed, there are only two instruction lengths and the beginning of the instruction tags how long it is. To my knowledge, all the most high-performance RISC-V cores use compressed instructions.
      • brucehoult 5y ago
        While decoding a given x86 instruction is serial, since about 2000 metadata has been added to the L1 instruction cache indicating which bytes start an instruction. So you can start decoding multiple instructions in parallel. Doing the same might be useful on a very wide RISC-V decoder. Not needed for 3 or 4 wide though. This is not very expensive, needing only 1 bit per 16 bits of instruction cache data (6.25% overhead), as RISC-V instructions can only start on 2 byte boundaries. This is quite small compared to the 25% to 30% code size you typically save from using both 2 and 4 byte instructions (30% to 50% more instructions in a cache of fixed size). x86 also uses cache of the micro-ops generated from each instruction, to avoid decoding recently-used instructions at all. That's completely unnecessary with simple instruction encodings such as RISC-V.
        • hajile 5y ago
          I assume you’re talking about HAT (head on tails). The only way to mark in cache is to analyze the incoming streams which still uses significant power and can itself be bottlenecked. As I recall, there’s also occasional waste space on x85 because there’s so many length options. With RISC-V, chunks parse faster because you can skip (eg) 512 bytes and I believe only the last two bytes need to be inspected to ensure it’s sliced and potentially padded correctly. At that point, I don’t know that any other scheme is needed. All the fast ARMv8 implementations use uop cache and fast RISC-V implementations will do the same as they gain an even bigger advantage.
  • klelatti 5y ago
    > 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.
• ch_123 5y ago
  > Besides, there don't seem to be good multicore architectures for RISC-V, that's probably the biggest show stopper in this age of multicore computing. That's just a matter of investment into the architecture rather than an intrinsic characteristic of the instruction set. There were no good x86 or ARM architectures until various companies decided to make them happen.