Comparing Managed and unmanagged

[Giovanni Bassi]

Hello group,

I was discussing with a friend, a C++ programmer, and he told me that C++
code has a better performance than managed code (from either C#, VB.net,
managed code from .net framework).
I understand that managed code is running on top of other code and that
means we have more layers to get down to the operating system.
But isn't that also true for MFC applications, for example? Aren't they also
running on the top of previously made code?
In the end isn't it the same? Managed runs on top of the .net framework, and
unmanaged runs, for example, on top of MFC.
After all, is C++ faster? If not, why would I use it at all? If it is, how
much faster and is there anything that can be done (or being done) to
increase the perfomance of managed code up to C++ speed?

I also read that MFC is a more developed framework than the .net currently
is, meaning it offers more to the user of its classes. The example used was
the description of menu items appearing in the status bar. This
functionality is intrisinsic to MFC and is something we don't have yet ready
with .net framework (even though we can develop our own framework and do the
job ourselves). Is this so, and if it is does anybody know if Microsoft is
planning to work on the .net framework to increase the functionality? Also,
wouldn't that risk portability?
I also noticed that the classes from MFC have their code available. Why
isn't it so for .net framework?

Talking about portability, I haven't yet seen any .net framework for any
other plataforms. I heard about one being developed for Linux (maybe from
Coreal, I am not sure), but so far, I heard nothing I could trust. Have you
guys?

Thank you all that answer for helping me with those doubts,

Giovanni Bassi

 

[Alvin Bruney [MVP]]

I'll jump you on this one.

