Eigen vs. BLAS/LAPACK libraries, NVIDIA DGX Spark with SVE (October 2026)

The cells of the DGX Spark NEON page measured again on the same core with Eigen compiled for SVE (-march=armv9-a+sve2 -msve-vector-bits=128 -DEIGEN_ARM64_USE_SVE), which selects Eigen’s SVE packet backend at the 128-bit vector length of this CPU. SVE and NEON are the same width here, so a difference between the two pages is code generation, not vector width: Eigen’s SVE kernels are a separate, younger backend, and the compiler targets Armv9-A rather than the Armv8-A baseline of the NEON build. The Grace SVE page makes the same comparison on a Neoverse V2.

The libraries are those of the NEON page and were not measured again: they choose their kernels at run time from the CPU and do not change with Eigen’s build flags.

Conditions

GEMM at n = 1024 ran at 76 GFLOP/s in double and 160 in float with Eigen built for SVE, against 72 and 155 for the NEON build of the previous page; the libraries stand at 83 and 171 (Arm Performance Libraries), 79 and 170 (NVPL) and 69 and 137 (OpenBLAS).

How to read the numbers. Every rate is nominal GFLOP/s: the textbook operation count of the operation, stated in each section below, divided by the median wall time of one call. Eigen was measured twice, in two binaries of the same SVE build, those linked against Arm Performance Libraries and NVPL, where only the Eigen cells ran. The Eigen line on each chart is the median of the two passes and the shaded band is their spread, the run-to-run noise on this host. The spread is within 3 % for 93 % of the cells, within 5 % for 95 % and above 10 % for 2 %; the widest are AXPY and DOT cells up to n = 1000, the binary-dependent effect the NEON page also shows (DOT in double at n = 6, 11.8 against 15.8 GFLOP/s), and DOT in float between n = 1536 and 6144, at 54 to 56 GFLOP/s in the Arm Performance Libraries binary against 60 to 62 in the NVPL binary.

A ratio divides that median by the library’s rate from the NEON page’s session, since the library does not change with Eigen’s build. Each operation’s SVE passes ran on the machine that measured its NEON page cells, in the same job, after all of that machine’s NEON runs. The cells above L3, where both builds run at the bandwidth of one core, bound the drift between the two sessions: AXPY and DOT at n = (2^{24}) and GEMV at n = 4096 in double repeat the NEON session’s Eigen rates within 3 % (4.40 against 4.42, 4.80 against 4.80 and 8.37 against 8.57 GFLOP/s).

Each run covered one operation in one binary and started only once the whole machine had used less than 0.5 of a core over a 5 s window; the load average before and after each run is in its result file (between 0.92 and 1.49 before and between 1.00 and 1.42 after a run). None of the 24 runs had to be repeated, and no cell errored.

For the eigenvalue and singular value decompositions the operation count is the one of the classical algorithm, so a divide-and-conquer or blocked implementation is credited with work it does not do; the ratios between arms are unaffected.

The dotted vertical lines on the charts mark the sizes at which the operands of the call, inputs and outputs together, fill the core’s L1 data cache (64 KiB), its L2 (2 MiB) and its cluster’s L3 (16 MiB).

SVE against NEON

Geometric mean of the rate of the SVE build over the rate of the NEON build, Eigen against Eigen, over the square shapes in each size band; above 1, SVE is faster. Over all 882 cells the mean is 0.96: 236 cells are more than 5 % slower under SVE and 92 more than 5 % faster.

