PatentLLMThis is the second in a short series that benchmarks a single RTX 5090 by re-running published Go solvers — programs that don't just play Go but prove the outcome under perfect play. The first installment was GPU-bound. This one is the mirror image: the graphics card sits almost idle while the CPU does all the work. So this piece is really about a CPU — and one number on it in particular.
What's being solved
117 classic life-and-death puzzles from Cho Chikun's well-known encyclopedia. Each asks one yes/no question: under perfect play, does this group live or die? You don't need to read Go — what matters is that the solver proves the answer exhaustively rather than guessing a good move. Five-minute budget per problem.
I rebuilt the RZS-TT solver from Shih et al. (A Study of Solving Life-and-Death Problems in Go Using Relevance-Zone Based Solvers, IEEE Transactions on Games 2025; rlglab/study-LD-RZ) and ran the full set on one RTX 5090 + Core Ultra 9 285K, using the paper's own config and 5-minute limit. The paper's reference machine was a single GTX 1080Ti with a Xeon E5-2683 v3 — about a decade older on both the GPU and the CPU.
The GPU is a spectator
The network guiding this solver is tiny: 765,523 parameters, a 3.7 MB file. Across the entire ~11-hour run the RTX 5090 sat at about 23% utilization (measured; it never rose above ~27%). The GPU is not the bottleneck. The hot path is all on the CPU: expanding "relevance zones," matching Go-shape patterns, and — above all — pounding a transposition table, a giant hash of already-proven positions. That access pattern is random and pointer-chasing: latency-bound work whose speed is dictated by the cache hierarchy, not by FLOPS.
So when the solver proves more problems inside the same 5-minute budget, the honest question is not "what did the 5090 do?" — it's "what changed on the CPU in ten years?"
The numbers (with the caches lined up)
This run (Core Ultra 9 285K) Paper (Xeon E5-2683 v3)
Microarchitecture Arrow Lake / Lion Cove (2024) Haswell-EP (2014)
Search threads used 2 of 24 cores 2 of 14 cores
L2 cache PER CORE 3 MB 256 KB <-- ~12x
L1 data PER CORE 48 KB 32 KB
L3 cache (shared) 36 MB 35 MB (basically flat)
GPU utilization ~23% (idle, RTX 5090) -- (GTX 1080Ti)
Problems proven (RZS-TT) 84 / 117 (72%) 68 / 106 (64%)(The problem sets differ — 117 vs the paper's 106 — so compare the rate, 72% vs 64%.)
The case for L2
Look at which cache actually grew. The big shared L3 is essentially unchanged (35 → 36 MB). Clock and IPC rose too, of course. But the standout is private L2 per core: 256 KB → 3 MB, about 12× (measured on this machine via sysfs; the hypervisor flattens Arrow Lake's hybrid P/E layout, but each core the solver runs on presents a private 3 MB L2).
Why that matters for this workload: a life-and-death proof search spends its time chasing entries in a transposition table that churns constantly. On Haswell, two search threads shared just 512 KB of L2 between them, so the hot part of that table spilled out to L3 and DRAM almost immediately — every spill is a stall. On Arrow Lake, each of the two threads gets its own 3 MB of fast L2: roughly 6 MB of hot working set now living a cache level closer to the core. For latency-bound pointer-chasing, that is exactly the lever that turns "ran out of time at 5 minutes" into "proved it with seconds to spare." The fact that the shared L3 barely moved, while the private L2 grew 12×, is what points the finger specifically at L2 rather than at raw memory bandwidth.
To be clear, this is a hypothesis, not a measurement. The clean proof would be an L2 miss-rate comparison between the two machines — but hardware performance counters aren't exposed under WSL2, so I can't show cache-miss deltas here. What I can show is the access pattern (cache-latency-bound), the size contrast (12× L2, flat L3), and the outcome (more proofs in the same wall-clock budget). L2 is the leading suspect; higher clocks, a wider core, and DDR5 latency all contribute as well.
Either way, the headline framing has to be honest: this is a CPU-generation benchmark — Haswell 2014 to Arrow Lake 2024 — with the GPU nearly idle. Calling it "5090 vs 1080Ti" would be marketing, not measurement.
Same card, opposite bottleneck
This is why running both solvers on one machine is worth it. The killall-go solver used a bigger network and leaned GPU-bound, so there a clean per-worker GPU number fell out (~2× throughput). Same RTX 5090, opposite bottleneck. What a benchmark measures depends entirely on where the slow part is — and "I bought a 5090" tells you almost nothing until you know that.
Reproducibility and the frontier
Proof search is parallel and non-deterministic, so I ran the full set three times (two complete passes plus a single-threaded re-run of the borderline cases). 77 problems solved in both full passes; just 5 sit right at the 5-minute cliff and flip with the random seed. 33 problems went unproven in every run — the genuine frontier: 3 from volume 1, and 30 in volume 2's hardest section. Those need something smarter than raw compute.
What's next
A follow-up runs the pattern-table variant (RZS-PT) on the same machine. Only the algorithm changes — same CPU, same GPU, same problems — so it cleanly separates the hardware contribution from the algorithm contribution, completing a 2×2 matrix (old/new hardware × TT/PT algorithm) with no cross-machine confound.
Reproduction of rlglab/study-LD-RZ (Shih, Wu, Wei, Hsu, Guei, Wu — IEEE ToG 2025) — full credit to the original authors; this work only swaps the hardware underneath and measures the difference.