what static compiler could optimize when JIT could not ?

Are there examples of what static compiler could optimize when JIT开发者_如何学JAVA could not ?

For example, some optimization of C++ compiler which could not be done by .NET JIT ?

None. Proof: Take any compiler and use it as a JIT. QED.

However, JIT is limited in execution time, so it's unacceptable to do complex optimizations there.

This answer has a list of optimizations and strategies used by the JIT optimizer. They are not fundamentally different from what a native code optimizer does.

One constraint in the jitter is that it cannot spend a great deal of time analyzing the code. Every millisecond it burns affects the responsiveness of the program. Two strategies help. Assemblies can be pre-jitted by ngen.exe, all of the .NET assemblies are and it is wise to do the same with your own assemblies. As long as they are 'large', less time might be spent jitting the code than finding and loading the .ni.dll file on disk.

And the jitter compiles code on demand, just before a method starts executing. Which tends to spread the cost over time, relevant to code that runs at human time where responsiveness matters.

One detail worth noting is that a jitter can take advantage of core specific instructions. That's an edge that is largely gone, cores are not that different these days. But it will readily generate 64-bit code on a x64 operating system without doing anything special.

A typical number that's bandied about is that jitted machine code is 85% as efficient as native precompiled code. Take that with several large lumps of salt, the quality and nature of the source code is always first.

In general there are no things that a static complier can do that a JIT compiler cannot - since the JIT compiler has all the information that an equivalent static compiler would have - and more. A JIT compiler has one huge advantage - it knows the exact environment the code will be run in.

There may be specific optimizations available in C++ that aren't in C# due to language features. But again it's more likely to be the other way around - it's easier to reason about C# in the absence of pointers for example.

When looking at optimization in C# much of the optimization occurs in the translation from C# to IL, not by the JIT.

The primary issue here is run-time and resources. It takes 61 hours to compile Visual Studio- and I don't even know what kind of build machine they have. JITs, however, have to run with a fraction of the machine's real resources and in milliseconds. There's no way that they could possibly optimize as strongly.

A static compiler is run well in advance, while a JIT is done shortly before the code is executed. A static compiler has a lot more time to run, and so optimizations which take a long time to perform are often done by static compilers but not by JIT compilers. In principle a JIT could do these optimizations, but the additional time it takes to perform them makes them impractical.

On the other hand, a modern JIT can in some cases make more aggressive assumptions about the code (producing faster code than a static compiler can), because it has the option of falling back to a less-optimized version if those assumptions turn out to be incorrect.