問題タブ [ryujit]

今日、 MSDNで新しい .Net Native に関する記事を読みました。

「Windows ストア アプリは、.NET ネイティブで最大 60% 高速に起動し、メモリ フットプリントがはるかに小さくなっています。最初のリリースは、この新しいコンパイラを使用してアプリを開発およびテストできる Developer Preview です。この .NET Native のプレビュー リリースでは、 C# の生産性を備えた C++ のパフォーマンス」.

もちろん、これは非常に興味深いことですが、.Net Native が優れたパフォーマンスを提供する新しいコンパイラである場合、なぜ RyuJIT を使用する必要があるのでしょうか。この新しい .Net Native とは何ですか? 新しい .Net Native と RyuJIT の違いは何ですか。また、Microsoft は Roslyn と呼ばれるサービスとしてコンパイラをリリースしました。では、Roslyn がこの新しい .Net Native をどのようにサポートするかについて説明します。

Ryujit は SSE 命令をサポートしますが、Ryujit は 64 ビット専用です。

ほとんどの顧客は、会社のポリシーと予算 (テスト コストのため) のために、Windows 32 ビット OS に固執します。

私の理解では、Ryujit は新しい「64 ビットに最適化された JIT スキーム」です。

ただし、ご存知のように、SSE 命令セットは 32 ビットと 64 ビットに存在します。

Mono.Simd は、x86 または Arm 32 ビット プロセッサで動作します。

(Java SIMD 呼び出しは x86 および 64 ビットで動作するようです)。

私たちのプロジェクトはすべての CPU を対象としているため、「SSE をサポートしている Mono を使用するか、CPU と OS を変更してください」と顧客に伝えることは非常に困難です。

なぜ MS .NET Framework for x86 は SSE コマンドをサポートしていないのに、Ryujit はサポートしているのでしょうか?

（私はCPUの専門家ではありませんが、.NETに「このコマンドでSSEを強制する（可能であれば）」を選択するオプションがあることを願っています）

Visual Studio 2015 RC1 をインストールした後、従来の ASP.NET プロジェクトを読み込み、.NET バージョンを 4.6 に変更しました。プロジェクトは正常に動作しますが、ウェブサイトの読み込みは相変わらず遅いです。RyuJITの活躍を期待していましたが、そうではないようです。

RyuJIT に関するこのスレッドを見てきましたが、そこに記載されているメソッドのいずれでも RyuJIT の痕跡は見られません。

空のコンソール プロジェクトでも同じ問題が発生します。出力ウィンドウ、モジュール ウィンドウ、または実行中の Windows タスクに Ryujit が表示されません。

そのため、RyuJIT は以前のプレビューにあったため検出できないか、実行されていません。いずれにせよ、私は立ち往生しています。

RyuJIT が VS 2015 で実行されていることを確認するにはどうすればよいですか?そうでない場合に実行するにはどうすればよいですか?

Net 4.6 RC x64 は x86 (リリース バージョン) の 2 倍遅い:

次のコードを検討してください。

私のマシンでは、x86 リリース バージョンが完了するまでに 4.5 秒かかり、x64 リリース バージョンは 9.5 秒かかります。x64 に必要な特定のフラグ/設定はありますか?

アップデート

この問題でRyuJITが役割を果たしていることがわかりました。app.configuseLegacyJitで有効にすると結果が異なり、今回は x64 の方が高速です。

アップデート

現在、この問題は CLR チームのcoreclr、問題 993に報告されています。

関数が初めて呼び出されると、JIT が呼び出され、.Net IL コードが x86 命令にコンパイルされ、メモリのどこかに保持されることを理解しています。x86アセンブリ命令を分析できるように、このx86コードが保持されている場所を知る必要があります(この質問の文脈では目的はあまり重要ではありません)。変換されたコードが保存されるか、おそらく JIT コードのどの関数がそれを行うか。私はJITコードを持っています（.netソースコードはGitHubで公開されていますが、これまでのところコードのサイズに圧倒されています）. あらゆる種類の助けをいただければ幸いです。前もって感謝します...

Visual Studioの逆アセンブラーと同じように、実行中の.net exeのx86アセンブリ命令ダンプを提供できる逆アセンブラーを提案できると助かりますが、自動的に実行する必要があります。これはngenによって静的に実行できることを知っています。ngen は x86 命令に変換でき、その後、逆アセンブラーはダンプを取得できますが、exe の実行後にこれを行う必要があることが重要です。

これは、x86 命令ダンプが必要な理由は、複数の .net exe 間の類似性を見つけるためです。静的に逆アセンブルされたアセンブリを直接見る場合の課題は、アセンブリがパックまたは難読化されている可能性があることです。ただし、実行時にパッカー プログラムによってアンパック/難読化解除され、JIT コンパイルされた x86 命令は同様に見えます。

.NET Framework 4.6の発表を読むと、RyuJIT が .NET 4.6 専用であることを暗示しているようです。

これは、RyuJIT を有効にするには、アプリケーションのターゲットを .NET 4.6 に変更する必要があるということですか?

最近 .net 4.6 にアップグレードした後、RyuJit が誤った結果を生成するバグを発見しました。現在、useLegacyJit enabled="true" を app.config に追加することで、この問題を回避することができました。

以下によって生成されたマシンコードをデバッグするにはどうすればよいですか?

VS 2015 RTM で新しいコンソール プロジェクトを作成し、Release、Any CPU に設定し、Prefer 32 ビットのチェックを外し、デバッガーを接続して実行しても、接続せずに実行しても同じ結果が得られます。

以下を生成する必要があります: False False

しかし、代わりに以下を生成します: True False

この例の重要な部分は

これは常に false を返す必要がありますが、出力からわかるように、メソッドが最初に実行されると True が返され、メソッドが 2 回目に実行されると別の答えが返されます。Calculate() メソッドからさらにいくつかの行を削除すると、常に True が返されますが、示されている例は、実際の運用シナリオに最も近いものです。

現在、C# のみを使用して巨大な配列内のすべての値の合計を計算し、SIMD を使用してパフォーマンスを比較しようとしていますが、SIMD バージョンはかなり遅いです。以下のコード スニペットを参照して、何か不足している場合はお知らせください。「vals」は、画像ファイルから読み取られる巨大な配列であり、無駄を省くためにその部分を省略しています。

および GetSIMDVectors メソッド