C++/CLI the fastest compiler? Yes, at least for me. :-)

[Don Kim]

Ok, so I posted a rant earlier about the lack of marketing for C++/CLI,
and it forked over into another rant about which was the faster
compiler. Some said C# was just as fast as C++/CLI, whereas others said
C++/CLI was more optimized.

Anyway, I wrote up some very simple test code, and at least on my
computer C++/CLI came out the fastest. Here's the sample code, and just
for good measure I wrote one in java, and it was the slowest! ;-) Also,
I did no optimizing compiler switches and compiled the C++/CLI with
/clr:safe only to compile to pure verifiable .net.

//C++/CLI code
using namespace System;

int main()
{
long start = Environment::Ti ckCount;
for (int i = 0; i < 10000000; ++i) {}
long end = Environment::Ti ckCount;
Console::WriteL ine(end - start);
}
//C# code
using System;

public class ForLoopTest
{
public static void Main(string[] args)
{
long start = Environment.Tic kCount;
for (int i =0;i < 10000000; ++i) {}
long end = Environment.Tic kCount;
Console.WriteLi ne((end-start));
}
}

//Java code
public class Performance
{
public static void main(String args[])
{
long start = System.currentT imeMillis();
for (int i=0; i < 10000000; ++i) {}
long end = System.currentT imeMillis();
System.out.prin tln(end-start);
}
}

Results:

C++/CLI -> 15-18 secs
C# -> 31-48 secs
Java -> 65-72 secs

I know, I know, these kind of test are not always foolproof, and results
can vary by computer to computer, but at least on my system, C++/CLI had
the fastest results.

Maybe C++/CLI is the most optimized compiler?

-Don Kim

[Carl Daniel [VC++ MVP]]

Don Kim wrote:

C++/CLI -> 15-18 secs
C# -> 31-48 secs
Java -> 65-72 secs

I know, I know, these kind of test are not always foolproof, and
results can vary by computer to computer, but at least on my system,
C++/CLI had the fastest results.

Maybe C++/CLI is the most optimized compiler?

After increasing the length of the loops by a factor of 100, I see about a
2X speed advantage for C++/CLI as well. Looking at the IL produced by the
two compilers for the respective main functions:

C++:

..method assembly static int32 main() cil managed
{
// Code size 40 (0x28)
.maxstack 2
.locals (int32 V_0,
int32 V_1,
int32 V_2)
IL_0000: call int32 [mscorlib]System.Environm ent::get_TickCo unt()
IL_0005: stloc.2
IL_0006: ldc.i4.0
IL_0007: stloc.0
IL_0008: br.s IL_000e
// start of loop
IL_000a: ldloc.0
IL_000b: ldc.i4.1
IL_000c: add
IL_000d: stloc.0
IL_000e: ldloc.0
IL_000f: ldc.i4 0x3b9aca00
IL_0014: bge.s IL_0018
IL_0016: br.s IL_000a
// end of loop
IL_0018: call int32 [mscorlib]System.Environm ent::get_TickCo unt()
IL_001d: stloc.1
IL_001e: ldloc.1
IL_001f: ldloc.2
IL_0020: sub
IL_0021: call void [mscorlib]System.Console: :WriteLine(int3 2)
IL_0026: ldc.i4.0
IL_0027: ret
} // end of method 'Global Functions'::mai n

C#:

