4 ms·

All the optional extensions will make writing portable code practically impossible. What is an optimization on one chip will be a crushing pessimization on anot

All the optional extensions will make writing portable code practically impossible. What is an optimization on one chip will be a crushing pessimization on another, if it runs at all. I gather they have started to publish "profiles" that might rein in the worst of this. And the profile meant for desktop workstation use appears to have "popcount" and a few other concessions. But, unlike in the x86, ARM, or POWER worlds, where we have the notion of a generation on a timeline, nothing like that helps contain the complexity of development targets. Each extension is its own extra dimension to be used or compensated for lack of, separately. I have not seen any chip with a popcount instruction yet, but have not checked this year.

drpixie 4y ago
Agreed - unfortunately many extensions going in too many directions. It might be more practical to require extensions to conform to a hierarchy, so if you implement Z, you must also implemented X and Y. Given the low cost of transistors, it seems parsimonious to be defining lots of incompatible variations on the RISC-V theme. Look at the ARM market, with minor variations in the number of timers and IO pins, most chips follow one of only a few common directions - eg. we've got small bit-pushing chips as controllers, and larger chips with FP and MMU for "computers".
- yummypaint 4y ago
  I am hoping the diversity of extensions will help spur development of more general and adaptable ways of using different computing hardware. I think these are innevitable growing pains coming from an era where all the design decisions were made by just a few players. I would argue some of standardization in the arm market has alot to do with the business desire to fit products into pre-defined niches that don't compete with each other.
vardump 4y ago
Nothing prevents compilers from compiling in multiple paths for anything performance critical. That's how it's already being done on x86. If AVX-512 is available, use it. If not, maybe fall back to AVX-2. Else fall back to SSE2. Etc. GCC multiversioning: https://gcc.gnu.org/wiki/FunctionMultiVersioning https://gcc.gnu.org/wiki/FunctionMultiVersioning Clang multiversioning: https://clang.llvm.org/docs/AttributeReference.html#cpu-dispatch https://clang.llvm.org/docs/AttributeReference.html#cpu-disp...

drpixie 4y ago

Agreed - unfortunately many extensions going in too many directions. It might be more practical to require extensions to conform to a hierarchy, so if you implement Z, you must also implemented X and Y. Given the low cost of transistors, it seems parsimonious to be defining lots of incompatible variations on the RISC-V theme. Look at the ARM market, with minor variations in the number of timers and IO pins, most chips follow one of only a few common directions - eg. we've got small bit-pushing chips as controllers, and larger chips with FP and MMU for "computers".

yummypaint 4y ago
I am hoping the diversity of extensions will help spur development of more general and adaptable ways of using different computing hardware. I think these are innevitable growing pains coming from an era where all the design decisions were made by just a few players. I would argue some of standardization in the arm market has alot to do with the business desire to fit products into pre-defined niches that don't compete with each other.

vardump 4y ago

Nothing prevents compilers from compiling in multiple paths for anything performance critical. That's how it's already being done on x86. If AVX-512 is available, use it. If not, maybe fall back to AVX-2. Else fall back to SSE2. Etc. GCC multiversioning: https://gcc.gnu.org/wiki/FunctionMultiVersioning https://gcc.gnu.org/wiki/FunctionMultiVersioning Clang multiversioning: https://clang.llvm.org/docs/AttributeReference.html#cpu-dispatch https://clang.llvm.org/docs/AttributeReference.html#cpu-disp...