4 ms·

Compressed instructions and macro-fusion aren't magical solutions. It's not always possible to convince the compiler to generate the magical sequence required,

Compressed instructions and macro-fusion aren't magical solutions. It's not always possible to convince the compiler to generate the magical sequence required, and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding. Beyond that, compressed instructions are not a 1:1 substitute for more complex instructions, because a pair of compressed instructions cannot have any fields that cross the 16-bit boundary. This means you can't recover things like larger load/store offsets. Additionally, you can't discard architectural state changes due to the first instruction. If you want to fuse an address computation with a load, you still have to write the new address to the register destination of the address computation. If you want to perform clever fusion for carry propagation, you still have to perform all of the GPR writes. This is work that a more complex instruction simply wouldn't have to perform, and again it complicates a high performance implementation.

jpfr 5y ago
In the context of gmp, people write architecture-specific assembly for the inner loop anyway. Besides that, you raise good points on sources of complexity. I’m waiting for the benchmarks once such developments have been incorporated. Everything else is guesswork.
- throwaway81523 5y ago
  If they didn't implement those benchmarks (at least in simulation, like they benchmarked everything else) before releasing the spec, then they have nothing but handwaving and wishful thinking in saying this issue can be solved by op fusion. The reality is that they optimized for 1980s-style C programming without noticing that this isn't the 1980s any more.
panick21_ 5y ago
Part of the idea is to create standard ways to do certain things and then hope compiler writers generation code according to that. That will allow more chip designers to take advantage of those if they want to. They spent a lot of time and effort on making sure the decoding pretty good and useful for high performance implementations. RISC-V is designed for very small and very large system. At some point some tradeoffs need to be made but these are very reasonable and most of the time no a huge problem. For the really specialized cases where you simply can't live with those extra instruction, those will be added to the standard and then some profiles will include them and others not. If those instructions are really as vital as those that want them claim, they will find their way into many profiles. Saying RISC-V is 'terrible' because of those choices is not fair way of evaluating it.
- userbinator 5y ago
  RISC-V is designed for very small and very large system That's exactly the problem --- there is no one-size-fits-all when it comes to instruction set design.
  - panick21_ 5y ago
    There is a trade-off but there is overall far more value in having it be unified. The trade-offs are mostly very small or non existent once you consider the standard extensions that different use cases will have. Overall having a unified open instruction set is far better then hand designing many different instruction sets just to get marginal improvement. Some really extreme application might require that, but for the most part the whole indsutry could do just fine with RISC-V. Both on the low and on the high end, and in fact better then most of the alternative all things considered. If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others.
    - ddingus 5y ago
      >overall far more value in having it be unified. >[...] >If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others. So which is it? Unified or something else?
      - panick21_ 5y ago
        The goal is that there is a unified core that runs the majority code. The majority of ecosystem and tooling works of a common base. Lots of code can be used in a way to be very universal. Some verticals that will be special like deep embedded will likely be different enough that it will be slightly different, but it still profits from all the work going into the overall ecosystem. RISC-V allows 'the market' to decide between uniformity and specialty in a orthogonal way. My bet is that this will actually lead to a lot of uniformity in most verticals.
audunw 5y ago
> and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding. More difficult than x86? We're talking about a damn simple variable width decoding here. I could imagine RISC-V with C extension being more tricky than 64-bit ARM. Maybe. > and again it complicates a high performance implementation. But so much of the rationale behind the design of RISC-V is to simplify high performance implementation in other ways. So the big question is what the net effect is. The other big question is if extensions will be added to optimise for desktop/server workloads by the time RISC-V CPUs penetrate that market significantly.
imtringued 5y ago
Let's assume you are right. In 5 years the organization behind RISC-V apologizes and introduces a "bignum" extension. That doesn't sound too bad.
socialdemocrat 5y ago
I don’t see why offsets larger than 16-bit are important. Are you implying that most fusion candidate pairs would need this? In tight inner loops why would you need large offsets? Of course you discard architectural state changes in fusion. If I have a bunch of instructions which end up reading from memory into register x10, then I can fuse with all previous instructions which wrote into x10, as their results get clobbered anyway. Disclaimer: I may have misunderstood the point you made. However you don’t seem to make it clear how fusion is bad for performance. What performance tricks are you giving up by doing fusion?

