SPEC CPU 2026 Benchmark Suite

• SPEC CPU 2026 is a next-generation performance benchmark suite that evaluates CPU architectures with enhanced relevance, reproducibility, and portability.
• It comprises 52 diverse component benchmarks grouped into INT and FP Rate/Speed workloads across applications like databases, compilers, and simulations.
• Performance analysis reveals increased instruction counts, higher cache pressure, and improved multithreaded scaling compared to CPU17, with a novel RRR mode for throughput testing.

Searching arXiv for the specified papers on SPEC CPU 2026 to ground the article in current literature. SPEC CPU 2026, often abbreviated CPU26, is the seventh major incarnation of SPEC’s industry-standard CPU performance suite and the first major evolution since SPEC CPU2017. It was designed to re-establish a general-purpose baseline for CPU evaluation in an environment where CPUs increasingly orchestrate AI accelerators, execute latency-sensitive control code, and sustain datacenter services, while specialized suites such as MLPerf Inference and DCPerf target narrower workload classes. Across 52 component benchmarks, CPU26 emphasizes relevance, reproducibility and correctness, portability and longevity, and richer microarchitectural diversity, including a standardized heterogeneous throughput mode called Rolling–Round–Robin Rate (RRR) (Madhav et al., 2 May 2026, Li et al., 5 May 2026).

1. Design objectives and development methodology

CPU26 was developed around three over-arching goals: relevance, reproducibility and correctness, and portability and longevity. Relevance was defined as the use of real, production applications covering a broad span of domains and microarchitectural behaviors. Reproducibility and correctness were enforced through strict determinism, result validation, and a harness that records detailed statistics. Portability and longevity were pursued through adherence to modern ISO language standards—C18, C++17, and Fortran 2018—together with warning-free code and support for diverse ISAs, endianness, and operating systems (Madhav et al., 2 May 2026).

The suite emerged from the three-year CPUv8 search program, which solicited open-source candidates from academia and industry. Of 33 submissions, 29 completed porting and had workloads defined; 24 of these ultimately joined the final suite, yielding 52 component benchmarks. Selection was governed by principled filters: determinism, portability, environmental isolation, user-space focus, and legal hygiene. Determinism required removal of heuristic or data-dependent stopping criteria; pseudo-random behavior was replaced with reproducible generators such as std::mt19937, and unstable algorithms such as std::sort were replaced with stable equivalents. Portability required excising platform-specific intrinsics and hand-tuned assembly in favor of standard ISO C/C++/Fortran constructs. Environmental isolation removed system calls beyond ubiquitous libc routines and reduced I/O through buffered streams, trimmed file footprints, and minimized write/flush system calls. User-space focus required over 95% of execution time to reside in benchmark code rather than the OS or instrumentation. Legal hygiene required exhaustive provenance and license review to ensure commercial redistributability (Madhav et al., 2 May 2026).

Validation of workload diversity used multiple, qualitatively distinct inputs per benchmark. The committee examined Basic Block Vector recurrence plots and PMC time-series on representative hardware to ensure that each sub-input exercised unique code paths and microarchitectural bottlenecks, including front-end versus back-end stalls and speculation penalties. Inputs with nearly identical BBV regions were pruned in favor of more diverse partners. Portability was further validated via continuous integration across x86-64, ARMv8, POWER, and RISC-V, and across Linux, Windows, macOS, and AIX. Code hardening used -Wpedantic, AddressSanitizer, ThreadSanitizer, and ARM MTE; endian-dependent I/O formats and pointer-casting assumptions were refactored for POWER/AIX; and MinGW/MSVC porting exposed data-model and path-handling errors, including an astrodynamics formula error in JSBSim that was fixed upstream (Madhav et al., 2 May 2026).

2. Suite composition and application coverage

CPU26 expands from 43 to 52 binaries, organized into four benchmark groups: 14 INT Rate workloads, 13 INT Speed workloads, 12 FP Rate workloads, and 13 FP Speed workloads. Relative to CPU17, it introduces 29 new programs—16 in Integer and 13 in Floating-Point—while retiring only a handful of longstanding CPU17 components such as mcf and leela (Li et al., 5 May 2026).

