What is the Java Vector API, and what problem does it solve compared to ordinary scalar arithmetic loops?

## The problem: scalar loops waste the CPU A normal arithmetic loop in Java processes **one element per iteration**: ```java for (int i = 0; i < a.length; i++) c[i] = a[i] + b[i]; ``` This is called **scalar** code — one operation on one pair of values at a time. But modern CPUs contain **SIMD** units. **SIMD** stands for *Single Instruction, Multiple Data*: a single machine instruction operates on a whole pack of values simultaneously. For example, Intel's **AVX2** registers are 256 bits wide, holding 8 `float`s (32 bits each); AVX-512 holds 16; ARM has **NEON** (128-bit) and **SVE** (scalable). One SIMD add can therefore do 8 or 16 additions at once, giving a large throughput win on big arrays. ## Why not just rely on the JIT? The HotSpot JIT compiler already has **auto-vectorization** (a pass called *superword* / SLP) that *sometimes* turns a scalar loop into SIMD instructions. The problem is it is **opportunistic and fragile**: a slightly awkward loop shape, a method call, a branch, or an unusual reduction can silently disable it, and you have no guarantee or feedback. Performance becomes unpredictable across JVM versions. ## What the Vector API provides The **Vector API** (`jdk.incubator.vector`, still an **incubator module** — see below) is an **explicit, hardware-agnostic** way to write SIMD code in pure Java. You describe computations as operations on `Vector` objects whose elements are called **lanes**, and the JIT reliably lowers each operation to the best vector instruction available on the *actual* CPU at runtime. Crucially it is **portable**: the same bytecode runs on AVX2, AVX-512, NEON, or SVE, and if a machine has no vector unit (or a narrower one), the runtime **gracefully falls back** to scalar execution — your code still produces correct results, just slower. ## Core shape of the code ```java static final VectorSpecies<Float> S = FloatVector.SPECIES_PREFERRED; for (int i = 0; i < a.length; i += S.length()) { var va = FloatVector.fromArray(S, a, i); var vb = FloatVector.fromArray(S, b, i); va.add(vb).intoArray(c, i); } ``` Here `S.length()` is how many lanes fit (e.g. 8). Each iteration loads a slice of 8 elements into a vector, adds lane-wise, and stores 8 results. A separate tail loop handles leftover elements that don't fill a full vector (or a *mask* covers them — see the masks question). ## Incubator status The API has shipped as an **incubator** (JEP 338 in Java 16, re-incubated many times since). *Incubator* means it is a non-final, preview-style module: you must add it explicitly (`--add-modules jdk.incubator.vector`), the package is `jdk.incubator.*`, and its surface **can change between releases**. It is intentionally tied to **Project Valhalla** (value types) for a final form, so it stayed incubating for years. ## When to use it Use it for **throughput-bound numeric kernels**: dense linear algebra, image/signal processing, machine-learning inference, hashing/crypto, and similar tight loops over large primitive arrays. It is **not** for general business logic — the per-call overhead and code complexity only pay off when the same simple operation runs across many elements.