It is very difficult to compare these two languages because it is inherently
extremely difficult to write applications which do not project a bias toward
one language (there's a long thread about this in here as well). What I come
away with is that a less than knowledgable well-intentioned programmer can
easily screw up the application and introduce bias. It's easy to write code
as well which subverts the optimization process of .net. With all that said,
I believe that on an ordinary day with all things considered, a C#
application can come within at least 95% percent performance of C++. This
would only hold for non-memory intensive applications. I believe, and there
is support for this belief, that C++ would lose out in memory intensive
applications.

But isn't that also true for MFC applications, for example? Aren't they also
running on the top of previously made code?

right so this means that his point is moot.

After all, is C++ faster? If not, why would I use it at all? If it is, how

I believe that choosing a language depends much more than on performance.
What about readability, maintainability, portability, time to production
etc? Is that worth the 5% performance improvement? Is that even worth 15%
performance improvement?

Is this so, and if it is does anybody know if Microsoft is

planning to work on the .net framework to increase the functionality? Also,
wouldn't that risk portability?

realize that .net framework is in its first major version. The fact that it
even sits in the same playing field as a language developed in 1985 bears
testimony to the fact that it was well designed and developed in the first
place and that something was done right to begin with.

The plain fact of the matter is that C++ is inherently difficult to master.
It is even more difficult to write efficient well behaved code in C++. All
this enormous cost increases the cost of development and time to market in
C++. Now, at least, we have a viable alternative. I'm no C++ basher. I've
programmed at an advanced level in it for 5 years. In my mind, there is
absolutely no choice but to move to .net. none at all.

this is a can of worms by the way. but there's nothing going on at work so
feel free to fire away.

 

[Giovanni Bassi]

Hey Alvin,

Thanks for bringing all that information up. It surely clears many of my
doubts.

I am still missing the portability part and a little bit of the others. If
anyone knows about it please come and share!

Thanks again,

Giovanni Bassi

I'll jump you on this one.

It is very difficult to compare these two languages because it is inherently
extremely difficult to write applications which do not project a bias toward
one language (there's a long thread about this in here as well). What I come
away with is that a less than knowledgable well-intentioned programmer can
easily screw up the application and introduce bias. It's easy to write code
as well which subverts the optimization process of .net. With all that said,
I believe that on an ordinary day with all things considered, a C#
application can come within at least 95% percent performance of C++. This
would only hold for non-memory intensive applications. I believe, and there
is support for this belief, that C++ would lose out in memory intensive
applications.

But isn't that also true for MFC applications, for example? Aren't they also
running on the top of previously made code?

right so this means that his point is moot.

After all, is C++ faster? If not, why would I use it at all? If it is,

how
I believe that choosing a language depends much more than on performance.
What about readability, maintainability, portability, time to production
etc? Is that worth the 5% performance improvement? Is that even worth 15%
performance improvement?

Is this so, and if it is does anybody know if Microsoft is

planning to work on the .net framework to increase the functionality? Also,
wouldn't that risk portability?

realize that .net framework is in its first major version. The fact that it
even sits in the same playing field as a language developed in 1985 bears
testimony to the fact that it was well designed and developed in the first
place and that something was done right to begin with.

The plain fact of the matter is that C++ is inherently difficult to master.
It is even more difficult to write efficient well behaved code in C++. All
this enormous cost increases the cost of development and time to market in
C++. Now, at least, we have a viable alternative. I'm no C++ basher. I've
programmed at an advanced level in it for 5 years. In my mind, there is
absolutely no choice but to move to .net. none at all.

this is a can of worms by the way. but there's nothing going on at work so
feel free to fire away.
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/3he3b

Hello group,

I was discussing with a friend, a C++ programmer, and he told me that C++
code has a better performance than managed code (from either C#, VB.net,
managed code from .net framework).
I understand that managed code is running on top of other code and that
means we have more layers to get down to the operating system.
But isn't that also true for MFC applications, for example? Aren't they also
running on the top of previously made code?
In the end isn't it the same? Managed runs on top of the .net framework, and
unmanaged runs, for example, on top of MFC.
After all, is C++ faster? If not, why would I use it at all? If it is, how
much faster and is there anything that can be done (or being done) to
increase the perfomance of managed code up to C++ speed?

I also read that MFC is a more developed framework than the .net currently
is, meaning it offers more to the user of its classes. The example used was
the description of menu items appearing in the status bar. This
functionality is intrisinsic to MFC and is something we don't have yet ready
with .net framework (even though we can develop our own framework and do the
job ourselves). Is this so, and if it is does anybody know if Microsoft is
planning to work on the .net framework to increase the functionality? Also,
wouldn't that risk portability?
I also noticed that the classes from MFC have their code available. Why
isn't it so for .net framework?

Talking about portability, I haven't yet seen any .net framework for any
other plataforms. I heard about one being developed for Linux (maybe from
Coreal, I am not sure), but so far, I heard nothing I could trust. Have you
guys?

Thank you all that answer for helping me with those doubts,

Giovanni Bassi

 

[Richard Grimes [MVP]]

I was discussing with a friend, a C++ programmer, and he told me that
C++ code has a better performance than managed code (from either C#,
VB.net, managed code from .net framework).

The first thing to think about is that the JIT compiler was written by the
Visual C++ team, they're the experts in optimization, so I'm sure they have
made sure that during JIT compilation they optimize as much as possible. In
this respect you could say that native C++ code and IL are mere inputs into
compilers written by the optimization gurus in the C++ team. Knowing this,
how can you say that JIT compiled code is slower than x86 compiled from
native C++?

I understand that managed code is running on top of other code and
that means we have more layers to get down to the operating system.
But isn't that also true for MFC applications, for example? Aren't
they also running on the top of previously made code?
In the end isn't it the same? Managed runs on top of the .net
framework, and unmanaged runs, for example, on top of MFC.

This is difficult to answer without profiling. Both the framework and an MFC
app run over Win32, the question is how many layers are there between the
app and Win32? In my experience, many of the .NET classes are thin wrappers
over Win32, but then again, a lot of MFC classes are too. I guess there's
not much difference between the two, (although .NET does have to use a
[efficient] thunking layer to get down to Win32).

After all, is C++ faster? If not, why would I use it at all? If it
is, how much faster and is there anything that can be done (or being
done) to increase the perfomance of managed code up to C++ speed?

Compiled C++ is definately faster than other languages, and faster than
interpreted languages. But as I've said, the .NET JIT compiler benefits from
the Visual C++ team's experience, so saying that compiled C++ is fast also
implies that JIT compiled code is fast too (Of course, you do have to
take that once-only JIT compilation hit).

In my tests (which were limited to a single computationally intensive
routine) managed code actually ran *faster*. I compiled to x86 a FFT
algorithm in native C++ using various optimization switches. A did some
minor adjustments (to make sure that .NET memory allocations were used) and
compiled the same code to IL, again, with various optimization switches. I
took measurements of how long the code took to perform calculations over
large input data, discounting the time taken to JIT compile the code (ie I
averaged the .NET code over many runs, but discounting the first call of the
function) and I found that in most cases the .NET code was faster. Microsoft
does not publish performance data and your tests may be different to mine,
but it certainly convinced me that the statement that 'native C++ is faster
than .NET' is baseless.

I also read that MFC is a more developed framework than the .net
currently is, meaning it offers more to the user of its classes. The
example used was the description of menu items appearing in the
status bar. This functionality is intrisinsic to MFC and is something
we don't have yet ready with .net framework (even though we can
develop our own framework and do the job ourselves).

Sadly, that is true. Windows Forms is essentially a managed version of VB6
forms.

Is this so, and
if it is does anybody know if Microsoft is planning to work on the
.net framework to increase the functionality? Also, wouldn't that
risk portability?

Not that I know of. Its very sad.

On the bright side, *everything* will change in Longhorn, you can still
write Windows Forms apps, but there is a new paradigm that you should target
instead: the presentation services in Avalon.

I also noticed that the classes from MFC have their code available.
Why isn't it so for .net framework?

I have heard people from Microsoft say (at public conferences) that they
were considering doing this since it would help when you debug your code.
However, I would say that it would be make debugging more convenient. You
see, there's several .NET decompilers out there and in effect these give you
access to the source code (you just can't step through the code with a
debugger).

Talking about portability, I haven't yet seen any .net framework for

My opinion on portability is that .NET is *not* designed to be portable.
When you compile code to an assembly the *exact* version of the framework
and the *exact* versions of the libraries it uses are embedded in the
assembly. The framework checks all of those versions with the
libraries/runtime it can find and throws an exception if the version is not
available. You can turn this off with a configuration file, but there's a
reason why such 'static' binding occurs. It may be possible that other third
party runtimes weaken this requirement, but that will simply end up in the
Java 'write once, test everywhere' mentality.

On the other hand, the source code is likely to be portable across compilers
on different platforms, especially if you write in C# which is an agreed
standard.

Richard

 

[Giovanni Bassi]

Hey Richard,

Thanks for your reply too! It was very explanative! It cleared some other
doubts.

Giovanni Bassi

I was discussing with a friend, a C++ programmer, and he told me that
C++ code has a better performance than managed code (from either C#,
VB.net, managed code from .net framework).

The first thing to think about is that the JIT compiler was written by the
Visual C++ team, they're the experts in optimization, so I'm sure they have
made sure that during JIT compilation they optimize as much as possible. In
this respect you could say that native C++ code and IL are mere inputs into
compilers written by the optimization gurus in the C++ team. Knowing this,
how can you say that JIT compiled code is slower than x86 compiled from
native C++?

I understand that managed code is running on top of other code and
that means we have more layers to get down to the operating system.
But isn't that also true for MFC applications, for example? Aren't
they also running on the top of previously made code?
In the end isn't it the same? Managed runs on top of the .net
framework, and unmanaged runs, for example, on top of MFC.

This is difficult to answer without profiling. Both the framework and an MFC
app run over Win32, the question is how many layers are there between the
app and Win32? In my experience, many of the .NET classes are thin wrappers
over Win32, but then again, a lot of MFC classes are too. I guess there's
not much difference between the two, (although .NET does have to use a
[efficient] thunking layer to get down to Win32).

After all, is C++ faster? If not, why would I use it at all? If it
is, how much faster and is there anything that can be done (or being
done) to increase the perfomance of managed code up to C++ speed?

Compiled C++ is definately faster than other languages, and faster than
interpreted languages. But as I've said, the .NET JIT compiler benefits from
the Visual C++ team's experience, so saying that compiled C++ is fast also
implies that JIT compiled code is fast too (Of course, you do have to
take that once-only JIT compilation hit).

In my tests (which were limited to a single computationally intensive
routine) managed code actually ran *faster*. I compiled to x86 a FFT
algorithm in native C++ using various optimization switches. A did some
minor adjustments (to make sure that .NET memory allocations were used) and
compiled the same code to IL, again, with various optimization switches. I
took measurements of how long the code took to perform calculations over
large input data, discounting the time taken to JIT compile the code (ie I
averaged the .NET code over many runs, but discounting the first call of the
function) and I found that in most cases the .NET code was faster. Microsoft
does not publish performance data and your tests may be different to mine,
but it certainly convinced me that the statement that 'native C++ is faster
than .NET' is baseless.

I also read that MFC is a more developed framework than the .net
currently is, meaning it offers more to the user of its classes. The
example used was the description of menu items appearing in the
status bar. This functionality is intrisinsic to MFC and is something
we don't have yet ready with .net framework (even though we can
develop our own framework and do the job ourselves).

