Steel Bank Common Lisp versão 2.6.7

Artigo original ↗ Discussão no Hacker News ↗

Steel Bank Common Lisp 2.6.7 introduz recursos notáveis voltados para desempenho, como suporte ampliado a SIMD em ARM64 e AVX-512 em x86-64, levando a discussões técnicas sobre como operações vetoriais programadas explicitamente funcionam no SBCL. Os comentaristas avaliam a praticidade do Common Lisp hoje, contrastando seus pontos fortes — desenvolvimento interativo, implantação baseada em imagens, alto desempenho e uso em sistemas reais como o Hacker News — com lacunas percebidas no ecossistema, limitações de concorrência e sua reputação de linguagem de nicho ou “hobby”. A discussão também aborda detalhes de ferramentas e portabilidade, incluindo a maturidade do SBCL no Windows, recursos de alocação em arenas de memória e comparações com outros ecossistemas como Elixir, Clojure e workflows de imagens no estilo Smalltalk.

SIMD, AVX-512 e recursos de desempenho

  • A nova versão adiciona suporte de contrib SIMD para ARM64 e suporte a AVX-512 no backend x86-64.
  • SIMD é explícito, não auto-vetorizado: os usuários trabalham com tipos e operações SIMD (semelhantes a intrínsecos de C), que compilam para instruções específicas (por exemplo, adições e carregamentos vetoriais).
  • Padrões de exemplo: construir pacotes SIMD e iterar sobre arrays com acessores cientes de SIMD; o código compilado são loops apertados sobre instruções vetoriais.
  • O AVX-512 atualmente tem suporte no nível do compilador; os usuários finais precisariam definir VOPs personalizados para chamar instruções específicas de AVX-512 até que o sb-simd tenha bindings de nível mais alto.
  • Vários comentaristas estão entusiasmados com o novo suporte a ISA para projetos hobby de alto desempenho.

Onde o Common Lisp se encaixa (e onde não se encaixa)

  • Fortes encaixes sugeridos: ferramentas CLI/TUI e GUIs de desktop em que tempos de inicialização de dezenas de milissegundos são aceitáveis e o desenvolvimento interativo é valioso.
  • Serviços web são vistos como um encaixe mais fraco: implementações de CL geralmente oferecem apenas threads do sistema operacional e promises; a falta de concorrência leve de primeira classe torna backends do tipo “10k conexões” menos agradáveis em comparação com plataformas como Elixir/BEAM.
  • Motores de jogos e aplicações intensivas em computação são considerados plausíveis, especialmente com o desempenho do SBCL e seu bom FFI.
  • Alguns argumentam que CL é melhor como linguagem de extensão/incorporação (por exemplo, via ECL) e para ferramentas pessoais; outros relatam usá-la profissionalmente, inclusive em grandes empresas e domínios complexos.

Ecossistema, “Boring Tech” e o papel do Lisp

  • Uma visão: Lisp (e, de forma semelhante, Haskell) continua sendo em grande parte um nicho de hobbyistas; macros, reflexão e DSLs incentivam fragmentação e prejudicam a manutenibilidade em escala de equipe. Pilhas “simples e chatas” são preferidas no trabalho.
  • Visão contrária: o uso moderno de Lisp (Common Lisp, Clojure, Emacs Lisp etc.) é prático e difundido em certos nichos; macros são usadas com discernimento, e as equipes convergem para bibliotecas internas sem caos.
  • O debate gira em torno das compensações entre linguagens expressivas e altamente personalizáveis e ecossistemas padronizados e de baixa fricção.

Arenas de memória e controle de baixo nível

  • As arenas de memória do SBCL são mencionadas como poderosas, mas pouco documentadas: os usuários podem criar arenas e redirecionar alocações com funções/macros fornecidas.
  • São levantadas preocupações sobre a interação com GC, compartilhamento entre threads e o uso correto de destruição/rewind de arena para evitar vazamentos ou referências pendentes; é solicitada uma documentação oficial mais clara.

Implementação, portabilidade e ferramentas

  • O SBCL agora roda bem no Windows; outra implementação de CL é citada por compilar mais rápido, mas com menos otimização e manutenção mais fraca.
  • Múltiplas implementações são valorizadas por exporem problemas de portabilidade.
  • O SBCL pode gerar executáveis únicos com imagens embutidas; dependências dinâmicas de bibliotecas C continuam sendo uma consideração de implantação.
  • O SB-MANUAL (manual via docstrings e integração com editor) é destacado como uma melhoria de usabilidade.