Steel Bank Common Lisp version 2.6.7
Steel Bank Common Lisp 2.6.7 introduces notable performance-oriented features such as expanded SIMD support on ARM64 and AVX-512 on x86-64, prompting technical exploration of how explicitly programmed vector operations work in SBCL. Commenters weigh the practicality of Common Lisp today, contrasting its strengths—interactive development, image-based deployment, high performance, and use in real systems like Hacker News—against perceived ecosystem gaps, concurrency limitations, and its reputation as a niche or “hobby” language. The thread also touches on tooling and portability details, including SBCL’s Windows maturity, memory arena allocation features, and comparisons with other ecosystems such as Elixir, Clojure, and Smalltalk-style image workflows.
SIMD, AVX-512, and Performance Features
- New release adds SIMD contrib support for ARM64 and AVX-512 support in the x86-64 backend.
- SIMD is explicit, not auto-vectorized: users work with SIMD types and operations (similar to C intrinsics), which compile to specific instructions (e.g., vector adds and loads).
- Example patterns: construct SIMD packs and loop over arrays with SIMD-aware accessors; compiled code is tight loops over vector instructions.
- AVX-512 is currently compiler-level support; end users would need to define custom VOPs to call specific AVX-512 instructions until sb-simd grows higher-level bindings.
- Several commenters are enthusiastic about the new ISA support for high-performance hobby projects.
Where Common Lisp Fits (and Doesn’t)
- Suggested strong fits: CLI/TUI tools and desktop GUIs where startup times of tens of milliseconds are acceptable and interactive development is valuable.
- Web services are seen as weaker fit: CL implementations generally offer only OS threads and promises; lack of first-class lightweight concurrency makes “10k connections” style backends less pleasant compared to platforms like Elixir/BEAM.
- Game engines and computation-heavy applications are considered plausible, especially with SBCL’s performance and good FFI.
- Some argue CL is best as an extension/embedded language (e.g., via ECL) and for personal tools; others report using CL professionally, including in large companies and complex domains.
Ecosystem, “Boring Tech”, and Lisp’s Role
- One view: Lisp (and similarly Haskell) remains mostly a hobbyist niche; macros, reflection, and DSLs encourage fragmentation and hurt team-scale maintainability. “Simple and boring” stacks are preferred at work.
- Counter-view: Modern Lisp usage (Common Lisp, Clojure, Emacs Lisp, etc.) is practical and widespread in certain niches; macros are used judiciously, and teams converge on internal libraries without chaos.
- Debate centers on tradeoffs between expressive, highly customizable languages and standardized, low-friction ecosystems.
Memory Arenas and Low-Level Control
- SBCL’s memory arenas are mentioned as powerful but under-documented: users can create arenas and redirect allocations with provided functions/macros.
- Concerns are raised about interaction with GC, cross-thread sharing, and correct use of arena destruction/rewind to avoid leaks or dangling references; clearer official documentation is requested.
Implementation, Portability, and Tooling
- SBCL now runs well on Windows; another CL implementation is noted for faster compilation but less optimization and weaker maintenance.
- Multiple implementations are valued to expose portability issues.
- SBCL can build single executables with embedded images; dynamic C library dependencies remain a deployment consideration.
- SB-MANUAL (manual via docstrings and editor integration) is highlighted as a usability improvement.