The level-1 and level-2 kernels and the two eigensolvers are within 7 % of the NEON build in every band but two: AXPY up to n = 16 gains 11 to 23 % (2.3 against 2.8 ns per call at n = 2), and GEMV in float up to n = 16 loses 15 %. Unlike on Grace, the matrix-product kernel gains in double: GEMM runs 4 to 9 % faster than under NEON from n = 32 on, and SYRK, POTRF, GETRF, GEQRF and TRSM in double follow it by up to 8 % at their larger sizes. In float, GEMM is 8 to 30 % slower between n = 12 and 160 and 1 to 6 % faster from n = 500 on. The losses concentrate in float at small and medium sizes: TRSM in float runs at 0.38 to 0.57 of its NEON rate from n = 8 to 128 (17.7 against 47.0 GFLOP/s at n = 16) and at 0.62 to 0.89 from 200 to 1024; GETRF in float at 0.47 to 0.57 up to n = 8 and 0.70 to 0.81 up to 128; GEQRF in float at 0.80 to 0.95 at every size; POTRF in float at 0.53 to 0.84 up to n = 16; GESDD in float at 0.88 to 0.96. One size stands out: at n = 192 GEMM and SYRK drop in both SVE passes (GEMM in double to 59 GFLOP/s, against 78 and 80 at n = 160 and 200; SYRK in double to 42, against 59 and 67 at n = 128 and 200), a step the NEON build does not take here. In double that step is not the SVE code but the packing buffers Eigen allocates on every call being page-faulted in again on each call, which depends on the process’s earlier allocations: with glibc’s malloc thresholds fixed the SVE binary runs the GEMM cell at 79 GFLOP/s, and the NEON binary takes the same step when it runs those cells alone (libeigen/eigen#3201); the float step at n = 192 was not re-measured. Since the vector width is the same, the other differences are costs and gains in Eigen’s SVE packet kernels and in the compiler’s handling of the fixed-length SVE types, not in the hardware.

AXPY

y += alpha * x against ?axpy, alpha = 0.75; (2n) flops. Lengths run from 2 to (2^{24}) (128 MiB per double vector), through every cache level into DRAM.

Short vectors. Up to about n = 32 the AXPY and DOT rates measure the cost of a call rather than the kernel. Eigen’s expression compiles inline into the calling loop, while a call into a shared library pays a cost of its own before it reads an element. That cost is fixed per call, so the ratios at the small end are ratios of fixed costs. The DOT cells in double at n = 2 show it directly: 0.6 ns per call for Eigen in either build, against 3.1 ns for OpenBLAS, 4.1 ns for Arm Performance Libraries and 14.6 ns for NVPL. Eigen still computes the whole operation on every call; nothing is hoisted out of the timed loop.

The SVE build is 11 to 23 % faster than the NEON build up to n = 16 and within 8 % of it from n = 48 on, apart from n = 100 (0.85) and n = 256 in float (1.17, a cell the NEON build runs slowly); the comparison with the libraries is that of the NEON page.

DOT

x.dot(y) against ?dot; (2n) flops, the same lengths. Real scalars only: the Fortran convention for returning a complex function value is not fixed by the platform ABI and differs between library builds, so ?dotc cannot be declared portably.

Up to about n = 32 the rates measure the cost of a call; see AXPY.

Within the run-to-run spread of the NEON build at every length (0.89 to 1.15 per cell); Eigen remains the fastest arm in L1, and in float through L2.

GEMV

y.noalias() += A * x against ?gemv, column-major, no transposition; (2mn) flops.

Square matrices, then the short-fat (n = 10000, m grows) and tall-skinny (m = 10000, n grows) sweeps.

Square shapes are within 4 % of the NEON build from n = 128 on, apart from n = 4097 in double (0.86), and up to 29 % slower in float at n ≤ 16; the sweeps are within 2 % of the NEON build except 100-by-10000 in float (0.92).

GEMM

C.noalias() += A * B against ?gemm, column-major, no transposition; (2mnk) flops.

Square matrices first; then the two tall-skinny sweeps, where m stays at 4096 or 10000 while n = k grows; then the assorted non-square shapes that fit neither.

The SVE matrix-product kernel reaches 75 to 80 GFLOP/s in double from n = 200 on, 4 to 9 % above the NEON kernel, which narrows the gap to the vendor libraries: at n = 1024 Eigen runs at 0.92 of Arm Performance Libraries and 0.96 of NVPL in double, against 0.86 and 0.91 under NEON. In float it reaches 157 to 161 GFLOP/s from n = 500 on, 1 to 6 % above the NEON kernel, but runs 8 to 30 % below it between n = 12 and 160, and at 0.80 to 0.83 of it on the 64-by-1024-by-64 and 64-by-64-by-1024 shapes. At n = 192 both precisions drop by 16 to 26 % in both SVE passes (59 GFLOP/s in double, against 78 and 80 at n = 160 and 200); in double that is page faults on the per-call packing buffers, not the kernel, and the cell runs at 79 GFLOP/s with glibc’s malloc thresholds fixed (libeigen/eigen#3201).

TRSM

A.triangularView<Lower>().solveInPlace(X) against ?trsm with the m-by-m lower triangle on the left and n right-hand sides, no transposition, non-unit diagonal; (m(m+1)n) flops. The solve is destructive, so the timed region includes one copy of B for both arms.

Square shapes (m = n), then the sweeps with a fixed triangle of order 1024 or 4096 and a growing number of right-hand sides, then the remaining shapes with 4096 right-hand sides against a small triangle.

In float the SVE build runs at 0.38 to 0.57 of the NEON build from n = 8 to 128 (17.7 against 47.0 GFLOP/s at n = 16), at 0.51 to 0.89 from 192 to 1024 and at 0.91 to 0.98 above, so it falls behind Arm Performance Libraries from n = 192 to 1001, where the NEON build led; with 64 and 256 equations against 4096 right-hand sides it runs at 0.51 and 0.68 of the NEON rate. In double it is 13 to 23 % slower than NEON from n = 16 to 200 and 1 to 7 % faster from 768 on.

SYRK

C.selfadjointView<Lower>().rankUpdate(A) against ?syrk, lower triangle, no transposition, with C n-by-n and A n-by-k; (n(n+1)k) flops.

Square shapes (n = k), then the sweeps: a 4096-by-4096 matrix updated by a growing number of columns, and the Gram matrix of a short, wide factor with 4096 columns.

The SVE build is 2 to 8 % faster than the NEON build in both precisions from n = 24 on, which brings Eigen to 0.94 of the vendor libraries in double at n = 1024 (0.89 under NEON). The exception is n = 192, where it drops to 0.71 (float) and 0.67 (double) of the NEON rate in both SVE passes; the NEON page’s drops at n = 384 and 768 in float and 512 in double are there in the SVE build too. Those three drops are the per-call allocation of the packing buffers (libeigen/eigen#3201): with glibc’s malloc thresholds fixed the SVE binary runs them at 149, 157 and 72 GFLOP/s.

POTRF

LLT<Ref<MatrixXd>> in place against ?potrf, lower triangle, symmetric positive definite operand; (n^3/3) flops. The timed region includes one copy of the operand for both arms, since the factorization is destructive.

In float the SVE build is 16 to 47 % slower than NEON up to n = 16 and level from n = 48 on. In double it is 7 to 18 % slower up to n = 16 and 2 to 5 % faster from n = 128 on, which puts LLT level with NVPL at the largest sizes.

GETRF

PartialPivLU<Ref<MatrixXd>> in place against ?getrf, square operand; (2n^3/3) flops. Both arms copy the operand into a destination allocated once and factorize the copy; neither allocates inside the timed region.

In float the SVE build runs at 0.47 to 0.57 of the NEON build up to n = 8, 0.70 to 0.81 from 12 to 128 and 0.83 to 1.0 above, which costs it its lead over Arm Performance Libraries below n = 16. In double it is 8 to 21 % slower up to n = 12, within 4 % from 16 to 1024 and 2 to 8 % faster above.

GEQRF

HouseholderQR<Ref<MatrixXd>> in place against ?geqrf, m ≥ n; (2mn^2 - 2n^3/3) flops, the same copy-then-factorize protocol as GETRF.

Square shapes, then the tall-skinny sweeps with m fixed at 4096, 10000 and 100000.

In float the SVE build is 5 to 20 % slower than NEON at every size (13 to 15 % from n = 96 to 1536) and in the sweeps up to 10 % slower; in double it is within 4 % of NEON from n = 64 on and 4 to 11 % slower below.

SYEV

SelfAdjointEigenSolver with eigenvectors against ?syev (jobz = 'V', lower triangle), the like-for-like pair: tridiagonalization followed by implicit QR iteration on both sides; (9n^3) flops, the count of that algorithm (Golub & Van Loan, section 8.3.3). Neither works in place: the solver copies the operand internally and the reference arm pays the same one copy. Sizes to 2048.

Unchanged: within 4 % of the NEON build from n = 12 on except n = 257 (0.93 and 0.94); Eigen keeps its lead of 1.2 to 3.4x over every library.

GESDD

BDCSVD<MatrixXd, ComputeThinU | ComputeThinV> against ?gesdd with jobz = 'S', divide and conquer on both sides, m ≥ n, the thin U and V computed; (14mn^2 + 8n^3) flops, the Golub-Reinsch count (Golub & Van Loan, table 8.6.1). Square sizes to 2048, then tall-skinny sweeps with m fixed at 4096 and 10000.

In float the SVE build is 4 to 12 % slower than NEON at every size from n = 16 on, and in the sweeps except 10000-by-8; in double it is within 5 % of NEON.

GEEV

EigenSolver with eigenvectors against ?geev (jobvr = 'V'), a dense random nonsymmetric operand: Hessenberg reduction, QR iteration to the Schur form and back-substitution for the eigenvectors on both sides; (25n^3) flops, the count of the Hessenberg QR algorithm with Schur vectors (Golub & Van Loan, section 7.5.6). Sizes to 1024.

Within the run-to-run spread of the NEON build: 0.94 to 1.10 of its rate from n = 24 on. Eigen falls to 0.24 to 0.3x of the libraries at n = 1024, as on the NEON page.

Summary

Geometric mean of the Eigen ÷ library rate ratio over the square shapes in each size band. Above 1, Eigen is faster. Only the vector operations reach the last band.

Caveats

• The libraries were not measured again: their rows are the NEON page’s session, 0.3 to 2.8 hours earlier on the same machines, with the drift bound above. Each selects its kernels at run time for the CPU it finds, so their rates do not depend on Eigen’s build.
• SVE and NEON are both 128 bits wide on this CPU, so this page says nothing about wider SVE implementations; it compares Eigen’s two AArch64 backends at equal width.
• The SVE build targets Armv9-A (-march=armv9-a+sve2), the NEON build the Armv8-A baseline; the compiler’s own code generation for the scalar parts differs between the two as well.
• OpenBLAS 0.3.34 has no Cortex-X925 target and runs the Neoverse V2 kernels its own CPU detection selects; NVPL’s fixed cost per call, 15 ns at n = 2, sets its ratios at the smallest sizes.
• The operations were measured on three DGX Spark machines, every arm of an operation, NEON and SVE, on one of them; see the NEON page for the split. Every number is from one Cortex-X925 core in the cluster with the 16 MiB L3, single-threaded.

Full tables

GFLOP/s per shape and library, with the Eigen ÷ library ratio: Eigen’s median over its two SVE passes against the library’s rate from the NEON page’s session.