私は最近それについて考えていました.JITコンパイルに与えられるほとんどの利点は、多かれ少なかれ代わりに中間形式に起因するはずであり、ジッティング自体はコードを生成するための良い方法ではないようです.
したがって、これらは私がよく耳にする主なJITコンパイル支持の議論です。
- ジャストインタイム コンパイルにより、移植性が向上します。それは中間フォーマットに起因するものではありませんか？つまり、仮想バイトコードをマシンに取り込んだら、それをネイティブ バイトコードにコンパイルすることを妨げるものは何もありません。移植性は、「実行」段階ではなく、「配布」段階の問題です。
- では、実行時にコードを生成するのはどうでしょうか。まあ、同じことが当てはまります。真のジャストインタイムのニーズに対応するジャストインタイム コンパイラをネイティブ プログラムに統合することを妨げるものは何もありません。
- ただし、ランタイムはそれを一度だけネイティブ コードにコンパイルし、結果の実行可能ファイルをハード ドライブのどこかにキャッシュのようなものに保存します。ええ、確かに。しかし、それは時間の制約の下でプログラムを最適化したものであり、それ以降は改善されません。次の段落を参照してください。
事前コンパイルにも利点がなかったわけではありません。ジャストインタイムコンパイルには時間の制約があります。プログラムの起動中にエンド ユーザーを永遠に待たせることはできないため、どこかで実行するというトレードオフがあります。ほとんどの場合、最適化が少なくなります。私の友人は、関数のインライン展開とループの展開を "手動で" (処理中のソース コードを難読化する) ことで、C#数値処理プログラムのパフォーマンスにプラスの影響を与えたというプロファイリングの証拠を持っていました。私の側で同じことを行い、私のCプログラムが同じタスクを実行しても、肯定的な結果は得られませんでした。これは、私のコンパイラーが行うことを許可された広範な変換によるものだと思います。
それでも、私たちはジットされたプログラムに囲まれています。C#とJavaはどこにでもあり、Python スクリプトはある種のバイトコードにコンパイルできます。他のプログラミング言語も同じように動作するはずです。私が行方不明になったのには、正当な理由があるに違いありません。では、ジャストインタイムコンパイルが事前コンパイルよりも優れている理由は何でしょうか?
EDITいくつかの混乱を解消するために、私はすべて実行可能ファイルの中間表現に賛成であると述べることが重要かもしれません。これには多くの利点があります (実際、ジャストインタイムコンパイルのほとんどの引数は、実際には中間表現の引数です)。私の質問は、それらをネイティブ コードにコンパイルする方法についてです。
ほとんどのランタイム (またはコンパイラー) は、ジャストインタイムまたは事前にコンパイルすることを好みます。コンパイラが最適化を実行するためにより多くの時間を割くことができるため、私には事前コンパイルの方が優れた代替手段のように思えますが、Microsoft、Sun、および他のすべての企業がなぜ逆の方向に進んでいるのか疑問に思っています。ジャストインタイムでコンパイルされたプログラムでの私の経験では、基本的な最適化が貧弱であったため、プロファイリング関連の最適化については少し懐疑的です。
C コードの例を使用したのは、事前コンパイルとジャストインタイムコンパイルの例が必要だったからです。Cコードが中間表現に出力されなかったという事実は、状況とは関係ありません。なぜなら、事前にコンパイルした方がすぐにより良い結果が得られることを示す必要があったからです。