IIUCの場合、各仮想マシンインスタンスがJIT命令のわずかな違いで実行される可能性があるという理由で、各フォークが個別の仮想マシンを作成しますか?
また、以下の注釈で時間属性が何をするのかについても興味があります。
@Warmup(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
@Measurement(iterations = 10, time = 500, timeUnit = TimeUnit.MILLISECONDS)
TIA、オレ
JMHは、いくつかの理由でフォーク機能を提供します。 1つは、上記のRafaelで説明したコンパイルプロファイルの分離です。ただし、この動作は@Forksアノテーションによって制御されません(0フォークを選択しない限り、つまり、ベンチマークを実行するためにサブプロセスがフォークされることはありません)。ウォームアップモードコントロール(-wm)を使用して、ベンチマークウォームアップの一部としてすべてのベンチマークを実行することを選択できます(したがって、JITが機能する混合プロファイルを作成します)。
現実には、多くのことが共謀して結果を何らかの形で傾けることができ、ベンチマークを複数回実行して実行ごとの差異を確立することは、JMHがサポートする重要なプラクティスです(ほとんどの手動フレームワークは役に立ちません) 。実行ごとの差異の理由には、次のものが含まれる場合があります(ただし、他にもあると確信しています)。
CPUは特定のC状態で起動し、負荷に直面して周波数をスケールアップしてから、過熱してスケールダウンします。この問題は、特定のOSで制御できます。
プロセスのメモリアライメントは、ページング動作の違いにつながる可能性があります。
少なくともいくつかのフォークを使用してベンチマークを実行すると、これらの違いを取り除き、ベンチマークに見られる実行から実行への差異のアイデアを得るのに役立ちます。デフォルトの10から始めて、ベンチマークに応じて実験的に削減(または増加)することをお勧めします。
JVMは、アプリケーションの動作のプロファイルを作成することにより、アプリケーションを最適化します。このプロファイルをリセットするためにフォークが作成されます。それ以外の場合、実行中:
benchmarkFoo();
benchmarkBar();
とは異なる測定値になる可能性があります
benchmarkBar();
benchmarkFoo();
最初のベンチマークのプロファイルが2番目のベンチマークに影響を与えるためです。
時間は、ベンチマークのウォームアップまたは実行に費やすJMHの長さを決定します。これらの時間が短すぎると、VMが十分にウォームアップされていないか、結果の標準偏差が高すぎる可能性があります。
更新:
JMH(Java Microbenchmark Harness))は、JDK12以降のJDKに追加されました。
@Fork
アノテーションは、ベンチマークの実行がどのように行われるかを指示します。value
パラメーターは、ベンチマークが実行される回数を制御し、warmup
パラメーターは、結果が収集される前にベンチマークがドライランされる回数を制御します。 。
例:
@Benchmark
@Fork(value = 1, warmups = 3)
@BenchmarkMode(Mode.AverageTime)
public void myMethod() {
// Do nothing
}
これは、[〜#〜] jmh [〜#〜] 3つのウォームアップフォークを実行し、結果を破棄に移動する前にリアルタイムベンチマークに移動するように指示します。 。