7 ms·

Two words: instruction density. It doesn’t matter if they’re fused or not if the reduced instruction density increases memory usage and puts more pressure on I

Two words: instruction density. It doesn’t matter if they’re fused or not if the reduced instruction density increases memory usage and puts more pressure on I$. Also, I don’t buy the whole fusion argument on the grounds that having to fuse super complex (5 instruction or more) sequences adds enough complexity that you’ve got opportunity cost. Much better for everyone if the CPU doesn’t have to do that fusion. That’s the whole point of good ISA design - to prevent the need for fusing in cases you’re doing something super common.

jhallenworld 6y ago
You need the icache to be post-fusion..
- bertr4nd 6y ago
  It’s not just the I$ though, it’s the MLC, LLC, and I-TLB. And instruction density at those levels actually matters quite a lot for big binaries (my experience in this regard is with HHVM at FB, but it’s certainly not unique).
  - jhallenworld 6y ago
    Yeah, pretty much agreeing with you. I think if they are going to rely on fusion in the ISA, they should limit it to the most minimal fusion implementation to have the widest possible chance of adoption. So assume the hardware can only fuse two instructions and design the ISA with this restriction in mind.
- brandmeyer 6y ago
  Intel and AMD's experience with complex transformations on the instruction stream suggests that its overall better to do it in a L0 decode cache.
rwmj 6y ago
That's what the RISC-V compressed instruction encoding is all about. There is a paper which I can't find right now about how the compressed encoding achieves something similar to x86 code size on typical application code. As I said above, the jury is still out until we get very high performance RISC-V implementations which are equivalent to existing high end x86 and aarch64 designs. Edit: Here's the thesis about the design decisions in the C encoding: https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.pdf https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.p... See also the diagram on page 62 of this document: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...
- pizlonator 6y ago
  First of all: I agree with you that the jury is out. We are all speculating. I might be wrong. The thing I see is this: you can also add compressed encodings for any ISA. And that has its own costs (it’s harder to decode and it’s harder on software that wants to do bidirectional analysis of machine code). So “my isa has shortcomings but it’s cool because compression” isn’t a perfect argument since if your isa lacks those shortcomings then you still benefit from compression and you don’t need it as much, which is better.
  - anp 6y ago
    Do any other ISAs have compressed encodings in wide use? It seems a bit like a chicken and egg problem - why build all the silicon to handle decoding it if your base ISA is dense enough?
    - darknoon 6y ago
      Sounds pretty similar to thumb mode on ARM, no?
      - mark_mcs 6y ago
        And ARM licensed the Hitachi SuperH patents when implementing Thumb. It's not exactly a new concept.
        deleted 6y ago
        [deleted]
    - loeg 6y ago
      ARM had Thumb, right? Is that a deadend at this point?
      - deaddodo 6y ago
        Thumb was removed from ARMv8 (AArch64). If you use 32-but legacy, it may exist on some chips; but it’s no longer the benefit it once was.
Veedrac 6y ago
> having to fuse super complex (5 instruction or more) sequences Can you give an example of someone advocating for 5 instruction fusion? Normally it's limited to three.
- pizlonator 6y ago
  I’d have to reinvestigate more than I feel like doing right now so I’ll tell you where to look. You need fast sequences for all of these variants: - add or sub or mul - signed or unsigned - 32 bit or 64 bit Some of those need 5 instructions. I don’t remember which adventure you need to pick to get 5.
  - Veedrac 6y ago
    Thanks for the reply but I'm not sure what you mean. Are you saying you want to add an i32 to a u64? Or am I completely misunderstanding? I'm not sure why unsigned-unsigned or signed-signed instructions would be hard. Idk about mixed sign operations, but when do they ever occur without first casting one to the other?
    - pizlonator 6y ago
      I mean you will do overflow checks on the following. I’ll use the “s” and “u” prefixes to mean signed and unsigned. Unsigned matters less than signed. sadd32, sadd64, uadd32, uadd64, ssub32, ssub64, usub32, usub64, smul32, smul64, umul32, umul64
      - Veedrac 6y ago
        Ah, I get you now. Yes, this looks like a weak point, and I totally get why it'd screw with Javascript optimizations. I don't think it's a fusion problem; even if you did fuse these sequences, they'd still be bad, since they'd be writing lots of extra registers.
        pizlonator 6y ago
dmix 6y ago
> particularly ones like x86 where what the processor actually runs looks nothing like the machine code. (Quoted from OPs comment) This isn’t a subject I’m an expert at but wouldn’t this mean there’s already some sort of translation going on already on the other systems? So it’s mostly just added end user work not a giant performance loss on RISC? It would just then simply be a layer of abstraction that is lost.
- arcticbull 6y ago
  Some huge portion of the x86 power budget is just the instruction decoder. The instruction set is so nutty that trying to implement them all directly in hardware is a non-starter. The x86 front end breaks down big instructions into smaller RISC-like micro-ops and then fuses/re-orders/optimizes/etc and runs those instead. There’s pros and cons, the con being sheer complexity and power budget, the pros are that it’s an abstraction so the microarchitecture can change completely without recompiling your code —- and you get CPU specific optimizations too. The CPU is basically emulating x86. You could in theory build an x86 CPU with a RISC-V core behind that decoder.
  - brandmeyer 6y ago
    > Some huge portion of the x86 power budget is just the instruction decoder. This is a widely held meme, but the internet at large doesn't have any evidence to back it up. A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Intel and AMD chose not to pursue those markets. The expensive parts of a high-end CPU aren't normally in the instruction decode part. They are in the branch prediction, branch mispredict recovery, forwarding networks, memory re-ordering, and so on. Anything short of a dataflow ISA has little impact on those structures.
    - MrBuddyCasino 6y ago
      > A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Weren't there Windows Phone devices with x86 SoC, but they weren't competitive?

