問題タブ [jit]

Sun の正規の JVM 実装では、かなり高度な最適化がバイトコードに適用され、コードが数回実行された後にネイティブに近い実行速度が得られます。

問題は、このコンパイルされたコードが、同じ関数/クラスを後で使用するときに使用するためにディスクにキャッシュされないのはなぜですか?

現状では、プログラムが実行されるたびに、JIT コンパイラーはコンパイル済みのバージョンのコードを使用するのではなく、新たに起動します。この機能を追加すると、バイトコードが本質的に解釈されているときに、プログラムの初期実行時間が大幅に短縮されるのではないでしょうか?

私たちがよく知っているように、.NET はIntegerOverflow整数がオーバーフローするたびに例外をスローします。これはとても良いことだと思います。

しかし、どうやってこれを速くするのだろうか。x86 は整数のオーバーフローをトラップしません。他のアーキテクチャでそれができるとしたら、私は驚きます。私が x86 で見つけた最善の解決策は、すべての算術演算の後に「INTO」命令を配置することです。しかし、それは顕著な減速につながると思います。

操作がオーバーフローできないことが証明できる場合は、コンパイラで静的チェックを行ってこれを回避できます。しかし、コンパイラが操作の結果を判断できない場合、パフォーマンスが重要な内部ループはどうなるでしょうか?

Mono のソースを見てみましたが、これらのチェックを行っている場所が見つかりませんでした。

それで、彼らが実際に何をしているのか、誰かが手がかりを持っていますか? 本当に知りたいです。

余談ですが、.NET JITC が出力する x86 コードを確認する方法はありますか?

作品にはdalvikvm用のjitコンパイラモジュールがあり、その結果は非常に有望であると読みました。実行速度が100％向上したと言う人もいます。それがAndroidリリースにいつ組み込まれるかについて誰かが考えを持っていますか？ネクサス1のRAMの量（512MB）は、jitがまもなく導入される可能性があることを示唆しています。Android 2.5かもしれませんか？

これまでに、ほとんどの主流のブラウザーは、最適化JITコンパイラーをJavaScriptインタープリター/仮想マシンに統合し始めました。それは誰にとっても良いことです。さて、私は彼らがどの最適化を実行するのか、そしてそれらを最大限に活用する方法を正確に知るのは難しいでしょう。主要なJavaScriptエンジンのそれぞれにおける最適化に関するリファレンスは何ですか？

バックグラウンド：

私は、より高レベルでより安全な言語からJavaScriptを生成するコンパイラーに取り組んでいます（恥知らずなプラグ：OPAと呼ばれ、非常にクールです）。生成するアプリケーションのサイズを考えると、JavaScriptコードを可能な限り高速でメモリ効率が高いこと。高レベルの最適化を処理できますが、どの低レベルのコードが最良の結果を生成するかを知るために、どのランタイム変換が実行されるかについてもっと知る必要があります。

一例として、私の頭の中から：私がコンパイルしている言語は、すぐに怠惰のサポートを統合するでしょう。JITエンジンは怠惰な関数定義でうまく動作しますか？

次のコードは、Visual Studio内でリリースを実行する場合と、VisualStudio外でリリースを実行する場合で異なる出力を提供します。Visual Studio 2008を使用しており、.NET3.5をターゲットにしています。.NET3.5SP1も試しました。

Visual Studioの外部で実行している場合は、JITが起動する必要があります。（a）C＃で何か微妙なことが起こっているのに欠けているか、（b）JITが実際にエラーになっています。JITがうまくいかないかどうかは疑わしいですが、他の可能性が不足しています...

Visual Studio内で実行する場合の出力：

Visual Studioの外部でリリースを実行した場合の出力：

理由は何ですか？

私は最近それについて考えていました.JITコンパイルに与えられるほとんどの利点は、多かれ少なかれ代わりに中間形式に起因するはずであり、ジッティング自体はコードを生成するための良い方法ではないようです.

したがって、これらは私がよく耳にする主なJITコンパイル支持の議論です。

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

事前コンパイルにも利点がなかったわけではありません。ジャストインタイムコンパイルには時間の制約があります。プログラムの起動中にエンド ユーザーを永遠に待たせることはできないため、どこかで実行するというトレードオフがあります。ほとんどの場合、最適化が少なくなります。私の友人は、関数のインライン展開とループの展開を "手動で" (処理中のソース コードを難読化する) ことで、C#数値処理プログラムのパフォーマンスにプラスの影響を与えたというプロファイリングの証拠を持っていました。私の側で同じことを行い、私のCプログラムが同じタスクを実行しても、肯定的な結果は得られませんでした。これは、私のコンパイラーが行うことを許可された広範な変換によるものだと思います。

それでも、私たちはジットされたプログラムに囲まれています。C#とJavaはどこにでもあり、Python スクリプトはある種のバイトコードにコンパイルできます。他のプログラミング言語も同じように動作するはずです。私が行方不明になったのには、正当な理由があるに違いありません。では、ジャストインタイムコンパイルが事前コンパイルよりも優れている理由は何でしょうか?

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

ほとんどのランタイム (またはコンパイラー) は、ジャストインタイムまたは事前にコンパイルすることを好みます。コンパイラが最適化を実行するためにより多くの時間を割くことができるため、私には事前コンパイルの方が優れた代替手段のように思えますが、Microsoft、Sun、および他のすべての企業がなぜ逆の方向に進んでいるのか疑問に思っています。ジャストインタイムでコンパイルされたプログラムでの私の経験では、基本的な最適化が貧弱であったため、プロファイリング関連の最適化については少し懐疑的です。

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

毎日実行される Java プロセスがあり、JIT によって完全に最適化されるまでに約 1,000 または 2,000 ヒットします。私がやりたいのは、JIT情報を保存して、翌日最適化された状態で開始できるようにすることです。これは可能であるように思われますが、そうする方法を見つけることができませんでした。

Q1) なぜ C# は最初に IL にコンパイルされ、次に実行時に JIT にコンパイルされ、仮想マシン上で実行されるのですか (?)。それとも、ネイティブのマシンコードに準拠した JIT ですか?

Q2) 2 番目が正しい場合 (ネイティブ マシン コードに準拠した JIT)、コードが実行される .NET サンドボックスはどこにありますか?

Q3) また、そもそもコードを IL にコンパイルする理由を教えてください。常にネイティブ マシン コードにコンパイルしないのはなぜですか? ngenと呼ばれるMSのツールがありますが、なぜそれがオプションなのですか?

私は最近、実際のリクエストの処理を開始する前に (高スループット要件で) アプリをウォームアップする必要があるシナリオについて学びました。この背後にあるロジックは、JIT がそのパフォーマンス マジックを実行できるようにすることでした。

これはJavaアプリの標準ですか、それともメモリが重い(フットプリント)アプリに対して一般的に行われますか?

汎用コレクションが列挙子をどのように最適化したかを確認するために mscorlib を調べていたところ、次のことがわかりました。

スタック サイズは 3 で、バイトコードのサイズは 80 バイトである必要があります。メソッドの名前付けはMoveNextRare私を悩ませ、エラーのケースと空のコレクションのケースが含まれているため、明らかにこれは関心の分離に違反しています。

スタック スペースを最適化し、JIT を支援するために、メソッドがこのように分割されていると仮定しMoveNextます。また、パフォーマンスのボトルネックの一部についても同じことを行いたいと考えていますが、ハード データがなければ、ブードゥー教のプログラミングを貨物に変えたくありません。カルト;）

ありがとう！フロリアン