VVE EigenCore
Forty-nine minutes becomes twenty-nine seconds. Same code, same call, and the same answer on Intel, AMD and Arm.
You switch it on when you start your program. Nothing in your code changes.
VVE EigenCore is one 1.4 MB file that sits under the math calls your program already makes. The clock: one problem with 16,384 unknowns, solved start to finish by single-threaded reference netlib LAPACK and by VVE, one processor core each, on the same machine.
One input. Four builds. One answer.
Change the machine. Change the compiler. Change the architecture. The answer does not move.
In plain terms
VVE finds the eigenvalues of a symmetric matrix: the handful of numbers that describe how a structure vibrates, where a signal came from, or which energy levels a system allows. It returns the same result on every machine, and it is fastest when the matrix has structure. The three terms below explain each of those claims before the numbers make them.
Many engineering problems arrive as a large grid of numbers, a matrix. Hidden inside it are a handful of values that describe how the whole thing behaves: the pitches a structure rings at, the direction a radar echo came from, the energy levels of a quantum system. An eigensolver finds those values. Nearly every scientific library has one, and most of them call LAPACK to do it. VVE EigenCore replaces that LAPACK call.
A tuned math library, two chips
the last digits moved
VVE EigenCore, the same two chips
identical, every bit
Fast math libraries choose a different route through the arithmetic depending on the chip they land on. The answers agree to many digits but not the last ones, so the same program on two machines returns two slightly different results. Harmless in a quick experiment. A real problem when a result has to be reproduced, audited or certified. VVE takes one route everywhere, so the result is the same bits on every machine. With no large tuned library underneath, it is also small enough to ship anywhere.
Many of the matrices that matter in these fields are mostly zeros, with the information packed along a narrow band. The standard route still works through every entry. VVE SmartRoute, the structure-aware part of EigenCore, detects the band and works along it, so the effort grows with the square of the problem size rather than the cube. That is where the speed comes from, and it is also why VVE does not compete on dense, unstructured matrices.
What you get
One core against one core, N = 16,384
98–103×
vs single-threaded reference netlib LAPACK dsyev (the default dense path) — same size, same routine, same machine
In wall clock: 2,932.9 s becomes 28.8 s for one full decomposition.
The measured record →Different chips, different compilers
VVE carries its own arithmetic, so there is no vendor math library underneath to behave differently on a different chip.
What bit-identical means here →libvve.so, to scale
A problem with 524,288 unknowns: VVE peaks at 53 MB where holding the whole matrix would take 2,048 GiB.
The memory law →Fit check
VVE is built for problems where each point only interacts with its neighbours. That shows up in the matrix as a narrow band, and the band is where VVE is fast.
Radar, sonar and 5G arrays
Bridges, machines and buildings
Molecules and materials
Not a fit. Dense matrices with no structure. Tuned vendor libraries already do that well, and VVE does not compete there.
How the numbers were made
Each figure ships with the four things that make it checkable on your own hardware.
Flagship workload
A radar, a sonar or a phone mast has to work out where a signal came from. Here is the whole story in four pictures.
That third step is an eigenproblem solved under a clock, and it is the one workload that needs all three VVE outcomes at once: fast on this kind of matrix, identical on every board, and small enough to fit beside the firmware.
Three ways in
A VVE EigenCore evaluation build and the harness we measured with, run on your matrices. The first number you see is one you measured yourself.
Request an evaluation →A drop-in for existing LAPACK calls, a direct call for banded data, or an integration plan for routines outside the covered set.
Partner with us →The technical record, the claims discipline and the roadmap, shared with investor relations for diligence.
Investor relations →Tell us the spectra you actually run and the hardware you have to run them on. We send an evaluation build and the harness we measured with, so the first number you see is one you measured yourself.