hckrnws

This article has a whole lot of "it's not X, it's Y"…

In reality this isn't much of a change. For decades it's been a given that mainstream CPUs have vector instructions. RISC-V was the odd man out in _not_ mandating vector instructions. Even so, most CPU code doesn't use them.

And this is unlikely to change anytime soon. Yes, ML workloads are becoming much more popular, but CPUs are still not parallel enough to do a good job at them. Only occasionally is it a good idea to try anyway.

Edit: Note that there is something novel about the approach that RISC-V and ARM are now following, namely being vector-length agnostic, but this is unlikely to have much impact on how much CPU code is vectorized in the first place. It improves scalability a little, but also gives compilers a little harder of a job. It is not something that's going to fundamentally transform the extent to which CPU code uses vector instructions.

It looks like the author may work for Andes. If their out-of-order implementation is weak I could see why they would push vectors as an alternative.

This article is a complete waste of time. It reads like a children's story or a marketing announcement but it's not actually saying anything meaningful or making any technical point beyond just stating "If we use vectors then maybe we don't need speculation" but without providing much evidence except that highly parallel workloads already have enough work to do. Go figure. It mentions in the article we already have GPUs for this. CPUs are famously burdened with workloads that usually aren't GPU workloads. But now there's a declaration of a RVV requirement or something. (I say this as a SIMD programmer who likes a lot about RVV)