45

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. The theory being that native applications are usually just compiled for a processor family (like x86), so the compiler cannot make certain optimizations as they may not truly be optimizations on all processors. On the other hand, the CLR can make processor-specific optimizations during the JIT process.

Does anyone know if Microsoft's (or Mono's) CLR actually performs processor-specific optimizations during the JIT process? If so, what kind of optimizations?

John Rudy
  • 37,282
  • 14
  • 64
  • 100
dewald
  • 5,133
  • 7
  • 38
  • 42
  • As far as I know, right now, not really. – zneak Mar 08 '10 at 22:44
  • 1
    A conspiracy theorist could also ponder whether MS could code the JIT to de-optimize if the software is running under a competitor's system, such as being virtualized on an x86 Mac, assuming they could detect that it was a Mac. – AaronLS Mar 08 '10 at 22:44
  • 8
    @aaronls: MacBU makes an estimated 350 million dollars a year in revenue for Microsoft. Macs are a *profit center* for Microsoft, which is the largest provider of Mac software in the world outside of Apple itself. How do these facts fit into your conspiracy theory? – Eric Lippert Mar 09 '10 at 02:06
  • 13
    @Eric Conspiracy theories are notorious for ignoring the facts. – AaronLS Mar 09 '10 at 14:36

7 Answers7

28

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.

Sam Harwell
  • 97,721
  • 20
  • 209
  • 280
  • 4
    Wow. This is one nice find. +1 – Andras Vass Mar 08 '10 at 23:21
  • Quote from the blog: "we don't vectorize code (which is the real win with SSE2)". So sadly, JIT doesn't take much advantages. – colinfang Jan 06 '14 at 01:43
  • @colinfang but it will soon: http://blogs.msdn.com/b/dotnet/archive/2014/04/07/the-jit-finally-proposed-jit-and-simd-are-getting-married.aspx – Den Jun 26 '14 at 14:54
8

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.

Mehrdad Afshari
  • 414,610
  • 91
  • 852
  • 789
2

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

H H
  • 263,252
  • 30
  • 330
  • 514
  • As I understand the question, the OP is looking for processor-specific optimizations *within a processor family* (e.g. does it generate specific code depending the current processor is based on NetBurst vs. Core microarchitecture, both running in 32 bit mode?) – Mehrdad Afshari Mar 08 '10 at 22:50
  • @Mehrdad, I know this was not the main direction but I thought it deserved a mention. – H H Mar 08 '10 at 23:12
2

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

erasmus
  • 925
  • 2
  • 9
  • 16
2

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).

kvb
  • 54,864
  • 2
  • 91
  • 133
  • Does Microsoft's CLR perform inline caching? – dewald Mar 09 '10 at 16:39
  • @dewald - Not that I know of, but I believe that several Java VMs do. Since methods are not virtual by default in C# (as opposed to Java) I think that this was a lower priority for .NET. However, this is only one example of how optimizations can be made at runtime by a JIT that are hard or impossible to make statically. – kvb Mar 09 '10 at 17:03
  • 2
    @dewald - See http://stackoverflow.com/questions/1255803/does-the-net-clr-jit-compile-every-method-every-time for more on the contrast between the CLR and JVM approaches. – kvb Mar 09 '10 at 17:37
  • Nowadays though a lot of C++ compilers can perform profile guided optimization, which can also do this sort of optimizations. – Aidiakapi May 30 '15 at 12:51
1

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).

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Do you have a reference to support your claim that MS .NET doesn't? Not questioning it, just wondering if that's opinion or documented fact. – Eric J. Mar 08 '10 at 22:51
  • 2
    Well, it turns out that Microsoft .NET does a few optimizations based on instruction set but not particular CPU characteristics such as cache layout (http://blogs.msdn.com/davidnotario/archive/2005/08/15/451845.aspx). My point about precompiled code being able to use the same optimizations (and more that are too costly to find in a JIT compiler) still holds though. – Ben Voigt Mar 09 '10 at 00:24
0

I know the rules for whether or not to inline functions changes depending on the processor type (x86, x64). And of course the pointer sizes will vary depending on if it runs as 32-bit or 64-bit.

Jonathan Allen
  • 68,373
  • 70
  • 259
  • 447
  • Yeah, but pointer size _always_ changes, no matter if you're using a traditional compiler or not. – zneak Mar 08 '10 at 22:52