« Todos Deveriam Conhecer SIMD »: o lembrete de Mitchell Hashimoto sobre a única otimização que ainda importa

Mitchell Hashimoto (fundador da HashiCorp) escreve um ensaio que apresenta uma tese simples: na era dos CPUs de núcleos largos, não conhecer o SIMD é deixar 4× a 16× de desempenho na mesa.

O Cas Concreto

Mitchell Hashimoto — o cofundador da HashiCorp que se tornou um contribuidor individual prolífico (hoje trabalha no Ghostty, seu emulador de terminal em Zig) — publicou um longo artigo intitulado simplesmente Everyone Should Know SIMD. A tese se resume em uma frase: em um mundo onde os CPUs estagnam em frequência, mas aumentam em registradores vetoriais, ignorar o SIMD é deixar escapar ordens de grandeza de desempenho.

SIMD (Single Instruction, Multiple Data) refere-se às instruções de CPU que aplicam a mesma operação a vários valores simultaneamente — somar oito float em um único ciclo, comparar dezesseis bytes de uma vez. Nos CPUs x86-64 modernos, são os conjuntos de instruções SSE / AVX / AVX2 / AVX-512. No ARM (Apple Silicon, servidores Neoverse), são NEON e SVE.

Por baixo do capô: por que o assunto ressurge

O debate não é novo — o SIMD existe desde o MMX (1996). O que mudou:

1. A largura dos registradores: 128 bits (SSE, NEON) → 256 bits (AVX2) → 512 bits (AVX-512). Um registrador AVX-512 comporta 16 float32 ou 64 int8.
2. A disponibilidade: AVX2 está presente em todos os CPUs x86 de consumo desde o Haswell (2013). NEON é padrão em todos os ARMv8 (iPhone 5S e posteriores, todos os servidores ARM).
3. A frequência do CPU atinge um teto: os ganhos “grátis” de uma geração para outra diminuem. A vetorização, por outro lado, continua valendo.
4. Os auto-vetorizadores têm limites: compiladores (LLVM, GCC) vetorizam bem loops simples, mas falham frequentemente quando há um desvio, um pointer chasing, uma acumulação específica. O programador precisa intervir manualmente.

O que Hashimoto diz

A mensagem central: o SIMD não é exclusivo de codificadores de motores gráficos ou codecs de vídeo. Qualquer manipulação de dados em massa — parsers JSON, mecanismos de busca de texto completo, comparações de strings, cálculos estatísticos, filtros de imagem, hashes — se beneficia massivamente de uma passagem para o vetorial.

Casos de uso tangíveis:

• simdjson faz parsing de JSON a 3-5 GB/s em um CPU recente, em grande parte graças ao SIMD.
• Os mecanismos de ordenação VqSort (Google) e ips4o usam SIMD para superar std::sort em um fator de 3-5 em arrays de inteiros.
• Os DBs colunares (ClickHouse, DuckDB) são construídos em torno de kernels SIMD.
• O parsing de Protobuf e UTF-8 pode ser vetorizado para um ganho semelhante.

Em outras palavras: não é mais uma área de nicho, é uma competência básica para tudo que diz respeito a desempenho em volume.

Como começar sem se afogar

O SIMD manual é conhecido por ser trabalhoso: intrinsics ilegíveis, portabilidade frágil entre x86 e ARM. Três abordagens viáveis hoje:

1. Highway (Google): biblioteca C++ que abstrai SSE/AVX/NEON/SVE por trás de uma API comum, com dispatch em tempo de execução conforme o CPU.
2. std::simd (proposto para C++26): na STL, portátil, mas ainda experimental.
3. SIMD portátil em Rust / Zig: as duas linguagens oferecem APIs vetoriais portáteis (core::simd no Rust nightly, @Vector builtin no Zig).

Para um desenvolvedor aplicativo “padrão”, a entrada por uma biblioteca portátil (Highway, std::simd, @Vector) evita mergulhar nos intrinsics de baixo nível, mantendo a essência do ganho.

Nossa leitura

Hashimoto acerta em cheio: a geração de desenvolvedores formada em runtimes gerenciados (JavaScript, Python, Go) muitas vezes ignora que o CPU dispõe, há dez anos, de meios de cálculo que nunca são usados por seu código. Não é uma acusação — é um diagnóstico. E o retorno sobre o investimento, quando finalmente se conectam esses meios a um caminho crítico, é espetacular.

Para reter

• O SIMD não é mais uma otimização exótica: é a principal fonte de ganhos restantes no CPU.
• Bibliotecas portáteis (Highway, std::simd, Zig @Vector) tornam a entrada acessível.
• Tudo que processa dados em volume (parsers, DBs, imagens, hashes) deve ser questionado sob essa perspectiva.