Debian Code Search elimina a última dependência de cgo

O Debian Code Search passa a funcionar sem código C. Michael Stapelberg substituiu uma biblioteca de compressão em C com sete anos por uma versão em Go puro, assente no pacote SIMD experimental do Go. Segundo relata, iguala o original em C na velocidade. "I deleted the last cgo dependency in Debian Code Search", escreveu no seu blogue a 6 de setembro de 2026.

O Debian Code Search é o serviço que permite pesquisar 130 GiB de código-fonte em todos os pacotes Debian. Funciona desde 2012.

O que o TurboPFor faz e porque estava lá C

A biblioteca em causa é o TurboPFor. É um formato de compressão de inteiros, usado dentro de um índice invertido para guardar listas de identificadores de documentos de forma compacta.

Esse trabalho é pouco vistoso e crítico para o desempenho. Um motor de pesquisa de código passa muito tempo a descodificar essas listas, por isso o descodificador define a velocidade de cada consulta.

O Go consegue chamar C, através de uma ponte chamada cgo. Funciona, mas custa. Cada chamada atravessa uma fronteira, a compilação cruzada fica mais difícil, e a compilação passa a precisar de uma cadeia de ferramentas de C além da do Go. Stapelberg suportou essa troca durante sete anos porque a versão em C era mais rápida.

O que a reescrita em Go conseguiu

A reescrita assenta no simd/archsimd, um pacote experimental que chegou com o Go 1.26. SIMD significa single instruction, multiple data: uma instrução do processador opera sobre um lote de valores em vez de sobre um só.

Dois números do texto destacam-se. A codificação popcount posicional, um passo de contagem de bits do formato, correu cerca de duas vezes mais depressa pelo caminho SIMD. Os blocos completos descodificaram cerca de três vezes mais depressa do que a versão escalar em Go.

Medida	Resultado
Codificação popcount posicional	Cerca de 2x mais rápida com SIMD
Débito em blocos completos	Cerca de 3x mais rápido que o Go escalar
Face à biblioteca em C original	Empate, codificador e descodificador
Dependências de cgo restantes	Nenhuma

Empate é a palavra importante. A versão em Go não bate o C. Fica a par, e isso basta para deixar de compensar manter a dependência de C.

O senão: continua a ser uma experiência

Isto não funciona logo à partida. O pacote está atrás de uma opção de compilação. Stapelberg cita o requisito diretamente. "Go 1.26 introduces a new experimental simd/archsimd package", escreve, "which can be enabled by setting the environment variable GOEXPERIMENT=simd at build time."

Um pacote experimental pode mudar de forma entre versões, e a API aqui é deliberadamente específica da arquitetura em vez de portável. Contámos que o Go 1.27 acrescenta um pacote simd portável ao lado do específico da arquitetura. É essa a direção, mas nenhum é ainda estável.

O que isto significa para programadores

A lição transponível é que a saída de emergência do cgo está a estreitar. Muitos projetos em Go mantêm uma dependência de C por causa de um ciclo pesado, e aceitam em troca uma compilação mais difícil. Se o SIMD em Go chega a par de C escrito à mão em compressão de inteiros, essa troca merece ser reavaliada no seu próprio código.

Verifique primeiro o que o cgo lhe custa de facto. Não é só velocidade. É compilação cruzada, cadeias de ferramentas de C na integração contínua, ligação estática e a depuração depois de uma falha que atravessa a fronteira. O ganho de Stapelberg é tanto uma compilação mais simples como uma mais rápida.

Não ponha GOEXPERIMENT=simd numa compilação de produção para já. Experimental quer dizer que o pacote pode mexer-se, e uma API específica da arquitetura quer dizer que o seu código não é portável por omissão. Faça um protótipo, meça os seus próprios números e mantenha o caminho de C até a API assentar.

Se quer a implementação em vez do resumo, o port para Go é publicado à parte como goturbopfor. O serviço que alimenta é de código aberto sob a organização Debian. A lista de núcleos SIMD reais escritos em Go é curta neste momento, e este faz parte dela.