Group	Workloads
INT Rate	14
INT Speed	13
FP Rate	12
FP Speed	13

The workload mix spans games, databases, network simulation, language runtimes, compilers, static analysis, EDA, data compression, cryptography, graph analytics, bioinformatics, physics, climate, ocean modeling, fluid dynamics, neural simulation, and NLP. Concrete examples named in the two papers include chess and Othello engines, SQLite, OMNeT++, CPython, GCC, LLVM, VPR, ABC, xz, zstd, SEALCrypto, NEST, and Marian, as well as open-source parent applications such as Stockfish (706), SQLite (708), gem5 (735), Gmsh (737), JSBSim FlightDM (748), NEST (767), and Graph500 (854) (Li et al., 5 May 2026, Madhav et al., 2 May 2026).

This breadth is paired with an expanded multithreaded set. Of the 52 benchmarks, 22 SPECspeed programs use threads or processes. The integer-domain multithreaded set includes 801.xz, 807.ntest, 817.flac, 821.gcc, 823.llvm, 827.cppcheck, 854.graph500, and 846.minizinc; the floating-point set includes 800.pot3d, 803.sph_exa, 809.cactus, 811.tealeaf, 816.nab, 820.cloverleaf, 822.palm, 849.fotonik3d, 857.namd, 865.roms, 867.nest, 872.marian, and 881.neutron. These programs range from high-IPC, back-end-bound kernels such as 809.cactus to front-end and instruction-delivery-limited workloads such as 827.cppcheck and 753.ns3, to memory-latency-sensitive graph analytics such as 854.graph500 and branchy codecs such as 817.flac (Madhav et al., 2 May 2026).

3. Microarchitectural characterization

A central result of CPU26’s characterization is that it shifts stress toward contemporary CPU bottlenecks. Across nine real servers from Intel, AMD, Ampere, and NVIDIA, covering both x86_64 and AArch64, the suite exhibits larger dynamic instruction counts, larger memory footprints, and substantially higher instruction-cache pressure than CPU17. IPC is defined as

$$\mathrm{IPC}=\frac{\text{Total Instructions Retired}}{\text{Total Cycles}}.$$

Relative to CPU17, CPU26 increases dynamic instruction counts by $1.22\times$ for INT Rate, $1.15\times$ for FP Rate, $17.86\times$ for INT Speed, and $2.67\times$ for FP Speed. The Rate workloads also increase working-set size: median RSS rises to approximately $1.4$ GB from approximately $0.8$ GB, and the maximum rises to approximately $2.2$ GB from $1.7$ GB (Li et al., 5 May 2026).

The most pronounced shift is in the front end. L1I$MPKI rises by \(5.9\times\) in INT Rate and \(3.3\times\) in FP Rate relative to CPU17. At the same time, L3$ MPKI falls by $1.22\times$0 and branch MPKI by approximately $1.22\times$1 in INT Rate, reflecting removal of extreme outliers such as mcf. L1D$MPKI grows only modestly, by approximately$1.22\times$2 in Integer and $1.22\times$3 in Floating-Point. Translation behavior also becomes more demanding: L1-dTLB MPMI increases by $1.22\times$4 in Integer and $1.22\times$5 in Floating-Point, while L1-iTLB MPMI increases by $1.22\times$6 and $1.22\times$7, respectively, though still below DCPerf’s deep-footprint levels (Li et al., 5 May 2026).

The complementary characterization in the suite-design paper emphasizes the spread of behavioral modes within the benchmark set. PMC characterization on an AMD EPYC 9755 shows retiring fractions from 20% to 60%, front-end stalls from 5% to 55%, back-end stalls from 20% to 65%, and speculation losses up to 15%. Taken together, these results indicate that CPU26 is not narrowly tuned to a single bottleneck. Rather, it combines higher front-end stress and larger instruction footprints with a balanced instruction mix across compute, memory, and control-flow behavior (Madhav et al., 2 May 2026).

4. Representativeness and compact subsets

