3 ms·

I've never really been a fan of this take. It seems to rest a lot on the ideas that: 1) Fusion is hard. While it can be hard (fusing x86 will be), I do not see

I've never really been a fan of this take. It seems to rest a lot on the ideas that: 1) Fusion is hard. While it can be hard (fusing x86 will be), I do not see why it would be meaningfully difficult for RISC-V hardware (except on devices so small it's better to have the simpler base ISA anyway), or compilers, who can in the worst case just treat fused pairs as their own instructions. 2) There's anything wrong with just most software assuming a fairly fixed set of extensions, as seems to have happened. If microcontrollers want to use a subset without multipliers, that doesn't mean anyone else has to care. If bitmanip is stabilized before RISC-V breaks into more common consumer use, why not assume it when writing code? It's only a problem if people make it one. Most of the rest don't matter much in a global sense. The arguments about which operations go in which extensions might have meaningful merit, but it seems not very important to me.

Jasper_ 6y ago
Fusion is hard. At least, unconstrained fusion is hard. If you have a couple instructions pairs to fuse together, that's fine, but fusing any possible compiler output together is going to make decode even more complicated in practice. This is why Intel publishes software optimization guides that go over what their fusions are, but it doesn't seem like the RISV-C spec is going to do that yet for many cases. And compiler authors need to know which instruction stream to generate to ensure fused execution.
- Veedrac 6y ago
  Mostly the concern around the lack of instructions in RISC-V revolves around a few well-known cases (eg. indexed loads) where the instructions to fuse are pretty canonical. There is always room for creativity, but that would be the same with or without indexed loads in the base instruction set. Any non-monopolistic hardware ecosystem has this problem; we've been able to ignore it largely on x86 since Intel had had a performance monopoly for so long, but once you have multiple competing core implementations compilers will have to worry about the edge-case performance differences. What I'm talking about is more specific to groups of instructions that are safe to treat as fused by default. Note that even if the compiler outputs a pair of instructions but the hardware running the code doesn't fuse it, out-of-order execution means the penalty will generally be extremely small versus the best unfused instruction schedule. RISC-V does give guidelines on which instructions are good fusion candidates. See for example section 2.13 in the bitmanip extension document. Hardware, naturally, just has a fixed set of fusions it does.
pizlonator 6y ago
fusion is not just hard, it’s opportunity cost. Let’s say you have budget to implement the top 10 most important fusions. On other ISAs you’d use that budget on things that aren’t about condition codes or array access.
- Veedrac 6y ago
  Opportunity cost in what sense? If the ISA is simple and regular, then the silicon costs should be miniscule, and the engineering costs not meaningfully larger than if those instructions were separate unfused instructions that had separate encodings instead.
  - pizlonator 6y ago
    For a 5-instruction massacre that uses tmp registers along the way, I guarantee you it won’t be easy.
    - Veedrac 6y ago
      If I thought 5 instruction fusions were necessary, I would not be a fan of fusion either.
      - pizlonator 6y ago
        The checklist for what needs to be fast is every combo of: - add or sub or mul - 32 bit or 64 bit - signed or unsigned. I don’t remember which adventure you need to pick to get 5. Source: I had to make most of these fast to make JSC competitive. Edit: I said all, should have said most. Unsigned is less important for JS.

Jasper_ 6y ago

Fusion is hard. At least, unconstrained fusion is hard. If you have a couple instructions pairs to fuse together, that's fine, but fusing any possible compiler output together is going to make decode even more complicated in practice. This is why Intel publishes software optimization guides that go over what their fusions are, but it doesn't seem like the RISV-C spec is going to do that yet for many cases. And compiler authors need to know which instruction stream to generate to ensure fused execution.

Veedrac 6y ago
Mostly the concern around the lack of instructions in RISC-V revolves around a few well-known cases (eg. indexed loads) where the instructions to fuse are pretty canonical. There is always room for creativity, but that would be the same with or without indexed loads in the base instruction set. Any non-monopolistic hardware ecosystem has this problem; we've been able to ignore it largely on x86 since Intel had had a performance monopoly for so long, but once you have multiple competing core implementations compilers will have to worry about the edge-case performance differences. What I'm talking about is more specific to groups of instructions that are safe to treat as fused by default. Note that even if the compiler outputs a pair of instructions but the hardware running the code doesn't fuse it, out-of-order execution means the penalty will generally be extremely small versus the best unfused instruction schedule. RISC-V does give guidelines on which instructions are good fusion candidates. See for example section 2.13 in the bitmanip extension document. Hardware, naturally, just has a fixed set of fusions it does.

pizlonator 6y ago

fusion is not just hard, it’s opportunity cost. Let’s say you have budget to implement the top 10 most important fusions. On other ISAs you’d use that budget on things that aren’t about condition codes or array access.

Veedrac 6y ago
Opportunity cost in what sense? If the ISA is simple and regular, then the silicon costs should be miniscule, and the engineering costs not meaningfully larger than if those instructions were separate unfused instructions that had separate encodings instead.
- pizlonator 6y ago
  For a 5-instruction massacre that uses tmp registers along the way, I guarantee you it won’t be easy.
  - Veedrac 6y ago
    If I thought 5 instruction fusions were necessary, I would not be a fan of fusion either.
    - pizlonator 6y ago
      The checklist for what needs to be fast is every combo of: - add or sub or mul - 32 bit or 64 bit - signed or unsigned. I don’t remember which adventure you need to pick to get 5. Source: I had to make most of these fast to make JSC competitive. Edit: I said all, should have said most. Unsigned is less important for JS.