Picture a weather model adding two arrays of a million numbers each. A plain scalar CPU treats this as a million tiny dramas: load one number, load another, add them, store the result — then check the loop counter, test whether to branch back, and do it all again, a million times. Most of those instructions are pure bookkeeping. Only a third of them do arithmetic at all.
A vector processor looks at that same loop and says: why describe the same operation a
million times? Say it once, over the whole array. A single vector instruction —
The archetype is the Cray-1 (1976), Seymour Cray's masterpiece. Where a scalar CPU has registers holding one number each, a vector machine adds vector registers, each holding a whole array — the Cray-1 had eight vector registers of 64 elements apiece. A vector instruction reads two of them, streams the elements through a deeply pipelined arithmetic unit, and writes a third.
Two special registers make it flexible. The vector length register (VLR) says how many
of the elements are actually live — so a loop over 150 numbers runs as 64 + 64 + 22, the last pass with
A vector unit gets its throughput two ways at once. First, each arithmetic unit is deeply pipelined: a floating-point multiply might take 7 stages, but once the pipeline is full it delivers one finished product every cycle. Second, the elements are spread across several parallel lanes — each lane is its own pipeline handling every fourth element, say — so a 4-lane unit retires four results per cycle. Because the elements of a vector are known to be independent, the hardware never has to check for data hazards between them, which is exactly what lets it fill those pipelines fearlessly.
Suppose you compute
Here is the headline benefit made concrete. Take
Roughly a
A vector unit that retires four adds per cycle needs eight input numbers and produces four outputs every
cycle. Feeding it is the whole game. Classic vector supercomputers therefore skipped caches in favour of
many banks of fast, heavily interleaved SRAM, and their designers obsessed over
bandwidth, not latency. A vector kernel is almost always
This is also why stride and gather/scatter matter so much. Unit-stride
access (stride 1) streams cleanly across memory banks. A large stride can slam the same bank repeatedly
and stall. And gather/scatter — using an index vector to fetch
Through the 1980s a Cray was the supercomputer. What killed the pure vector machine wasn't a
better idea — it was economics. Commodity microprocessors, riding the same manufacturing wave that made
PCs cheap, got fast enough that a rack of them beat a bespoke vector machine per dollar (the "attack of
the killer micros"). The vector idea, though, never died — it just moved. It reappeared as
It is tempting to think a 64-element vector register is only a fat integer you operate on all at once. But the defining feature is the vector length register: the same code runs correctly on arrays of 3, 64, or 150 elements without change, because the length is a runtime value, not baked into the instruction. That is precisely what packed-SIMD (MMX/SSE/AVX) got wrong for decades — those bake a fixed width into the opcode, so widening from 128 to 256 to 512 bits meant a whole new instruction set each time. The classic vector machine, and modern RISC-V V / ARM SVE, are "vector-length agnostic": write once, run at whatever width the hardware happens to have.
| Scalar loop | Vector instruction | |
|---|---|---|
| Instructions to add N numbers | ~8 per element | ~8 per strip of 64 |
| Loop overhead | paid every element | amortised over the whole vector |
| Hazard checks between elements | each iteration | none — elements are independent |
| Bottleneck | front-end / control | memory bandwidth |
| Best access pattern | any | unit-stride; gather/scatter is slow |