jpfr 5y ago

In the context of gmp, people write architecture-specific assembly for the inner loop anyway. Besides that, you raise good points on sources of complexity. I’m waiting for the benchmarks once such developments have been incorporated. Everything else is guesswork.

throwaway81523 5y ago
If they didn't implement those benchmarks (at least in simulation, like they benchmarked everything else) before releasing the spec, then they have nothing but handwaving and wishful thinking in saying this issue can be solved by op fusion. The reality is that they optimized for 1980s-style C programming without noticing that this isn't the 1980s any more.

panick21_ 5y ago

Part of the idea is to create standard ways to do certain things and then hope compiler writers generation code according to that. That will allow more chip designers to take advantage of those if they want to. They spent a lot of time and effort on making sure the decoding pretty good and useful for high performance implementations. RISC-V is designed for very small and very large system. At some point some tradeoffs need to be made but these are very reasonable and most of the time no a huge problem. For the really specialized cases where you simply can't live with those extra instruction, those will be added to the standard and then some profiles will include them and others not. If those instructions are really as vital as those that want them claim, they will find their way into many profiles. Saying RISC-V is 'terrible' because of those choices is not fair way of evaluating it.

userbinator 5y ago
RISC-V is designed for very small and very large system That's exactly the problem --- there is no one-size-fits-all when it comes to instruction set design.
- panick21_ 5y ago
  There is a trade-off but there is overall far more value in having it be unified. The trade-offs are mostly very small or non existent once you consider the standard extensions that different use cases will have. Overall having a unified open instruction set is far better then hand designing many different instruction sets just to get marginal improvement. Some really extreme application might require that, but for the most part the whole indsutry could do just fine with RISC-V. Both on the low and on the high end, and in fact better then most of the alternative all things considered. If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others.
  - ddingus 5y ago
    >overall far more value in having it be unified. >[...] >If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others. So which is it? Unified or something else?
    - panick21_ 5y ago
      The goal is that there is a unified core that runs the majority code. The majority of ecosystem and tooling works of a common base. Lots of code can be used in a way to be very universal. Some verticals that will be special like deep embedded will likely be different enough that it will be slightly different, but it still profits from all the work going into the overall ecosystem. RISC-V allows 'the market' to decide between uniformity and specialty in a orthogonal way. My bet is that this will actually lead to a lot of uniformity in most verticals.

audunw 5y ago

> and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding. More difficult than x86? We're talking about a damn simple variable width decoding here. I could imagine RISC-V with C extension being more tricky than 64-bit ARM. Maybe. > and again it complicates a high performance implementation. But so much of the rationale behind the design of RISC-V is to simplify high performance implementation in other ways. So the big question is what the net effect is. The other big question is if extensions will be added to optimise for desktop/server workloads by the time RISC-V CPUs penetrate that market significantly.

imtringued 5y ago

Let's assume you are right. In 5 years the organization behind RISC-V apologizes and introduces a "bignum" extension. That doesn't sound too bad.

socialdemocrat 5y ago

I don’t see why offsets larger than 16-bit are important. Are you implying that most fusion candidate pairs would need this? In tight inner loops why would you need large offsets? Of course you discard architectural state changes in fusion. If I have a bunch of instructions which end up reading from memory into register x10, then I can fuse with all previous instructions which wrote into x10, as their results get clobbered anyway. Disclaimer: I may have misunderstood the point you made. However you don’t seem to make it clear how fusion is bad for performance. What performance tricks are you giving up by doing fusion?