4 ms·

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

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.
    - brucehoult 5y ago
      Uhhh .. while overall I agree more with you and less with klelatti, you appear to have missed Thumb2, introduced in 2003. Original Thumb was 16 bit opcodes only, and you could switch modes in a program between Thumb mode and ARM mode but not mix 16 and 32 bit instructions together. With Thumb2, 32 bit opcodes (completely different to original ARM opcodes) were added to the original Thumb 16 bit opcodes, and you can freely intermix them, just as you can with RISC-V with the C extension. With ARMv7 Thumb2 is the standard execution mode used on iPhones and Android and so forth. While ARM's Cortex-A application processors continue to implement original ARM mode, the Cortex-M series is Thumb2 only (except the M0(+), which is Thumb1 plus just a couple of 32 bit instructions). I'm personally surprised that ARM dropped 16 bit opcodes in their 64 bit ISA -- I was right from when I first read the manual in 2012. It hurts code density a lot. They pretty much managed to match x86_64 and maybe they thought that was the only competition they would have and it was good enough. It's true that fixed length instructions simplifies very wide decoders. But ARM has not after ten years built a core with a very wide decoder. Only Apple has. And having two lengths doesn't hurt much, especially when you can tell which length you have from examining just a couple of bits in the instruction (two bits in RISC-V, three bits in Thumb2). It's certainly much much easier than x86 where you have to decode a potentially unlimited number of prefix bytes, several opcode bytes, AND a possible modrm byte just to figure out how long the instruction is. Even x86 is a solved problem. For cold code you have to do it the hard way, but for frequently executed code in loops or common subroutines you can just add a few extra bits to each byte (or block) in the instruction cache storing the length of each instruction calculated the last time it was executed. As instructions are limited to 15 bytes, in the simplest (but most wasteful) implementation you need to add 4 bits to each byte indicating the length of the instruction that starts there. But adding a single bit to each byte indicating whether an instruction starts there would do the job too. Solved problem, basically. That extra bit makes the instruction cache 12.5% bigger, but this is more than made up for by the 25% to 30% code size reduction from having 16 bit instructions available. And with only two instruction lengths it's probably not even necessary.

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.
  - brucehoult 5y ago
    Uhhh .. while overall I agree more with you and less with klelatti, you appear to have missed Thumb2, introduced in 2003. Original Thumb was 16 bit opcodes only, and you could switch modes in a program between Thumb mode and ARM mode but not mix 16 and 32 bit instructions together. With Thumb2, 32 bit opcodes (completely different to original ARM opcodes) were added to the original Thumb 16 bit opcodes, and you can freely intermix them, just as you can with RISC-V with the C extension. With ARMv7 Thumb2 is the standard execution mode used on iPhones and Android and so forth. While ARM's Cortex-A application processors continue to implement original ARM mode, the Cortex-M series is Thumb2 only (except the M0(+), which is Thumb1 plus just a couple of 32 bit instructions). I'm personally surprised that ARM dropped 16 bit opcodes in their 64 bit ISA -- I was right from when I first read the manual in 2012. It hurts code density a lot. They pretty much managed to match x86_64 and maybe they thought that was the only competition they would have and it was good enough. It's true that fixed length instructions simplifies very wide decoders. But ARM has not after ten years built a core with a very wide decoder. Only Apple has. And having two lengths doesn't hurt much, especially when you can tell which length you have from examining just a couple of bits in the instruction (two bits in RISC-V, three bits in Thumb2). It's certainly much much easier than x86 where you have to decode a potentially unlimited number of prefix bytes, several opcode bytes, AND a possible modrm byte just to figure out how long the instruction is. Even x86 is a solved problem. For cold code you have to do it the hard way, but for frequently executed code in loops or common subroutines you can just add a few extra bits to each byte (or block) in the instruction cache storing the length of each instruction calculated the last time it was executed. As instructions are limited to 15 bytes, in the simplest (but most wasteful) implementation you need to add 4 bits to each byte indicating the length of the instruction that starts there. But adding a single bit to each byte indicating whether an instruction starts there would do the job too. Solved problem, basically. That extra bit makes the instruction cache 12.5% bigger, but this is more than made up for by the 25% to 30% code size reduction from having 16 bit instructions available. And with only two instruction lengths it's probably not even necessary.