Debian Code Search wirft die letzte cgo-Abhängigkeit raus

Debian Code Search läuft jetzt ohne C-Code. Michael Stapelberg ersetzte eine sieben Jahre alte C-Kompressionsbibliothek durch eine reine Go-Fassung auf Basis von Gos experimentellem SIMD-Paket. Sie erreicht laut seinem Bericht das Tempo des C-Originals. "I deleted the last cgo dependency in Debian Code Search", schrieb er in seinem Blog am 6. September 2026.

Debian Code Search ist der Dienst, mit dem sich 130 GiB Quellcode über jedes Debian-Paket hinweg durchsuchen lassen. Er läuft seit 2012.

Was TurboPFor tut und warum dort C stand

Die fragliche Bibliothek heißt TurboPFor. Sie ist ein Format zur Ganzzahlkompression und speichert in einem invertierten Index Listen von Dokument-IDs kompakt.

Diese Aufgabe ist unscheinbar und zeitkritisch. Eine Codesuche verbringt viel Zeit damit, solche ID-Listen zu dekodieren. Der Dekoder bestimmt also das Tempo jeder Anfrage.

Go kann C aufrufen, über eine Brücke namens cgo. Das funktioniert, kostet aber. Jeder Aufruf überquert eine Grenze, Cross-Compiling wird schwieriger, und der Build braucht neben Go auch eine C-Toolchain. Stapelberg trug diesen Handel sieben Jahre, weil die C-Fassung schneller war.

Was die Go-Neufassung erreichte

Die Neufassung stützt sich auf simd/archsimd, ein experimentelles Paket, das mit Go 1.26 kam. SIMD steht für Single Instruction, Multiple Data: ein CPU-Befehl arbeitet auf einem Bündel von Werten statt auf einem einzelnen.

Zwei Zahlen aus dem Beitrag stechen heraus. Die positionsweise Popcount-Kodierung, ein Bitzählschritt im Format, lief mit dem SIMD-Pfad etwa doppelt so schnell. Vollständige Blöcke dekodierten rund dreimal schneller als in der einfachen skalaren Go-Fassung.

Messgröße	Ergebnis
Positionsweise Popcount-Kodierung	Etwa 2x schneller mit SIMD
Durchsatz bei vollen Blöcken	Etwa 3x schneller als skalares Go
Gegen die ursprüngliche C-Bibliothek	Gleichstand, Kodierer und Dekodierer
Verbleibende cgo-Abhängigkeiten	Keine

Gleichstand ist das wichtige Wort. Die Go-Fassung schlägt C nicht. Sie zieht gleich, und das genügt, damit sich die C-Abhängigkeit nicht mehr lohnt.

Der Haken: es ist weiterhin ein Experiment

Das läuft nicht ohne Weiteres. Das Paket steckt hinter einem Build-Schalter. Stapelberg zitiert die Anforderung direkt. "Go 1.26 introduces a new experimental simd/archsimd package", schreibt er, "which can be enabled by setting the environment variable GOEXPERIMENT=simd at build time."

Ein experimentelles Paket kann zwischen Releases seine Form ändern, und die API ist hier bewusst architekturspezifisch statt portabel. Wir haben berichtet, dass Go 1.27 ein portables simd-Paket neben dem architekturspezifischen ergänzt. Das ist die Richtung, aber stabil ist keines von beiden.

Was das für Entwickler bedeutet

Die übertragbare Erkenntnis: die Notausgangstür cgo wird schmaler. Viele Go-Projekte halten eine C-Abhängigkeit für eine heiße Schleife und nehmen dafür einen schwierigeren Build in Kauf. Wenn SIMD in Go bei Ganzzahlkompression mit handgeschriebenem C gleichzieht, lohnt sich dieser Handel im eigenen Code eine erneute Prüfung.

Prüfen Sie zuerst, was cgo Sie tatsächlich kostet. Es geht nicht nur um Tempo. Es geht um Cross-Compiling, C-Toolchains in der CI, statisches Linken und das Debuggen nach einem Absturz über die Grenze hinweg. Stapelbergs Gewinn ist ebenso ein einfacherer wie ein schnellerer Build.

Setzen Sie GOEXPERIMENT=simd noch nicht in einen Produktions-Build. Experimentell heißt, das Paket kann sich bewegen, und eine architekturspezifische API heißt, Ihr Code ist nicht von sich aus portabel. Prototypen bauen, eigene Zahlen messen, den C-Pfad behalten, bis die API steht.

Wer die Umsetzung statt der Zusammenfassung lesen will: die Go-Portierung erscheint getrennt als goturbopfor. Der Dienst, den sie speist, ist quelloffen unter der Debian-Organisation. Die Liste echter, in Go geschriebener SIMD-Kernel ist derzeit kurz, und dieser steht darauf.