..method public hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 47 (0x2f)
.maxstack 2
.locals init (int64 V_0,
int32 V_1,
int64 V_2,
bool V_3)
IL_0000: nop
IL_0001: call int32 [mscorlib]System.Environm ent::get_TickCo unt()
IL_0006: conv.i8
IL_0007: stloc.0
IL_0008: ldc.i4.0
IL_0009: stloc.1
IL_000a: br.s IL_0012
// start of loop
IL_000c: nop
IL_000d: nop
IL_000e: ldloc.1
IL_000f: ldc.i4.1
IL_0010: add
IL_0011: stloc.1
IL_0012: ldloc.1
IL_0013: ldc.i4 0x3b9aca00
IL_0018: clt
IL_001a: stloc.3
IL_001b: ldloc.3
IL_001c: brtrue.s IL_000c
// end of loop
IL_001e: call int32 [mscorlib]System.Environm ent::get_TickCo unt()
IL_0023: conv.i8
IL_0024: stloc.2
IL_0025: ldloc.2
IL_0026: ldloc.0
IL_0027: sub
IL_0028: call void [mscorlib]System.Console: :WriteLine(int6 4)
IL_002d: nop
IL_002e: ret
} // end of method ForLoopTest::Ma in
The C++ compiler did generate more optimized IL. It's surprising to me that
the JIT didn't do a better job of optimizing the C#-produced code.

Note that the C# code converted the time to a 64 bit value (C#'s long is 64
bits, while C++'s long is 32 bits), but that occurred outside the loop so it
should have next to no impact on the overall speed of the code.

-cd

[Jochen Kalmbach [MVP]]

Hi Carl!

The C++ compiler did generate more optimized IL. It's surprising to me that
the JIT didn't do a better job of optimizing the C#-produced code.

Wasn´t there a statement that the JIT for .NET 2.0 is not doing
optimizations (only simple optimizations) ?
I just remember a blog-entry from someone at blogs.msdn.com. .. but
couldn´t find it anymore...
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Jochen Kalmbach [MVP]]

>> The C++ compiler did generate more optimized IL. It's surprising to

me that the JIT didn't do a better job of optimizing the C#-produced
code.

Wasn´t there a statement that the JIT for .NET 2.0 is not doing
optimizations (only simple optimizations) ?
I just remember a blog-entry from someone at blogs.msdn.com. .. but
couldn´t find it anymore...

Currently I could only find the confirmation of the "missing"
optimization for the CF. But I tought the same was true for the
"desktop"-framework...

http://blogs.msdn.com/stevenpr/archi...12/502978.aspx

<quote>
Because the CLR can throw away native code under memory pressure or when
an application moves to the background, it is quite possible that the
same IL code may need to be jit compiled again when the application
continues running. This fact leads to our second major jit compiler
design decision: the time it takes to compile IL code often takes
precedence over the quality of the resulting native code. As with all
good compilers, the Compact Framework jit compiler does some basic
optimizations, but because of the need to regenerate code quickly in
order for applications to remain responsive, more extensive
optimizations generally take a back seat to shear compilation speed.
</quote>

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Andre Kaufmann]

Jochen Kalmbach [MVP] wrote:

Currently I could only find the confirmation of the "missing"
optimization for the CF. But I tought the same was true for the
"desktop"-framework...

http://blogs.msdn.com/stevenpr/archi...12/502978.aspx

<quote>
Because the CLR can throw away native code under memory pressure or when
an application moves to the background, it is quite possible that the
same IL code may need to be jit compiled again when the application
continues running. This fact leads to our second major jit compiler
design decision: the time it takes to compile IL code often takes
precedence over the quality of the resulting native code. As with all
good compilers, the Compact Framework jit compiler does some basic
optimizations, but because of the need to regenerate code quickly in
order for applications to remain responsive, more extensive
optimizations generally take a back seat to shear compilation speed.
</quote>

That may be true. But I wonder why there cannot be both ?
A fast IL compiler and one that is slow, but optimizes much better. E.g.
"ngen" could have a command line switch to generate more optimized code.

Andre

[Eugene Gershnik]

Don Kim wrote:

I did no optimizing compiler switches

[...]

Then the test is meaningless. If you don't ask the compiler to optimize why
should it spend any effort on making your code fast?

[I don't have any stake in C++/CLI, C# or Java -- they can all die as far as
I am concerned -- my objection as an outsider is only about how you tested.]

--
Eugene
http://www.gershnik.com