One of the more consequential findings about CPU26 is that the full suite is not always necessary for architectural evaluation. Representativeness was studied with a three-stage pipeline: hardware-counter metrics across 9 machines, totaling 171 dimensions from 19 counters on each platform, were normalized to zero mean and unit variance; Principal Component Analysis was then used to capture at least 90% of variance in a low-dimensional subspace; hierarchical agglomerative clustering was then performed in PCA space, where shorter linkage distances imply higher behavioral similarity. For each of the four CPU26 groups, the analysis produced 4–5 clusters, and the medoid of each cluster—the workload minimizing the sum of distances to all other members—was selected as the representative (Li et al., 5 May 2026).

Subset fidelity was measured through the geometric-mean SPEC score, denoted $1.22\times$8, with error and accuracy defined as

$1.22\times$9

Using this criterion, 4–5 representatives per group recover 96.4%–99.9% of full-suite behavior: 99.90% for INT Rate, 99.07% for FP Rate, 96.61% for INT Speed, and 96.40% for FP Speed. The associated reduction in evaluation time is approximately 80% (Li et al., 5 May 2026).

This result directly addresses a common assumption in benchmarking practice: that fidelity necessarily requires the entire suite on every evaluation pass. The reported data instead support a two-level methodology in which compact medoid subsets are used for rapid design-space exploration or simulator studies, while the full suite remains available for final validation and aggregate scoring. The papers present this not as a replacement for the complete suite, but as a cost-effective reduction that preserves suite-level behavior with minimal coverage loss.

5. Position relative to CPU2017, MLPerf, and DCPerf

Cross-suite comparison situates CPU26 between earlier general-purpose SPEC generations and specialized modern benchmark suites. Using PCA and dendrogram analysis over compute intensity, vector share, cache MPKI, branch MPKI, TLB MPMI, and front-end/back-end stall cycles, the characterization paper finds that CPU26 removes extreme outliers from CPU17, yields more concentrated suite-level behavior, and shifts the centroid toward higher front-end pressure. In this sense it remains a general-purpose suite while moving closer to contemporary service-like CPU behavior than prior SPEC CPU generations (Li et al., 5 May 2026).

Quantitatively, the Rate suites illustrate this middle position. Compute intensity, defined as non-load/store/branch instructions, is 43.21% for CPU26 INT Rate, versus 39.71% for CPU17 and 42.51% for DCPerf. For FP Rate, vector intensity is approximately 29.97% in MLPerf, approximately 7.5% in CPU26, and approximately 5% in DCPerf, showing that CPU26 is substantially less SIMD-heavy than MLPerf. For INT Rate, L1I$$MPKI is 6.2 in CPU26, 1.05 in CPU17, and approximately 12 in DCPerf. CPU26 therefore falls between earlier general-purpose behavior and service workloads with extreme front-end stress (<a href="/papers/2605.03713" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Li et al., 5 May 2026</a>).</p> <p>This comparison is important because CPU26 is not presented as a substitute for domain-specific benchmarking. MLPerf remains the vector/FP outlier, with higher L2/L3 and <a href="https://www.emergentmind.com/topics/distributionally-robust-adaptive-mechanism-dram" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">DRAM</a> bandwidth demands. DCPerf remains the suite with extreme L1I$$ MPKI and front-end stalls in workloads such as tao and django. CPU26 instead covers what the characterization paper describes as the “middle” of general computing: broader than domain-specific suites, more representative of current CPU bottlenecks than CPU17, but still distinct from service and inference extremes (Li et al., 5 May 2026).

6. Evaluation modes, system studies, and throughput semantics

