Way to improve managed code performance

[Nadav]

Hi,

I hope this post will find it's way to some MS technical authority...

I am experienced with bought Unmanaged C++ and Managed code ( C# ), There
are some issues with the .NET framework that make me wonder...

Take in mind the following points:
1. Managed objects are managed by the GC through the managed heap.
2. The GC moves the physical data representation of managed objects to
reserve address space.

Problems with this logic:
******************
A. to be able to access the physical address space directly ( through
unmanaged code ) one would have to 'pin' the managed object, hence,
preventing the GC from moving the physical data around, pinning data in such
a way causes a performance degradation.
B. Passing unmanaged pointers to methods with managed Object type variables
is not possible, a managed wrapper must be created and the data should be
copied to the managed buffer, doing rapid memory coping dramatically reduce
performance...

Resolution:
********
64bit computing offers a huge address space, this makes the need for the GC
memory compacting mechanism unnecessary as the address-space is so large,
disabling memory compaction will cancel the need of pinning managed objects (
as they will be pinned anyhow ) and will enable more efficient data transfer
between managed and unmanaged code ( as referred to in B. )

Nadav
nadavrub AT gmail DOT com

[Ollie Riches]

have you ever used a computer where the hard drive is fragmented over 95% ?
"Nadav" <Na***@discussions.microsoft.com> wrote in message
news:08**********************************@microsof t.com...

Hi,

I hope this post will find it's way to some MS technical authority...

I am experienced with bought Unmanaged C++ and Managed code ( C# ), There
are some issues with the .NET framework that make me wonder...

Take in mind the following points:
1. Managed objects are managed by the GC through the managed heap.
2. The GC moves the physical data representation of managed objects to
reserve address space.

Problems with this logic:
******************
A. to be able to access the physical address space directly ( through
unmanaged code ) one would have to 'pin' the managed object, hence,
preventing the GC from moving the physical data around, pinning data in such a way causes a performance degradation.
B. Passing unmanaged pointers to methods with managed Object type variables is not possible, a managed wrapper must be created and the data should be
copied to the managed buffer, doing rapid memory coping dramatically reduce performance...

Resolution:
********
64bit computing offers a huge address space, this makes the need for the GC memory compacting mechanism unnecessary as the address-space is so large,
disabling memory compaction will cancel the need of pinning managed objects ( as they will be pinned anyhow ) and will enable more efficient data transfer between managed and unmanaged code ( as referred to in B. )

Nadav
nadavrub AT gmail DOT com

[Bruce Wood]

Logical disconnect: "64bit computing offers a huge address space"

"Address space" does not equal "available RAM". Just because my machine
can address so many trillions of bytes does not mean that I have that
installed on my motherboard.

Writing a system that assumes that I have massive amounts of memory
available when, in fact, I don't results in two potential problems:

1. An application that gobbles massive amounts of memory when it
doesn't have to. Perhaps more than I have, leading it to run like a
pig. And, even if I really do have that much memory...

2. An application that gobbles up more memory than it needs to, and so
leaves less memory for other applications running in the same
(physical) memory that could probably use that memory in order to do
something useful.

It's bad enough that you can now suck up a meg of RAM without meaning
to on a single (ill-conceived) method call in O-O languages, without
the garbage collector getting into the act and not bothering to make
efficient use of memory because there's "lots there".

If you're so concerned about low-level efficiencies in your code,
_don't use a garbage-collected language like C#_. Don't try to hammer
in a screw. Don't push on a rope. If you want raw speed, or you need
predictable real-time deadlines, use C or C++ compiled to unmanaged
code. Yes, the garbage collector often gets in the way of performance;
for that reason, if you need that much performance, don't use a GCed
language.

[_R]

On 17 Feb 2005 09:40:58 -0800, "Bruce Wood" <br*******@canada.com>
wrote:

If you're so concerned about low-level efficiencies in your code,
_don't use a garbage-collected language like C#_. Don't try to hammer
in a screw. Don't push on a rope. If you want raw speed, or you need
predictable real-time deadlines, use C or C++ compiled to unmanaged
code. Yes, the garbage collector often gets in the way of performance;
for that reason, if you need that much performance, don't use a GCed
language.

I realize I'm a couple weeks late replying to this, but why would C#
be inherently so much weaker at memory allocation in comparison
to C++? I understand the possible performance issues, but it sounded
like you were saying that the alloc mechanism itself is inferior.

Or were you referring to the fact that not explicitly dealllocing ram
at chosen times causes the problems?

[Tad Marshall]

My impression is that GC'ed memory allocation is blindingly fast, and stays
this way until you run out of memory and have to GC. So, if you have 1 GB
of RAM and need 128 KB, you will never see a slowdown from GC. If you have
1 GB of RAM and need 128 MB over and over, then this will be an issue.

If you know exactly what you will be doing with memory, the fastest scheme
is probably to do it yourself. I write some code where I needed to flip
back and forth between two tables, and there was no reason to ask the memory
system to help me ... I just allocate two tables, and flip back and forth
between them. If your memory needs are random and unpredictable, then GC is
your friend ... just let it do its thing

Just my 2c.

Tad

"_R" <[e-mail]> wrote in message
news:n7********************************@4ax.com...

On 17 Feb 2005 09:40:58 -0800, "Bruce Wood" <br*******@canada.com>
wrote:

If you're so concerned about low-level efficiencies in your code,
_don't use a garbage-collected language like C#_. Don't try to hammer
in a screw. Don't push on a rope. If you want raw speed, or you need
predictable real-time deadlines, use C or C++ compiled to unmanaged
code. Yes, the garbage collector often gets in the way of performance;
for that reason, if you need that much performance, don't use a GCed
language.

I realize I'm a couple weeks late replying to this, but why would C#
be inherently so much weaker at memory allocation in comparison
to C++? I understand the possible performance issues, but it sounded
like you were saying that the alloc mechanism itself is inferior.

Or were you referring to the fact that not explicitly dealllocing ram
at chosen times causes the problems?