6 ms·

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case imple

by jpfr 5y ago

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

theresistor 5y ago
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?
- 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?
okl 5y ago
Sweet spot seems to be 16-bit instructions with 32/64-bit registers. With 64-bit registers you need some clever way to load your immediates, e.g., like the shift/offset in ARM instructions.
msbarnett 5y ago
He literally addressed this, albeit obliquely, in the message > I have heard that Risc V proponents say that these problems are known and could be fixed by having the hardware fuse dependent instructions. Perhaps that could lessen the instruction set shortcomings, but will it fix the 3x worse performance for cases like the one outlined here? Macro-fusion can to some extent offset the weak instruction set, but you're never going to get a multiple integer multiplier speedup out of it given the complexity of inter-op architectural state changes that have to be preserved, and instruction boundary limitations involved; it's never going to offset a 3x blowup in instruction count in a tight loop.
- socialdemocrat 5y ago
  Fusing 3 instructions is not unusual, those could also have been compressed. Thus you have no more microcode to execute and only 50% more cache usage rather than 300%
alerighi 5y ago
Even if you do so, the program size is still bigger, and it consumes more disk, RAM and most importantly cache space. Wasting cache for having multiple instructions when on another architecture it's done by only one doesn't make particular sense to me. Also, it's said that x86 is bad because the instructions are then reorganized and translated inside the CPU. But it seems that you are proposing the same, the CPU that preprocessed the instructions and fuses some into a single one (the opposite that x86 does). Ad that point, it seems to me that what x86 does makes more sense: have a ton of instruction (and thus smaller programs and thus more code that can fit in cache) and split them, rather than having a ton of instructions (and waste cache space) for then the CPU to combine them into a single one (a thing that a compiler can also do).
- Buttons840 5y ago
  How many cache misses are for program instructions, versus data misses?
  - anarazel 5y ago
    IME icache misses are a frequent bottleneck. There's plenty code where all the time is spent in one tight inner loop and thus the icache is not a constraint, but there's also a lot of cases with a much flatter profile. Where icache misses suddenly become a serious constraint.
    - imtringued 5y ago
      Obtaining the carry bit does not involve branches though. Overflow checking probably does.
  - alerighi 5y ago
    Depends on the application. But even if they are few, it's not a good reason to have them just for having a nice instruction set, that if you are not writing assembly by hand (and nobody does these days) doesn't give you any benefit. Also don't reason with the desktop or server use case in mind, where you have TB of disk and code size doesn't matter. RISC-V is meant to be used also for embedded systems (in fact their use nowadays is only for these systems), where usually code size matter more than performance (i.e. you typically compile with -Os). In these situations more instructions means more flash space wasted, meaning you can fit less code.

by jpfr 5y ago

theresistor 5y ago

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?
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?

okl 5y ago

Sweet spot seems to be 16-bit instructions with 32/64-bit registers. With 64-bit registers you need some clever way to load your immediates, e.g., like the shift/offset in ARM instructions.

msbarnett 5y ago

He literally addressed this, albeit obliquely, in the message > I have heard that Risc V proponents say that these problems are known and could be fixed by having the hardware fuse dependent instructions. Perhaps that could lessen the instruction set shortcomings, but will it fix the 3x worse performance for cases like the one outlined here? Macro-fusion can to some extent offset the weak instruction set, but you're never going to get a multiple integer multiplier speedup out of it given the complexity of inter-op architectural state changes that have to be preserved, and instruction boundary limitations involved; it's never going to offset a 3x blowup in instruction count in a tight loop.

socialdemocrat 5y ago
Fusing 3 instructions is not unusual, those could also have been compressed. Thus you have no more microcode to execute and only 50% more cache usage rather than 300%

alerighi 5y ago

Even if you do so, the program size is still bigger, and it consumes more disk, RAM and most importantly cache space. Wasting cache for having multiple instructions when on another architecture it's done by only one doesn't make particular sense to me. Also, it's said that x86 is bad because the instructions are then reorganized and translated inside the CPU. But it seems that you are proposing the same, the CPU that preprocessed the instructions and fuses some into a single one (the opposite that x86 does). Ad that point, it seems to me that what x86 does makes more sense: have a ton of instruction (and thus smaller programs and thus more code that can fit in cache) and split them, rather than having a ton of instructions (and waste cache space) for then the CPU to combine them into a single one (a thing that a compiler can also do).

Buttons840 5y ago
How many cache misses are for program instructions, versus data misses?
- anarazel 5y ago
  IME icache misses are a frequent bottleneck. There's plenty code where all the time is spent in one tight inner loop and thus the icache is not a constraint, but there's also a lot of cases with a much flatter profile. Where icache misses suddenly become a serious constraint.
  - imtringued 5y ago
    Obtaining the carry bit does not involve branches though. Overflow checking probably does.
- alerighi 5y ago
  Depends on the application. But even if they are few, it's not a good reason to have them just for having a nice instruction set, that if you are not writing assembly by hand (and nobody does these days) doesn't give you any benefit. Also don't reason with the desktop or server use case in mind, where you have TB of disk and code size doesn't matter. RISC-V is meant to be used also for embedded systems (in fact their use nowadays is only for these systems), where usually code size matter more than performance (i.e. you typically compile with -Os). In these situations more instructions means more flash space wasted, meaning you can fit less code.