CPU26 supports architectural study beyond aggregate scores. The characterization paper reports page-size and allocator experiments in which replacing glibc’s malloc with mimalloc or tcmalloc on an x86_64 platform with 4 KB pages yields CPU26 Rate speedups of 8.1%–12.7%, compared with 13.7%–20.9% for CPU17. The main mechanism is reduced L1 iTLB and dTLB misses, at $1.15\times$0 and $1.15\times$1, respectively. On a 64 KB-base-page AArch64 system, the allocator and transparent huge page effects shrink to $1.15\times$2 on average, suggesting that larger base page sizes already mitigate translation overhead but may expose fragmentation costs. Hardware prefetching on Intel Ice Lake improves geometric-mean IPC by $1.15\times$3 for CPU17, $1.15\times$4 for CPU26, and $1.15\times$5 for DCPerf, with L2 prefetchers giving more uplift than L1. Compiler evolution also shows stronger sensitivity in CPU26: comparing gcc-13, gcc-14, and gcc-15, CPU26 INT Rate gains $1.15\times$6 from gcc-15 versus gcc-13, driven primarily by a 17.7% reduction in dynamic instruction count despite a slight $1.15\times$7 IPC change (Li et al., 5 May 2026).

The suite also broadens sensitivity to ISA and scaling studies. Retired-instruction counts across nine machines vary by $1.15\times$8–$1.15\times$9 with $17.86\times$0 on CPU17, but by $17.86\times$1–$17.86\times$2 with $17.86\times$3 on CPU26 INT Rate, indicating broader ISA-level coverage. In many-core scaling, CPU26 doubles the number of multithreaded Speed workloads from 11 in CPU17 to 22. When sweeping from 1 to 40 threads on a 40-core monolithic chip and a $17.86\times$4-core chiplet design, CPU26 attains geometric-mean normalized Speed scores of $17.86\times$5 and $17.86\times$6 at 40 threads, versus $17.86\times$7 and $17.86\times$8 for CPU17, and it sustains higher headroom from 32 to 40 threads (Li et al., 5 May 2026).

The most novel execution mode is Rolling–Round–Robin Rate. In classic SPECrate, $17.86\times$9 copies of the same benchmark execute in parallel. In RRR, $2.67\times$0 parallel slots each run the full suite of $2.67\times$1 benchmarks in a rotating schedule so that each slot executes every benchmark exactly once. If $2.67\times$2 is the time to run benchmark $2.67\times$3 in isolation, and the schedule offset is $2.67\times$4, then slot $2.67\times$5 executes benchmarks in the order $2.67\times$6, for $2.67\times$7, with total runtime

$2.67\times$8

Let $2.67\times$9. The throughput rate is then

$1.4$0

This methodology standardizes heterogeneous, multiprogrammed throughput benchmarking while exposing real cross-benchmark contention in cache sharing, TLB pressure, and front-end bandwidth (Madhav et al., 2 May 2026).

A concrete RRR case study combines 709.cactus_r, which has high L1I$1.4$1 MPKI. The resulting proxy exhibits L1I$1.4$2 MPKI of approximately 2.64, and IPC of approximately 1.16. DCPerf’s django and tao exhibit L1I$$MPKI of approximately 39.7 and 45.1, and the proxy’s IPC falls within 13.7<h2 class='paper-heading' id='role-in-contemporary-cpu-evaluation'>7. Role in contemporary CPU evaluation</h2> <p>CPU26’s stated role is to provide a stronger general-purpose baseline for CPU architecture research and product evaluation than CPU17, without collapsing the distinction between general-purpose benchmarking and domain-specific suites. Its increased instruction volume, larger working sets, higher L1I$$ stress, broader multithreaded coverage, and sensitivity to compiler, allocator, prefetch, ISA, and scaling effects make it suitable for both aggregate benchmarking and detailed microarchitectural study (Li et al., 5 May 2026).

At the same time, the papers consistently frame CPU26 as complementary rather than exhaustive. CPU26 covers a broad middle ground of modern software behavior; MLPerf continues to stress vector/FP throughput and high bandwidth demand; DCPerf continues to stress front-end limits and deep instruction footprints. Within CPU26 itself, compact subsets can preserve 96.4%–99.9% of full-suite behavior, and RRR supplies a standardized mechanism for heterogeneous throughput experiments. In that combination of broad workload coverage, principled construction, internal representativeness, and flexible execution modes lies the suite’s primary significance for contemporary CPU evaluation (Madhav et al., 2 May 2026, Li et al., 5 May 2026).