HomeJavaModsVectorX
VectorX
ModsJava

VectorX

by etil2jz · on Modrinth

Vectorizes specific Minecraft hot paths to make them faster

⬇ Download on Modrinth

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:

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:

Backend CPU-seconds
Vector (AVX-512) 4.20
Scalar 5.59

≈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.

Option Default Effect
backendForcedScalar false Forces every kernel to scalar, overriding everything below.
densityFunctionMap auto auto = vector if available and correct, scalar otherwise · scalar = force scalar · off = disable the hook.
densityFunctionClamp auto Same auto / scalar / off semantics.
packedStorageUnpack auto Same auto / scalar / off semantics.
canyonCarverSkip auto Same auto / scalar / off semantics.
selfTest true Runs the scalar-vs-vector check at startup. Leave this on.
diagnostics false Logs a full startup report: module resolution, per-kernel backend, fallback reason, vector width, known mod interactions.

Everything except diagnostics needs a restart.

Verified by MCModsHub

These come from our own check of the pack file, not from the source page.

Explore more