25 ms·

This isn't an isolated case. RISC-V makes the same basic tradeoff (simplicity above all else) across the board. You can see this in the (lack of) addressing mod

This isn't an isolated case. RISC-V makes the same basic tradeoff (simplicity above all else) across the board. You can see this in the (lack of) addressing modes, compare-and-branch, etc. Where this really bites you is in workloads dominated by tight loops (image processing, cryptography, HPC, etc). While a microarchitecture may be more efficient thanks to simpler instructions (ignoring the added complexity of compressed instructions and macro-fusion, the usual suggested fixes...), it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop.

rstuart4133 5y ago
> it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop. As someone else who replied said, I'm not a CPU architect, just software that works close to the metal. That means I pay attention to compiler output. What you say is true in the very early says: compilers did indeed use the x86's addressing modes in all sorts of odd ways to squeeze as many calculations as possible into as few bytes as possible. Then it went in the reverse direction. You started seeing compilers emitting long series of simple instructions instead, seemingly deliberately avoiding those complex addressing modes. And now it's swung back again - I'm the complier using addressing modes to shift plus a couple of adds in one instruction is common again. I presume all these shifts were driven by speed of the resulting code. I have no idea why one method was faster than the other - but clearly there is no hard and fast rule operating here. For some internal x86's implementations using complex addressing modes was a win. On some, for exactly the same instruction set, it wasn't. There is no cut and dried "best" way of doing it, rather it varies as the transistor and power budget changes. One thing we do know about RISC-V is it is intended to cover a _lot_ transistor and power budgets. Where it's used now (low power / low transistor) is turned out their design decisions have turned out _very_ well, far better than x86. More fascinatingly to me, today the biggest speed ups compilers get for super scalar arch's has nothing to do with the addressing modes so much attention is being focused on here. It comes from avoiding conditional jumps. The compilers will often emit code that evaluates both paths of the computation (thus burning 50% more ALU time on a calculating a result that will never be used), then choose the result they want with a cmov. In extreme cases, I've seen doing that sort of thing gain them a factor of 10, which is far more than playing tiddly winks with addressing modes will get you. I have no idea how that will pan out for RISC-V. I don't think any one has done a super scalar implementation of it yet(?) But in the non-super scalar implementations the RISC-V instruction set choices have worked out very well so far. And when someone does do a super scalar implementation (and I'm sure there will be a lot of different implementations over time), it seems very possible x86's learnings on addressing mode use will be yesterdays news.
nickez 5y ago
For those use cases you typically have specialised hardware or an FPGA.
- deleted 5y ago
  [deleted]
- vadfa 5y ago
  So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?
  - lvh 5y ago
    An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).
    - plorkyeran 5y ago
      Hardware video decoding is done by a single-purpose chip on the graphics card (or dedicated hardware inside the GPU), not via software running on the GPU. Adding support for a new video codec requires buying a new video card which supports that codec.
      - The_rationalist 5y ago
        While this is true (GPUs have embedded video ASICs), are there software GPU decoders for video codecs that outperform CPU decoders (and do not use the hardcoded GPU ASICs)? This would allow newer codecs to become mainstream more quickly vs the inertia of needing to buy a new GPU.
    - imtringued 5y ago
      SystemC bloat will require you to upgrade to a bigger FPGA!
lottospm 5y ago
I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know. Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer macro-instructions are not automatically a win. I guess we'll eventually see in benchmarks. Even though Intel has had decades to refine their CPUs I'm quite excited to see where RISC-V is going.
- theresistor 5y ago
  As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it for performance, when most ISAs prefer to fix the problem upstream.
  - jasonhansel 5y ago
    Indeed. Also not an expert, but relying on macro-op fusion in hardware is tricky IIRC since different implementors will (likely) choose different macro-ops, resulting in strange performance differences between otherwise-identical chips. Of course, you could start documenting "official" macro-ops that implementations should support, but at that point you're pretty much inventing a new ISA...
    - seoaeu 5y ago
      RISC-V does document "official" macro-ops that implementations are encouraged to support.
  - evilos 5y ago
    > "X86 has an internal RISC" is an over-simplification that obscures reality Is it misleading though? I don't mind simplifications unless they are misleading. Would like to hear your criticisms of this meme.

