Seu código é rápido — se você tiver sorte: por que seus micro-benchmarks mentem

Um tweet viral questiona a confiabilidade dos micro-benchmarks: o mesmo código pode variar em até 30% dependendo da ordem dos símbolos, da posição na memória ou do nome do usuário. O que isso muda para o desenvolvimento.

Em termos simples

Um desenvolvedor demonstrou que o mesmo trecho de código pode ser 30% mais rápido ou mais lento dependendo de parâmetros que não têm relação alguma com o algoritmo: ordem dos símbolos no link-time, tamanho das variáveis de ambiente, alinhamento de memória. Em outras palavras, grande parte do que medimos em microssegundos depende da sorte.

A história

O autor, em tiki.li/blog/lucky_code, retoma um tema já conhecido entre compiladores (Emery Berger, Stabilizer, ASPLOS 2013) e o atualiza: ele executa o mesmo binário, sem modificá-lo, e varia parâmetros periféricos (nome do diretório de build, ordem de link dos arquivos objetos, tamanho do $PATH). Os tempos de execução mudam significativamente, chegando a mais de 30% em micro-benchmarks. A causa: o alinhamento das instruções nos caches L1i/uop, o decodificador x86 e a previsão de desvios, que são sensíveis ao endereço virtual do código.

O ponto que deveria incomodar a todos: na vida real, comparamos um PR antes/depois, notamos um ganho de 8% e fazemos o merge. Quantos desses ganhos são sinal real? Quantos são ruído de alinhamento?

Por baixo dos panos

• Stabilizer (Berger 2013) randomiza a alocação de stack, heap e código a cada execução — as medições se tornam distribuições, não pontos.
• Hyperfine + -warmup + -runs 50 NÃO resolve o problema: ele tira a média, mas o alinhamento permanece o mesmo em cada execução do mesmo binário.
• A boa prática: recompilar com offsets aleatórios (Stabilizer ou padding manual) OU executar com -randomize-address e reportar um IC 95%, não uma média.

Então, o que fazer?

Três consequências para o ofício. Um: qualquer ganho de performance abaixo de 10% em um micro-benchmark único provavelmente é ruído. Rejeite-o ou refaça-o com randomização. Dois: as regressões de performance em CI (como Codspeed) devem adotar a randomização, caso contrário vamos deixar passar regressões reais e entrar em pânico com ruído. Três: os benchmarks de marketing de compiladores e runtimes (Bun vs Node, Zig vs C…) devem ser lidos com esse filtro. A performance, nesse nível, depende tanto da engenharia de build quanto do algoritmo.