ベンチマーキング

ベンチマーキングでは通常、同じことを行う 2 つ以上のプログラムのパフォーマンスを比較します。場合によっては、Firefox vs Safari vs Chrome のように、2 つ以上の異なるプログラムを比較することもあります。また、同じプログラムの 2 つの異なるバージョンを比較することもあります。後者の場合、「この変更によって処理は速くなったのか？」という問いに対して、信頼性の高い答えを得られます。

ベンチマーキングは複雑なトピックであり、この本の範囲を超えて網羅的に扱うことはできませんが、ここでは基本を示します。

まず、測定するワークロードが必要です。理想的には、プログラムの現実的な使用状況を表すさまざまなワークロードを用意します。実世界の入力を使うワークロードが最適ですが、microbenchmarks や stress tests も適度に使えば有用です。

次に、ワークロードを実行する方法が必要です。これは使用するメトリクスも決定します。

• Rust 組み込みの benchmark tests は単純な出発点ですが、不安定な機能を使用するため、nightly Rust でしか動作しません。
• Criterion と Divan は、より高度な代替手段です。
• Hyperfine は優れた汎用ベンチマーキングツールです。
• Bencher は GitHub CI を含む CI 上で継続的ベンチマーキングを実行できます。
• Gungraun は、高精度な測定を備えた cargo bench 統合を提供します。
• カスタムのベンチマーキングハーネスも可能です。たとえば、rustc-perf は Rust コンパイラのベンチマークに使用されるハーネスです。

メトリクスに関しては多くの選択肢があり、適切なものはベンチマーク対象のプログラムの性質によって異なります。たとえば、バッチプログラムに適したメトリクスが、インタラクティブなプログラムに適しているとは限りません。多くの場合、ウォールタイムはユーザーが知覚するものに対応するため、明らかな選択肢です。しかし、ウォールタイムは分散が大きくなることがあります。特に、メモリレイアウトのわずかな変化が、大きいものの一時的なパフォーマンス変動を引き起こすことがあります。そのため、分散のより小さい他のメトリクス（サイクル数や命令数など）が妥当な代替手段となる場合があります。

複数のワークロードから得られた測定値を要約することも課題であり、その方法はさまざまですが、明らかに最善と言える単一の方法はありません。

優れたベンチマーキングは困難です。とはいえ、特にプログラムの最適化を始める段階では、完璧なベンチマーキング環境を用意することに過度に気を使う必要はありません。並のベンチマーキングでも、ベンチマーキングをまったく行わないよりははるかに優れています。何を測定しているのかについて柔軟な姿勢を保ち、プログラムのパフォーマンス特性を学ぶにつれて、時間をかけてベンチマーキングを改善していけます。