0

コードスニペットは次のとおりです。

https://gist.github.com/987751

私にとっては、次のような時間があります。

java -client：
  forループがかかりました：23
  メソッド呼び出しにかかった：19

java -server：
  forループにかかった時間：0＃予想どおり高速
  メソッドの呼び出しにかかった時間：48＃遅い-予想されますか？

したがって、最初の質問は「なぜクライアントVMよりも遅いのか」です。

また、次の質問は、「メソッド呼び出し方法でその超0msの高速化を実現することは可能ですか（ほぼ同じコードです）」と思います。

また、この奇妙さにもかかわらず、たとえば匿名のクラスなどでも、ホットスポットは一般的にはるかに高速に実行されると思いますか？

ありがとう！

-ロジャー-

4

1 に答える 1

2

ホットスポットの2つのフレーバーがどのように調整されているかについてのすべてです。

  • クライアントは高速（より）起動するように調整されています。JITは、メソッドを「ほぼ」すぐにコンパイルします。

  • サーバーは、長時間のチューニングサーバーインスタンスであると想定されるものの存続期間にわたって、より高い（より）スループットが得られるようにチューニングされます。これにより、JITがメソッドをコンパイルする前に、インタープリターがメソッドをはるかに長く実行できるようになります（使用統計を収集します）。次に（私は信じています）より積極的な最適化を実行します...これには時間がかかります。

関連する回答：「java-server」と「java-client」の本当の違いは？

ちなみに、クライアントモードとサーバーモードの両方を実行しているのは同じホットスポットJVMです。AFAIK、違いは、2つのモードが異なるデフォルトのJVMチューニング/構成パラメーターを選択することによるものです。

したがって、最初の質問は「なぜクライアントVMよりも遅いのか」です。

知らない。

おそらく、クライアントモードは、この（非常に人工的な）ベンチマークに本当に役立つ特定の最適化を可能にします。あるいは、サーバーモードの最適化の1つは、実際にはこの（非常に人工的な）ベンチマークの最適化に反するものです。本当に知りたい場合は、JITコンパイラにネイティブコードをダンプして詳細に分析してもらいます。（しかし、それは時間の無駄だと思います。）

また、次の質問は、「メソッド呼び出し方法でその超0msの高速化を実現することは可能ですか（ほぼ同じコードです）」と思います。

簡単だ。オプティマイザーは、メソッド呼び出しが他に影響を与えないことを理解し、呼び出しを最適化しました。その後、ループを最適化することもできます。

また、この奇妙さにもかかわらず、たとえば匿名のクラスなどでも、ホットスポットは一般的にはるかに高速に実行されると思いますか？

私はあなたが何かを推測するべきではないと思います。

ただし、あなたのマイクロベンチマークが実際のプログラムについて意味のあることを言っているとは思いません。マイクロベンチマークは一般的に誤解を招く傾向があり、あなたのベンチマークには欠陥があり（たとえば、最適化されるループ）、典型的な（よく書かれた）Javaプログラムが行うようなことをテストしていないようです。

HotSpotの2つのモードの相対的なパフォーマンスが本当に心配な場合は、現実的なデータでアプリケーションのパフォーマンスを実行して測定する必要があります。

...そしてなぜサーバーJVMは一見悪いものを選択するのでしょうか？

オプティマイザーは、実際のプログラムを最適化するように設計されています...有用な計算とはまったく似ていない奇妙なことを行うのに時間を費やすマイクロベンチマークではありません。すべての最適化がすべての状況で有益であるとは限りません。おそらく、ある種のエッジケースに遭遇したことでしょう。

ただし、これは、実際のアプリケーションで同じことが起こっている場合にのみ関係します。

最後に、JVMのバージョン、プラットフォーム、およびハードウェアの詳細は指定しません。これらのことは、相対的なパフォーマンス測定に大きな違いをもたらす可能性があります。

于 2011-05-23T23:02:24.733 に答える