468,771 Members | 1,978 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,771 developers. It's quick & easy.

optimized code

Is it still true that the managed C++ compiler will produce much better
opimizations than the C# compiler, or have some of the more
global/aggressive opimizations been rolled into the 2005 compiler?

Are simple common sub-expressions and loop invariants optimized out in the
current optimizer?

thanks,
m
Dec 6 '05 #1
10 1923

"Mike" <vi********@yahoo.com> wrote in message
news:Oj****************@TK2MSFTNGP10.phx.gbl...
Is it still true that the managed C++ compiler will produce much better
opimizations than the C# compiler, or have some of the more
global/aggressive opimizations been rolled into the 2005 compiler?


Yes, the Managed C++ compiler should still be better. the C# compiler still
doesn't go very far as far as optimizations go, AFAIK anyway. They are left
to the JIT.
Dec 6 '05 #2

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway. They
are left to the JIT.


Thanks. Well, I guess I don't care if the compiler does the magic, or the
JIT.
I assume the JIT is limited to peephole optimizations? Does the JIT handle
common sub-expression removal, loop invarients, etc?

If I have an inner loop of something like:
for ( i ...) {
a.b.c.x = ...
a.b.c.y = ...
a.b.c.arr[i] =
...
}

Do I need to put a.b.c in a local outside the loop, or will the JIT take
care of this?
Sometimes it's cleaner to code this way, sometimes not - but there's also
auto-generated code, and whether I need to generate code with temps.

thanks

Dec 6 '05 #3
Interesting, re: managed C++:
http://msdn.microsoft.com/msdnmag/is...Optimizations/
"Mike" <vi********@yahoo.com> wrote in message
news:ui****************@TK2MSFTNGP10.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway. They
are left to the JIT.


Thanks. Well, I guess I don't care if the compiler does the magic, or the
JIT.
I assume the JIT is limited to peephole optimizations? Does the JIT
handle common sub-expression removal, loop invarients, etc?

If I have an inner loop of something like:
for ( i ...) {
a.b.c.x = ...
a.b.c.y = ...
a.b.c.arr[i] =
...
}

Do I need to put a.b.c in a local outside the loop, or will the JIT take
care of this?
Sometimes it's cleaner to code this way, sometimes not - but there's also
auto-generated code, and whether I need to generate code with temps.

thanks

Dec 6 '05 #4

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:Oj****************@TK2MSFTNGP10.phx.gbl...
Is it still true that the managed C++ compiler will produce much better
opimizations than the C# compiler, or have some of the more
global/aggressive opimizations been rolled into the 2005 compiler?


Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway. They
are left to the JIT.

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.
Willy.
Dec 6 '05 #5

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uh****************@TK2MSFTNGP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:Oj****************@TK2MSFTNGP10.phx.gbl...
Is it still true that the managed C++ compiler will produce much better
opimizations than the C# compiler, or have some of the more
global/aggressive opimizations been rolled into the 2005 compiler?


Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway. They
are left to the JIT.

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.


Ya, for the most part IL doesn't lend itself to much optimization. You can't
stash locals in registers or play memory tricks to boost performance. Still,
the C++ code should be dumped through the optimization layer in the C++
compiler before its emitted. I'd guess they go faruther, even if the results
aren't always obvious.

I am a little surprised the C++ compiler doesn't do some of hte more basic
optimizations that it should be entirely capable of doing.
Dec 7 '05 #6

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


Dec 7 '05 #7
Daniel O'Connell [C# MVP] <onyxkirx@--NOSPAM--comcast.net> wrote:

<snip>
I am a little surprised the C++ compiler doesn't do some of hte more basic
optimizations that it should be entirely capable of doing.


While I can't say for sure that the same would be true in .NET, in Java
Sun found that the more they tried to optimise the bytecode, the harder
it was to optimise at JIT time. Optimisation can make the code more
complicated by trying to guess what will happen to it, whereas a JIT
can optimise well when it can easily understand the meaning of the
code.

For instance, if a compiler does loop unrolling in the IL, the JIT
would have a difficult job doing a different level of loop unrolling in
the JITted code, even though it knows better how much processor cache
is available (which may not currently be a factor in how much loop
unrolling the JIT does, but it easily *could* be).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Dec 7 '05 #8
Can anyone comment on C# vs. C++ for floating point performance with V2?

In
http://msdn.microsoft.com/library/de...etperftips.asp
we
read:

"Floating Point—The v1 JIT does not currently perform all the FP-specific
optimizations that the VC++ backend does, making floating point operations
more expensive for now. "

Has this been improved? Can anyone quantify the difference in performance.
I have a highly computation-intensive program written in C# and wonder what
the difference would be if I were to rewrite in C++.

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uh****************@TK2MSFTNGP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:Oj****************@TK2MSFTNGP10.phx.gbl...
Is it still true that the managed C++ compiler will produce much better
opimizations than the C# compiler, or have some of the more
global/aggressive opimizations been rolled into the 2005 compiler?


Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway. They
are left to the JIT.

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

Dec 7 '05 #9
All depends on what exactly you are measuring , how you are comparing and
what you are expecting.
But suppose we are talking about code generated by MSFT VS2005 C#, C++ and
C++/CLI, first, you should understand that you are basically using the same
math library (the CRT library) for all three. That means that the results
should be comparable for both C# and C++/CLI, and that C++ should take
advantage of the back-end optimizer which can do a better job than the JIT
compiler.
Anyway what I have measured so far using VS2005, is a slight advantage (<
5%) for C++/CLI over C# and a larger advantage (<20%) for C++ oner C#.

The difference between C# and C++/CLI is due to a better optimized IL
produced by the C++ compiler, when enabling max. optimizations (enables the
fastest FP unit mode).
The difference between managed and unmanaged C++ is due to the extra
redirection (through the CLR) between managed code(well, JIT'd ) and the
math library.
Note that your mileage may vary, therefore, I would suggest you do your
homework, run some benchmarks, compare and make a language decision. Note
however, that performance should never be the only criterion to select a
development language (or platform). Remember faster is not always better,
especially when talking about FP arithmetics.
Willy.
"Fred Mellender" <no****************@frontiernet.net> wrote in message
news:YT***************@news02.roc.ny...
Can anyone comment on C# vs. C++ for floating point performance with V2?

In
http://msdn.microsoft.com/library/de...etperftips.asp
we
read:

"Floating Point—The v1 JIT does not currently perform all the FP-specific
optimizations that the VC++ backend does, making floating point operations
more expensive for now. "

Has this been improved? Can anyone quantify the difference in
performance. I have a highly computation-intensive program written in C#
and wonder what the difference would be if I were to rewrite in C++.

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uh****************@TK2MSFTNGP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:Oj****************@TK2MSFTNGP10.phx.gbl...
Is it still true that the managed C++ compiler will produce much better
opimizations than the C# compiler, or have some of the more
global/aggressive opimizations been rolled into the 2005 compiler?
Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway. They
are left to the JIT.

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


Dec 7 '05 #10

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...
All depends on what exactly you are measuring , how you are comparing and
what you are expecting.
But suppose we are talking about code generated by MSFT VS2005 C#, C++ and
C++/CLI, first, you should understand that you are basically using the
same math library (the CRT library) for all three. That means that the
results should be comparable for both C# and C++/CLI, and that C++ should
take advantage of the back-end optimizer which can do a better job than
the JIT compiler.
Anyway what I have measured so far using VS2005, is a slight advantage (<
5%) for C++/CLI over C# and a larger advantage (<20%) for C++ oner C#.

The difference between C# and C++/CLI is due to a better optimized IL
produced by the C++ compiler, when enabling max. optimizations (enables
the fastest FP unit mode).
The difference between managed and unmanaged C++ is due to the extra
redirection (through the CLR) between managed code(well, JIT'd ) and the
math library.
Note that your mileage may vary, therefore, I would suggest you do your
homework, run some benchmarks, compare and make a language decision. Note
however, that performance should never be the only criterion to select a
development language (or platform). Remember faster is not always better,
especially when talking about FP arithmetics.
I'd think inner-loop FP code could win even more if branch reduction due to
loop unrolling and other factors, and better register allocation, was able
to reduce the time between calls, keeping the integer and FP piplelines as
full as possible. But I guess the new processors do a reasonable job of
magically looking ahead and doing many things at once too, so at some point
further front-end opimizations may not help at all.


Willy.
"Fred Mellender" <no****************@frontiernet.net> wrote in message
news:YT***************@news02.roc.ny...
Can anyone comment on C# vs. C++ for floating point performance with V2?

In
http://msdn.microsoft.com/library/de...etperftips.asp
we
read:

"Floating Point-The v1 JIT does not currently perform all the FP-specific
optimizations that the VC++ backend does, making floating point
operations more expensive for now. "

Has this been improved? Can anyone quantify the difference in
performance. I have a highly computation-intensive program written in C#
and wonder what the difference would be if I were to rewrite in C++.

"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:uh****************@TK2MSFTNGP12.phx.gbl...

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eN****************@TK2MSFTNGP09.phx.gbl...

"Mike" <vi********@yahoo.com> wrote in message
news:Oj****************@TK2MSFTNGP10.phx.gbl...
> Is it still true that the managed C++ compiler will produce much
> better opimizations than the C# compiler, or have some of the more
> global/aggressive opimizations been rolled into the 2005 compiler?
>

Yes, the Managed C++ compiler should still be better. the C# compiler
still doesn't go very far as far as optimizations go, AFAIK anyway.
They are left to the JIT.
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.
Willy.



Dec 7 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by SSG | last post: by
8 posts views Thread by Jarod | last post: by
17 posts views Thread by Grizlyk | last post: by
7 posts views Thread by Zytan | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.