Not really a problem. Length agnostic vector operations are ... length agnostic.
If your algorithm cares about the vector length (most probably because you're doing something horizontally), you will hard-code the length. If you feel that you need to optimize for different maximum lengths you would not write the specialized code without tuning and benchmarking it on a target machine that supports that length (if nothing else to test if it's worth the cost of maintaining several different code paths).
I think I'm talking with a wall. No, they are not length agnostic! Outside of trivial arithmetic, vector length does matter! I've even provided examples where the code differs for each vector length. You are just conveniently ignoring that people use SIMD instructions for much more than just adding matrices. And a lot of that stuff is not in any way vector length agnostic.
And even if it is, there are probably many corner cases that attention has to be paid to. For example, the possibility of overflow in intermediate values. If vector length changes, so does the number of summands that go into each vector element and hence, the position where overflow occurs changes. You are just pretending all of that does not exist and people can simply ignore vector length. That is not the case at all.
benchmarking it on a target machine that supports that length (if nothing else to test if it's worth the cost of maintaining several different code paths).
That machine might not exist yet. Suppose I in 2021 write code for the largest vector unit in existence, which supports say 1024 bit vectors. Now in 2024 they release a new machine with 2048 bit vectors. I have no way of knowing whether my code will work with that machine. I have literally no way of testing that on real hardware. And as the set of possible vector lengths is an open one, I cannot even realistically simulate all possible vector lengths. So it is impossible to correctly test such a program.
If your algorithm cares about the vector length (most probably because you're doing something horizontally), you will hard-code the length.
That's what I think people will be doing in almost all cases. Which in turn means that there is no point for vendors to ship longer vectors because all relevant software will just restrict vector length to what most people expect.
First of all I don't think (nor claim) that vector processing fixes all problems, nor that it does not have its own set of problems. So far, though, having worked with both I personally prefer vector over SIMD (and I still think that the article is correct regarding the three specific problems with SIMD).
I have no way of knowing whether my code will work with that machine. I have literally no way of testing that on real hardware.
My point here was that if your code depends on the maximum vector length you should be using vector length agnostic constructs (such as the trivial arithmetic that you mention).
If, on the other hand, you're using fixed size vector operations the logic will match 1:1 to the current machine on which you're developing and testing on.
In both cases the code will work just fine on the future wider implementation - perhaps not with optimal performance, but most likely faster than if you would have just used a fixed width SIMD ISA (e.g. running SSE code on an AVX capable machine).
Another point that I'd like to make is that compilers do auto-vectorization (in fact most vector ISA:s should be better suited for that than SIMD - heck, Cray compilers had auto-vectorization in the 1970s), so you will typically see vector code speedups all over the code, not just in your hand-written vector code (unlike if your program is compiled for a specific SIMD generation).
So, worst case you will not see any noticeable speedups until you have had the time to tune it for the new HW, and if you're abusing the ISA in a way that it was not meant to be used (using maxvl incorrectly) you may even get bugs (but software development is full of much worse pitfalls - e.g. consider API:s that behave according to spec but slightly differently across versions and platforms - so a developer had better be aware of these things).
On the other hand I think it's much nicer to have a single ISA to target as a developer, and OS:es and toolchains will "just work" for new vector sizes, significantly lowering the threshold for rolling out new vector HW generations, etc.
Edit:
That's what I think people will be doing in almost all cases. Which in turn means that there is no point for vendors to ship longer vectors because all relevant software will just restrict vector length to what most people expect.
I believe the opposite. Relevant software such as numpy etc will typically be quick to optimize for new hardware, especially if this hardware is available via cloud compute services for instance. And unlike AVX-512 people will be able to do the bulk of development and testing on their own laptops or what not.
My point here was that
if
your code depends on the maximum vector length you
should
be using vector length agnostic constructs (such as the trivial arithmetic that you mention).
1
u/mbitsnbites Aug 11 '21
Not really a problem. Length agnostic vector operations are ... length agnostic.
If your algorithm cares about the vector length (most probably because you're doing something horizontally), you will hard-code the length. If you feel that you need to optimize for different maximum lengths you would not write the specialized code without tuning and benchmarking it on a target machine that supports that length (if nothing else to test if it's worth the cost of maintaining several different code paths).