vector length

Suppose you have a stamp that prints eight envelopes per press, but today's job is exactly twenty-three envelopes. Twenty-three does not divide evenly by eight: two presses cover sixteen, a third covers eight more — but you must not stamp the last one of that third press, or you would ruin a blank envelope on the desk. Vector length is the dial that tells the machine 'only the first N lanes are real this time; ignore the rest.' It is how a fixed-width vector unit handles arrays whose size is not a tidy multiple of the lane count.

On a real vector processor there is a special vector-length register. A loop over an array of, say, 1000 elements with 64-element vector registers runs in chunks: set length to 64 and process elements 0 to 63, again for 64 to 127, and so on; the final chunk has only 1000 minus 960 = 40 elements left, so you set the length to 40 and the hardware operates on just those lanes, leaving the other 24 untouched. This 'strip-mining' turns any-length array into a sequence of full-width passes plus one short tail, with no out-of-bounds damage and no wasted writes.

Vector length is also the cleaner idea behind modern length-agnostic vector ISAs. In RISC-V's vector extension or ARM's SVE, the program does not hard-code the width; it asks the hardware 'how many elements can you do at once?' and loops by that amount. The same binary then runs correctly on a small chip with 128-bit vectors and a big one with 512-bit vectors, each just looping a different number of times — you write the code once and it scales. The honest caveat: a short tail chunk wastes some lanes, so very short arrays get little benefit, and the loop setup overhead can dominate when the data is tiny.