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.Environment::get_TickCount()
 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.Environment::get_TickCount()
 IL_001d:  stloc.1
 IL_001e:  ldloc.1
 IL_001f:  ldloc.2
 IL_0020:  sub
 IL_0021:  call       void [mscorlib]System.Console::WriteLine(int32)
 IL_0026:  ldc.i4.0
 IL_0027:  ret
} // end of method 'Global Functions'::main

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.Environment::get_TickCount()
 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.Environment::get_TickCount()
 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(int64)
 IL_002d:  nop
 IL_002e:  ret
} // end of method ForLoopTest::Main

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

[...]

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

Such micro benchmark has little value, an empty loop will be hoisted in
optimized builds (you ain't gonna do this in real code do you?).
More important is the way you measure execution time here, it is wrong. The
reason or this is that Environment.TickCount is updated with the real time
clock tick. That is every 10 msec or 15,6 msec or higher, depending on the
CPU type (Intel AMD, variants...). For instance an AMD 64 ticks at an
interval of 15.5 msec, most intel based systems have an interval of 10msec,
most SMP systems tick at 20msec or higher.

To get accurate results you need to use the high performance counters or the
Stopwatch class  in V2.
Here is the adapted code:

// C# code
// csc /o- bcs.cs
using System;
using System.Diagnostics;
public class ForLoopTest
{
public static void Main(string[] args)
{
   long nanosecPerTick = (1000L*1000L*1000L) / Stopwatch.Frequency;

   Stopwatch sw = new Stopwatch();
   sw.Start();
   for (int i =0;i < 10000000; ++i) {}
   sw.Stop();
   long ticks = sw.Elapsed.Ticks;
   Console.WriteLine("{0} nanoseconds", ticks * nanosecPerTick);
   }
}

// C++/CLI code
// cl /CLR:safe /Od bcc.cpp
#using <System.dll>
using namespace System;
using namespace System::Diagnostics;

int main()
{
  Int64 nanosecPerTick = (1000L * 1000L * 1000L) /
System::Diagnostics::Stopwatch::Frequency;

   Stopwatch^ sw = gcnew Stopwatch;
   sw->Start();
   for (int i = 0; i < 10000000; ++i) {}
   sw->Stop();
   Int64 ticks = sw->Elapsed.Ticks;
   Console::WriteLine("{0} nanoseconds", ticks* nanosecPerTick);
}

On my system using above code and the command line arguments as specified in
the source (both non optimized) show following results:

C#
37714104 nanoseconds
C++/CLI
37389069 nanoseconds

That means both are equaly fast, but again this means nothing, such micro
benchmarks have no value.

Note that an optimized C++ build will hoist the empty loop (removes it
completely from IL). This kind of hoisting is not done by the C# compiler,
and there is a reason for it.
That doesn't mean there is no loop optimization, it's just done at the JIT
level!!.

Willy.

Richard Grimes'a article 'Is Managed Code Slower than Unmanaged Code' might
be of interest.
http://www.grimes.demon.co.uk/dotnet/man_unman.htm

Seems to indicate that there isn't much to choose between c# and c++/cli. c#
can be faster in some circumstances.

Michael