「コードは速い―運が良ければ」：なぜマイクロベンチマークが嘘をつくのか

ウイルス性の投稿がマイクロベンチマークの信頼性に疑問を投げかける：同じコードでも、シンボルの順序、メモリ上の位置、ユーザー名によって30%も変動する可能性がある。これがクラフトに与える影響とは。

簡単に言えば

同じコードでも、リンク時のシンボルの順序や環境変数のサイズ、メモリアラインメントといったアルゴリズムとは無関係なパラメータによって、30%も速くなったり遅くなったりすることが、ある開発者によって示されました。つまり、マイクロ秒単位で測定される多くの部分は、偶然の要素に左右されるのです。

経緯

著者は tiki.li/blog/lucky_code で、コンパイラ業界では既によく知られた話題（Emery Berger、Stabilizer、ASPLOS 2013）を再び取り上げています。同じバイナリを改変せずに実行し、ビルドディレクトリ名、オブジェクトファイルのリンク順、$PATHのサイズといった周辺パラメータを変化させると、ランタイムが大幅に変動し、マイクロベンチマークでは30%を超える差が出ることもあります。原因は、L1i/uopキャッシュ、x86デコーダ、分岐予測がコードの仮想アドレスに敏感であるためです。

多くの人が不快に感じる点：実際の現場では、PRの前後比較で8%のパフォーマンス向上を記録し、マージします。これらの向上のうち、実質的なシグナルはどれくらいで、アラインメントノイズはどれくらいでしょうか？

内部の仕組み

• Stabilizer（Berger 2013）は、スタック、ヒープ、コードのアロケーションをランダム化し、測定結果を分布として扱います。
• Hyperfine + -warmup + -runs 50 では問題は解決しません。同じバイナリの実行ではアラインメントが常に同じため、平均化しても状況は変わりません。
• 正しい方法：ランダムなオフセットで再コンパイル（Stabilizer、または手動パディング）するか、-randomize-addressで実行し、平均値ではなく95%信頼区間（IC 95%）を報告します。

結論

パフォーマンスの向上に関する3つの教訓です。

1. マイクロベンチマークの単一測定で10%未満のパフォーマンス向上は、おそらくノイズです。これを却下するか、ランダム化の下で再実行します。

2. CIのパフォーマンスリグレッション（例：Codspeed）ではランダム化を採用すべきです。そうしないと、実際のリグレッションを見逃し、ノイズにパニックを起こすことになります。

3. コンパイラやランタイムのベンチマーク（Bun vs Node、Zig vs C…）は、このフィルターを通して読む必要があります。このレベルのパフォーマンスは、ビルドエンジニアリングとアルゴリズムの両方に依存します。