JITコンパイルの欠点は何ですか?

java jit
JITコンパイルの欠点は何ですか?

Just In Time Compilationには、多くの理論上の利点があります。マシン、フラグの状態、コードの使用方法に関する詳細情報があります。 実行前の時間のかかるコンパイルを回避できるため、開発サイクルが短縮されます。

簡単に言えば、JITコンパイルはアプローチとして優れているようです。ある程度のオーバーヘッドがありますが、十分にスマートであれば、それを相殺するのに十分なほどコードを高速化できます。

しかし、それがすべてではないと思います。 理論的および実用的な欠点は何ですか? はい、「メモリ消費量の増加」と同様に、「起動時間が遅い」とよく言われますが、それ以上あるのでしょうか。

たとえば、トレースとJITコンパイルはCPUキャッシュを破壊しますか? プログラムが大きく、特に多くの特にホットなパスがない場合、価値のあるものよりも多くの時間をトレースとJIT-tingに費やすリスクがありますか?

誰かがこれについて、またはJITに固有の問題を解決することについて論文を書いているようです。 誰かが測定値を持っている場合、それでもなお良い。

_編集:解釈と比較するのではなく、事前のコンパイル(潜在的にフィードバック指向の最適化)と比較して、ジャストインタイムコンパイルについて話します。

  5  0


ベストアンサー

JITが適切に機能していれば、実際の欠点はありません。 とはいえ、ホットスポットは非常に複雑であるため、ホットスポットの安定化には長い時間がかかりました。 ベンチマークデータに関しては、いつでも次の実験を実行できます。

SPECjbb、SPECjvm、または独自のベンチマークを実行し、 `java`を実行するコマンドラインを変更して以下を含めます。

-Xint

これにより、実行時コンパイルが発生しなくなります。

1


_
たとえば、トレースとJITコンパイルはCPUキャッシュを破壊しますか? プログラムが大きく、特に多くの特にホットなパスがない場合、価値のあるものよりも多くの時間をトレースとJIT-tingに費やすリスクがありますか?
_

それはもっともらしい。 しかし、最適化ゲーム全体は、さまざまな要因をトレードオフして、平均的なケースで最高の結果を達成することです。 ほとんどのアプリケーションには、ホットパスがすべて標準クラスライブラリにある場合でも、比較的ホットパスとコールドパスがあります。

あなたが効果的に言っていることに加えて、この仮想的なアプリケーションはJITコンパイルの価値がないということです。 その場合、「修正」は、JITコンパイルをオフにして実行することです。

_
誰かがこれについて、またはJITに固有の問題を解決することについて論文を書いているようです。
_

あなたはそう思ったでしょう。

しかし、逆に、Oracle、IBMなどのJVMでJITコンパイラを構築および保守する人々は、自分のアイデアや結果について世界中に伝えることが制限される可能性があります…​ 商業的理由のため。 (ソースコードの公開は一つのことですが、彼らが特定の戦略を選んだ理由を説明することは別のことです。)動機付けの問題もあります。

1


主な問題は、現在VMをロードする必要があることです。これは、コンパイラーとランタイム全体をメモリーにロードするため、高速ではありません。

いったんロードされると、コンパイルとプロファイリングは長期にわたってバックグラウンドで実行でき、ランタイムの状況に合わせて手動で最適化することにより、静的にコンパイルされた言語よりも理論的に大幅に高速化できます。 (関数に副作用がなく、同じパラメーターで1秒間に50回呼び出される外部データに依存しないと判断された場合を考えてください。動的にコンパイルされた言語は、定数を返すことを簡単に学習できます。 これは、静的にコンパイルされた言語では単純に一般的に実行できないものです。)

これは必ずしもVMの問題になるとは限らないことに注意してください。VMをOSに組み込み、複数のアプリでVMを再利用し始めると、この問題はなくなります。

また、vmバイトコードはより少ないバイトでより多くの処理を行う傾向があります。 これが、Microsoftが最初にExcel / Word(pre-java)でVMを使用した理由であり、単にコードサイズを小さくすることでした。

この部分は推測に過ぎませんが、読み取り/書き込みがボトルネックにならないため、カスタムCPUを最適化してより高速に動作させることができると思います。 RISCシステムは、I / OではなくCPU操作がボトルネックであると想定する傾向があります。これが常に真実であるとは思いません。ハードウェア。

私のポイント? 本質的な欠点はなく、実際の主な欠点はロード時間です。

ああ、もう1つの現実の欠点は、JavaとC#がヒープ上のすべてのオブジェクトを割り当てる傾向があることです。 ヒープの割り当ては、C#/ JavaではC ++よりもはるかに高速ですが、スタックの割り当て速度には達していません。

0


タイトルとURLをコピーしました