Benchmarks

All benchmarks were run on an Apple M2 Max, macOS 26, single-threaded, with Julia 1.12.6 and AppleAccelerate.jl v0.8.0 master (all tables measured July 2026, after the 2D real FFT / batched FFT / FFT setup-caching work). Times are the minimum of 5 trials.

Single-threaded execution is used to compare kernel quality on a level footing. This is not representative of how OpenBLAS is normally deployed — OpenBLAS scales GEMM across CPU cores, whereas Accelerate offloads large GEMM to a shared SME co-processor that a single thread already saturates. See the GEMM note below for a multi-threaded comparison.

How these benchmarks are generated

Every table on this page is produced by the scripts in test/bench/, driven by run_benchmarks.jl:

julia --project=test/bench test/bench/run_benchmarks.jl          # all suites
julia --project=test/bench test/bench/run_benchmarks.jl dense    # one suite

Each suite runs in its own fresh Julia process so that the OpenBLAS/SuiteSparse baselines are measured before AppleAccelerate is loaded (loading it forwards BLAS/LAPACK through libblastrampoline for the rest of the process). The tables on this page were produced by running the suites one at a time so no two benchmarks compete for the machine. All suites default to a single thread; the dense suite additionally honors a BENCH_THREADS environment variable for thread-scaling sweeps like the GEMM table below:

BENCH_THREADS=4 julia --project=test/bench test/bench/run_benchmarks.jl dense

Array Operations

Performance comparison of vDSP array operations vs Julia Base equivalents (map(Base.f, X) for unary, @simd loops for binary/compound). Source: bench_array.jl.

Unary Math Functions

Transcendental functions show the biggest gains — vDSP is 7–19× faster for sin/cos on Float32:

Reductions

sum/maximum/minimum are 1.0–1.2× faster. Note: dot is slower via vDSP because Julia's LinearAlgebra.dot already uses the Accelerate-forwarded BLAS:

Binary Element-wise Ops

Addition and multiplication are memory-bandwidth-bound, so Float64 results hover at parity, while vDSP shows a modest edge for Float32:

Dense Linear Algebra

Performance comparison of Apple Accelerate vs OpenBLAS. The dense benchmark script loads OpenBLAS first, then switches to Accelerate via LBT, so both are measured in the same process. Source: bench_dense.jl.

GEMM (mul!) — GFLOPS (higher is better)

Single-threaded, Accelerate is 6–13× faster for matrix multiply, with the largest gains for Float32:

Factorizations (Float64) — time in μs (lower is better)

Linear Solve (A\b) — time in μs (lower is better)

Sparse Linear Algebra

Performance comparison of Apple Sparse Solvers vs SuiteSparse (CHOLMOD/UMFPACK). The sparse benchmark script runs SuiteSparse first (before loading AppleAccelerate), so SuiteSparse uses OpenBLAS internally, then loads AppleAccelerate and re-runs with Apple's sparse solvers. Source: bench_sparse.jl.

Sparse Matrix-Vector Multiply (density=0.01)

SuiteSparse CSC SpMV is 2.4–4.5× faster due to its simpler data layout:

QR Factorize + Solve

SuiteSparse LU (\) is modestly faster for Float64 (near parity by N=2000). Apple QR wins for Float32 at N≥1000 (up to 2×):

Cholesky Factorize + Solve

Apple Cholesky is around parity at N=500 and pulls ahead as N grows, reaching ~4× at N=5000:

FFT

FFT performance comparing Apple vDSP against FFTW, both single-threaded. With pre-planned transforms (FFTW.MEASURE plans) FFTW leads across sizes and dimensions — typically 1.5–2.4× for 1D and up to ~14× for large 2D Float64 grids — with vDSP reaching parity only for Float32 at the largest 1D sizes. For no-plan convenience calls, however, the picture changed with the FFT setup cache: AppleAccelerate.fft(x) reuses a cached setup after the first call at each size, and now beats FFTW's unplanned fft(x) at small sizes and wins or ties for Float32 at every size tested (see the last table). vDSP's FFT also remains useful to avoid an FFTW dependency or when Accelerate is already loaded. Source: bench_fft.jl.

Complex 1D FFT (pre-planned)

FFTW leads for 1D complex transforms, typically by 1.6–2.4×; vDSP reaches parity for Float32 at some large sizes:

Real FFT (pre-planned)

FFTW leads for real transforms too, though vDSP closes to near parity for Float32 at large sizes:

Complex 2D FFT (pre-planned)

FFTW is substantially faster for 2D complex transforms — up to ~14× for large Float64 grids — so prefer FFTW when 2D FFTs dominate:

Real 2D FFT (pre-planned)

The new 2D real FFT (rfft(A::Matrix)) follows the same pattern — FFTW leads by roughly 2–3.5× at moderate sizes, more for large Float64 grids:

Batched 1D FFT (columns of a matrix)

The new fft(A, 1) transforms each column via vDSP_fftm_*. FFTW's planned batched transforms lead by 2–4.4×:

No-plan fft(x) — cached setups

This table compares the convenience entry points: AppleAccelerate.fft(x) vs FFTW.fft(x), neither given a pre-built plan. AppleAccelerate reuses a cached vDSP setup after the first call at each size (FFTW builds an ESTIMATE plan per call), so for the common "just call fft" pattern vDSP now leads at small sizes and wins or ties for Float32 at every size tested: