問題タブ [jit]

Visual Studio2005で「Webサイト」としてコンパイルされ、Web展開プロジェクトを使用してプリコンパイル/パッケージ化されたASP.NET 2.0アプリケーション（MSIからIIS 6.0にインストールされたもの）があります。開発者は、次のバージョンのWebアプリケーションへの変更を検討する必要がありますが、このバージョンでは変更されません）。

アプリケーションがリサイクルされるときはいつでも（たとえば、web.configに変更が加えられると）、最初のヒットで、ASP.NETはアプリケーションをJITします。この一環として、ログインページに必要なすべてのアセンブリを取得し、それらをTemporary ASP.NET Files'assembly \ dl3'ディレクトリのネイティブコードにコンパイルします。これには20〜60秒かかります。これは、まれにしか発生しないリサイクルでのみ発生しますが、発生すると、ページの読み込みにかかる時間が大幅に長くなり、これを最適化できる可能性があると思います。

考慮する必要のあるDLLは122あるようです。そのうちのいくつかはプリコンパイルされたコードビハインドであり、その他はWebサイトのサードパーティコンポーネントです（たとえば、NHibernate.dll、レポートコンポーネントなど）。

なぜすべてを再コンパイル/再JITするのですか？ほとんどのアセンブリが変更されていないことを検出せず、変更を試みないのはなぜですか？問題の原因がバッチコンパイルではないことを証明できますか？（<compilation debug="false"> web.configで設定しました。）

他の質問は、NGENが役立つかもしれないことを示唆していますが、ASP.NET1.xでは使用できないと読みました。2.0を使用していますが、どちらの方法でも明確な答えを見つけることができません。

ターミナル サービス環境で .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 の本を払い落としましたが、これを解決するための検索クエリのアイデアが不足しています。「何が起こっているのかわからない」というひどいしつこい気持ちを解消して、私の一日を充実させてくれるのは誰!?! :)

私はC＃（基本的にはマルチトラックエディター）でDSPアプリケーションを書いています。私はかなり長い間さまざまなマシンでプロファイリングを行ってきましたが、いくつかの「奇妙な」ことに気づきました。

私の自宅のマシンでは、再生ループの最初の実行は利用可能な時間の約50％〜60％を占め（JITがその仕事をしているためだと思います）、その後のループでは安定した5になります。 ％ 消費。問題は、低速のコンピューターでアプリケーションを実行すると、最初の実行に使用可能な時間よりも多くの時間がかかり、再生が中断され、出力オーディオが混乱することです。これは許容できません。その後、消費量は8％〜10％になります。

最初の実行後も、アプリケーションは時間のかかるルーチンを時々（2秒ごとに）呼び出し続けます。これにより、5％の安定した消費で、20％〜25％の非常に短いピークが発生します。アプリケーションをしばらく実行すると、これらのピークも7％〜10％に低下することに気づきました。（JITがコードのこれらの部分を再コンパイルしたことが原因かどうかはわかりません）。

ですから、私はJITに深刻な問題を抱えています。アプリケーションは非常に遅いマシンでも正常に動作しますが、これらの「コンパイルストーム」は大きな問題になります。私はこの問題を解決する方法を見つけようとしていて、起動時に事前にアプリケーションに「スクイーズ」するようにアプリケーションに指示する属性ですべての「賢明な」ルーチンをマークするというアイデアを思いつきました。 、したがって、本当に必要なときに完全に最適化されます。しかし、これは単なるアイデアであり（私もあまり好きではありません）、問題全体に対してより良い解決策があるのではないかと思います。

皆さんのご意見をお聞かせください。

（NGENアプリケーションはオプションではありません。私は、取得できるすべてのJIT最適化が好きで欲しいです。）

編集：

メモリ消費とガベージコレクションのキックは問題ではありません。オブジェクトプールを使用しており、再生中のメモリの最大ピークは304Kbです。

C ++などの静的にコンパイルされた言語の実行時パフォーマンスを改善するためにJITトリックを使用している人はいますか？実行時に行われた監視に基づくホットスポット分析と分岐予測は、コードのパフォーマンスを向上させる可能性があるようですが、実行時にそのような監視と変更の実装が仮想マシンでのみ可能であるという基本的な戦略的理由があるかもしれません。動的言語愛好家が統計の収集とコードの再配置について話しているのを聞きながら、C ++コンパイラの作成者が「C++で記述されたプログラムでも同じことができる」とつぶやくのを耳にしたことをはっきりと覚えていますが、このメモリをサポートする証拠をWebで検索することはできません。

