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

The operations and shapes of the Grace and Apple M4 pages measured on one Cortex-X925 core of an NVIDIA DGX Spark, whose GB10 chip has 10 Arm Cortex-X925 performance cores and 10 Cortex-A725 efficiency cores. Eigen is built for NEON, the default on AArch64, against the same three BLAS/LAPACK libraries as on the Grace page, each at its newest release: Arm Performance Libraries 26.07, NVIDIA Performance Libraries (NVPL) 26.5 and OpenBLAS 0.3.34. 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 72 GFLOP/s in double and 155 in float in Eigen, against 83 and 171 for Arm Performance Libraries, 79 and 170 for NVPL, and 69 and 137 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 88 % of the cells, within 5 % for 95 % and above 10 % for 3 %. Most of the widest are at the small end of AXPY and DOT, where one binary runs a cell 14 to 20 % apart from the other two (AXPY in double at n = 32: 11.7 against 14.0 and 14.8 GFLOP/s). Two more are binary-dependent too: GEMM in float at n = 384 runs at 131 GFLOP/s in the Arm Performance Libraries and OpenBLAS binaries and at 158 in the NVPL binary, and DOT in float between n = 1536 and 4096 at 52 to 54 GFLOP/s in the NVPL binary against 61 to 62 in the other two. On the SVE page the slow DOT pass is the Arm Performance Libraries binary instead, in a run that ended at a load average of 1.03, so these follow the binary’s layout rather than the library it links or the load.