jhallenworld 6y ago

You need the icache to be post-fusion..

bertr4nd 6y ago
It’s not just the I$ though, it’s the MLC, LLC, and I-TLB. And instruction density at those levels actually matters quite a lot for big binaries (my experience in this regard is with HHVM at FB, but it’s certainly not unique).
- jhallenworld 6y ago
  Yeah, pretty much agreeing with you. I think if they are going to rely on fusion in the ISA, they should limit it to the most minimal fusion implementation to have the widest possible chance of adoption. So assume the hardware can only fuse two instructions and design the ISA with this restriction in mind.
brandmeyer 6y ago
Intel and AMD's experience with complex transformations on the instruction stream suggests that its overall better to do it in a L0 decode cache.

rwmj 6y ago

That's what the RISC-V compressed instruction encoding is all about. There is a paper which I can't find right now about how the compressed encoding achieves something similar to x86 code size on typical application code. As I said above, the jury is still out until we get very high performance RISC-V implementations which are equivalent to existing high end x86 and aarch64 designs. Edit: Here's the thesis about the design decisions in the C encoding: https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.pdf https://people.eecs.berkeley.edu/~krste/papers/waterman-ms.p... See also the diagram on page 62 of this document: https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.pdf https://people.eecs.berkeley.edu/~krste/papers/EECS-2016-1.p...

pizlonator 6y ago
First of all: I agree with you that the jury is out. We are all speculating. I might be wrong. The thing I see is this: you can also add compressed encodings for any ISA. And that has its own costs (it’s harder to decode and it’s harder on software that wants to do bidirectional analysis of machine code). So “my isa has shortcomings but it’s cool because compression” isn’t a perfect argument since if your isa lacks those shortcomings then you still benefit from compression and you don’t need it as much, which is better.
- anp 6y ago
  Do any other ISAs have compressed encodings in wide use? It seems a bit like a chicken and egg problem - why build all the silicon to handle decoding it if your base ISA is dense enough?
  - darknoon 6y ago
    Sounds pretty similar to thumb mode on ARM, no?
    - mark_mcs 6y ago
      And ARM licensed the Hitachi SuperH patents when implementing Thumb. It's not exactly a new concept.
      - deleted 6y ago
        [deleted]
  - loeg 6y ago
    ARM had Thumb, right? Is that a deadend at this point?
    - deaddodo 6y ago
      Thumb was removed from ARMv8 (AArch64). If you use 32-but legacy, it may exist on some chips; but it’s no longer the benefit it once was.

Veedrac 6y ago

> having to fuse super complex (5 instruction or more) sequences Can you give an example of someone advocating for 5 instruction fusion? Normally it's limited to three.

pizlonator 6y ago
I’d have to reinvestigate more than I feel like doing right now so I’ll tell you where to look. You need fast sequences for all of these variants: - add or sub or mul - signed or unsigned - 32 bit or 64 bit Some of those need 5 instructions. I don’t remember which adventure you need to pick to get 5.
- Veedrac 6y ago
  Thanks for the reply but I'm not sure what you mean. Are you saying you want to add an i32 to a u64? Or am I completely misunderstanding? I'm not sure why unsigned-unsigned or signed-signed instructions would be hard. Idk about mixed sign operations, but when do they ever occur without first casting one to the other?
  - pizlonator 6y ago
    I mean you will do overflow checks on the following. I’ll use the “s” and “u” prefixes to mean signed and unsigned. Unsigned matters less than signed. sadd32, sadd64, uadd32, uadd64, ssub32, ssub64, usub32, usub64, smul32, smul64, umul32, umul64
    - Veedrac 6y ago
      Ah, I get you now. Yes, this looks like a weak point, and I totally get why it'd screw with Javascript optimizations. I don't think it's a fusion problem; even if you did fuse these sequences, they'd still be bad, since they'd be writing lots of extra registers.
      - pizlonator 6y ago

dmix 6y ago

> particularly ones like x86 where what the processor actually runs looks nothing like the machine code. (Quoted from OPs comment) This isn’t a subject I’m an expert at but wouldn’t this mean there’s already some sort of translation going on already on the other systems? So it’s mostly just added end user work not a giant performance loss on RISC? It would just then simply be a layer of abstraction that is lost.

arcticbull 6y ago
Some huge portion of the x86 power budget is just the instruction decoder. The instruction set is so nutty that trying to implement them all directly in hardware is a non-starter. The x86 front end breaks down big instructions into smaller RISC-like micro-ops and then fuses/re-orders/optimizes/etc and runs those instead. There’s pros and cons, the con being sheer complexity and power budget, the pros are that it’s an abstraction so the microarchitecture can change completely without recompiling your code —- and you get CPU specific optimizations too. The CPU is basically emulating x86. You could in theory build an x86 CPU with a RISC-V core behind that decoder.
- brandmeyer 6y ago
  > Some huge portion of the x86 power budget is just the instruction decoder. This is a widely held meme, but the internet at large doesn't have any evidence to back it up. A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Intel and AMD chose not to pursue those markets. The expensive parts of a high-end CPU aren't normally in the instruction decode part. They are in the branch prediction, branch mispredict recovery, forwarding networks, memory re-ordering, and so on. Anything short of a dataflow ISA has little impact on those structures.
  - MrBuddyCasino 6y ago
    > A couple of publicly visible engineers that do have experience are on record as saying that cell-phone-class competitive x86 was absolutely possible. Weren't there Windows Phone devices with x86 SoC, but they weren't competitive?