VectorX

VectorX rewrites a small, carefully chosen set of Minecraft's hottest array loops using the Java Vector API (jdk.incubator.vector), so a single CPU instruction processes 4, 8 or 16 values at once instead of one thanks to AVX2, AVX-512 or NEON, whichever your CPU and JDK actually provide.

Unlike most SIMD experiments, every vectorized kernel here ships with a scalar twin, and VectorX falls back to that twin the moment anything is off: no Vector API module, an unexpected CPU, a failed startup correctness check, a conflicting mod, or an exception at runtime. Vanilla behaviour is preserved.

VectorX is a world generation and chunk I/O optimization. It cuts CPU time on the server thread (and on singleplayer's integrated server). It is not targeting FPS.

⚠️ Read this first: the required JVM flag

The Vector API is still an incubating JDK module, so the JVM won't expose it unless you ask for it. Add this to your JVM arguments, launcher profile or your server start script:

--add-modules=jdk.incubator.vector

Without this flag VectorX still loads and works perfectly, it just runs everything on the scalar backend and gives you no speedup at all. Check your log at startup:

[vectorx] VectorX ready: 4/4 kernels on the vector backend

If it says 0/4, the flag is missing.

What it optimizes

Four independent kernels, each individually toggleable:

• densityFunctionMap: element-wise transforms in DensityFunctions$Mapped, used throughout noise and terrain generation. Only half_negative, quarter_negative and squeeze are vectorized, the other ops are already branch-free and measured no real gain, so they're deliberately left on vanilla.
• densityFunctionClamp: the clamp applied across a whole density array, using lane-wise min/max instead of a per-element branch.
• packedStorageUnpack: both directions of palette bit-packing in SimpleBitStoragez / PalettedContainer, hit on every chunk save and every chunk load. Also covers SimpleBitStorage.getAll(IntConsumer), used by the block/fluid count recompute on chunk load and the biome-decoration possible-biomes scan.
• canyonCarverSkip: the ellipsoid-membership skip test in CanyonWorldCarver, bulk-computed for a whole vertical column instead of one call per block. CaveWorldCarver is deliberately not covered, its skip test closes over an RNG-derived local that can't be reached without risking desyncing generated terrain from vanilla.

Performance

Measured on a real dedicated server. Same seed, same coordinates, 1024 force-loaded chunks, AMD Ryzen 7 9800X3D (AVX-512 selected), Temurin 25.0.4 JDK:

≈1.33× faster, ≈25% less CPU time for identical world generation.

These numbers were measured with 3 of the 4 kernels active (before canyonCarverSkip was added) and don't yet reflect canyon carving's contribution. Treat this table as a floor, not the current total.

Isolated microbenchmarks show far bigger numbers (5–12× on the kernels themselves), but real chunk generation spends most of its time on noise sampling, feature/structure placement and biome computation, none of which VectorX touches. The 25% is the vectorized kernels' actual share of the total cost, measured in place rather than extrapolated.

Your results will vary: older CPUs limited to SSE/AVX2, or JDKs selecting a narrower vector width, will see proportionally less. Enable diagnostics in the config to see the width you actually get.

Why it's safe

1. Startup differential self-test. Each vector backend is run side by side with its scalar twin over generated inputs, including edge cases and non-multiple-of-lane-width lengths. One mismatch demotes that kernel to scalar for the session.
2. Per-call fail-open. Every hook catches Throwable and falls through to the exact vanilla code path, Mojang's own method body, or a per-element loop calling Mojang's own transform.
3. No hard Mixin requirements. A Minecraft update or conflicting mod that moves the targeted code makes VectorX inert, not crash-prone.
4. No static reference to the incubator module. VectorX loads and runs correctly on a JVM where jdk.incubator.vector is entirely absent.

Configuration

Edit the generated TOML file under config/, or open the settings screen in-game with Mod Menu.

Everything except diagnostics needs a restart.