問題タブ [ngen]

より詳細な最適化の設定を指定することで、.NET JIT コンパイラの動作を変更する方法があるかどうか疑問に思っていました。それができない場合は、何らかのプロファイルに基づく最適化を行うことができればいいでしょう。

Phoenix をご存じない方のために説明すると、これは Microsoft のコンパイラ フレームワークであり、Microsoft のすべての新しいコンパイラの基盤となることが明らかです。CIL、x86、x64、および IA64 からコードを読み取ることができます。x86、x64、IA64、または CIL でコードを出力します。

純粋な .Net アプリを純粋なネイティブ アプリに変換するために使用できますか? つまり、.Net .dll (mscoree でさえも) をロードする必要がなく、同じセマンティクスを持つのでしょうか? もちろん、これはリフレクションを除外しています。

ngen.exe (.Net Native Image Generator) バージョン 2.0.50727.312 を使用しています。これは最新バージョンですか？そうでない場合、最新バージョンはどこからダウンロードできますか? msdn のこのページには、ダウンロードへのリンクがないようです。問題があれば、.Net Framework 3.5 用の ngen.exe が必要です。

あまり変わらないことがわかっている場合、ASP.NET アプリケーションである NGEN を使用する方がよいでしょうか? それともJITで十分ですか？

私が質問した唯一の理由は、2002 年のJeffrey Richter によるこの記事に次のように書かれているからです。

そしてもちろん、Microsoft は CLR とその JIT コンパイラの改善に懸命に取り組んでおり、より高速に実行し、より最適化されたコードを生成し、より効率的にメモリを使用できるようにしています。これらの改善には時間がかかります。待ちきれない開発者のために、.NET Framework 再頒布可能パッケージには、NGen.exe というユーティリティが含まれています。

ClickOnce 配置で NGen を使用することはできますか?

私のコンピューターでは NGen に不満があり、何が問題なのかを深く理解する方法が見つかりません。

起動するたびに、ngen は次のメッセージをログに記録します。

.NET ランタイム最適化サービス (clr_optimization_v2.0.50727_32) - サービスが一時的なエラーの制限に達しました。シャットダウンします。Service Manager から返された最後のエラー: 0x8000ffff。

コマンドラインで最適化サービスを開始しようとすると、同じエラーが再度ログに記録されます。

ngen サービスを開始し、すぐにキューを一時停止することができました (次のように 2 行のバッチ ファイルを作成することによって)。

net start clr_optimization_v2.0.50727_32

ngen キューの一時停止

だから今、次のようにさまざまなステータスレベルでアイテムを実行して、キューをクリアしようとしました:

ngen executequeueditems 3 /nologo /verbose

しかし、結果は常に次のとおりです。

壊滅的な障害 (HRESULT からの例外: 0x8000FFFF (E_UNEXPECTED))

...途中でVisual Studio 2008をアンインストール/再インストールしました。SQLサーバー2005をアンインストールし、「システムファイルチェッカー」を実行しました：sfc /scannow

アイデアが不足しており、ngen の専門家からの助けが大好きです。

「これらの壊滅的な障害の原因は何ですか?」などの情報を入手するにはどうすればよいですか? ( /verbose オプションを使用しても、検出される情報の量は増えないことに注意してください。「生成されるキューにあるファイルは何ですか?」 -- それらのファイルの一部を削除したり、特定のファイルに問題を突き止めたりすることはできますか? ..

.net Framework 2.0 は vista であり、オペレーティング システムの保護された部分であるため、アンインストールと再インストールは簡単ではありません。

更新：ここで提供されているアドバイスも試しました（最初の返信で言及されています）-しかし、同じ壊滅的な失敗メッセージが表示されます。

C:\Windows\Microsoft.NET\Framework\v2.0.50727>ngen executequeueditems /nologo 致命的なエラー (HRESULT からの例外: 0x8000FFFF (E_UNEXPECTED))

NGEN.EXEインストーラーを作成する前に、アセンブリのネイティブ イメージを生成するために使用したいと思います。これにより、バイナリが保護されることを願っていReflectorます。私はこれについて正しいですか？

現在、すべてのネイティブ イメージがネイティブ イメージ キャッシュに保存されていることがわかりました。インストーラーでパッケージ化できるネイティブ バイナリを取得する方法はありますか? 一方、ネイティブ イメージを生成した後、元のアセンブリを削除することは可能ですか?

編集:サーバーと通信するときに暗号化にハードコードされたキーを使用するアプリケーションを使用しています。.NET を使用すると、非常に簡単に鍵を手に入れることができます。

ここで誰かがngenを使用したことがありますか？どこ？なぜ？パフォーマンスの改善はありましたか？いつ、どこで使用するのが理にかなっていますか？

ターミナル サービス環境で .NET 2.0 WinForms アプリを実行すると、説明のつかない予期しない結果が発生します。私が読んだすべてのことは、JIT されたアセンブリ (つまり、NGen を使用してネイティブ イメージを作成しない) により、すべてのコード スペースがプライベート ページに格納され、ワー​​キング セットのサイズ/メモリ プレッシャーが増加することを示しています。ただし、実際の結果 (Process Explorer、VMMap、および WinDbg を使用して検証) は、JIT されたアセンブリでさえ実際に共有可能なページに配置されていることを示しています (また、アプリの複数のインスタンスが実行されている場合、別の TS の下であっても実際に共有されています)。セッション/ユーザー)。

これがなぜなのか、誰か説明できますか？これは W2K8 サーバー環境で実行されているため、ASLR は、各アセンブリの特定のベース アドレスの欠如とその結果のリベースが問題を引き起こしていない理由を説明しています。それでも、これらがネイティブの PE イメージではないという事実は、これらのアセンブリのコードがプライベート ページに格納されるという結果になるはずです。

これは、メモリ負荷を軽減するために NGen を使用して調査を開始したときに発見されましたが、JIT されたアセンブリが既に共有されていたため、実際にはワーキング セットのサイズが増加していることがわかりました。

私が見つけた最新のリファレンスはここにありますが、これも実際の調査結果とは異なります。

http://blogs.msdn.com/morgan/archive/2009/03/07/developing-net-applications-for-deployment-on-terminal-services-or-citrix.aspx

編集:最初に質問を投稿して以来、Windows Server 2003 テスト ボックスでのさらなる実験でも、明らかに JIT されたアセンブリがプロセス間で共有可能であることを示していることを追加する必要があります。私が見つけることができるすべてのアドバイスがNGenが必要であることを示している理由について、私はまだ困惑していますが、現実世界のすべての証拠はそれと矛盾しています. ここの専門家が光を当てることができることを本当に望んでいます。

ありがとう！

編集:私はすべての .NET/CLR の本を払い落としましたが、これを解決するための検索クエリのアイデアが不足しています。「何が起こっているのかわからない」というひどいしつこい気持ちを解消して、私の一日を充実させてくれるのは誰!?! :)