Three machines. The twelve operations were split into three groups to fit the measurement into the 8-hour limit of a batch queue, and each group was measured on its own DGX Spark, held exclusively: GEQRF, GEMV and POTRF on the first; GEMM, TRSM, DOT and GEEV on the second; SYRK, GESDD, SYEV, AXPY and GETRF on the third. All three run the same CPU at the same fixed 3.9 GHz, the same kernel and the same software, unpacked from one archive. Every arm of an operation, the three library binaries here and the two SVE passes, ran on the same machine, so every chart and every ratio on this page comes from one machine; the rates of two different operations may come from two. A run started only once the 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.95 and 1.38 before and between 1.02 and 1.54 after a run, which includes the run’s own core). 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 Cortex-X925, 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 (2 MiB) and its cluster’s L3 (16 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.64 ns per call for Eigen 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.

In L1 and L2 Eigen’s AXPY runs at about one 128-bit vector per cycle in either precision: 14 to 16 GFLOP/s in double and 26 to 31 in float from n = 48 to (2^{17}). OpenBLAS reaches 24 to 25 GFLOP/s in double between n = 384 and 2048, 1.6x Eigen, and Arm Performance Libraries 18 to 20; in float the libraries’ lead is smaller, 36 to 40 GFLOP/s for Arm Performance Libraries and 33 to 35 for OpenBLAS. Up to n = 16 Eigen is 2x ahead of Arm Performance Libraries and 5 to 6x ahead of NVPL. From L3 into DRAM the four arms meet at the bandwidth of one core, 4.4 GFLOP/s at n = (2^{24}) in double, or 53 GB/s.

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 that fits in L1, and in float through L2: 30.6 GFLOP/s at n = 1024 in double against 23.6 for Arm Performance Libraries, 17.2 for OpenBLAS and 7.5 for NVPL, and 62 GFLOP/s in float at n = 4096, 1.9x Arm Performance Libraries and OpenBLAS. In double, from L1 to L3, Eigen and Arm Performance Libraries are level (ratios of 0.97 to 1.07), and both stay ahead of OpenBLAS through L2. NVPL’s DOT stays near 7.8 GFLOP/s in double and 15.5 in float from n = 2048 through L3, and only meets the others where DRAM bandwidth binds, at 4.8 GFLOP/s in double at n = (2^{24}).

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.

Eigen leads every library from n = 24 to 128, by 1.05 to 2.7x, and the two vendor libraries by 2.7 to 9.5x at n ≤ 16. From 200 to 768 the four arms are within 12 % of each other. Between the L2 and L3 boundaries OpenBLAS is ahead, by up to 1.35x: 21.7 GFLOP/s against Eigen’s 16.3 at n = 1024 in double, and 52.5 against 38.9 in float. From n = 4096 on every arm runs at 8 to 9.4 GFLOP/s in double, the memory bandwidth of one core. In the sweeps Eigen is up to 15 % behind the vendor libraries at 100 to 1000 rows or columns, and at 0.74 and 0.78 of OpenBLAS on 1000-by-10000 in float and 100-by-10000 in double; Eigen leads at the narrowest operands: 8-by-10000 runs at 1.4 to 2.3x every library in double, and 10000-by-8 at 1.4x OpenBLAS in both precisions.

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 72 to 75 GFLOP/s in double and 149 to 159 in float from n = 192 on (apart from the binary-dependent float cell at n = 384 described above) and holds that to n = 4096 and the 10000-by-4000 shapes. Arm Performance Libraries reaches 82 to 85 and 158 to 175: Eigen runs at 0.85 to 0.90 of its rate in double and 0.86 to 0.96 in float. NVPL is within 7 % of Eigen in double up to n = 512 and ahead from 768 on, where Eigen runs at 0.89 to 0.92 of it in double and 0.87 to 0.93 in float. OpenBLAS’s Neoverse V2 kernels reach 66 to 69 and 131 to 138, behind Eigen by 4 to 10 % in double and 11 to 17 % in float. Below n = 32 Eigen is 1.2 to 5x ahead of Arm Performance Libraries and 1.5 to 20x ahead of NVPL.

OpenBLAS’s square GEMM drops in double at n = 16, 32, 64, 96, 128 and 256 (13.5 to 56 GFLOP/s, against 66 to 68 at n = 100, 160, 192 and 257) and in float at n = 96 and 256; the 10 repetitions of each of these cells agree within 8 %, so the drops are a property of the library at those sizes, not noise. In double the 10000-by-8-by-8 shape puts Eigen behind Arm Performance Libraries and OpenBLAS: 34 GFLOP/s against 44 and 47.

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.

Eigen’s TRSM leads in float at every size up to 2048: 1.02 to 1.3x Arm Performance Libraries from n = 192 to 1024, 1.15 to 2x NVPL and 1.4 to 2.1x OpenBLAS, and 3.5x NVPL and OpenBLAS on 64 equations with 4096 right-hand sides. In double Eigen leads or is level up to n = 1024 and falls 3 to 11 % behind the two vendor libraries from 1536 on (67 to 68 GFLOP/s against 71 to 75), still 6 to 9 % ahead of OpenBLAS. NVPL’s call cost dominates the smallest triangles, where Eigen is 12 to 86x 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 69 GFLOP/s in double and 149 in float at n = 1024, 11 % behind the two vendor libraries in double and 5 to 9 % in float, and level with or ahead of OpenBLAS (1.01x and 1.10x). Eigen’s rate drops at three sizes in every pass and in both builds: n = 384 and 768 in float (103 and 121 GFLOP/s, against 132 to 153 at the sizes around them) and n = 512 in double (52 against 70). These are not the kernel: at those sizes the packing buffers Eigen allocates on every call go back to the operating system on each free and are page-faulted in again on the next call. The same binaries with glibc’s malloc thresholds fixed run them at 143 to 151 and 67 GFLOP/s (libeigen/eigen#3201). At n ≤ 8 the vendor libraries’ call costs put Eigen 3.4 to 5.4x (Arm Performance Libraries) and 12 to 24x (NVPL) ahead, while in double up to n = 12 Eigen runs at 0.68 to 0.85 of OpenBLAS.

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 LLT is ahead of all three libraries from n = 128 to 4096, by 1.05 to 2.1x: 137 GFLOP/s at n = 4096 against 110 for Arm Performance Libraries, 130 for NVPL and 126 for OpenBLAS. In double it is level with or ahead of the two vendor libraries at every size up to 1024, by up to 2.3x at n = 24, and above that ahead of Arm Performance Libraries and up to 6 % behind NVPL. OpenBLAS’s dpotrf is ahead of Eigen at several sizes between 32 and 200, by 1.4 to 1.5x at n = 32, 96 and 100, and within 6 % of it from 768 on.

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 PartialPivLU is the fastest arm at every size from 24 to 4096: 1.1 to 1.8x Arm Performance Libraries, 1.04 to 2x OpenBLAS, and 1.04 to 4.8x NVPL. In double it is 1.2 to 2.6x ahead of OpenBLAS below n = 96 and level with it from there on. It leads Arm Performance Libraries at most sizes above n = 24, by up to 1.3x at n = 256, 512 and 1024, where Arm Performance Libraries’ dgetrf drops (to 32, 39 and 48 GFLOP/s, against 38, 49 and 58 at n = 257, 500 and 1001). NVPL’s dgetrf catches up with Eigen at n = 2048 and is 3 to 8 % ahead 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.

Below n = 64 the two vendor libraries lead, Arm Performance Libraries by 1.2 to 1.6x in double at n ≤ 16; Eigen leads OpenBLAS there. Eigen’s rate drops at n = 64 in every pass (11.1 GFLOP/s in double, against 13.0 at n = 48 and 18.7 at 96), the one square size at which it trails all three libraries in both precisions. From 128 on Eigen is level with or ahead of every arm in float, by up to 2.9x over Arm Performance Libraries, whose sgeqrf stays near 30 GFLOP/s from n = 128 to 384; in double it is level with or ahead of NVPL and OpenBLAS up to n = 2048 (never below 0.92 of either) and within 10 % of Arm Performance Libraries from 384 on. At the largest sizes NVPL leads: Eigen runs at 0.95 of its rate in float and 0.85 in double at n = 4096. In the tall-skinny sweeps NVPL leads at 64 and 100 columns, by up to 1.8x in double, and Arm Performance Libraries trails at 256 columns, where Eigen is 2 to 4x ahead.

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

Eigen’s tridiagonal QR path is the fastest arm at every size: 1.2 to 2.1x every library in double and 1.3 to 3.5x in float, and 2.7 to 3.5x every library in float from n = 192 on (50 GFLOP/s at n = 512 against 16 to 17), 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.

Between n = 8 and 128 the libraries’ divide and conquer is ahead of BDCSVD in double, by up to 1.8x. From 192 to 2048 Eigen is level with NVPL in double and 1.1 to 1.2x ahead of it in float, 1.06 to 1.9x ahead of Arm Performance Libraries, whose rate falls above n = 1000, and within 14 % of OpenBLAS, which mostly leads in double and trails in float. In the tall-skinny sweeps Eigen leads every library at 64 to 256 columns, by up to 2.5x, is level with NVPL and OpenBLAS at 10000-by-1000, and runs at 0.54 to 0.59 of every library at 10000-by-8 in double.

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

EigenSolver stops scaling at n = 128 and stays at 12 to 14 GFLOP/s in double, while the three libraries’ dgeev climb to 54 to 58 GFLOP/s at n = 1000, so Eigen falls from 0.6 to 0.8x of the libraries at n = 192 to 0.23 to 0.28x at 1024, as on the other pages. Below n = 32 Eigen leads by 1.2 to 14x.

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.34 has no Cortex-X925 target; it runs the Neoverse V2 kernels its own CPU detection selects for this core. It was built from the release tarball with gfortran 13.3 unpacked from Ubuntu’s packages, and since the machines have no libgfortran.so.5, the copy from Ubuntu’s libgfortran5 package was on LD_LIBRARY_PATH for every run.
• NVPL’s fixed cost per call, 15 ns for AXPY and DOT at n = 2 against 3 and 0.6 ns for Eigen, sets its ratios at the smallest sizes; those cells say nothing about its kernels.
• The operations were measured on three DGX Spark machines, every arm of an operation on one of them. No cell was measured on more than one machine, so the machine-to-machine variation is not measured; all three report the same CPU, clock, kernel and performance governor.
• Every number is from one Cortex-X925 core in the cluster with the 16 MiB L3. The Cortex-A725 cores and the cluster with the 8 MiB L3 were not measured, and an unpinned single-threaded program may run on either kind of core.
• Eigen was compiled for the Armv8-A baseline that GCC targets by default; GCC 13 does not accept -mcpu=cortex-x925, and a CPU-specific target would change the compiler’s scheduling rather than Eigen’s kernels.
• One thread throughout; nothing here describes multithreaded behavior on this big.LITTLE part.

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.