Eigen vs. BLAS/LAPACK libraries, NVIDIA Grace with SVE (October 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 77 in float with Eigen built for SVE, against 35 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 39 and 84 (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 91 % of the cells, within 5 % for 95 % and above 10 % for 2 %; the widest is AXPY in float at n = 100, 14.8 against 21.3 GFLOP/s, and the rest of the top ten are AXPY and DOT cells below L2 and GEQRF at n = 2 and 3 (about 0.1 GFLOP/s), 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 1.1 % (3.6 against 3.7, 3.7 against 3.7 and 7.8 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.00 before and between 1.00 and 1.04 after a run, which is the run’s own core). 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: 380 cells are more than 5 % slower under SVE and 38 more than 5 % faster.

The level-1 kernels and SYEV are unchanged, and AXPY below n = 16 gains about 20 % from a shorter inlined loop. Everything that runs on the matrix-product kernel loses: GEMM by 2 to 4 % in double and 7 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.55 of its NEON rate from n = 8 to 64 (28.8 against 13.3 GFLOP/s at n = 16), GETRF in float at 0.68 below n = 16 and 0.77 up to 128, GEQRF in float at 0.79 to 0.85 from n = 24 on. 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. Both builds solve TRSM faster than in September, the NEON build by more, so TRSM in double now trails it by 19 to 29 % from n = 16 to 128 (16 to 19 % in September); the NEON build’s GEEV has also gained, so GEEV in double trails it by 7 % from n = 192 to 1024. 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 4.1 ns for OpenBLAS, 6.3 ns for Arm Performance Libraries 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 is 22 to 25 % faster than the NEON build up to n = 16 in float and n = 8 in double, 6 % ahead on average from n = 24 to 128, within the binary-to-binary spread of those lengths, and level with it on average from n = 192 on; 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 4 % of the NEON build in every size band but the shortest float vectors (0.94 at n ≤ 16); 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 3 % of the NEON build on average from n = 192 on and 9 to 15 % 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 37 GFLOP/s in double and 77 to 80 in float from n = 512 on, 2 to 4 % and 7 to 9 % below the NEON kernel, so the gap to the vendor libraries widens to 24 % (double) and 16 to 18 % (float) from n = 1536 on. OpenBLAS 0.3.34, with its Neoverse V2 kernels, is ahead too: Eigen runs at 0.87 of it in double and 0.94 in float there.

At n = 3 to 6, and n = 2 in float, both builds are slower than in September, this one by 14 to 36 % (n = 3 in double: 2.1 against 3.3 GFLOP/s); the cause has not been bisected.

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.55 of its NEON rate from n = 8 to 64 and at 0.84 to 0.90 at n = 1024 and 4096; in double the loss is 5 to 29 %. Both builds are faster than in September, since master solves whole diagonal blocks with the shared packet kernel (libeigen/eigen!3187): this one by up to 18 % between n = 16 and 384, the NEON build by 10 to 26 %, which widens the gap in double. Above n = 192 Eigen is within 10 % of OpenBLAS 0.3.34 (ahead in float up to n = 1024, behind in double), and from n = 1536 on 9 to 19 % 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 on average below n = 128 and 3 to 6 % slower above; from n = 192 on 16 to 17 % behind NVPL, 4 to 8 % behind OpenBLAS 0.3.34, and 4 to 12 % behind 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.

4 % slower than under NEON in double and 6 to 8 % in float above n = 192; still ahead of the two vendor libraries from n = 24 to 1024 in double (1.05 to 1.20), but OpenBLAS 0.3.34’s dpotrf is faster there: Eigen runs at 0.75 of it from n = 24 to 128 and 0.90 up to 1024.

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.68 of its NEON rate up to n = 16 and 0.77 up to 128, at 0.84 and 0.90 in the two larger size bands; in double the loss is 5 to 10 %. NVPL’s getrf leads by 12 to 28 % in double from n = 1536 on, and OpenBLAS 0.3.34 by 15 to 16 % in double from n = 192 on.

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 21 % from n = 64 on and the double build 2 to 4 %; from n = 192 on NVPL leads by 18 to 27 %, Arm Performance Libraries by 10 to 14 % at the largest sizes, and OpenBLAS 0.3.34, which the double build led in September, by 3 to 16 % in double from n = 200 on.

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 from September: in double within 2 % of the NEON build in every size band (only the odd sizes 257 and 1001 run at 0.90 to 0.92), in float 6 to 7 % slower below n = 192 and level above, so Eigen’s tridiagonal QR remains 1.3 to 1.7x faster than the libraries in double and 1.5 to 2.7x 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 September. The NEON build has gained 2 to 6 % in double since then, so this build now trails it by 7 % in double from n = 192 to 1024 and is level with it in float; EigenSolver stays at 7 to 8 GFLOP/s in double from n = 128 on while the libraries climb to 24 to 31 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, the 7.8 hours before the SVE passes 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.34 is built from the release tarball for its Neoverse V2 target, as the library reports at run time; the September pages used Ubuntu 24.04’s 0.3.26, which runs Neoverse V1 kernels on this CPU, so every OpenBLAS ratio differs from theirs. 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.
• 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.