Does the .NET CLR Really Optimize for the Current Processor

Question

When I read about the performance of JITted languages like C# or Java, authors usually say that they should/could theoretically outperform many native-compiled applications.

Answer 1

From back in 2005, David Notario listed several specific targeted optimizations is his blog entry "Does the JIT take advantage of my CPU?". I can't find anything about the new CLR 4, but I imagine several new items are included.

Answer 2

One processor specific optimization I'm aware of that's done in Mono is compiling Mono.Simd calls down to SSE instructions on processors that support SSE. If the processor running the code doesn't support SSE, the JIT compiler will output the equivalent non-SSE code.

Answer 3

I think some Java compilers do, Microsoft .NET doesn't, and it only beats precompiled when you compare apples to oranges. Precompiled can ship with a library variants tuned to different CPUs (or more likely, different instruction sets) and the runtime check to pick which library to load is a lot cheaper than JIT. For example, mplayer does this (google for mplayer enable-runtime-cpudetection).

Answer 4

.Net Framework Runtime Optimization Service optimizes not just programming issues (compiler's optimization) but also for processors.

Answer 5

The 32 and 64 bit Jitters are different, that's a start.

Answer 6

I'll point out that the main reason that I hear cited for the potential of JIT-compiled languages to outperform statically compiled languages has nothing to do with processor specific instructions. Instead, it's that information about the dynamic state of the program can be used to optimize code paths. For instance, inline caching can be used to make virtual method calls roughly as fast as non-virtual method calls. Roughly, this works by assuming that at a particular call site the method is called only on a single type and emitting code that jumps directly to that implementation (and then rewriting the code if this assumption is not born out later).