Debian Code Search、最後のcgo依存を削除

Debian Code SearchがCのコードなしで動くようになりました。Michael Stapelberg氏が7年前のC製の圧縮ライブラリを、Goの実験的なSIMDパッケージに基づく純粋なGo実装に置き換えました。速度はC版と同等だと同氏は報告しています。「I deleted the last cgo dependency in Debian Code Search」と、同氏は2026年9月6日に自身のブログで書きました。

Debian Code Searchは、Debianの全パッケージにまたがる130 GiBのソースコードを誰でも検索できるサービスです。2012年から稼働しています。

TurboPForの役割と、そこにCがあった理由

問題のライブラリはTurboPForです。整数圧縮の形式で、転置インデックスの中で文書IDの並びをコンパクトに保持します。

この仕事は地味で、しかも性能に直結します。コード検索エンジンは、そのIDの並びを復号することに多くの時間を使います。つまり復号器の速さが、すべての検索の速さを決めます。

GoはcgoというブリッジでCを呼べます。動きはしますが、代償があります。呼び出しのたびに境界をまたぎ、クロスコンパイルは難しくなり、ビルドにはGoに加えてCのツールチェーンも必要になります。C版のほうが速かったため、Stapelberg氏は7年間この取引を受け入れてきました。

Goでの書き直しが達成したこと

書き直しは、Go 1.26で入った実験的なパッケージsimd/archsimdに依存しています。SIMDはsingle instruction, multiple dataの略で、1つのCPU命令が値を1つずつではなくまとめて処理することを指します。

記事の数字のうち2つが目を引きます。この形式に含まれるビット計数の工程である位置つきpopcountの符号化は、SIMD経路でおよそ2倍速くなりました。完全なブロックの復号は、素朴なスカラー版のGoに比べておよそ3倍速くなりました。

指標	結果
位置つきpopcountの符号化	SIMDでおよそ2倍
完全なブロックのスループット	スカラーGoのおよそ3倍
元のCライブラリとの比較	符号化・復号とも同等
残るcgo依存	ゼロ

重要なのは「同等」という言葉です。Go版はCを上回ってはいません。並んだだけです。それでも、C依存を抱え続ける価値がなくなるには十分でした。

落とし穴: まだ実験扱い

そのままでは動きません。このパッケージはビルド時のフラグの後ろにあります。Stapelberg氏は要件をそのまま引用しています。「Go 1.26 introduces a new experimental simd/archsimd package」と書き、「which can be enabled by setting the environment variable GOEXPERIMENT=simd at build time」と続けています。

実験的なパッケージはリリース間で形が変わり得ますし、ここでのAPIは移植性ではなくアーキテクチャ固有であることを意図しています。当サイトではGo 1.27が移植性のあるsimdパッケージをアーキテクチャ固有のものと並べて追加したことを取り上げましたが、どちらもまだ安定版ではありません。

これが開発者にとって意味すること

応用できる結論は、cgoという逃げ道が狭くなってきたことです。多くのGoプロジェクトは、ひとつの重いループのためにC依存を抱え、その代わりにビルドの複雑さを受け入れています。整数圧縮でGoのSIMDが手書きのCと並べるなら、その取引は自分のコードでも見直す価値があります。

始める前に、cgoに実際いくら払っているかを確認してください。速度だけの話ではありません。クロスコンパイル、CIのCツールチェーン、静的リンク、境界をまたいだクラッシュのデバッグまで含みます。Stapelberg氏が得たのは、速いビルドであると同時に、単純なビルドでもありました。

GOEXPERIMENT=simdを本番のビルドにはまだ入れないでください。実験的とは、パッケージが動きうるということです。アーキテクチャ固有のAPIとは、コードが既定では移植可能でないということです。試作して、自分の数字を測り、APIが落ち着くまではCの経路を残しておいてください。

要約ではなく実装を読みたいなら、Goへの移植はgoturbopforとして別に公開されています。それが支えるサービスもDebianの組織の下でオープンソースです。Goで書かれた本物のSIMDカーネルの一覧はいま短く、これはその一つです。