SBCL 2.6.7 Brings AVX-512 and ARM64 SIMD to Lisp

If you want to understand why Common Lisp refuses to die, don't read a manifesto — read a changelog. SBCL 2.6.7 shipped on July 28, right on schedule, because SBCL has shipped essentially every month for two decades (the version number encodes it: 2.6.x means 2026). This one is worth a closer look than most, because it touches the two things that decide whether a 26-year-old compiler stays relevant: modern silicon and developer ergonomics.

Lisp finally meets the vector units you actually own

The headline items are in SIMD land. The sb-simd contrib — Marco Heisig's sb-simd library, which was folded into the SBCL distribution proper — now supports ARM64, and the x86-64 backend gains AVX-512 instructions, alongside a batch of additional SIMD instructions on both architectures.

Read those two changes against the hardware market and they're more pragmatic than they sound. ARM64 support means sb-simd now works where a large share of Lisp development actually happens in 2026: on Apple Silicon laptops, plus Graviton and Ampere instances on the server side. Until now, writing explicit SIMD kernels in Lisp meant x86-only code — awkward when your dev machine is an M-series Mac and NEON has been sitting there unused. And AVX-512, after Intel's messy retreat from it on consumer chips, has quietly become an AMD story: Zen 4 and Zen 5 run it well, and that's an increasingly common shape for the servers where numeric Lisp code — the Petalisp lineage, image processing, quant work — actually runs.

The compiler team is dogfooding this, too. The same release ships SIMD-accelerated UTF-8 conversion routines, continuing work from 2.6.6's faster UTF-8 encoding and decoding. That's the right pattern: the vector API is being hardened against a real, boring, universally-hit workload (every string crossing the FFI boundary), not just showcase kernels.

The honest caveat: sb-simd is still an explicit-intrinsics interface, closer to writing C with Intel intrinsics than to auto-vectorization. SBCL's compiler won't turn your idiomatic map into AVX-512 on its own. If you need throughput, you opt in, declare your types, and write the kernel. That's a fair trade — it's the same deal Rust's std::arch or .NET's Vector<T> offer — but nobody should read "AVX-512 support" as free speed for existing code.

The manual moves into the image

The other notable addition is a new contrib, SB-MANUAL, which packs the SBCL manual into docstrings on section definitions so you can browse it from inside a running image, integrated with Gábor Melis's MGL-PAX documentation system. Relatedly, DOCUMENTATION now accepts the DECLARATION doc-type.

It's easy to shrug at documentation plumbing, but this is Lisp playing to its actual strength. The workflow that keeps people on Common Lisp isn't macros — it's the live image: you sit in SLIME or Sly, inspect anything, redefine anything, and ask the system about itself. Docs that live in a browser tab were always a break in that loop. With the manual reachable through the same docstring machinery as everything else, "how does this SBCL extension work" becomes an in-editor lookup instead of a context switch. PAX users get the stronger version: the manual becomes linkable, browsable structure, not prose trapped in HTML. Most languages are currently trying to bolt this experience on with LSP hover docs; CL had the substrate all along and is now filling it in.

The boring middle of the changelog is the point

The rest of 2.6.7 is unglamorous in the way you want a compiler release to be: a fixed MULTIPLE-VALUE-CALL miscompilation, a fixed SAP-REF-N miscompilation on ARM64 (note: found and fixed as the ARM64 surface area grows — ports shake out bugs), better NaN handling in LOG, (EQL <complex>) types now handled properly by the type system, and small codegen wins like non-consing constant complex arguments to local functions and tighter code for SB-ALIEN:DEREF.

Individually, none of this matters to you. Cumulatively, it's the whole story. SBCL's monthly cadence means fixes land in weeks, regressions get caught against a small diff, and there's no big-bang release to fear. Compare that with the other side of the CL world — implementations like LispWorks and Allegro on yearly-or-slower commercial cycles, or ABCL and ECL with far less compiler investment — and the conclusion is hard to avoid: SBCL isn't just the default free Common Lisp, it's the implementation carrying the language's production credibility more or less alone. The Hacker News thread for this release predictably relitigated whether Lisp is viable at work; the practitioners in that thread running CL in fintech and at big tech shops are, almost without exception, running it on SBCL.

What to do with this

If you're on SBCL already, take the upgrade — miscompilation fixes alone justify it, and the monthly deltas are small enough that upgrades are routine. Build from source (sh make.sh remains refreshingly self-contained), or use Roswell to pin versions per-project; your distro's package will lag by months, which for SBCL's cadence means meaningfully stale. Then run your test suite: type-inference and transform changes occasionally surface latent bugs in your code that older SBCLs let slide.

If you're doing numeric work on Apple Silicon or AMD servers, sb-simd just became worth a serious look — with the caveat that documentation for the newer corners is thin, a complaint that surfaced immediately in the HN discussion. Expect to read the contrib's source.

And if you're not a Lisper at all, the takeaway is about maintenance models. SBCL gets AVX-512 and ARM64 SIMD in the same year they matter commercially, from a volunteer team a fraction the size of any corporate compiler group, because small monthly releases compound. It's the least fashionable release engineering imaginable, and it's why this particular dinosaur keeps outliving predictions of its extinction.