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.
3 min de lecture

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.
| Mesure | Résultat |
|---|---|
| Encodage popcount positionnel | Environ 2x plus rapide en SIMD |
| Débit sur blocs complets | Environ 3x plus rapide que le Go scalaire |
| Face à la bibliothèque C d'origine | Égalité, encodeur et décodeur |
| Dépendances cgo restantes | Aucune |
É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
- Debian Code Search: Fast TurboPFor with Go SIMD - Michael Stapelberg
- Debian Code Search - Debian
- stapelberg/goturbopfor - GitHub
Articles liés

Un binaire strip trafiqué peut piéger tout NixOS
Des chercheurs ont construit l'attaque trusting-trust de Ken Thompson à partir de GNU strip, et non d'un compilateur, pour piéger presque tous les binaires d'un installateur NixOS.

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.

Go 1.27 ajoute les méthodes génériques et un encoding/json plus rapide
Go 1.27 est sorti le 19 août 2026 avec des méthodes génériques, un moteur v2 sous encoding/json, des profils de fuite de goroutines et des signatures post-quantiques.