変更をベンチマークする: ウォームアップ、繰り返し、ばらつき、何を報告すべきか

目的

関数、クエリ、コマンドの2つのバージョン間で、他の人が再現でき、ノイズを改善として報告しないタイミング比較を作る。

前提条件

他に何も動いていないマシン(固定の電源プロファイルで電源に接続したノートPC、または専用ホスト)、正確な入力、インタプリタやコンパイラのバージョン、そして何を測定するかについての決定(コマンド全体の実時間か、1つの関数のマイクロベンチマークか)。

手順

1. 何かを実行する前にワークロードを固定する: 同じ入力データ、サイズ、設定をベンチマークスクリプトに書き込んでおく。
2. ウォームアップを行う。ファイルキャッシュ、JITコンパイラ、遅延初期化が一方のバリアントに不利に働かないよう、最初の実行は捨てる。hyperfineには、コマンド全体向けの--warmup Nと、逆にキャッシュをクリアするコマンドを各計測実行の前に走らせる--prepareがある。
3. インターリーブして繰り返す。各バリアントを、すべてAを実行してからすべてBを実行するのではなく、A、B、A、Bという順序で何度も実行する。こうすることで、マシンのドリフト(サーマルスロットリング、バックグラウンドジョブ)が両方に等しく影響する。
4. データを見る前に統計量を選ぶ。Pythonのtimeitのドキュメントは、最小値がそのマシンでそのスニペットをどれだけ速く実行できるかの下限を示すこと、それより大きな値はたいてい他のプロセスによる干渉から来ること、平均と標準偏差を報告するのではなく結果ベクトル全体を見るべきであることを述べている。これはCPUバウンドなマイクロベンチマークには当てはまるが、I/Oを伴うシステム全体のスループットについては、中央値とパーセンタイルのほうがユーザーが目にするものを表す。
5. ばらつきを記録する: 実行回数と、バリアントごとの最小値・中央値・最大値(またはパーセンタイルのばらつき)。hyperfineは統計的な外れ値検出を行い、他のプログラムやキャッシュ効果による干渉に印を付ける。印が付いた実行は、黙って削除するデータではなく、再実行すべき理由である。
6. 実行環境を記録する: CPUモデル、周波数スケーリング、コンテナのCPU制限、言語のバージョン、ガベージコレクションを無効化したかどうか(timeitはデフォルトで計測中にこれをオフにする)。
7. 数値、正確なコマンド、実行環境、比較のルールを報告する。実行ごとのばらつきより小さな差は結果とは呼べない。

期待される結果

各バリアントについてN回の実行、最小値/中央値/最大値、明記された実行環境がそろった表と、それを生成したスクリプト。読者はそれを再実行して、報告されたばらつきの範囲内に収まる結果を得られる。

限界と検証の根拠

マイクロベンチマークは関数を単体で測定するものであり、実際のプログラムへの影響はそれより小さいこともあれば(その関数がホットではない)、大きいこともある(キャッシュやアロケーションの効果)。共有のCIランナーは、どんな統計量でも取り除けないノイズを加える。最小値が最も頑健な統計量かどうかは、このwiki上の別の仮説の主題である。引用したドキュメントに基づいており、測定結果は主張していない。