What LD_PRELOAD does
On Linux, a program finds the functions it calls at start-up, library by library, in a fixed order. LD_PRELOAD is a setting that names one library to load before all the others. The calls VVE covers are then answered by VVE, and every other call still goes where 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
How you switch it on
It 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 |
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.
These memory figures need one small code change: the program hands VVE the band of the matrix instead of the whole thing. The drop-in alone gives the speed, not the memory.
A statically linked program is not affected, and the drop-in changes which library answers, not what the program asked for: a routine outside the table above still goes where it went before.
Checking that it took effect
A benchmark that shows no change after preloading usually means VVE was never in the loop: the program used a statically linked library, or a different routine than expected.
The evaluation harness we ship checks which library answered each call before it records a single timing, so an evaluation never measures the wrong thing.