Superscalar vs vector processors
Two very different approaches to extracting parallel work from an instruction stream: one discovers parallelism in hardware, the other lets software describe it.
A superscalar processor and a vector processor both aim to execute more than one operation at a time. They disagree about who is responsible for finding the parallel work.
The superscalar approach: discover it
A superscalar core fetches a stream of scalar instructions and decides, at runtime, which of them can execute simultaneously. Register renaming removes false dependencies, the scheduler issues instructions whose operands are ready, and a reorder buffer retires them in program order so the architectural state stays consistent.
The cost of this approach is structural. Discovering independent instructions requires wide fetch, large scheduling windows, many read and write ports, and accurate branch prediction, because a mispredict discards the speculative work in flight. Each additional issue slot tends to cost more area and power than the last.
The vector approach: describe it
A vector architecture takes the opposite position. One instruction describes the same operation applied across many elements, so the parallelism is stated in the encoding rather than inferred from it.
# conceptual: one instruction, VL elements
vadd.vv v3, v1, v2Because the elements of a vector operation are independent by definition, the hardware does not need to prove independence. It also gains information about memory: a unit-stride vector load announces a long, regular access pattern well before the data is needed, which is easier to prefetch and easier to schedule than the same accesses arriving as separate scalar loads.
Where each one struggles
Superscalar execution handles irregular, branch-heavy, pointer-chasing code that no vector encoding could describe. It degrades gradually rather than falling off a cliff.
Vector execution needs regularity. Loop-carried dependencies, unpredictable control flow inside the loop body, short trip counts and indirect memory access all reduce or eliminate the benefit. Predication and masking recover some control flow, and gather and scatter recover some indirection, but usually at a cost in throughput.
Why the distinction stopped being a choice
Contemporary CPUs are both. A modern out-of-order core executes SIMD or scalable vector instructions through its normal renaming and scheduling machinery, and the vector unit is one more class of execution port. That combination is precisely the arrangement the 1999 QCEV99 paper examined, when it was still a research question rather than a shipping design.
The practical consequence for a programmer: the superscalar part of the machine will do its work whether you help it or not, while the vector part mostly does not activate unless your data layout, dependencies and control flow allow it.
Related tool: QCEV Vector Inspector examines a loop for dependencies, memory access patterns and likely vector operations.
References
- Hennessy and Patterson, Computer Architecture: A Quantitative Approach, chapters on instruction-level and data-level parallelism.
- Quintana, Corbal, Espasa and Valero, “Adding a Vector Unit to a Superscalar Processor” (1999). [Citation to be completed with verified bibliographic details.]
- RISC-V “V” Vector Extension specification, RISC-V International.