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

The operations and shapes of the Zen 5 and Apple M4 pages measured on one core of an NVIDIA Grace, the 72-core Arm Neoverse V2 server CPU, with Eigen built for NEON, the default on AArch64, against the three BLAS/LAPACK libraries with tuned kernels for this CPU: Arm Performance Libraries, NVIDIA Performance Libraries (NVPL) and OpenBLAS. The SVE page has the same cells with Eigen built for SVE at the 128-bit vector length of this CPU.

Conditions

GEMM at n = 1024 ran at 37 GFLOP/s in double and 84 in float in Eigen, against 45 and 94 for Arm Performance Libraries, 45 and 95 for NVPL, and 35 and 71 for 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. Both arms of a comparison are built into the same binary and run on the same freshly randomized operands, and the reference library’s result is validated against Eigen’s before it is timed. A ratio divides Eigen’s rate by the library’s rate from the same binary and the same run. Each of the three binaries, one per library, also measured every Eigen cell, so Eigen was measured three times: the Eigen line on each chart is the median of the three passes and the shaded band is their spread, the run-to-run noise on this host. The spread is within 3 % for 84 % of the cells, within 5 % for 93 % and above 10 % for 2 %. The widest are at the small end of DOT and AXPY, where one of the three binaries runs a cell 17 to 26 % slower than the other two (DOT in float at n = 4: 8.4 against 11.2 GFLOP/s), a binary-dependent effect rather than noise.

Each run covered one operation against one library. The machine is a shared server that was otherwise idle: a run started only once the whole machine had used less than 0.5 of a core over a 5 s window, and the load average before and after each run is in its result file (between 0.92 and 1.08 after every run, which is the run’s own core; before the first run it was 3.15, the tail of the builds that preceded it, with the CPU already idle). None of the 36 runs had to be repeated, and no cell errored.

The libraries select their kernels at run time from the CPU they find themselves on, so they run whatever they choose for the Neoverse V2, SVE or NEON; only Eigen is held to NEON on this page, and to SVE on the SVE page. The library rows are the same on both.

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).

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 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.

In L1 and L2 (n up to about (2^{17})) Arm Performance Libraries is 5 to 15 % ahead of Eigen in double and Eigen 8 to 20 % ahead of OpenBLAS; from L3 into DRAM the four arms meet at the bandwidth of one core, 43 GB/s at n = (2^{24}) in double. NVPL’s cost per call puts Eigen 9x ahead of it at n ≤ 16.

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.

Eigen’s dot product is the fastest arm at every length up to L2: 18.5 GFLOP/s at n = 1024 in double against 14.6 for Arm Performance Libraries, 13.0 for OpenBLAS and 6.3 for NVPL, whose DOT stays at 6 GFLOP/s through L2 and only meets the others where DRAM bandwidth binds.

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.

Beyond L2 the square shapes run at the memory bandwidth for every arm. Below it Eigen matches the two vendor libraries and leads OpenBLAS by 1.3x; at n ≤ 16 the call costs put Eigen 3 to 8x ahead.

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.

Eigen’s NEON kernel reaches 37 GFLOP/s in double and 85 in float from n = 128 on and holds that to n = 4096 and the 10000-by-4000 shapes. The two vendor libraries reach 45 and 94, a lead of 17 % in double and 10 % in float that Eigen does not close at any size above 64. OpenBLAS’s Neoverse V1 kernels reach 35 and 71, behind Eigen by 4 % and 19 %. Below n = 32 Eigen is 2 to 2.8x ahead of every library.

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.

From n = 192 on the arms are within 20 % of each other: Eigen even with Arm Performance Libraries, 5 to 30 % ahead of OpenBLAS, and 9 to 17 % behind NVPL at the largest sizes. NVPL’s call cost dominates the smallest triangles, where Eigen is 31 to 40x faster.

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.

Eigen runs SYRK at 39 GFLOP/s in double at n = 1024, within 3 % of Arm Performance Libraries, 10 % ahead of OpenBLAS and 14 % behind NVPL, which holds the same margin as in GEMM. At n ≤ 16 the vendor libraries' call costs put Eigen 3x (Arm Performance Libraries) to 10 to 13x (NVPL) ahead; OpenBLAS keeps pace there.

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.

LLT is ahead of all three libraries from n = 24 to 1024, by 1.1 to 1.5x, and within a few percent of them above; NVPL’s potrf is the one arm to pull ahead, by 7 % in double at n ≥ 1536.

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.

PartialPivLU is 1.3 to 1.7x faster than Arm Performance Libraries between n = 24 and 1024 and even with it above. NVPL’s getrf is the fastest arm at the largest sizes, 13 % ahead of Eigen in double, while Eigen stays 4 to 17 % ahead of OpenBLAS throughout.

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 one factorization the vendor libraries lead throughout: NVPL by 15 to 20 % at every size above 24, Arm Performance Libraries by 1.7x in double at n ≤ 16 (a fixed cost in Eigen’s small Householder QR) and by 10 % at the largest sizes, with Eigen ahead between 192 and 1024. Eigen is 8 to 24 % ahead of OpenBLAS.

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.

Eigen’s tridiagonal QR path is 1.3 to 1.7x faster than every library in double and 2 to 2.7x in float at every size, the largest lead on the page for a LAPACK routine.

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.

Below n = 128 the libraries’ divide and conquer is 1.4x ahead of BDCSVD in double (ratios of 0.68 to 0.71); from 192 to 2048 Eigen is even with OpenBLAS, 1.2 to 1.7x ahead of Arm Performance Libraries and 15 % behind NVPL.

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.7 s in double.

EigenSolver stops scaling at n = 128 and stays at 7 to 8 GFLOP/s in double, while the three libraries' dgeev climb to 24 to 35 GFLOP/s at n = 1024, so Eigen is at 0.4x from n = 192 on, as on the Zen 5 and Apple M4 pages. Below n = 64 Eigen leads by 2.5 to 3.9x.

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 are not held to NEON: each selects its kernels at run time for the CPU it finds, so the library rows here and on the SVE page are the same measurements, and only Eigen’s build differs between the two pages.
• OpenBLAS 0.3.26 is Ubuntu 24.04’s packaged build, what apt install libopenblas-dev gives. It predates a Neoverse V2 target and runs its Neoverse V1 kernels, as the library reports at run time.
• NVPL’s fixed cost per call, 29 ns for AXPY and DOT at n = 2 against 3 and 1 ns for Eigen, sets its ratios at the smallest sizes; those cells say nothing about its kernels.
• The machine is a shared 72-core server. Every run took place with the rest of the machine idle, 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 together with the load average before and after each run.
• Eigen was compiled for the Armv8-A baseline that GCC targets by default; -mcpu=neoverse-v2 was not tried, and would change the compiler’s scheduling rather than Eigen’s kernels.
• 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 three passes against the library’s rate from the same binary.