問題タブ [jmh]

さまざまな実行エンジンを使用してさまざまなシミュレーションの実行時間を測定するマクロベンチマークの大規模なセットがあります (それらの一部は高度にマルチスレッド化されています)。これらのジョブのほとんどは、抽象基本クラスで次のように指定する jmh 設定を使用します。

(コマンドラインに -gc -si false も追加します)

これらのベンチマークのいずれかまたはいくつかの小さなサブセットを起動すると、すべて正常に動作します。ただし、それらすべてを一度に実行しようとすると（つまり、フィルタリングオプションなしで）、jmh はそれらのいくつかを正常に終了し、特定のベンチマークの後に突然フリーズします...それのすべてが実行され、最終結果が出力されますが、フォークされた JVM が強制終了され、新しい JVM が開始されていないように見えません。プロセス全体がスタックしているようです。出力された最後のステートメントの例:

フォークされた JVM を手動で強制終了すると、プロセス全体のブロックが解除されます。ただし、次のベンチマークを終了すると、再びスタックします...なぜそれが起こるのですか? そして、同じベンチマークを別々に起動すると、なぜそれが起こらないのですか?

また、JMHにはタイムアウトオプションがありますか?通常のシャットダウンに時間がかかりすぎると、フォークされたプロセスを強制的に強制終了しますか?

JMH について 2 つの質問があります。

1) 出力からグラフィックスを生成するにはどうすればよいですか? 私は csv/json に出力できることを知っており、自分で何かを設定できることを知っています。でも、自分でやらなくてよかった。

2) すぐに使用できるアーカイブ機能がいくつかありますか?たとえば、傾向分析などのために、時間の経過に伴うパフォーマンスの比較を行うことができます。または、異なる git ブランチ間でパフォーマンスを比較できます。これまでのところ、この機能は存在しないようで、自分で何かを考え出す必要があります。

Scala で Unicode 文字を含む文字列を逆にしようとしています。最速の方法を見つけたいです。これまでのところ、私はこのコードを持っています:

私のmacbook 2013では、次の結果が得られます。

しかし、それらの数字は偽の数字だと思います。scala、sbt、および JMH ライブラリを使用して関数を適切にベンチマークするのは誰ですか?

注: コメントから指摘されているように、Java でのマイクロ ベンチマークは深刻なビジネスです ( How do I write a correct micro-benchmark in Java? ) およびhttps://groups.google.com/d/msg/mechanical-sympathyを参照してください。 /m4opvy4xq3U/7lY8x8SvHgwJ . 外部ライブラリを使用せずにマイクロベンチマークを行うべきではない理由について。

jmh 0.6。依存関係として jmh-core、jmh-generator-annprocess、jmh-generator-reflection があります。

まず、残念ながらドキュメントが貧弱です。1 つには、maven ではなく gradle を使用しているため、maven アーキタイプを使用することはできません。

2 つ目は、コマンド ラインではなく Java API を使用することです。

私の非常に単純なコードは次のとおりです。

がないので、正規表現として.include()意味する.*ため、すべてのベンチマークです。これは、私のプロジェクトにある唯一のクラスです。

しかし、いいえ：「ベンチマークが見つかりません」。

したがって、最後の手段としてMETA-INF/MicroBenchmarks、他の場所で提案されているようにファイルを作成してみました。コンテンツ、クラスの名前:

しかし、それも機能しません:

もちろん、このファイルの形式は文書化されていません。

しかし、最初からこのファイルを使用したくありません。実行するクラスのリストを指定したい。

それ、どうやったら出来るの？

JMHホームページで指定されているように、maven archetypeプロジェクトを作成しました。生成されたプロジェクトの Maven ビルドを実行すると、「Annotation generator had throw the exception. java.lang.NullPointerException」が表示されます。私のJavaファイルは