[Shawn B.]

> Wasn´t there a statement that the JIT for .NET 2.0 is not doing

optimizations (only simple optimizations) ?
I just remember a blog-entry from someone at blogs.msdn.com. .. but
couldn´t find it anymore...

No, but there is a recent thread in this group where some MVP's insist that
the C++ compiler doesn't do optimized IL code and produces roughly what the
C# compiler does, despite the fact that your test, some VC++ devs,
publications, and my own internal software production has proved that the
C++/CLI compiler is the best optimized for IL of the MS stack. That said,
the same MVP insists that some MS employees have stated that the C++/CLI
compiler leaves all the optimzation to the JIT rather than front-end
optimizing.
Thanks,
Shawn

[Don Kim]

Eugene Gershnik wrote:

Then the test is meaningless. If you don't ask the compiler to optimize why
should it spend any effort on making your code fast?

That was the whole point. If I were to use optimizing options, there
would invariably be arguments that either I did not use the correct
ones, not in the proper order, that certain compiler switches are not
equivalent, etc., etc. Therefore, I compiled as is w/out any options to
see how each complier would compile on its own. I also made the test as
simple as possible so as to time how each compiler internally optimizes
a straight iteration of a common for loop.

In this case, it seems C++/CLI is the fastest in the managed Windows
environment.

-Don Kim

[Jochen Kalmbach [MVP]]

Hi Shawn!

Wasn´t there a statement that the JIT for .NET 2.0 is not doing
optimizatio ns (only simple optimizations) ?
I just remember a blog-entry from someone at blogs.msdn.com. .. but
couldn´t find it anymore...

No, but there is a recent thread in this group where some MVP's insist that
the C++ compiler doesn't do optimized IL code and produces roughly what the
C# compiler does, despite the fact that your test, some VC++ devs,
publications, and my own internal software production has proved that the
C++/CLI compiler is the best optimized for IL of the MS stack. That said,
the same MVP insists that some MS employees have stated that the C++/CLI
compiler leaves all the optimzation to the JIT rather than front-end
optimizing.

Really?
I thought the C++/CLI compiler does not care what code it is generating.
It always tryes to optimize the "pseudeo-code".

Nevertheless... I neither found docu that the JIT-compiler does
optimization nor does I found some docu that it does not...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Andre Kaufmann]

Shawn B. wrote:

Wasn´t there a statement that the JIT for .NET 2.0 is not doing
optimizations (only simple optimizations) ?
I just remember a blog-entry from someone at blogs.msdn.com. .. but
couldn´t find it anymore...
No, but there is a recent thread in this group where some MVP's insist that
the C++ compiler doesn't do optimized IL code and produces roughly what the

You mean the sample where W.D. [MVP] gives a samples that the C++/CLI
doesn't do global optimization on IL code ?

It does. IMHO the example is wrong. If I interpret the given example
correctly it's based on a call to an external DLL. So the C++/CLI
compiler must do an optimization over DLL boundaries ?! Since the DLL is
loaded dynamically, how should the C++/CLI compiler do any optimization ?

Why should the C++/CLI compiler not optimize the code ? I don't know how
the C++/CLI compiler is implemented, but I assume that the code
generation of native or CLI code is done by optimizing the generated
intermediate code, before native or managed code is generated. So that
(nearly) the same optimizer is used for "native code compiled to IL
code" and "native x86 code". If my assumption is true it would be plain
nonsense to revert this optimization, already done.
C# compiler does, despite the fact that your test, some VC++ devs,
publications, and my own internal software production has proved that the
C++/CLI compiler is the best optimized for IL of the MS stack. That said,
the same MVP insists that some MS employees have stated that the C++/CLI
compiler leaves all the optimzation to the JIT rather than front-end
optimizing.
If he gives a valid link to the statements, I will believe it. Which
doesn't mean that the statements are true.
Thanks,
Shawn

Andre