7 ms·

> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […] Well, and that is the

by inkyoto 2mo ago

> […] and hold on to 2 bytes from the previous cache line if there was 1/2 a 32-bit instruction at the end of the previous cache line […] Well, and that is the worst case scenario from the performance standpoint since, if a 32-bit instruction is spans a page boundary, it will result in a page fault stalling the instruction decoder. It might be acceptable in implementations not sensitive to such an overhead (e.g. embedded solutions) but is wholly unacceptable in high performance scenarios.

brucehoult 2mo ago
x86 seems to get by. And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead? As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in that next cache line / page. The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page. If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page. Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA. I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't). What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension. There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum. NEVER overnight between one standard and the next one. Which wouldn't have helped Qualcomm with their Nuvia core anyway. Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so. So problem solved.
- inkyoto 2mo ago
  x86 is an ancient design mired in legacy and problems, so Intel/AMD Intel and AMD had to make it work for a modern world even if that involved kludges, band-aids, and crutches. Whilst you do have a point there, personally I do not find x86 particularly interesting to discuss. I did not have Qualcomm and their latest bout of theatrical shenanigans concerning C in mind, either. Back onto C. – C demonstrably improves code density; – Improved code density is conducive of better instruction cache utilisation and reducing the pressure on the TLB; – Mixed-width decoding (a trade-off) demonstrably adds front-end work (especially in pathological cases[0]); – No publicly benchmarked RISC-V processor is sufficiently contemporary and wide (or very wide) to impart the net effect of that trade-off at the highest performance tier; – Performance targets (aarch64 and x86-64) are moving faster than publicly demonstrated performance of existing RISC-V implementations in silicon, and the gap is not closing in. So purported performance benefits of C may or may not materialise – it remains to be seen and proved, and claims that a future wide RISC-V core will validate design choices such as C remain not yet falsified projections rather than demonstrated engineering results – at this stage. [0] The second page is not resident, the decoder can't proceed because the second half-word can't be obtained, the access generates a page fault, the CPU eventually vectors to the page-fault handler. Genuine page faults are extremely expensive.
  - sylware 2mo ago
    Huh? There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?
    - inkyoto 2mo ago
      There are not.
      - sylware 2mo ago
        I thought so. But I want that :)
  - brucehoult 2mo ago

by inkyoto 2mo ago

brucehoult 2mo ago

x86 seems to get by. And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead? As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in that next cache line / page. The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page. If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page. Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA. I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't). What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension. There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum. NEVER overnight between one standard and the next one. Which wouldn't have helped Qualcomm with their Nuvia core anyway. Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so. So problem solved.

inkyoto 2mo ago
x86 is an ancient design mired in legacy and problems, so Intel/AMD Intel and AMD had to make it work for a modern world even if that involved kludges, band-aids, and crutches. Whilst you do have a point there, personally I do not find x86 particularly interesting to discuss. I did not have Qualcomm and their latest bout of theatrical shenanigans concerning C in mind, either. Back onto C. – C demonstrably improves code density; – Improved code density is conducive of better instruction cache utilisation and reducing the pressure on the TLB; – Mixed-width decoding (a trade-off) demonstrably adds front-end work (especially in pathological cases[0]); – No publicly benchmarked RISC-V processor is sufficiently contemporary and wide (or very wide) to impart the net effect of that trade-off at the highest performance tier; – Performance targets (aarch64 and x86-64) are moving faster than publicly demonstrated performance of existing RISC-V implementations in silicon, and the gap is not closing in. So purported performance benefits of C may or may not materialise – it remains to be seen and proved, and claims that a future wide RISC-V core will validate design choices such as C remain not yet falsified projections rather than demonstrated engineering results – at this stage. [0] The second page is not resident, the decoder can't proceed because the second half-word can't be obtained, the access generates a page fault, the CPU eventually vectors to the page-fault handler. Genuine page faults are extremely expensive.
- sylware 2mo ago
  Huh? There are RISC-V "performant" implementations on the best TSMC silicon process like x86-64 and aarch64?
  - inkyoto 2mo ago
    There are not.
    - sylware 2mo ago
      I thought so. But I want that :)
- brucehoult 2mo ago