What LD_PRELOAD does
On Linux, a dynamically linked program finds the functions it calls at start-up, library by library, in a fixed order. LD_PRELOAD names a library to load before all the others. Any function that library exports is found first, so a program that calls dsyev_ gets VVE's dsyev_ while every other call still resolves to wherever it did before.
Nothing is recompiled, relinked or patched. The program's own binary is untouched, and removing the variable puts the original library back.
Code changes required
0
lines of your code that change
The command
LD_PRELOAD=libvve.so python3 your_script.py
LD_PRELOAD=libvve.so ./your_program
# nothing else changesIt works for any program that reaches LAPACK through a shared library: compiled C, C++ and Fortran, and Python through NumPy and SciPy, whose eigh and eigvalsh end in a dsyev-family call. For Python there is also vvepy, a binding that calls VVE directly and can confirm that it did.
libvve.so runs on Linux (glibc) on x86_64 and aarch64, needs only libc, libm and libpthread, and is 1.4 MB on disk, so it travels with a container image or a board image without pulling a BLAS stack along.
What gets intercepted
| Routine | What it computes | Intercepted |
|---|---|---|
| dsyev | symmetric eigenvalues and eigenvectors, the default path | yes |
| dsyevd | the same, by divide and conquer | yes |
| dsyevr | the same, by MRRR, with eigenvalue subsets | yes |
| dstev | eigenvalues of a tridiagonal matrix given its two diagonals | yes |
| dgesdd | singular value decomposition, divide and conquer | yes |
| dgesvd | singular value decomposition, QR iteration | yes |
| dstemr | tridiagonal MRRR, the expert route | no, see the bands-native call |
The published speed record is for the symmetric eigensolvers. The two singular-value routines are covered by the same contract, and no ratio is published for them.
What happens on each call
VVE SmartRoute looks at the matrix it has been handed. If the numbers sit on a narrow band, with zeros elsewhere, the call goes down the structure-aware path, whose cost grows with N² rather than N³, and that is where the speed comes from. If no structure is found, the call runs an ordinary dense algorithm, and VVE makes no speed claim for it.
Either way the answer has to pass the same accuracy check as the routine it replaced: the result is put back into the original problem and the residual measured. Speed is only ever reported where accuracy was equal.
What the drop-in does not change
Memory. By the time a program calls dsyev, it has already built the full N×N matrix and handed it over. The drop-in cannot un-allocate it. The memory law on the benchmarks page, half a million dimensions solved in a few tens of megabytes, belongs to a different entry point.
A statically linked program has no dynamic lookup to intercept and is not affected. And the drop-in changes which library answers, not what the program asked for: a routine outside the table above, or a call made through a library that was itself statically linked, still goes where it went before.
Checking that it took effect
A benchmark that shows no change after preloading usually means the symbol was never bound to VVE: the program used a statically linked library, or a different routine than expected. Before timing anything, ask the dynamic linker which library answered.
LD_DEBUG=bindings LD_PRELOAD=libvve.so ./your_program 2>&1 | grep dsyev_The binding lines name the library that satisfied each call. If libvve.so is not on them, nothing was measured yet. The evaluation harness we ship asserts this before it records a single timing.