41

私は、JIT 固有の利点 (実行時にのみ利用可能な情報を使用できる) により、コンパイルされたコードのパフォーマンスに関して、JIT コンパイラーが最終的に AOT コンパイラーに勝ると考えていました。1 つの議論は、AOT コンパイラはコードのコンパイルにより多くの時間を費やすことができるが、サーバー VM も多くの時間を費やす可能性があるというものです。

場合によっては JIT が AOT コンパイラに勝っているように見えることは理解していますが、ほとんどの場合、依然として遅れをとっているようです。

私の質問は、JIT コンパイラーが AOT コンパイラーを打ち負かすのを妨げている特定の困難な問題は何ですか?

編集:
いくつかの一般的な引数:

  • AOT コンパイラは、高度な最適化により多くの時間を費やすことができます->サーバー VM を何日も実行している場合は、それ以上ではないにしても、同じ時間を費やすことができます。
  • バイトコードの解釈にはコストがかかります->最近ではほとんどの JIT コンパイラがネイティブのマシン命令をとにかくキャッシュします。

さらに別の編集:
特定の例については、次の記事を参照してください: Improving Swing Performance: JIT vs AOT Compilation . この記事から収集できることから、著者は基本的に、ホットスポットがない場合、ランタイム情報を持つことの利点が減少し、JIT のオーバーヘッドのない AOT が勝つと言っています。しかし、40％まで?? それはあまり意味がないようです。比較した JIT コンパイラがこの状況に合わせて調整されていなかったというだけですか? それとももっと根本的なものですか？

4

2 に答える 2

35

JIT と AOT (事前) コンパイルの間には明確なトレードオフがあります。

おっしゃるとおり、JIT は最適化に役立つランタイム情報にアクセスできます。これには、実行中のマシンに関するデータが含まれ、プラットフォーム固有のネイティブ最適化が可能になります。ただし、JIT には、バイトコードをネイティブ命令に変換するオーバーヘッドもあります。

このオーバーヘッドは、高速な起動またはほぼリアルタイムの応答が必要なアプリケーションでしばしば明らかになります。また、マシンに高度な最適化のための十分なリソースがない場合、またはコードの性質が「積極的に最適化」できないような場合、JIT はそれほど効果的ではありません。

たとえば、リンクした記事から抜粋:

... 明確なパフォーマンスのボトルネックがない場合、何を改善する必要がありますか? ご想像のとおり、プロファイル ガイド付き JIT コンパイラにも同じ問題が存在します。いくつかのホット スポットを積極的に最適化する代わりに、そのままにしておく「ウォーム スポット」がたくさんあります。

AOT コンパイラーは最適化に好きなだけ時間を費やすことができますが、JIT コンパイルは (応答性を維持するための) 時間要件とクライアント マシンのリソースによって制限されます。このため、AOT コンパイラーは、JIT 中にコストがかかりすぎる複雑な最適化を実行できます。

この SO の質問も参照してください: JIT コンパイラとオフライン コンパイラ

于 2011-09-29T01:16:49.427 に答える