ジャストインタイムコンパイルと事前コンパイルの利点は何ですか? 質問する

最近、このことについて考えていましたが、私には、ジットコンパイルは、多かれ少なかれ中間形式に起因するべきであり、JIT 自体はコードを生成するためのあまり良い方法ではありません。

これが主なJIT賛成派私がよく耳にするコンパイル時の議論:

1. ジャストインタイムコンパイルにより、移植性が向上します。それは中間形式に起因するのではないですか? つまり、仮想バイトコードをマシンにインストールしたら、それをネイティブ バイトコードにコンパイルすることを妨げるものは何もありません。移植性は「配布」フェーズで問題になるものであり、「実行」フェーズでは問題になりません。
2. さて、実行時にコードを生成するのはどうでしょうか?そうですね、同じことが当てはまります。実際のジャストインタイムのニーズに対応するジャストインタイム コンパイラをネイティブ プログラムに統合することを妨げるものは何もありません。
3. しかし、ランタイムはそれをネイティブ コードに一度だけコンパイルし、結果として得られた実行可能ファイルをハード ドライブのどこかの何らかのキャッシュに保存します。はい、確かにそうです。しかし、それは時間的制約の下でプログラムを最適化しただけで、そこから先は改善されません。次の段落を参照してください。

それは事前にコンパイルにも利点はありませんでした。ジャストインタイムコンパイルには時間的な制約があります。プログラムの起動中にエンドユーザーをいつまでも待たせるわけにはいかないので、どこかでトレードオフが発生します。ほとんどの場合、最適化があまり行われません。私の友人はプロファイリング証拠関数のインライン化とループの展開を「手動で」（その過程でソースコードを難読化する）すると、パフォーマンスに良い影響があった。C#数値計算プログラム。私の側でも同じことをしている。Ｃ同じタスクを実行するプログラムでは、肯定的な結果は得られませんでした。これは、コンパイラが実行できる変換が広範囲に及んだためだと考えています。

しかし、私たちは JIT されたプログラムに囲まれています。C#そしてジャワどこにでも存在するので、Pythonスクリプトは何らかのバイトコードにコンパイルできますし、他のプログラミング言語でも同じことができるはずです。私が見逃している理由があるはずです。では、ジャストインタイムコンパイルが優れている事前にコンピレーション？

編集混乱を解消するために、私は実行ファイルの中間表現に全面的に賛成だと述べることが重要かもしれません。これには多くの利点があります（そして、実際には、ジャストインタイムコンパイルは実際には中間表現の引数です。私の質問は、それらをネイティブ コードにコンパイルする方法についてのものです。

ほとんどのランタイム（またはコンパイラ）は、ジャストインタイムまたはアヘッドオブタイムのいずれかのコンパイルを好みます。事前にコンパイルはコンパイラが最適化を実行する時間が増えるため、私にとってはより良い選択肢のように思えますが、なぜMicrosoft、Sun、その他の企業が逆のことをしているのか不思議です。私はプロファイリング関連の最適化については少し疑問に思っています。ジャストインタイムコンパイルされたプログラムは基本的な最適化が不十分でした。

Cコードの例を使用したのは、事前にコンパイル対ジャストインタイムコンパイル。Ｃコードが中間表現に出力されなかったことは状況とは関係ありません。私が示したかったのは、事前にコンパイルにより、より良い結果がすぐに得られます。