「あなたのコードは高速です — 運が良ければ」: なぜマイクロベンチマークが嘘をつくのか

ウイルス化した投稿がマイクロベンチマークの信頼性に疑問を投げかける：同じコードでも、シンボルの順序、メモリ内の位置、ユーザー名によって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…）はこのフィルターを通して読むべきだ。このレベルのパフォーマンスは、アルゴリズムよりもビルドエンジニアリングにかかっているのだ。