Has microsoft given up on .NET for performance-critical applications?
Rüdiger Klaehn
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
Robert
> 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++?
Check out the Phoenix project. Basically a compiler with plugins. Write
your own
analysis phase, do EXE rewriting, whatever.
Rüdiger Klaehn
But how does that answer my question?
You mean that if I want decent performance from .NET applications I
have to write my own compiler using a compiler development kit that
microsoft kindly provided? Are you serious?
Or is microsoft planning an update to the CLR JIT based on phoenix?
Rüdiger Klaehn
> 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.
>
The best place to do this is the JIT compiler / runtime. But
everything would be better than having to go back to unmanaged C++.
>> 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?
>
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?
>
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.
Robert
> But how does that answer my question?
>
> You mean that if I want decent performance from .NET applications I
> have to write my own compiler using a compiler development kit that
> microsoft kindly provided? Are you serious?
>
> Or is microsoft planning an update to the CLR JIT based on phoenix?
Supposed to be the basis of all future Microsoft compilers.
Does not seem anywhere near release though..
Cowboy (Gregory A. Beamer)
about, but I have found .NET performs quite well for most apps. You will see
more perf out of .NET 4.0 when they get the parallel extensions fettered
out. I am not sure you will ever see the level of performance of C, but that
is fine for most apps. In general, perf is not the only concern, and in most
apps I have seen, it is not the primary concern.
But, if you need high performing algorithms, assembler, C and C++ are always
going to smoke a managed environment. The trade off is safety versus
performance. And it is likely that will not change for quite some time.
As for the "is Microsoft going to" part of the question, there are already
hints of looking at performance upgrades and you will see some in 4.0. But
the current "keeping up with the Jones" approach (perhaps "keeping ahead of
the Jones") pushes MS, like others, to keep adding sexy new features. This
does not mean you won't see incremental improvements in performance, but
that pure perf is not the design goal of .NET.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
*************************************************
| Think outside the box! |
*************************************************
"R�diger Klaehn" <ru...@lambda-computing.com> wrote in message
news:b7ff9953-1afa-4c60...@j12g2000vbl.googlegroups.com...
> R�diger
Rüdiger Klaehn
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:
> I am not sure what algorithms you are running or the scale you are talking
> about, but I have found .NET performs quite well for most apps.
>
observation satellite. It has to schedule as many activities as
possible on the satellite without violating resource constraints
(energy usage, storage space, etc). It is a very challenging
application. We need both lots of memory and high performance. But so
do many other mundane programs such as games.
Java has a reputation of being slow. It is not slow anymore, but
people still think of it as slow because it was slow the first time
they used a java program. The first impression counts. And .NET is
just getting a reputation for being slow.
> You will see
> more perf out of .NET 4.0 when they get the parallel extensions fettered
> out. I am not sure you will ever see the level of performance of C, but that
> is fine for most apps. In general, perf is not the only concern, and in most
> apps I have seen, it is not the primary concern.
>
In theory you should be able to see performance comparable to C. And
the java hotspot compiler does deliver some quite impressive
performance for tight loops. The achilles heel of java is that it
creates too many objects due to the fact that it does not have an
abstraction below a full-blown object. But at least they have done
something about it by implementing stack allocation in 1.7.
.NET has such an abstraction (structs/ValueTypes), but this idiotic
inlining limitation prevents it from being useful. It is possible to
fix this, and they did it for the x86 VM. But they still did not fix
it for the x64 VM. Not even in 4.0 beta 1.
I can't believe that in a huge company like microsoft there are no
resources for such vital problems. Look at the feedback item: it is
probably the highest rated performance-related feedback item. It has
been open since 2004. It is easy to fix. But they don't do it.
The only logical conclusion is that they have given up on .NET for
performance-critical stuff. There is no managed wrapper for Direct2D/
DirectWrite, and there is no longer a managed wrapper for DirectX.
(There is XNA, but that is for games, not for serious applications).
And windows 7 does not contain any managed code in core components. I
am not sure if it contains any managed code at all.
> But, if you need high performing algorithms, assembler, C and C++ are always
> going to smoke a managed environment. The trade off is safety versus
> performance. And it is likely that will not change for quite some time.
>
If you have a team of people who are not familiar with C++ and not
enough time to train them, you don't have much choice except to use a
managed language. Slow as hell compared to C++, but it beats tracking
down memory leaks and loose pointers created by rookie C++
programmers.
> As for the "is Microsoft going to" part of the question, there are already
> hints of looking at performance upgrades and you will see some in 4.0. But
> the current "keeping up with the Jones" approach (perhaps "keeping ahead of
> the Jones") pushes MS, like others, to keep adding sexy new features. This
> does not mean you won't see incremental improvements in performance, but
> that pure perf is not the design goal of .NET.
>
There is nothing sexy about adding lots and lots of limited use
features such as dynamic to a language. Except if you think that rube
goldberg machines are sexy. But that is of course just my personal
opinion.
G�nter Prossliner
> 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!
[Vance Morrison's Weblog : Here is your chance to get your Performance
requests in for the next version of the .NET Runtime]
http://blogs.msdn.com/vancem/archive/2009/05/28/here-is-your-chance-to-get-your-performance-requests-in-for-the-next-version-of-the-net-runtime.aspx
GP
Rüdiger Klaehn
> Hello Rüdiger!
>
> > 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!
>
> [Vance Morrison's Weblog : Here is your chance to get your Performance
>
> GP
On the off chance that they will listen this time, I have filled it
out. But all they need to do is to look for performance-related
feedback items that have a very high rating and that are open since
2004!!!!!! :-(
Ben Voigt [C++ MVP]
> On May 20, 12:47 am, "Cowboy \(Gregory A. Beamer\)"
> <NoSpamMgbwo...@comcast.netNoSpamM> wrote:
>> I am not sure what algorithms you are running or the scale you are
>> talking about, but I have found .NET performs quite well for most
>> apps.
>>
> The program in question is the mission planning software for an earth
> observation satellite. It has to schedule as many activities as
> possible on the satellite without violating resource constraints
> (energy usage, storage space, etc). It is a very challenging
> application. We need both lots of memory and high performance. But so
> do many other mundane programs such as games.
Well since C++ is designed with that application in mind
(http://www.research.att.com/~bs/autonomics09.pdf) I think you probably
should consider using it.
SG
>inlining limitation prevents it from being useful. It is possible to
>fix this, and they did it for the x86 VM. But they still did not fix
>it for the x64 VM. Not even in 4.0 beta 1.
>I can't believe that in a huge company like microsoft there are no
>resources for such vital problems. Look at the feedback item: it is
>probably the highest rated performance-related feedback item. It has
>been open since 2004. It is easy to fix. But they don't do it.
This is where open source do best, if .the code of .NET was open, you or
maybe someone else could have fixed this thing. So my answer is: try to look
at Mono and see if it fit your needs, its commercially supported but I
don't know his performances, otherwise make a switch to the Java world, or
use managed assemblies for the critical parts of your project.
G�nter Prossliner
> This is where open source do best, if .the code of .NET was open, you
> or maybe someone else could have fixed this thing.
Theoretically.
Great potions of the .NET Framework Base-Library Code has been made public.
But (of cause) you cannot "check-in" something.
There is an open CLR Implementation (Shared Source CLI) and AFAIK the MONO
project is based on this. You can build your own CLR based on that. But
that's not really an option in most cases. As with most other Open-Source
projects. As long as you chance are not committed in the main branch you get
an "isolated" version you cannot update or participate in other's work
because they don't include your adaptions.
> try to look at Mono and see if it fit your needs, its commercially
> supported but I don't know his performances,
"performance" has no plurar form ;-)
now comes complete nonsense ...
> otherwise make a switch to the Java world,
Because Java is open source?
> or use managed assemblies for the critical parts
> of your project.
It seems like you don't know what managed assemblies are.
GP
SG
>
>> otherwise make a switch to the Java world,
>
> Because Java is open source?
I didn't said it is.
>
>> or use managed assemblies for the critical parts
>> of your project.
>
> It seems like you don't know what managed assemblies are.
imho, sorry, another typo, i meant mixed code (native-managed) assemblies.
gareth erskine-jones
<ru...@lambda-computing.com> wrote:
>> 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?
>>
>That is not surprising since the EULA for the .NET framework forbids
>benchmarking, or at least posting benchmark results!
No it doesn't:
http://msdn.microsoft.com/en-us/library/ms973265.aspx
GSEJ
![Rich Lander [MSFT]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWHdGKIrlC0kDA3mN1zOV3j9NslZyLgAy2JL24D24c-Q3dcRQ=s40-c)
Rich Lander [MSFT]
The product team responded to the connect issue.
rich