Differences between Visual C++ and Visual C++.Net

  • Thread starter Thread starter LifeStory via DotNetMonster.com
  • Start date Start date
L

LifeStory via DotNetMonster.com

Hi all,

is there a differene between VC.Net and VC? (performance issues not the
syntax) and which is more efficient for programs that need very effecient
memry utilizations and multithreading applications?

Thanks,
nana
 
LifeStory via DotNetMonster.com said:
Hi all,

is there a differene between VC.Net and VC? (performance issues not the
syntax) and which is more efficient for programs that need very effecient
memry utilizations and multithreading applications?
Click to expand...

It's not clear what you're asking, since there are no products named "VC" or
"VC.NET". Are you asking about differences between Visual C++ (2002? 2003?
2005? 2008?) when producing native code versus managed code? Or is it
something else?

Efficiency is tricky - you need to be very specific about what's important.
For example, allocating memory is many times more efficient in managed code
than in unmanaged code, but there are other trade-offs (memory related and
otherwise) that may make managed code slower for a particular application.

-cd
 
LifeStory via DotNetMonster.com said:
Hi all,

is there a differene between VC.Net and VC? (performance issues not the
syntax) and which is more efficient for programs that need very effecient
memry utilizations and multithreading applications?
Click to expand...

Default memory allocator is a bottleneck for native C++ code, .NET's garbage
collector does better. But .NET cannot even come close to the performance
using a well-designed allocator like hoard.
http://www.hoard.org/
 
Default memory allocator is a bottleneck for native C++ code, .NET's
garbage collector does better. But .NET cannot even come close to the
performance using a well-designed allocator like hoard.
http://www.hoard.org/
Click to expand...

Can you point to any studies that justify that statement? The built-in
allocqator for VC++ is certainly no winner on speed, but for certain
workloads, I'd expect the .NET allocator to beat the best written non-GC
allocator. Likewise, for certain workloads, I'd expect a well written
non-GC allocator to kick the pants off of the .NET allocator. Which is
better depends on your application.

-cd
 
Carl Daniel said:
Can you point to any studies that justify that statement? The built-in
allocqator for VC++ is certainly no winner on speed, but for certain
workloads, I'd expect the .NET allocator to beat the best written non-GC
allocator. Likewise, for certain workloads, I'd expect a well written
non-GC allocator to kick the pants off of the .NET allocator. Which is
better depends on your application.
Click to expand...

The .NET allocator is still a shared allocator, with all the performance hit
associated with contention. Take a look at the hoard feature list. It
accounts for and tries to automatically improve things I'd never even
considered, like false cache-line sharing. The .NET allocator, though it
benefits from the advantages of GC, simply isn't in the same class.
Probably some gc-based allocator could beat hoard on the workloads you speak
of, but I don't think the .NET one is sophisticated enough to compete.
 
Back
Top