Levantamento mostra ecossistema de SIMD em Rust mais maduro, porém fragmentado em 2026

Um levantamento independente sobre o estado do SIMD em Rust↳Rust7 conteúdosDesmistificando Rust: a linguagem segura e rápida que você precisa conhecerDev (Back & Front) · out 2024Como criar seu primeiro Programa em Rust com Solana PlaygroundDev (Back & Front) · mai 2026Rust no ranking: a segurança de memória perdeu a guerra corporativa?Marketing Tech · abr 2026Ver tudo em Dev (Back & Front) → em 2026 compara cinco bibliotecas de vetorização e mostra o que muda para quem precisa de performance em bancos de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, buscas vetoriais e inferência de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →.

O gargalo que o SIMD resolve

Todo processador atual carrega muito mais capacidade de fazer contas do que consegue usar, porque decodificar instruções é o gargalo, não a aritmética em si. A saída é alimentar o processador com um lote de números de uma vez só, numa única instrução: em vez de somar dois números, soma-se dois vetores inteiros.

É essa técnica de single instruction, multiple data que dá nome ao SIMD, e é o motor por trás de bancos de dados vetoriais, mecanismos de busca por similaridade e boa parte do código de inferência de modelos de IA rodando em CPU, segundo o levantamento de Sergey "Shnatsel" Davidoff sobre o estado do SIMD em Rust em 2026 (https://shnatsel.github.io/state-of-simd-rust-2026/).

Em teoria, um processador x86 recente com vetores de 512 bits pode entregar até 8x de ganho em cálculos com f64 ou 64x com u8. Na prática, segundo o autor, o resultado pode rodar tanto mais lento quanto mais rápido, dependendo de como o código é escrito e de qual hardware realmente executa o binário.

O problema que só existe em x86

Cada arquitetura batizou sua extensão SIMD com um nome de marketing próprio: a ARM chama a dela de NEON e torna obrigatória em toda CPU de 64 bits; o WebAssembly não tem departamento de marketing e chama a dela de "WebAssembly 128-bit packed SIMD extension". Já o x86_64 empilhou extensões ao longo dos anos: SSE2 veio de fábrica, SSE4.2 acrescentou operações, AVX e AVX2 trouxeram vetores de 256 bits, e o AVX-512 foi além com 512 bits.

O problema é que nem toda CPU x86_64 em produção tem AVX2 ou AVX-512, então o compilador Rust, por padrão, só pode assumir SSE2. Times que controlam o próprio hardware, como quem roda cluster próprio ou usa só uma nuvem específica, podem forçar um patamar mínimo:

RUSTFLAGS='-C target-cpu=x86-64-v3' cargo build --release

Quem distribui binário para terceiros não tem essa opção e precisa recorrer ao "function multiversioning": compilar a mesma função várias vezes, uma por extensão de CPU, e escolher a versão certa em tempo de execução. ARM e WebAssembly não sofrem com isso: NEON é garantido em toda CPU ARM de 64 bits, e o WebAssembly resolve compilando dois binários e deixando o JavaScript decidir qual carregar.

Três formas de vetorizar em Rust

O levantamento organiza o ecossistema em três caminhos, do mais simples ao mais granular:

• Autovetorização: escrever Rust comum e deixar o compilador decidir. Mais fácil, mas frágil: funções grandes ou complexas raramente são vetorizadas de forma confiável, e o resultado muda entre versões do compilador.
• Abstrações portáveis de SIMD: tipos como i32x4 que somam com + normal, escondendo os intrínsecos por trás de uma API genérica.
• Intrínsecos específicos de plataforma: chamar diretamente instruções como _mm256_add_ps (x86) ou vaddq_u32 (ARM), com controle total e verbosidade máxima.

Ponto que muda o jogo para quem lida com f32/f64: o Rust 1.98 estabilizou operações algébricas como algebraic_add(), que permitem ao compilador alterar a precisão do resultado de forma controlada, algo parecido com a flag -ffast-math, porém mais seguro. Antes disso, autovetorização em ponto flutuante simplesmente não acontecia, porque o compilador não podia mudar o resultado observável de uma soma.

O tabuleiro das bibliotecas portáveis

Nenhuma abstração cobre tudo sozinha hoje. O levantamento compara cinco crates de SIMD portável usadas em produção: std::simd (nightly), fearless_simd, wide, pulp e macerator.

std::simd continua restrito ao nightly e sofre quebras de API ocasionais, o que pesa para quem precisa de builds estáveis em produção. Já wide, apesar de madura e com boa cobertura de plataformas, não compõe bem com multiversioning fora de hardware fixo, o que limita seu uso em software distribuído para terceiros.

fearless_simd: a crate que virou padrão de fato

O autor do levantamento se tornou mantenedor do fearless_simd depois de contribuir para o projeto ao longo do último ano, e a crate atingiu a versão 1.0, já com política de segurança formal documentada. A promessa central é resolver o multiversioning sem custo de boilerplate: basta anotar a função com #[simd] e o dispatch para a extensão de CPU correta acontece automaticamente, inclusive em funções pequenas, onde outras abordagens sofrem com overhead de chamada.

A crate também evita usar AVX-512 em CPUs onde essa extensão só piora o desempenho, um comportamento que outras bibliotecas não replicam por padrão. O ponto fraco reconhecido é trigonometria: ainda não existe porte de algo como o SLEEF para as rotinas do fearless_simd, então quem precisa de seno e cosseno vetorizados com boa precisão segue dependendo de outras soluções.

Nota da redação: os trechos de código desta reportagem reproduzem exemplos do levantamento original e não foram executados em ambiente próprio. Valide antes de usar em produção.

Para acesso seguro a intrínsecos específicos, o Rust 1.87 passou a permitir chamar intrínsecos de plataforma sem bloco unsafe na assinatura da função, desde que ela esteja anotada com #[target_feature(enable = "avx2")]:

#[target_feature(enable = "avx2")]
fn add_avx2(a: __m256, b: __m256) -> __m256 {
    _mm256_add_ps(a, b)
}

Ainda assim, chamar essa função de fora exige um bloco unsafe, a menos que se use um token de tipo que comprove em tempo de compilação que a checagem de feature da CPU já foi feita. Crates como archmage e o macro kernel! do próprio fearless_simd resolvem esse problema de formas distintas.

O autor foi direto ao justificar por que deixou de fora bibliotecas com desenvolvimento majoritariamente guiado por IA generativa:

Também estou excluindo crates cujo desenvolvimento é majoritariamente guiado por IA (como magetypes, simdeez e thermite) porque não posso recomendá-las para uso em produção, especialmente porque as duas últimas são preocupantemente cheias de bugs.

I'm also excluding crates whose development is primarily AI-driven (e.g. magetypes, simdeez, thermite) because I cannot recommend them for production use, especially since the latter two are disconcertingly buggy.Sergey "Shnatsel" Davidoff, mantenedor do fearless_simd

O que muda pra quem constrói no Brasil

Bancos vetoriais, mecanismos de busca semântica e pipelines de inferência local de modelos de IA em CPU são os casos de uso mais diretos do SIMD hoje, e times brasileiros que rodam esse tipo de carga em cloud própria ou em servidores dedicados agora têm mais de uma opção madura além de escrever intrínsecos à mão. Para quem controla o hardware de produção, comum em empresas com cluster próprio ou contrato fechado com uma única cloud, fixar -C target-cpu=x86-64-v3 no build já garante AVX2 sem multiversioning algum.

Para quem distribui binário para clientes com hardware variado, caso típico de ferramentas de linha de comando ou SDKs, fearless_simd reduz o atrito porque o multiversioning é configurável por quem monta o binário final, sem exigir reescrever a biblioteca. Bibliotecas de álgebra linear que já dependem de pulp, como o faer, seguem sendo opção sólida para quem já está no ecossistema de computação numérica em Rust.

O que ainda falta

Trigonometria vetorizada com boa precisão continua sendo o ponto fraco de praticamente todo o ecossistema: o levantamento aponta a crate sleef como a melhor opção disponível, mas ela não se integra com a crate multiversion, exigindo que quem precisa das duas coisas faça um fork manual para juntá-las. AVX-512 também segue como terreno delicado: bibliotecas como wide, pulp e macerator apenas checam se a extensão existe, sem verificar se ela realmente compensa no hardware específico, o que pode derrubar performance em vez de melhorá-la.

Isso deixa em aberto o cenário para quem quer boa cobertura de operações matemáticas e dispatch automático seguro ao mesmo tempo, sem abrir mão de nenhum dos dois.

Fonte

Sergey "Shnatsel" Davidoff, "The state of SIMD in Rust in 2026" (https://shnatsel.github.io/state-of-simd-rust-2026/).

Fonte: Hacker News