> What is the measurable benefit to implementing 128b SVE2 Probably not much, SVE2 has some nicer instructions, but neon already is quite solid. > And impleme

> What is the measurable benefit to implementing 128b SVE2 Probably not much, SVE2 has some nicer instructions, but neon already is quite solid. > And implementing 256b SVE has different issues depending on how you do it For in-order, and not very aggressively out-of-order cores having a larger vector length can be very useful to still get a lot of throughput out of your design. It also helps hide memory latency. Here is a paper: https://ar5iv.labs.arxiv.org/html/2309.06865 https://ar5iv.labs.arxiv.org/html/2309.06865 and presentation: http://riscv.epcc.ed.ac.uk/assets/files/sc23/Short-reasons-for-long-vectors-in-HPC-CPUs.pdf http://riscv.epcc.ed.ac.uk/assets/files/sc23/Short-reasons-f... For aggressively out-of-order cores it should, for the most part, just be about decode, and some what memory latency hiding. > 2x256b is only beneficial over 4x128b if you're limited by decode width [...] 3x256b would probably imply 3x128b which would regress existing NEON code. I agree, that's why I don't get why people are "excited" for Zen5 to have 512b execution units, instead of 256b ones. At best there won't be a performance improvement for avx/avx2 code, at worst a regression.