ジャストインタイムコンパイルとアヘッドオブタイムコンパイルの長所は何ですか？

質問

最近考えているのですが、ほとんどの利点が JIT コンパイルに与えられた利点のほとんどは、多かれ少なかれ、代わりに中間フォーマットに帰せられるべきであり、JIT それ自体はコードを生成するためのあまり良い方法ではないような気がします。

というわけで、これらは主に プロJIT のコンパイルに関する議論です。

1. ジャストインタイムコンパイルは、より大きな移植性を可能にします。 それは中間フォーマットに起因しているのでは？つまり、いったんマシンに取り込んだ仮想バイトコードをネイティブバイトコードにコンパイルすることを妨げるものは何もないのです。移植性は「配布」段階の問題であり、「実行」段階での問題ではありません。
2. なるほど、では実行時にコードを生成することについてはどうでしょうか？ まあ、同じことが当てはまります。本当のジャストインタイム ニーズのためのジャストインタイム コンパイラーを、ネイティブ プログラムに統合することを妨げるものは何もありません。
3. しかし、ランタイムはとにかく一度だけネイティブ コードにコンパイルし、結果の実行ファイルをハードドライブのどこかのキャッシュに保存します。 ええ、もちろんです。しかし、それは時間の制約の下であなたのプログラムを最適化したのであって、そこから先が良くなるわけではありません。次の段落を参照してください。

とは違うのです。 先行 のコンパイルにも利点がなかったわけではありません。 ジャストインタイム コンパイルには時間の制約があります。プログラムが起動する間、エンドユーザーをずっと待たせておくわけにはいかないので、どこかでトレードオフを行う必要があるのです。たいていの場合、最適化の度合いを減らすだけです。私の友人は プロファイリングの証拠 関数をインライン化し、ループを手動で展開する (その過程でソース コードを難読化する) ことで、パフォーマンスにプラスの影響があったというプロファイリングの証拠があります。 C# 数値計算プログラムにおいて、パフォーマンスに良い影響を与えました。 C で同じことをしても、良い結果は得られませんでした。これは、私のコンパイラに許された広範な変換によるものだと思います。

それなのに、私たちはジットプログラムに囲まれているのです。 C# と Java はどこにでもありますし、Pythonのスクリプトはある種のバイトコードにコンパイルできますし、他のプログラミング言語の束も同じだと思います。私が見逃している正当な理由があるはずです。では、なぜ ジャストインタイム のコンパイルが アヘッドオブタイム コンパイルに優れているのでしょうか？

EDIT いくつかの混乱を解消するために、私が実行ファイルの中間表現に賛成であることを述べるのは重要かもしれません。これには多くの利点があります (そして実際、のほとんどの議論は、を使用することです)。 ジャストインタイム に対するほとんどの議論が、実は中間表現に対する議論なのです）。私の質問は、それらがどのようにネイティブ コードにコンパイルされるべきかについてです。