への呼び出しで終了する C# コンストラクターではthis(...)、実際の呼び出しは次のように変換されます。

ここでの DS レジスタの内容は何ですか? データ セグメントであることはわかっていますが、この呼び出しは VMT テーブルなどを介したものですか? this(...)ただし、仮想メソッドへの呼び出しではなく、単なる別のコンストラクターであるため、それは疑わしいです。

F11 キーを押して (Visual Studio 2008) にトレースすると、その呼び出し命令で、プログラムがアクセス違反でクラッシュします。

コードはサード パーティのコントロール ライブラリの奥深くにあります。ソース コードはありますが、C# コードを介してトレースできる十分なデバッグ情報を使用してコンパイルされたアセンブリがなく、逆アセンブラーのみを使用して、それを実際のコードに合わせます。

問題の C# コードは次のとおりです。

Reflector には、次の IL コードが表示されます。

失敗するのは、同じクラスの他のコンストラクターへの最後の呼び出しです。デバッガーが他のメソッド内に現れることはなく、クラッシュするだけです。

JITting 後のメソッドの逆アセンブリは次のとおりです。

基本的に私が求めているのはこれです：

• ds:[ADDR]ここでの間接化の目的は何ですか? VMT-tableは仮想専用ですよね？そしてこれはコンストラクタです
• コンストラクターはまだ JIT されていない可能性があります。これは、呼び出しが実際に JIT shim を介して呼び出されることを意味する可能性がありますか? 私はここで深海にいるのではないかと心配しているので、何でも役立つかもしれません.

編集：まあ、問題は悪化したか、改善したか、または何でも。

Visual Studio 2008 ソリューションの C# プロジェクトで .NET 機能を開発し、Visual Studio を使用してデバッグと開発を行っています。

ただし、最終的に、このコードは Win32 Delphi アプリケーションによってホストされる .NET ランタイムにロードされます。

このような機能を簡単に実験できるようにするために、Visual Studio プロジェクト/ソリューション/デバッガーを構成して、生成された dll を Delphi アプリのディレクトリにコピーし、Visual Studio デバッガーを介して Delphi アプリを実行することもできます。

デバッガーの外でプログラムを実行すると問題は解決しますが、デバッグ中に毎回問題が発生します。

それが役立つかどうかはわかりませんが、コードの本番リリースはあと 6 か月ほど予定されていないため、間もなく行われるテスト リリースに対するプレッシャーが軽減されます。

後でメモリの部分に飛び込みますが、おそらく週末になるまでは続かないので、フォローアップを投稿します.

私はこの引用に出くわしました：

「.NET 共通言語ランタイム (CLR) は、NET がサポートするすべてのコンピューター アーキテクチャに対して少なくとも 1 つの JIT コンパイラを提供するため、同じ CIL セットを JIT コンパイルして、異なるアーキテクチャで実行できます。」

いろいろ調べましたが、CLR でサポートされている JIT コンパイラの決定的なリストが見つかりませんか?

No

• とにかく、JITコンパイラはバイトコードをまったく異なるものに「変換」する可能性があります。
• 時期尚早の最適化を行うことになります。

Yes

• どのメソッドが JIT でコンパイルされるかわからないので、すべて最適化した方がよいでしょう。
• それはあなたをより良い Java プログラマーにします。

（明らかに）よくわからないまま質問しているので、JITハイパーリンクにリダイレクトしてください。

Python の「yield」ステートメントにより、プロシージャからの単純な反復が可能になります。また、シーケンスを事前に計算して「任意の」サイズの配列に格納する必要がないことも意味します。

Cプロシージャから（yieldを使用して）反復する同様の方法はありますか？

可能な最小の CLI サブセット実装を探しています。

今のところ、インタープリターでも構いませんが、JITted ランタイムを本当に探しています。System.Object や Enum などのコア クラスを除いて、標準ランタイムからは何も必要ありません。また、移植可能であり、基盤となるシステムへの依存が最小限である必要があります。

私はモノを検討しましたが、かなり重いです。モノラルを要件に合わせて削減するのは大変な作業です。すでに行われているのだろうか。私は現在、「小さな」ビルドを含む pnet を見ています。