4

MPEGデコーダーでいくつかの最適化を行っています。最適化によって何も壊れていないことを確認するために、コードベース全体（最適化されたものとオリジナルの両方）をベンチマークするテストスイートがあり、両方が同じ結果を生成することを確認します（基本的にはデコーダーとcrc32を介していくつかの異なるストリームをフィードするだけです）出力）。

Sun 1.6.0_18で「-server」オプションを使用すると、ウォームアップ後の最適化されたバージョンでのテストスイートの実行が（デフォルトの「-client」設定と比較して）約12％遅くなりますが、元のコードベースは大幅に向上します。クライアントモードの約2倍の速度で実行されます。

最初はこれは単なるウォームアップの問題のように見えましたが、テストスイート全体を複数回繰り返すループを追加しました。その後、テストの3回目の反復から開始する各パスの実行時間は一定になりますが、最適化されたバージョンはクライアントモードよりも12％遅くなります。

また、コードには起動後のオブジェクトの割り当てがまったく含まれていないため、ガベージコレクションの問題ではないと確信しています。このコードは、主にいくつかのビット操作操作（ストリームデコード）と多くの基本的な浮動演算（PCMオーディオの生成）で構成されています。関連するJDKクラスは、ByteArrayInputStream（ストリームをテストにフィードし、ディスクIOをテストから除外する）とCRC32（結果を検証するため）のみです。また、Sun JDK 1.7.0_b98でも同じ動作が見られました（12％ではなく15％でした）。ああ、テストはすべて同じマシン（シングルコア）で行われ、他のアプリケーションは実行されていません（WinXP）。（System.nanoTime btwを使用して）測定された実行時間には避けられない変動がありますが、同じ設定での異なるテスト実行間の変動は2％を超えることはなく、通常は1％未満（ウォームアップ後）です。

サーバーJITでパフォーマンスが低下する既知のコーディングパターンはありますか？それができない場合、内部を「覗き見」してJITがそこで何をしているのかを観察するために利用できるオプションは何でしょうか。

  • たぶん、「ウォームアップ」の説明を間違って言いました。明示的なウォームアップコードはありません。テストスイート全体（12の異なるmpegストリームで構成され、合計で最大18万のオーディオフレームを含む）が10回実行され、最初の3つの実行は「ウォームアップ」と見なされます。私のマシンでは、1回のテストラウンドで100％CPUが約40秒かかります。

  • 提案されたようにJVMオプションを試して、「-Xms512m -Xmx512m -Xss128k -server -XX：CompileThreshold = 1 -XX：+ PrintCompilation -XX：+ AggressiveOpts -XX：+PrintGC」を使用してすべてのコンパイルがで行われることを確認できました最初の3ラウンド。ガベージコレクションは3〜4ラウンドごとに開始され、最大で40ミリ秒かかります（テストは16メートルで問題なく実行できるため、512メートルは非常に特大です）。このことから、ガベージコレクションはここでは影響がないと結論付けます。それでも、クライアントとサーバーを比較すると（他のオプションは変更されていません）、12/15％の違いが残っています。

4

1 に答える 1

6

これまで見てきたように、JITはバックグラウンドスレッドで実行されるため、テスト結果を歪める可能性があり、テストを実行しているメインスレッドからCPUサイクルを盗みます。

サイクルを盗むだけでなく、非同期であるため、ウォームアップを完了して実際にテストを開始したときに、動作が完了したかどうかを確認することはできません。同期JITコンパイルを強制するには、-XBatch非標準オプションを使用してJITコンパイルをフォアグラウンドスレッドに強制することができるため、ウォームアップが完了したときにJITが終了したことを確認できます。

HotSpotはメソッドをすぐにコンパイルしませんが、メソッドが特定の回数実行されるまで待機します。-XXオプションのページには、-serverのデフォルトは10000回であるのに対し、-clientのデフォルトは1500回であると記載されています。これは、特にウォームアップ-clientが1500〜10000回の間に多くの重要なメソッドを呼び出すことになった場合、速度低下の原因となる可能性があります。オプションを使用すると、ウォームアップフェーズ中にJITされますが、-serverを使用して実行すると、コンパイルが遅延する可能性があります。プロファイルされたコード。

HotSpotがメソッドをコンパイルする前に必要なメソッド呼び出しの数は、を設定することで変更できます-XX:CompileThreshold。テストを数回実行した場合でも、ウォームアップ中に漠然としたホットスポット（ルークウォームスポット？）でも変換されるように、20を選択します。これは過去に私にとってはうまくいきましたが、YMMVと異なる値はあなたにより良い結果を与えるかもしれません。

HotSpot VMオプションページをチェックして、-clientオプションと-serverオプションの間で異なる他のオプション、特にガベージコレクターオプションを見つけることもできます。これらはかなり異なるためです。

見る

于 2010-05-27T19:44:14.123 に答える