Skip to content
Tech AI Wire

Debian Code Search supprime sa dernière dépendance cgo

Michael Stapelberg a remplacé une bibliothèque C vieille de 7 ans par du Go pur utilisant le paquet SIMD expérimental, et a égalé la vitesse de la version C.

Par Tech AI Wire Team

3 min de lecture

XLinkedIn
A terminal running benchcmp to compare a scalar Go benchmark against a vectorised one, with the delta column showing the speed-up.

Debian Code Search fonctionne désormais sans code C. Michael Stapelberg a remplacé une bibliothèque de compression en C vieille de sept ans par une version en Go pur, bâtie sur le paquet SIMD expérimental de Go. Il indique qu'elle égale l'original en C pour la vitesse. "I deleted the last cgo dependency in Debian Code Search", a-t-il écrit sur son blog le 6 septembre 2026.

Debian Code Search est le service qui permet de chercher dans 130 Gio de code source à travers chaque paquet Debian. Il tourne depuis 2012.

Ce que fait TurboPFor et pourquoi il y avait du C

La bibliothèque en question s'appelle TurboPFor. C'est un format de compression d'entiers, utilisé dans un index inversé pour stocker des listes d'identifiants de documents de façon compacte.

Ce travail est ingrat et critique pour la performance. Un moteur de recherche de code passe beaucoup de temps à décoder ces listes. Le décodeur fixe donc la vitesse de chaque requête.

Go peut appeler du C, via un pont nommé cgo. Cela marche, mais cela coûte. Chaque appel franchit une frontière, la compilation croisée devient plus difficile, et la compilation exige une chaîne d'outils C en plus de celle de Go. Stapelberg a supporté ce compromis pendant sept ans parce que la version C était plus rapide.

Ce qu'a obtenu la réécriture en Go

La réécriture s'appuie sur simd/archsimd, un paquet expérimental arrivé avec Go 1.26. SIMD signifie single instruction, multiple data : une instruction processeur opère sur un lot de valeurs plutôt que sur une seule.

Deux chiffres du billet ressortent. L'encodage popcount positionnel, une étape de comptage de bits du format, a tourné environ deux fois plus vite par le chemin SIMD. Les blocs complets se sont décodés environ trois fois plus vite que la version Go scalaire.

MesureRésultat
Encodage popcount positionnelEnviron 2x plus rapide en SIMD
Débit sur blocs completsEnviron 3x plus rapide que le Go scalaire
Face à la bibliothèque C d'origineÉgalité, encodeur et décodeur
Dépendances cgo restantesAucune

Égalité est le mot important. La version Go ne bat pas le C. Elle fait jeu égal, ce qui suffit à rendre la dépendance C inutile à garder.

Le hic : c'est encore une expérience

Cela ne marche pas d'emblée. Le paquet est derrière un drapeau de compilation. Stapelberg cite l'exigence directement. "Go 1.26 introduces a new experimental simd/archsimd package", écrit-il, "which can be enabled by setting the environment variable GOEXPERIMENT=simd at build time."

Un paquet expérimental peut changer de forme entre deux versions, et l'API est ici délibérément spécifique à une architecture plutôt que portable. Nous avons raconté que Go 1.27 ajoute un paquet simd portable à côté de celui spécifique à l'architecture. C'est la direction prise, mais aucun des deux n'est stable.

Ce que cela signifie pour les développeurs

L'enseignement transposable est que l'échappatoire cgo se rétrécit. Beaucoup de projets Go gardent une dépendance C pour une boucle chaude, et acceptent en échange une compilation plus pénible. Si le SIMD en Go atteint la parité avec du C écrit à la main sur la compression d'entiers, ce compromis mérite d'être réexaminé chez vous.

Vérifiez d'abord ce que cgo vous coûte réellement. Il ne s'agit pas que de vitesse. Il s'agit de compilation croisée, de chaînes d'outils C dans l'intégration continue, d'édition de liens statique, et du débogage après un plantage traversant la frontière. Le gain de Stapelberg est autant une compilation plus simple qu'une compilation plus rapide.

Ne mettez pas GOEXPERIMENT=simd dans une compilation de production pour l'instant. Expérimental veut dire que le paquet peut bouger, et une API spécifique à une architecture veut dire que votre code n'est pas portable par défaut. Prototypez, mesurez vos propres chiffres, et gardez le chemin C jusqu'à ce que l'API se stabilise.

Si vous voulez l'implémentation plutôt que le résumé, le portage Go est publié séparément sous le nom goturbopfor. Le service qu'il alimente est open source sous l'organisation Debian. La liste des vrais noyaux SIMD écrits en Go est courte en ce moment, et celui-ci y figure.

Sources

  1. Debian Code Search: Fast TurboPFor with Go SIMD - Michael Stapelberg
  2. Debian Code Search - Debian
  3. stapelberg/goturbopfor - GitHub

Articles liés

A terminal showing a large C++ project compiling, with the CMake percentage counter partway through and object files scrolling past.
Coding

LLVM débat de compiler ClangIR par défaut

Une RFC LLVM propose de compiler ClangIR dans Clang par défaut. Personne ne l'utiliserait sans drapeau, mais des estimations doublent les temps de compilation.