Steel Bank Common Lisp versión 2.6.7

Artículo original ↗ Discusión en Hacker News ↗

Steel Bank Common Lisp 2.6.7 introduce funciones destacables orientadas al rendimiento, como compatibilidad SIMD ampliada en ARM64 y AVX-512 en x86-64, lo que impulsa una exploración técnica sobre cómo funcionan en SBCL las operaciones vectoriales programadas explícitamente. Los comentaristas evalúan la utilidad de Common Lisp hoy, contraponiendo sus fortalezas —desarrollo interactivo, despliegue basado en imágenes, alto rendimiento y uso en sistemas reales como Hacker News— frente a carencias percibidas del ecosistema, limitaciones de concurrencia y su reputación como lenguaje de nicho o de “hobby”. El hilo también aborda detalles de herramientas y portabilidad, incluida la madurez de SBCL en Windows, las funciones de asignación en arenas de memoria y comparaciones con otros ecosistemas como Elixir, Clojure y flujos de trabajo estilo Smalltalk basados en imágenes.

SIMD, AVX-512 y funciones de rendimiento

  • La nueva versión añade compatibilidad con contrib de SIMD para ARM64 y compatibilidad con AVX-512 en el backend de x86-64.
  • SIMD es explícito, no se vectoriza automáticamente: los usuarios trabajan con tipos y operaciones SIMD (similares a las intrínsecas de C), que se compilan en instrucciones específicas (p. ej., sumas y cargas vectoriales).
  • Patrones de ejemplo: construir paquetes SIMD y recorrer matrices con accesores conscientes de SIMD; el código compilado son bucles ajustados sobre instrucciones vectoriales.
  • AVX-512 es actualmente compatibilidad a nivel de compilador; los usuarios finales tendrían que definir VOPs personalizados para invocar instrucciones AVX-512 específicas hasta que sb-simd amplíe los enlaces de nivel superior.
  • Varios comentaristas se muestran entusiasmados con la nueva compatibilidad con ISA para proyectos hobby de alto rendimiento.

Dónde encaja Common Lisp (y dónde no)

  • Encajes fuertes sugeridos: herramientas CLI/TUI y GUIs de escritorio donde tiempos de arranque de decenas de milisegundos son aceptables y el desarrollo interactivo es valioso.
  • Los servicios web se consideran un encaje más débil: las implementaciones de CL suelen ofrecer solo hilos del sistema operativo y promesas; la falta de concurrencia ligera de primera clase hace menos agradable el estilo de backend de “10k conexiones” en comparación con plataformas como Elixir/BEAM.
  • Los motores de juegos y las aplicaciones intensivas en cómputo se consideran plausibles, especialmente por el rendimiento de SBCL y su buen FFI.
  • Algunos argumentan que CL es mejor como lenguaje de extensión/embebido (p. ej., mediante ECL) y para herramientas personales; otros informan usar CL profesionalmente, incluso en grandes empresas y dominios complejos.

Ecosistema, “tecnología aburrida” y el papel de Lisp

  • Una opinión: Lisp (y de forma similar Haskell) sigue siendo en gran medida un nicho de aficionados; las macros, la reflexión y los DSL fomentan la fragmentación y perjudican la mantenibilidad a escala de equipo. En el trabajo se prefieren stacks “simples y aburridos”.
  • Contraopinión: el uso moderno de Lisp (Common Lisp, Clojure, Emacs Lisp, etc.) es práctico y está muy extendido en ciertos nichos; las macros se usan con criterio, y los equipos convergen en bibliotecas internas sin caos.
  • El debate se centra en las compensaciones entre lenguajes expresivos y altamente personalizables frente a ecosistemas estandarizados y de baja fricción.

Arenas de memoria y control de bajo nivel

  • Se mencionan las arenas de memoria de SBCL como potentes pero poco documentadas: los usuarios pueden crear arenas y redirigir asignaciones con las funciones/macros proporcionadas.
  • Se plantean preocupaciones sobre la interacción con GC, el compartido entre hilos y el uso correcto de la destrucción/rewind de arenas para evitar fugas o referencias colgantes; se pide una documentación oficial más clara.

Implementación, portabilidad y herramientas

  • SBCL ahora funciona bien en Windows; se menciona otra implementación de CL por compilar más rápido pero con menos optimización y mantenimiento más débil.
  • Se valoran múltiples implementaciones para poner de manifiesto problemas de portabilidad.
  • SBCL puede construir ejecutables únicos con imágenes incrustadas; las dependencias dinámicas de bibliotecas C siguen siendo una consideración de despliegue.
  • SB-MANUAL (manual mediante docstrings e integración con el editor) se destaca como una mejora de usabilidad.