"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uh****************@TK2MSFTNGP12.phx.gbl...
The same applies to the "managed C++" compiler, common sub-expressions and
loop invariants are handled by the JIT not by the compiler fron-ends.
The managed C++ compiler generates IL, sometimes it does a better job, but
I've seen IL code that was better optimized by the C# compiler. Anyway the
differences are < 5% (both sides), MS said that they will focus on the JIT
to further optimize, not in the C++ front-end.
This does not seem to jibe with:
http://msdn.microsoft.com/msdnmag/is...Optimizations/
---snipped from above page---
Another common misconception is that the same kind of superior performance
on the .NET Framework can be attained regardless of the language you
use-that the generated Microsoft intermediate language (MSIL) from various
compilers is inherently equal. Even in Visual Studio .NET 2003 this was not
true, but in Visual Studio 2005, the C++ compiler team went to great lengths
to make sure that all of the expertise gained from years of optimizing
native code was applied to managed code optimization. C++ gives you the
flexibility to do fine tuning such as high-performance marshaling that is
not possible with other languages. Moreover, the Visual C++ compiler
generates the best optimized MSIL of any of the .NET languages. The result
is that the best optimized code in .NET comes from the Visual C++ compiler.
....
With Visual C++ 2005, the compiler can perform a large subset of the
standard native code optimizations on MSIL code. These include everything
from dataflow-based optimizations to expression optimization to loop
unrolling. This level of optimization is unmatched in any other language on
the platform. In Visual C++ .NET 2003, Whole Program Optimization (WPO) was
not supported for builds using the /clr switch, but Visual C++ 2005 adds
this capability for managed code. This feature enables cross-module
optimization, which I'll discuss later in the article.
The only class of optimizations not available for managed code in Visual C++
2005 are Profile Guided Optimizations, although they may be available in a
future version. For more information, see Write Faster Code with the Modern
Language Features of Visual C++ 2005
....
The optimizations done on MSIL code are a large subset of those done on
unmanaged code. It's worth pointing out that the class of allowable
optimizations is different depending on whether the compiler is generating
verifiable code (/clr:safe) or unverifiable code (/clr or /clr:pure). A few
examples of the types of things that the compiler can not do because of
either metadata or verifiability constraints include strength reduction (to
convert multiplications into pointer addition), and inlining the access of
private members of one class into the method body of another class.
After the MSIL code is generated by the Visual C++ compiler, it is then
consumed by the JIT. The JIT reads in the MSIL and begins to perform
optimizations that are very sensitive to changes in the MSIL. One
instruction sequence of MSIL might be very amenable to optimization, whereas
another (semantically equivalent) sequence stifles optimization. For
example, register allocation is an optimization in which the JIT optimizer
attempts to map variables to registers; registers are what the actual
hardware uses as operands to perform arithmetic and logical operations. At
times, semantically equivalent code, written in two different ways, might
cause the optimizer to have a more difficult time performing good register
allocation. Loop unrolling is an example of a transformation that might
cause the JIT to have problems register-allocating.
Loop unrolling done by the C++ compiler can expose more instruction-level
parallelism, but can also create more live variables that the optimizer
needs to track for register allocation. The CLR JIT can only track a fixed
number of variables for register allocation; once it has to track more than
this, it begins to spill the contents of registers into memory.
For this reason, the Visual C++ compiler and the JIT must be tuned in tandem
to generate the best code. The Visual C++ compiler is responsible for those
optimizations that are too time-consuming for the JIT and those for which
too much information would be lost in the compilation process from C++
source to MSIL.
