私は、JIT の本質的な利点 (実行時にのみ利用可能な情報を使用できる) により、コンパイルされたコードのパフォーマンスの点では、JIT コンパイラが最終的に AOT コンパイラを上回るだろうと考えていました。1 つの議論は、AOT コンパイラはコードのコンパイルに多くの時間を費やすことができますが、サーバー VM も多くの時間を費やす可能性があるということです。
JIT は場合によっては AOT コンパイラーよりも優れているようですが、ほとんどの場合、依然として遅れをとっているようです。
そこで私の質問は、JIT コンパイラが AOT コンパイラに勝つことを妨げている具体的な困難な問題は何なのかということです。
編集：
よくある議論:
- AOTコンパイラは高度な最適化に多くの時間を費やすことができる->サーバー VM を数日間実行している場合は、同じ時間、あるいはそれ以上の時間を費やすことになります。
- バイトコードの解釈にはコストがかかる->最近では、ほとんどの JIT コンパイラーはネイティブマシン命令をキャッシュします。
さらにもう一つの編集:
具体的な例については、この記事を参照してください。Swing パフォーマンスの向上: JIT と AOT コンパイルこの記事から私が理解できることは、著者が基本的に言っているのは、ホットスポットがない場合、実行時情報を持つことの利点が減り、JIT のオーバーヘッドのない AOT が勝つということです。しかし、40% もですか?? あまり意味がないように思われます。比較された JIT コンパイラーがこの状況に合わせて調整されていなかっただけなのでしょうか? それとも、もっと根本的な問題なのでしょうか?
ベストアンサー1
あります明確なトレードオフJIT と AOT (事前) コンパイルの違い。
ご指摘のとおり、JIT は最適化に役立つ実行時情報にアクセスできます。これには、実行中のマシンに関するデータも含まれ、プラットフォーム固有のネイティブ最適化が可能になります。ただし、JIT にはバイトコードをネイティブ命令に変換するオーバーヘッドもあります。
このオーバーヘッドは、高速な起動やほぼリアルタイムの応答が必要なアプリケーションで顕著になります。マシンに高度な最適化のための十分なリソースがない場合や、コードの性質上、JITが効果的でない場合もあります。「積極的に最適化されています。」
例えば、リンクした記事:
... 明らかなパフォーマンスのボトルネックがない場合、何を改善すればよいのでしょうか? ご想像のとおり、プロファイル ガイド付き JIT コンパイラにも同じ問題があります。積極的に最適化すべきホット スポットがいくつかあるのではなく、そのまま残されている「ウォーム スポット」が多数あります。
AOT コンパイラは、最適化に好きなだけ時間を費やすことができますが、JIT コンパイルは時間要件 (応答性を維持するため) とクライアント マシンのリソースによって制限されます。このため、AOT コンパイラは、JIT ではコストがかかりすぎる複雑な最適化を実行できます。
この SO の質問も参照してください:JIT コンパイラとオフライン コンパイラ