Temporal Publishes svm-vec, a Prototype Adding 512-Bit Vector Instructions to Solana's sBPF

Temporal's GitHub organization has published svm-vec, a proof-of-concept prototype that adds 512-bit vector instructions to sBPF, the bytecode that Solana SOL$102.08+1.9% programs compile to and validators execute. Its README calls it "512-bit vector ops for sbpf, written in stock rust, with no compiler changes." Vector (SIMD) instructions process many numbers in one operation instead of one at a time, which is how modern CPUs speed up cryptography and machine-learning maths. All three commits in the repo's history are dated 28 October 2026.

A developer posting as Ben (@HypoNyms) announced it on X at 18:35 UTC that day as "our latest vectorization SIMD design for solana," adding: "ONCHAIN AI IS HERE." Temporal, which runs the HumidiFi prop AMM, named a new CEO on 27 October.

sol_math syscall versus vector instructions: the SIMD 708 debate

svm-vec lands two days after developers began debating sol_math, a proposed syscall in SIMD discussion 708 that would batch vector arithmetic behind a single call out to the runtime. On that thread, Blueshift's Dean Little argued for a dedicated vector memory region instead, writing that a syscall API "introduces an unnecessary boundary between the compiler and the host's native ISA." svm-vec sits in that compiler-side camp: vector operations become instructions inside the virtual machine itself, with no syscall in between.

How 512-bit vector registers work in sBPF

According to the README, svm-vec encodes each vector operation as a variant of sBPF's existing call instruction, so no new opcode is needed. The VM gains 30 vector registers, held as hidden state, which the x86-64 JIT (the step that turns sBPF into native machine code on a validator) pins to the CPU's AVX-512 registers. Developers write ordinary Rust using _svm512_* intrinsics, and a linker pass assigns registers.

The VM changes live in a fork of Anza's sbpf, about 2,100 lines of new vector and JIT code, and the linker changes in a fork of Blueshift's sbpf-linker, roughly 3,000 lines. Everything sits behind a config flag; programs that use no vector ops run on the original code paths.

svm-vec benchmarks: compute units versus JIT speed

The README reports two different gains, measured on a single AMD EPYC 9534 (Zen 4). The compute-unit (CU) figure is what a program is charged against its budget; the JIT figure is real execution time.

The announcement mixes the columns: its 232x is the MLP's CU reduction, while 28x and 25x are JIT speedups. Falcon-512 is a post-quantum signature scheme, designed to resist future quantum computers. The MLP is a small neural network with 256 inputs and 16 outputs, so the "onchain AI" in the announcement means models of that scale for now.

Against Dean Little's earlier hand-built AVX-512 Falcon experiment, the README reports Falcon verification using 1.06x fewer CUs and running 1.04 to 1.11x faster. The speed is close to parity. The more interesting claim is that svm-vec matches a bespoke implementation from generic Rust.

What a Solana mainnet path for sBPF vector ops would require

svm-vec's README lists its own gaps: interpreter and x86-64 JIT only, "no aarch64 jit, no firedancer." It also says "cu is 1 per op, so multi-instruction ops (hsum, insert, compares) are underpriced," which means the CU reductions may overstate what a properly priced version would show.

By our reading, shipping it would take a formal SIMD with a feature gate, consensus-exact pricing for vector ops, matching implementations in Agave and Firedancer, and support or a fallback for non-x86 validators. No SIMD has been filed for svm-vec, and we found no public comment on it from either client team. What it does supply is one half of the test cavemanloverboy proposed on discussion 708: "literally just impl the two things and see which one is faster."