C # jitter improvements in future versions of the framework

Question

I noticed that C # jitter produces significantly slower code than the C ++ compiler, even if you do not use “managed utility” constructs (for example, arrays with verified indexing).

To quantify it, I calculated the following simple cycle:

public static int count = 1000000000; public static int Main() { int j = 0; for (int i = 0; i < count; ++i) { j += (i % 2 == 0) ? ((i + 7) >> 3) : (i * 7); } return j; } 

This loop takes 3.88 seconds to execute (compiled with / o). An equivalent cycle compiled with VC 2010 (-O2) takes 2.95 s.

To make sure that the lost code was actually generated, I compared the machine codes: created a list (/ FA) from the VC compiler and connected the debugger to the C # program (after the loop was completed).

In fact, the C ++ version uses some smart tricks. For example, to avoid costly multiplication by 7, there is a separate register, which is incremented by 7 each loop counter. The C # version performs imul every time. There are other differences.

I understand that C # jitter has much less time to compile code at runtime than VC at build time. But, for example, Java Jitter dynamically optimizes commonly used methods. C # doesn't seem to do this.

My question is: do you plan to improve C # jitter in future versions of the framework?

Answer 1

Release build, VS2008SP1, .NET 3.5SP1, an average of 10 tests:

 .NET, x86: 2.646 seconds C++, x86: 2.652 seconds .NET, x64: 2.352 seconds C++, x64: 2.090 seconds 

Classic errors suggest that / o is significant by measuring the recording time, starting the debug build, testing with the debugger attached, so that the jitter optimizer is turned off.

The x64 jitter uses the same trick you talked about, it is not unique to the C ++ code generator:

 00000030 xor r9d,r9d ... 00000059 add r9d,7 

The new .NET 4.5 feature is optimized profiling.

Future plans are never shared by a company such as Microsoft, and there is no point guessing them.

Answer 2

Are you planning to improve jquery C # in future versions of frames?

You ask whether last month there was a secret meeting between Microsoft and Xamarin, where it was decided that although they both spent the last decade improving their vacillations, they are now tired of improving the situation and would not be worried anymore, and MS reappointed would everyone, while Xamarin rejected any submitted corrections that improved jitter?

I would say that this is unlikely, and, like any other actively developing software project in the world, there are plans to improve it.

Also, if I really wanted to run the code that you gave as quickly as possible, I would optimize it to return 161315136; . Similar code can prove that implementation A is slower than implementation B in this case, but says nothing about where the people behind the implementation should focus their efforts.