4 ms·

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

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...
    - klelatti 5y ago
      > If backward compatibility is king, the only analysis needed would be "dual decoders is too complex". So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all. I'm making no claims at all that Arm made the right choices - just that they actually made a choice and it's very unlikely they would have left huge amounts of performance on the table. Rather that if you're going to make claims for RISC-V materially exceeding Arm performance you need to have some evidence beyond back of an envelope cache size analyses to back it up. And sorry a copy pasted SiFive press release from Ars with some odd claims on die area doesn't count as evidence. I don't have any skin in this competition and like RISC-V a lot. I just don't like these spurious claims like the 20% in the thread above.
      - hajile 5y ago
        > So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all. This isn’t true. They had a MODAL decoder. It either grabbed 4 bytes or 2 bytes, but never both intermixed. This modal switch was actually the big reason why performance suffered so much with thumb. Such a switch means in effect that you just treat thumb as additional 32-bit addressing modes where the first 16 bits are don’t cares (and optimize to turn that half off in thumb mode). Intermixed instruction lengths require looking at 16-bit chunks and deciding if they stand alone or if they belong together. It also causes a less dramatic multiple decoder issue where you can accidentally cut instructions apart in the middle and send half to two different decoders. “Nobody ever got fired for choosing IBM.” CST looked to have huge performance gains, but when AMD actually bet everything on it, they nearly went bankrupt before they could turn things around. ARM either had a solid delivery of their new ISA in 2011, or MIPS 64 was going to kill them. You may not remember, but at that time Google had first-class support for MIPS in Android and Apple was rumored to be in talks to buy MIPS outright. Betting their tenuous dominant market share on risky propositions would be a fool’s errand —- doubly so for a soft IP company. It would also give a talking point to Intel that ARM was moving in their direction as proof x86 was a real competitor. Instruction size advantages aren’t “back of the envelope”. There are papers on the topic if you care to look. Those papers compare real world instruction counts in non-trivial, real world software. The cache comparison is very real in those applications. The effects of increasing cache size are well studied and well known. You’re arguing that we don’t really know if gravity works the same on planets in other solar systems. Sure, marketing copy isn’t everything. Intel’s not stupid and I’d say their engineers are easily some of the best. They could have gone with ARM any time they liked (they used to design ARM chips). They could have chosen one of several other designs or decided to wait for another generation. I may not trust their marketing copy completely, but I doubt Intel is just looking at marketing copy. I doubt Intel is throwing doubt about the future of x86 into the mix over a huge nothing.

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...
  - klelatti 5y ago
    > If backward compatibility is king, the only analysis needed would be "dual decoders is too complex". So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all. I'm making no claims at all that Arm made the right choices - just that they actually made a choice and it's very unlikely they would have left huge amounts of performance on the table. Rather that if you're going to make claims for RISC-V materially exceeding Arm performance you need to have some evidence beyond back of an envelope cache size analyses to back it up. And sorry a copy pasted SiFive press release from Ars with some odd claims on die area doesn't count as evidence. I don't have any skin in this competition and like RISC-V a lot. I just don't like these spurious claims like the 20% in the thread above.
    - hajile 5y ago
      > So AArch32 has a variable width decoder but it was too complex to build one into AArch64. That makes no sense at all. This isn’t true. They had a MODAL decoder. It either grabbed 4 bytes or 2 bytes, but never both intermixed. This modal switch was actually the big reason why performance suffered so much with thumb. Such a switch means in effect that you just treat thumb as additional 32-bit addressing modes where the first 16 bits are don’t cares (and optimize to turn that half off in thumb mode). Intermixed instruction lengths require looking at 16-bit chunks and deciding if they stand alone or if they belong together. It also causes a less dramatic multiple decoder issue where you can accidentally cut instructions apart in the middle and send half to two different decoders. “Nobody ever got fired for choosing IBM.” CST looked to have huge performance gains, but when AMD actually bet everything on it, they nearly went bankrupt before they could turn things around. ARM either had a solid delivery of their new ISA in 2011, or MIPS 64 was going to kill them. You may not remember, but at that time Google had first-class support for MIPS in Android and Apple was rumored to be in talks to buy MIPS outright. Betting their tenuous dominant market share on risky propositions would be a fool’s errand —- doubly so for a soft IP company. It would also give a talking point to Intel that ARM was moving in their direction as proof x86 was a real competitor. Instruction size advantages aren’t “back of the envelope”. There are papers on the topic if you care to look. Those papers compare real world instruction counts in non-trivial, real world software. The cache comparison is very real in those applications. The effects of increasing cache size are well studied and well known. You’re arguing that we don’t really know if gravity works the same on planets in other solar systems. Sure, marketing copy isn’t everything. Intel’s not stupid and I’d say their engineers are easily some of the best. They could have gone with ARM any time they liked (they used to design ARM chips). They could have chosen one of several other designs or decided to wait for another generation. I may not trust their marketing copy completely, but I doubt Intel is just looking at marketing copy. I doubt Intel is throwing doubt about the future of x86 into the mix over a huge nothing.