rstuart4133 5y ago

> it's not going to be 2-3x faster, so it's never going to compensate for a 2-3x larger inner loop. As someone else who replied said, I'm not a CPU architect, just software that works close to the metal. That means I pay attention to compiler output. What you say is true in the very early says: compilers did indeed use the x86's addressing modes in all sorts of odd ways to squeeze as many calculations as possible into as few bytes as possible. Then it went in the reverse direction. You started seeing compilers emitting long series of simple instructions instead, seemingly deliberately avoiding those complex addressing modes. And now it's swung back again - I'm the complier using addressing modes to shift plus a couple of adds in one instruction is common again. I presume all these shifts were driven by speed of the resulting code. I have no idea why one method was faster than the other - but clearly there is no hard and fast rule operating here. For some internal x86's implementations using complex addressing modes was a win. On some, for exactly the same instruction set, it wasn't. There is no cut and dried "best" way of doing it, rather it varies as the transistor and power budget changes. One thing we do know about RISC-V is it is intended to cover a _lot_ transistor and power budgets. Where it's used now (low power / low transistor) is turned out their design decisions have turned out _very_ well, far better than x86. More fascinatingly to me, today the biggest speed ups compilers get for super scalar arch's has nothing to do with the addressing modes so much attention is being focused on here. It comes from avoiding conditional jumps. The compilers will often emit code that evaluates both paths of the computation (thus burning 50% more ALU time on a calculating a result that will never be used), then choose the result they want with a cmov. In extreme cases, I've seen doing that sort of thing gain them a factor of 10, which is far more than playing tiddly winks with addressing modes will get you. I have no idea how that will pan out for RISC-V. I don't think any one has done a super scalar implementation of it yet(?) But in the non-super scalar implementations the RISC-V instruction set choices have worked out very well so far. And when someone does do a super scalar implementation (and I'm sure there will be a lot of different implementations over time), it seems very possible x86's learnings on addressing mode use will be yesterdays news.

nickez 5y ago

For those use cases you typically have specialised hardware or an FPGA.

deleted 5y ago
[deleted]
vadfa 5y ago
So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?
- lvh 5y ago
  An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).
  - plorkyeran 5y ago
    Hardware video decoding is done by a single-purpose chip on the graphics card (or dedicated hardware inside the GPU), not via software running on the GPU. Adding support for a new video codec requires buying a new video card which supports that codec.
    - The_rationalist 5y ago
      While this is true (GPUs have embedded video ASICs), are there software GPU decoders for video codecs that outperform CPU decoders (and do not use the hardcoded GPU ASICs)? This would allow newer codecs to become mainstream more quickly vs the inertia of needing to buy a new GPU.
  - imtringued 5y ago
    SystemC bloat will require you to upgrade to a bigger FPGA!

lottospm 5y ago

I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know. Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer macro-instructions are not automatically a win. I guess we'll eventually see in benchmarks. Even though Intel has had decades to refine their CPUs I'm quite excited to see where RISC-V is going.

theresistor 5y ago
As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it for performance, when most ISAs prefer to fix the problem upstream.
- jasonhansel 5y ago
  Indeed. Also not an expert, but relying on macro-op fusion in hardware is tricky IIRC since different implementors will (likely) choose different macro-ops, resulting in strange performance differences between otherwise-identical chips. Of course, you could start documenting "official" macro-ops that implementations should support, but at that point you're pretty much inventing a new ISA...
  - seoaeu 5y ago
    RISC-V does document "official" macro-ops that implementations are encouraged to support.
- evilos 5y ago
  > "X86 has an internal RISC" is an over-simplification that obscures reality Is it misleading though? I don't mind simplifications unless they are misleading. Would like to hear your criticisms of this meme.