C＃やJavaなどのJITted言語のパフォーマンスについて読んだとき、作成者は通常、多くのネイティブコンパイル済みアプリケーションよりも理論的に優れている必要がある/できると言っています。ネイティブアプリケーションは通常、プロセッサファミリ（x86など）用にコンパイルされるだけであるという理論です。したがって、コンパイラは、すべてのプロセッサで実際に最適化されるとは限らないため、特定の最適化を行うことができません。一方、CLRは、JITプロセス中にプロセッサ固有の最適化を行うことができます。
Microsoft（またはMono）のCLRが実際にJITプロセス中にプロセッサ固有の最適化を実行するかどうかを誰かが知っていますか？もしそうなら、どのような最適化ですか？
2005年にさかのぼって、David Notarioは、彼のブログエントリ「JITは私のCPUを利用していますか？」であるいくつかの特定のターゲット最適化をリストしました。新しいCLR4については何も見つかりませんが、いくつかの新しいアイテムが含まれていると思います。
Monoで行われていることを私が知っているプロセッサ固有の最適化の1つは、SSEをサポートするプロセッサでSSE命令へのMono.Simd呼び出しをコンパイルすることです。コードを実行しているプロセッサがSSEをサポートしていない場合、JITコンパイラは同等の非SSEコードを出力します。
32ビットと64ビットのジッタは異なります。それが始まりです。
.Net Frameworkランタイム最適化サービスは、プログラミングの問題（コンパイラーの最適化）だけでなく、プロセッサーの問題も最適化します。
JITコンパイル言語が静的コンパイル言語よりも優れている可能性があると私が聞いた主な理由は、プロセッサ固有の命令とは何の関係もないことを指摘しておきます。代わりに、プログラムの動的状態に関する情報を使用して、コードパスを最適化できます。たとえば、インラインキャッシングを使用して、仮想メソッド呼び出しを非仮想メソッド呼び出しとほぼ同じ速度で行うことができます。大まかに言うと、これは、特定の呼び出しサイトでメソッドが単一の型でのみ呼び出され、その実装に直接ジャンプするコードを発行すると仮定することで機能します（この仮定が後で生まれない場合は、コードを書き直します）。
一部のJavaコンパイラはそうだと思いますが、Microsoft .NETはそうではなく、リンゴとオレンジを比較すると、プリコンパイルされたものよりも優れています。プリコンパイルされたものは、異なるCPU（またはより可能性が高いのは異なる命令セット）に調整されたライブラリバリアントとともに出荷でき、ロードするライブラリを選択するためのランタイムチェックはJITよりもはるかに安価です。たとえば、mplayerはこれを行います（google for mplayer enable-runtime-cpudetection）。
インライン関数を使用するかどうかのルールは、プロセッサの種類（x86、x64）によって異なります。そしてもちろん、ポインタのサイズは、32ビットまたは64ビットのどちらで実行されるかによって異なります。