SIMD independente de plataforma em Go

Artigo original ↗ Discussão no Hacker News ↗

As novas APIs SIMD independentes de plataforma do Go pretendem tornar mais fáceis e portáveis as operações vetorizadas de baixo nível entre CPUs, reduzindo a necessidade de assembly escrito à mão ou de C/C++ para código crítico de desempenho. Os comentadores veem ganhos claros em projetos reais e acolhem o design em camadas que equilibra portabilidade com acesso a funcionalidades específicas da arquitetura, ao mesmo tempo que notam que a autovetorizaçao do compilador também está a melhorar em paralelo. O debate também revisita os compromissos do Go em torno de segurança de memória e data races, e como as suas funcionalidades de desempenho em evolução o posicionam ao lado de linguagens como Rust, C++, Java e Mojo para cargas de trabalho de alto desempenho como bases de dados, analytics e ML.

Recepção geral e primeiras experiências

  • Muitos comentadores estão entusiasmados: isto elimina uma necessidade antiga de recorrer a C/C++/assembly para código Go crítico de desempenho.
  • Alguns já relatam ganhos reais de velocidade (por exemplo, ~30% na estimativa de primeiro plano em imagens; ganhos mensuráveis na inferência de modelos de voz; ~5x versus escalar num demo de troca de paleta no browser, com SIMD portátil apenas ~11% mais lento do que SIMD específico da arquitetura).
  • É visto como especialmente benéfico para bases de dados, analytics e outras cargas de trabalho multicore, numéricas ou favoráveis a vetores.

SIMD vs autovetorizaçao

  • Alguns observam que, para muitas cargas de trabalho, a autovetorizaçao do compilador é “boa o suficiente” e lamentam que esta funcionalidade não resolva diretamente essa lacuna.
  • Outros apontam que há trabalho ativo na autovetorizaçao do compilador Go e que SIMD explícito e melhor autovetorizaçao são complementares.
  • Surge a sugestão de adicionar linters ou ferramentas que possam transformar automaticamente loops adequados em padrões SIMD.

Interop, assembly e desempenho

  • As queixas sobre o overhead de CGO mantêm-se: o modelo de memória e o modelo de concorrência do Go diferem do C, por isso atravessar a fronteira continua caro.
  • Uma minoria sugere usar assembly em Go em vez de CGO para caminhos críticos de desempenho; alguns projetos já fazem SIMD pesado em assembly Go.

Design da API e portabilidade

  • O design em camadas ( archsimd específico da arquitetura + simd portátil) é elogiado; as pessoas gostam de que o overhead de despacho seja empurrado para os chamadores via multi-versionamento no arranque.
  • Uma preocupação: o tamanho do código pode crescer porque funções que usam SIMD recebem múltiplas cópias especializadas; o impacto real em binários não é claro.
  • A abordagem é elogiada por ser mais amiga de ISAs de comprimento variável de vetores, como SVE e RISC-V RVV, ao evitar tamanhos fixos de vetores no sistema de tipos.

Segurança de memória e data races

  • Um grande subthread debate se Go é “memory safe” tendo em conta que data races em valores multibyte (slices, strings, interfaces) podem levar a tearing, acesso fora dos limites, panics e, em princípio, corrupção de memória.
  • Alguns argumentam que segurança de memória é um termo técnico de segurança; por essa definição comum, Go é memory safe exceto quando se usa unsafe ou há races.
  • Outros insistem que a possibilidade de corrupção de memória induzida por race significa que Go não é totalmente memory safe, especialmente em comparação com linguagens cujos modelos de memória excluem tal comportamento.

Comparações entre linguagens e filosofia

  • Go é comparado com Rust, Java, C#, D, Zig, Julia, Swift, C++ (incluindo std::simd), Mojo e SIMD de WebAssembly.
  • Os comentadores destacam a filosofia de design conservadora do Go, de “fazer menos coisas, mas fazê-las bem”, notando paralelos com o longo caminho até às generics.
  • Alguns sentem que Rust tem mais impulso, mas veem nichos estáveis para ambas as linguagens.

Miscelânea

  • Pequena digressão sobre a definição de “API”.
  • Várias pessoas lamentam a falta de realce de sintaxe na documentação oficial do Go; outras defendem realce mínimo ou inexistente.