4 ms·

Just to be clear, SVE is similar to AVX512 but the “Scalable” part is that the length is not hard-coded to any set number of bits or elements. It is more like t

Just to be clear, SVE is similar to AVX512 but the “Scalable” part is that the length is not hard-coded to any set number of bits or elements. It is more like the vector computers of old, such as the Cray-1. This means there is no need for continually updating the instruction set with longer and longer versions of the same instructions. Hopefully this leads to a more stable base and wider adoption, we’ll see how that works in practice though!

mort96 4y ago
I'm not really convinced we need to continually update the instruction set with non-scalable vector instructions either tbh, it seems like we've stalled on 256 bit wide instructions to the point where AMD is emulating 512 bit instructions using 256 bit wide execution units and the performance benefits of 512 bit wide instructions even on Intel is marginal at best. That's not to say scalable instructions are a bad idea. It certainly makes it easier to make small CPUs which support all the software written for vector instructions without having to emulate 256 or 512 bit wide execution units.
renox 4y ago
I seem to remember reading that the 'scalable' part of SVM was lost as soon as you did loop unrolling.. I hope I'm wrong though!
synergy20 4y ago
yes,SVE is vector which is scalable and AVX is SIMD which has a few fixed width.
diamondlovesyou 4y ago
I don't think scalable vectors is particularly useful feature, especially compared to what compilers have to go though to support it. It's much more useful to be able to do "more powerful" things with existing vector widths at hardware speeds (or perhaps just make the existing stuff faster than it is) than to be able to go wider. Scalable vectors also doesn't solve the ISA problem: don't break existing processors.
- evancox100 4y ago
  Of course they are free to add new "more powerful" instructions to SVE at any time, just like Intel could for AVX, etc. Also, I think it is supposed to be easier for compilers to autovectorize SVE than, say, neon. Whether that's the case in practice I don't know. Is there something specific you see that makes it more difficult than with SIMD-style, fixed operation width instructions? Or you are referring to something else with "compiler support"?

mort96 4y ago

I'm not really convinced we need to continually update the instruction set with non-scalable vector instructions either tbh, it seems like we've stalled on 256 bit wide instructions to the point where AMD is emulating 512 bit instructions using 256 bit wide execution units and the performance benefits of 512 bit wide instructions even on Intel is marginal at best. That's not to say scalable instructions are a bad idea. It certainly makes it easier to make small CPUs which support all the software written for vector instructions without having to emulate 256 or 512 bit wide execution units.

renox 4y ago

I seem to remember reading that the 'scalable' part of SVM was lost as soon as you did loop unrolling.. I hope I'm wrong though!

synergy20 4y ago

yes,SVE is vector which is scalable and AVX is SIMD which has a few fixed width.

diamondlovesyou 4y ago

I don't think scalable vectors is particularly useful feature, especially compared to what compilers have to go though to support it. It's much more useful to be able to do "more powerful" things with existing vector widths at hardware speeds (or perhaps just make the existing stuff faster than it is) than to be able to go wider. Scalable vectors also doesn't solve the ISA problem: don't break existing processors.

evancox100 4y ago
Of course they are free to add new "more powerful" instructions to SVE at any time, just like Intel could for AVX, etc. Also, I think it is supposed to be easier for compilers to autovectorize SVE than, say, neon. Whether that's the case in practice I don't know. Is there something specific you see that makes it more difficult than with SIMD-style, fixed operation width instructions? Or you are referring to something else with "compiler support"?