.NETのCLRのJITは、あらゆる方法、毎回コンパイルしていますか？
https://stackoverflow.com/questions/1255803
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian解決
注：この答えは、「毎の実行」状況にあります。コードは通常、あなたがプログラムを実行するたびにJITコンパイルされています。 NGEN に使用するか、<のhref = "https://msdn.microsoft.com /en-us/vstudio/dotnetnative.aspx」のrel = "noreferrer">。NETネイティブには、その話を変更し、あまりにも...
は、ホットスポットとは異なり、CLRのJITコンパイルが常にの正確の実行に一回。それは解釈したことがない、それは実際の使用量に基づいて、以前よりも重い最適化して再コンパイルすることはありません。
このはもちろん、変更される可能性があり、それは、V1以来、その方法をされていると私はそれがいつでもすぐに変更することを期待しないでください。
利点は、JITがずっと簡単になるということです - すでに実行されている「古い」コードを検討する必要はありません、もはやなど有効な前提に基づい最適化を元に戻す
。.NETの賛成で一つのポイントは、ほとんどのCLR言語は多くのインライン化を行うことができることを意味、デフォルトでメソッド非仮想作るということです。最初に、最適化を元に戻す（または条件依然として実際のタイプに基づいて、インラインコードを使用するいくつかのケースでは、いくつかの巧妙なものを行い）、その時点で上書きされるまでホットスポットは、メソッドをインライン化することができます。心配することは少ない仮想メソッドでは、.NETは、主に仮想何かをインライン化することができないの痛みを無視することができます。
編集：上記は、デスクトップのフレームワークについて説明します。それは、必要に応じて再びJITting、したい場合Compact Frameworkでは、ネイティブコードをスローします。しかし、これはまだホットスポットの適応最適化のようではありません。
マイクロフレームワークではなく、コードを解釈、全く明らかにJITありません。これは非常に制約のあるデバイスのための理にかなっています。 （私は、マイクロフレームワークについて多くを知ると言うことはできません。）
他のヒント
.NETランタイムは常に実行前にコードのJITをコンパイルします。だから、それは解釈されることはありません。
あなたはの CLRの設計選択する <でいくつかのより多くの興味深い読書を見つけることができますアンダース・ヘルスバーグを持つ/ em>の。特に、一部ます：
私は、MicrosoftがILは、常に、決してコンパイルしないと解釈されることが決定したことを読みました。どのように指示における符号化タイプ情報は、通訳がより効率的に実行に役立ちますか。
アンダース・ヘルスバーグ：インタプリタがやみくも命令は、スタックの一番上に何があるかを追跡することなく、言うことを行うことができた場合、それはより速く行くことができます。それはIADDを見たとき、例えば、インタプリタは第一種であることを追加しているかを把握する必要はありません、それは整数アドオンです知っています。誰かがすでにスタックが正しく見えることを確認したと仮定すると、それはそこにいくつかの時間を削減しても安全だ、とあなたは通訳のためにその気に。我々のケースでは、しかし、我々はCLRと解釈したシナリオを対象とする意図はありません。私たちは、常にJIT [ジャストインタイムコンパイル]意図、およびJITの目的のために、我々はとにかく種類の情報を追跡する必要がありました。我々はすでに型情報を持っているので、それが実際の指示でそれを置くために私たちに何かを購入していません。
ビル・ベナーズ：現代の多くのJVM [Java仮想マシン]彼らはバイトコードを解釈することによって開始した適応最適化を、行います。それは、それらが天然にそれをコンパイルし、時間の90％〜80％に実行されるコードの10％〜20％を見つけるために実行されると、それらはアプリケーションをプロファイリング。彼らは必ずしもジャストインタイムしかし、これらのバイトコードをコンパイルしないでください。彼らはネイティブにコンパイルし、バックグラウンドで最適化されているようメソッドのバイトコードはまだインタプリタにより実行することができます。ネイティブコードの準備ができたら、それはバイトコードを置き換えることができます。解釈のシナリオを対象としないことで、あなたは完全にCLRで実行にそのアプローチを除外している？
アンダース・ヘルスバーグ：いいえ、私たちは完全にそれを除外していません。我々はまだ解釈することができます。私達はちょうど解釈するために最適化されていません。私たちは、これまで解釈すること最高性能のインタプリタを書くために最適化されていません。私は、誰もが任意のより多くのことをしないと思います。 10年前にセットトップボックスのために、それは興味深いだったかもしれません。しかし、それはもはや面白いん。 JIT技術を使用して、複数の可能なJIT戦略を持つことができるポイントに得ています。我々は、特定のメソッドを実行していることをすべての時間を発見するときには、少しでも多くの時間を費やしていると最適化のより良い仕事をして、別のJITを使用して、その後、ちょうどすぐにリッピング速いJITを使用して想像し、することができます。そんなに多くのあなたはJIT単位で行うことができますがあります。
メモリ不足のデバイスのために、将来のあるトレースベースのJITを見ていいだろう。これは主に、解釈のホットスポットを見つけ、アセンブラにそれらを変換し、それらをキャッシュします。私は、これはGoogleが自分のAndroid JITで何をするかだと思うとマイクロソフトリサーチには、のために現在進行中の研究プロジェクトを持っていますトレースベースのJITます。
私は記事を見つけ、の SPUR：Trace- CILのためのベースのJITコンパイラの ..多分これのいくつかは
私はそうは思わない、と私はそれが今までにすべきとは思いません。
どのようにJITは、特定のメソッドが呼び出されますどのように多くの時間を知っているだろうか？意思決定への解釈の要因の頻度ではないでしょうか？
私はまた、JITコンパイラが解釈が関数自体を解釈することなく、最高のだろうかどうかを判断するための機能を解析することができるだろうどれだけ疑問でしょう。そして（メソッドの少なくとも一つのパスが行われたことを）事実は、単に最初の場所でコンパイルされた方法を決定しようとしているのオーバーヘッドを減らすために、各メソッドをコンパイルするほうがよいのではないだろうことを考えると？