Sadly, that is true. Windows Forms is essentially a managed version of VB6
forms.

Is this so, and
if it is does anybody know if Microsoft is planning to work on the
.net framework to increase the functionality? Also, wouldn't that
risk portability?

Not that I know of. Its very sad.

On the bright side, *everything* will change in Longhorn, you can still
write Windows Forms apps, but there is a new paradigm that you should target
instead: the presentation services in Avalon.

I also noticed that the classes from MFC have their code available.
Why isn't it so for .net framework?

I have heard people from Microsoft say (at public conferences) that they
were considering doing this since it would help when you debug your code.
However, I would say that it would be make debugging more convenient. You
see, there's several .NET decompilers out there and in effect these give you
access to the source code (you just can't step through the code with a
debugger).

Talking about portability, I haven't yet seen any .net framework for

My opinion on portability is that .NET is *not* designed to be portable.
When you compile code to an assembly the *exact* version of the framework
and the *exact* versions of the libraries it uses are embedded in the
assembly. The framework checks all of those versions with the
libraries/runtime it can find and throws an exception if the version is not
available. You can turn this off with a configuration file, but there's a
reason why such 'static' binding occurs. It may be possible that other third
party runtimes weaken this requirement, but that will simply end up in the
Java 'write once, test everywhere' mentality.

On the other hand, the source code is likely to be portable across compilers
on different platforms, especially if you write in C# which is an agreed
standard.

Richard

 

[Richard Grimes [MVP]]

Hey Richard,

Thanks for your reply too! It was very explanative! It cleared some
other doubts.

happy to help

Richard