Has microsoft given up on .NET for performance-critical applications?

  • Thread starter Thread starter Rüdiger Klaehn
  • Start date Start date
R

Rüdiger Klaehn

Hello everybody,

I have noticed that performance-related improvements seem to have a
very low priority at microsoft compared to adding new language
features and APIs. Longstanding issues such as the total lack of
inlining when using value types are not fixed on the x64 CLR despite
being open for four years!

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93858

In general, the generated machine code is very poorly optimized
compared to e.g. the machine code generated by the java hotspot JIT.
And new high-performance APIs such as Direct2D and DirectWrite are
released as pure native APIs. Not even managed wrappers are provided.

It seems that microsoft has given up on the CLR as far as high
performance code is concerned. The features being released with
the .NET framework 4.0 (dynamic invoke, better com and office
interop, ...) all point to .NET languages being used primarily as glue
languages and not as core languages.

Is there any large performance update planned to the CLR JIT compiler
in the future, or should people needing acceptable performance move
back to unmanaged C++?

best regards,

Rüdiger
 
Admittedly this does seem to have fallen by the wayside a bit, or at least
it seems to have. This is an inherent problem with non-native code though,
and it's probably something that's not going away soon. It may be more a
case of the problem needing to be solved at the OS level rather than the
compiler level.
In general, the generated machine code is very poorly optimized
compared to e.g. the machine code generated by the java hotspot JIT.
I haven't seen (or heard of) any performance benchmarks between Java apps
optimised using that particular JIT though - do you know of any (links?) and
if so, are comparable Java apps significantly faster than a .NET equivalent?

I wonder if anyone has produced a 3rd party optimizer for .NET IL that can
out-pace the MS compilers output? I know C++/CLI has different (and
generally better) optimisations for its compiled output than the natively
..NET languages like VB.NET and C#, so perhaps there is more scope for
improvement there?

Regards,
Alex
 
Admittedly this does seem to have fallen by the wayside a bit, or at least
it seems to have.  This is an inherent problem with non-native code though,
and it's probably something that's not going away soon.  It may be morea
case of the problem needing to be solved at the OS level rather than the
compiler level.
Click to expand...
The best place to do this is the JIT compiler / runtime. But
everything would be better than having to go back to unmanaged C++.
I haven't seen (or heard of) any performance benchmarks between Java apps
optimised using that particular JIT though - do you know of any (links?) and
if so, are comparable Java apps significantly faster than a .NET equivalent?
Click to expand...
That is not surprising since the EULA for the .NET framework forbids
benchmarking, or at least posting benchmark results!

In general, java is much faster in tight loops, but loses out for
large applications because the java bytecode does not support value
types. But the next version of the java JIT compiler will contain a
feature called stack allocation that will reduce this problem quite a
bit.
I wonder if anyone has produced a 3rd party optimizer for .NET IL that can
out-pace the MS compilers output?  I know C++/CLI has different (and
generally better) optimizations for its compiled output than the natively
.NET languages like VB.NET and C#, so perhaps there is more scope for
improvement there?
Click to expand...
I would be happy if the C# compiler/JIT combo would produce the same
code quality as the C++ CLR/JIT combo. I don't really care if the
optimization happens at MSIL level or during JIT compilation.

A better version of ngen.exe that allows merging assemblies and then
optimizing the combined assembly would be perfect. Something like this
could be made in a man-year or so using the phoenix compiler
framework.

But it won't happen because .NET performance does not have any
priority for Microsoft. Correction: they do care about startup
performance, but not about raw performance for longer-running programs.
 
Back
Top