Eigen vs. BLAS/LAPACK libraries, NVIDIA Grace with SVE (September 2026)

The cells of the Grace 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 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 34 GFLOP/s in double and 78 in float with Eigen built for SVE, against 37 and 84 for the NEON build of the previous page; the libraries stand at 45 and 94 (Arm Performance Libraries), 45 and 95 (NVPL) and 35 and 71 (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 97 % and above 10 % for 1 %; the widest is AXPY in float at n = 100, 15.0 against 21.5 GFLOP/s, and the rest of the top ten are AXPY and DOT cells below L2, the binary-dependent effect the NEON page also shows.

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. 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 rates within 2 % (3.6 against 3.7, 3.7 against 3.7 and 7.9 against 7.9 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.48 before and between 1.00 and 1.61 after a run. Two of the 24 runs, DOT and GEQRF in the Arm Performance Libraries binary, ended at 1.6, so another process was awake for part of them; their cells agree with the second pass within the spreads above, the widest being DOT in double at n = 2048, 16.5 against 18.7 GFLOP/s). 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 (1 MiB) and the shared L3 (114 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.94: 365 cells are more than 5 % slower under SVE and 37 more than 5 % faster.

The level-1 kernels and the two eigensolvers are unchanged, and AXPY below n = 16 gains 20 % from a shorter inlined loop. Everything that runs on the matrix-product kernel loses: GEMM by 4 to 5 % in double and 8 to 9 % in float above n = 192, and TRSM, SYRK, POTRF, GETRF and GEQRF with it. The float losses are the largest, and they concentrate at small sizes: TRSM in float runs at 0.46 to 0.58 of its NEON rate from n = 8 to 64 (24.9 against 11.5 GFLOP/s at n = 16), GETRF in float at 0.65 below n = 16 and 0.76 up to 128, GEQRF in float at 0.81 to 0.86 throughout. Since the vector width is the same, these are costs in Eigen’s SVE packet kernels and in the compiler’s handling of the fixed-length SVE types, not in the hardware. The tall-skinny GEMV sweep is the one place SVE is clearly ahead: 10000-by-100 runs at 1.5x (float) and 1.7x (double) the NEON rate.

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.95 ns per call for Eigen in either build, against 6.3 ns for Arm Performance Libraries, 11.1 ns for OpenBLAS and 28.9 ns for NVPL. Eigen still computes the whole operation on every call; nothing is hoisted out of the timed loop.

The SVE build matches the NEON build from n = 24 on and is 17 to 25 % faster below it; 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.

Unchanged from the NEON build within 1 to 3 % at every length; Eigen remains the fastest arm up to 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 2 % of the NEON build above n = 192 and 10 to 14 % slower below; the 10000-by-100 cells of the tall-skinny sweep run 1.5x (float) and 1.7x (double) faster than under NEON.

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 34 to 35 GFLOP/s in double and 78 in float, 4 to 5 % and 8 to 9 % below the NEON kernel, so the gap to the vendor libraries widens to 23 % (double) and 18 % (float); against OpenBLAS the double rate is even and the float rate 10 % ahead.

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.

The largest loss on the page: in float the SVE build runs at 0.46 to 0.58 of its NEON rate from n = 8 to 64 and at 0.86 to 0.90 at n = 1024 and 4096; in double the loss is 6 to 18 %. Eigen is still even with OpenBLAS above n = 192 and 10 to 20 % behind the vendor libraries.

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.

Within 2 % of the NEON build below n = 128 and 4 to 6 % slower above; 10 to 17 % behind NVPL and even with Arm Performance Libraries in double.

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.

3 to 4 % slower than under NEON in double and 7 to 9 % in float above n = 192; still ahead of all three libraries from n = 24 to 1024 in double.

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.65 of its NEON rate below n = 16 and 0.76 up to 128, at 0.87 to 0.91 above; in double the loss is 4 to 10 %. NVPL’s getrf leads by 18 % in double at the largest sizes.

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.

The float build loses 14 to 19 % at every size above 24 and the double build 3 to 7 %; NVPL leads by 16 to 24 %, Arm Performance Libraries by 13 % at the largest sizes, and Eigen stays ahead of OpenBLAS in double.

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, where a call of SelfAdjointEigenSolver takes 5.5 s in double.

Unchanged: within 2 % of the NEON build at every size, so Eigen’s tridiagonal QR remains 1.3 to 1.7x faster than the libraries in double and 1.9 to 2.8x in float.

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.

2 to 3 % slower than under NEON in double and 7 to 9 % in float; the comparison with the libraries is that of the NEON page within those margins.

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, where a call of EigenSolver takes 3.8 s in double.

Unchanged from the NEON build within 3 %; EigenSolver stays at 7 to 8 GFLOP/s in double from n = 128 on while the libraries climb to 24 to 35 at n = 1024.

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, three to thirteen hours earlier on the same core, 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.26 is Ubuntu 24.04’s packaged build and runs its Neoverse V1 kernels on this CPU, as the library reports at run time; NVPL’s fixed cost per call, 29 ns at n = 2, sets its ratios at the smallest sizes.
• The machine is a shared 72-core server. Runs were gated on measured CPU use rather than on the harness’s 1-minute load average, which still carried the previous run’s own core when the next run was due; the result files therefore record allow_noisy: true with the load average before and after each run. Two runs saw a load average of 1.6 at their end, as described above.
• The kernel runs with 64 KiB pages, so the TLB reaches eight times further than on a 4 KiB-page system; rates at the largest sizes may not transfer to such a system.

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.