`。私が得る例外は

整数プリミティブを使用して文字列に変換することに関する少しの議論を調査しているときに、次のJMHマイクロベンチマークを作成しました。"" + nInteger.toString(int)

Linux マシン (最新の Mageia 4 64 ビット、Intel i7-3770 CPU、32GB RAM) に存在する両方の Java VM で、デフォルトの JMH オプションを使用して実行しました。最初の JVM は、Oracle JDK 8u5 64 ビットで提供されたものでした。

この JVM を使用すると、期待どおりの結果が得られました。

つまり、オブジェクトをStringBuilder作成して空の文字列を追加する追加のオーバーヘッドにより、クラスの使用が遅くなります。StringBuilder使用String.format(String, ...)はさらに遅く、桁違いに遅くなります。

一方、ディストリビューションで提供されるコンパイラは、OpenJDK 1.7 に基づいています。

ここでの結果は興味深いものでした:

この JVM を使用すると、なぜStringBuilder.append(int)これほど高速に見えるのでしょうか? クラスStringBuilderのソース コードを調べても、特に興味深いことは何もありませんでした。問題のメソッドは とほとんど同じですInteger#toString(int)。興味深いことに、Integer.toString(int)(stringBuilder2マイクロベンチマーク) の結果を追加しても、それほど速くはないようです。

このパフォーマンスの不一致は、テスト ハーネスの問題ですか? または、私の OpenJDK JVM には、この特定のコード (アンチ) パターンに影響を与える最適化が含まれていますか?

編集：

より単純な比較のために、Oracle JDK 1.7u55 をインストールしました。

結果は、OpenJDK の結果と同様です。

これは、より一般的な Java 7 と Java 8 の問題のようです。おそらく、Java 7 ではより積極的な文字列の最適化が行われたのでしょうか?

編集2：

完全を期すために、これらの両方の JVM の文字列関連の VM オプションを次に示します。

Oracle JDK 8u5 の場合:

OpenJDK 1.7 の場合:

このUseStringCacheオプションは Java 8 で削除され、代替品はありませんでした。残りのオプションは同じ設定になっているようです。

編集3：

のソース コードとのファイルAbstractStringBuilderのクラスを並べて比較すると、注目に値するものは何もありません。多くの表面的な変更とドキュメントの変更は別として、は符号なし整数をサポートするようになり、 とより多くのコードを共有するためにわずかにリファクタリングされました。これらの変更は、 で使用されるコード パスに影響を与えるものではないようですが、見落としがあるかもしれません。StringBuilderIntegersrc.zipIntegerStringBuilderStringBufferStringBuilder#append(int)

IntStr#integerToString()と のために生成されたアセンブリ コードの比較は、IntStr#stringBuilder0()はるかに興味深いものです。生成されたコードの基本的なレイアウトはIntStr#integerToString()両方の JVM で似ていましたが、Oracle JDK 8u5 は、Integer#toString(int)コード内の一部の呼び出しをインライン化することに関して、より積極的であるように見えました。アセンブリの経験がほとんどない人でも、Java ソース コードとの明確な対応がありました。

ただし、のアセンブリ コードIntStr#stringBuilder0()は根本的に異なっていました。Oracle JDK 8u5 によって生成されたコードは、再び Java ソース コードに直接関連していました。同じレイアウトであることは容易に認識できました。それどころか、OpenJDK 7 によって生成されたコードは、訓練されていない目 (私のように) にはほとんど認識できませんでした。コンストラクターでの配列のnew StringBuilder()作成と同様に、呼び出しは一見削除されましたStringBuilder。さらに、逆アセンブラー プラグインは、JDK 8 の場合ほど多くのソース コードへの参照を提供できませんでした。

これは、OpenJDK 7 でのより積極的な最適化パスの結果であるか、または特定の操作のために手書きの低レベル コードを挿入した結果である可能性が高いと思いますStringBuilder。JVM 8 実装でこの最適化が行われない理由、またはInteger#toString(int)JVM 7 で同じ最適化が実装されなかった理由がわかりません。JRE ソース コードの関連部分に詳しい人がこれらの質問に答える必要があると思います...