Home > Archive > Visual Studio > March 2004 > Re: Visual Studio .NET Verdict? Are People Using C#?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Visual Studio .NET Verdict? Are People Using C#?
|
|
| JohnGardnerJr 2004-03-29, 12:34 pm |
| Why "Resource Acquisiton Is Initialization" (RAII) which is really a topic
about exception safety, not about fundamental direction of the language or
its applicability to real-time determinism or do we (I) have the wrong
acronym?
Normally when I here of RAII in the context of C++ I think of Stroustrup's,
Sutter's comments on exception safety.
It seems like GC (garbage collection) would be the battle of choice???
And while RAII does similar things, you really have to work at it. And I am
not the only one saying this either. Andrei Alexandrescu has made similar
comments. In that it's a pain to wrap every resource up as class.
So far, for my real-time stuff, GC hasn't been that much of a problem since
you can inhibit it during sections of code where you need dedicated
processing. Granted my stuff isn't that demanding ( I don't have worry
about anything shorter than a millisecond)
Personally, I think C++ will be replaced by .Net languages for most Windows
development in the next few years . My company is already heading in this
direction. Limitations with .Net haven't been many and we can write code so
much faster. In other arenas I believe it will live on much longer.
I think developers get tired of having to deal with so many "gotchas". You
really have to deal very carefully with the language ( in the case of C++).
I want to focus on what I am trying to accomplish not on the tool that I use
to accomplish it. Sometimes I think the flood of developers to Java is
cause less by a desire to portability in favor of an easier to use tool.
Regarding Java, I agree that C# and Java are very similar ( I like C# as a
language better though) but it if you're developing for Windows I think you
will get much better performance from C#.
"David Turner" <david@firepro.co.za> wrote in message
news:1074756833.216249@tanzanite.firepro.co.za...
> Hi
>
about[color=darkred]
about[color=darkred]
> different
>
> When I said "compare" there, I meant it more in the sense of "saying C++
and
> C# are similar". They're surprisingly unsimilar. Sure, the syntax looks
> quite similar, but they're on different ends of an ideological split.
>
> As I said, a good way to start learning about that split is by reading up
on
> RAII. The executive summary is that C++ is more suitable to tasks that
are
> less interactive but have more stringent constraints on timeliness,
> predictability and robustness.
>
> Regards
> David Turner
>
>
| |
| fungus 2004-03-29, 6:51 pm |
| JohnGardnerJr wrote:
> Why "Resource Acquisiton Is Initialization" (RAII) which is really a topic
> about exception safety, not about fundamental direction of the language or
> its applicability to real-time determinism or do we (I) have the wrong
> acronym?
>
> It seems like GC (garbage collection) would be the battle of choice???
Glub, no.
Why would you put your precious system resources in
the hands of fate?
"When will the file be flushed to disk and closed?"
"Dunno, I'm still waiting for the garbage collector
to kick in...".
"Exactly when will that network socket be available
for re-use?"
"How should I know, it's all automatic...isnīt it?"
Sorry, that's not good enough...
> And while RAII does similar things, you really have
> to work at it.
Not really. Learn to use C++ properly and it's
nearly as "automatic" as your garbage collector.
> In that it's a pain to wrap every resource up as class.
>
In a real sized program it's an insignificant amount
of code. Most resources in such programs are (or should
be) abstracted so the wrapping has to be anyway.
> I think developers get tired of having to deal with so many "gotchas". You
> really have to deal very carefully with the language ( in the case of C++).
> I want to focus on what I am trying to accomplish not on the tool that I use
> to accomplish it.
With a bit of practice it comes easily.
> Sometimes I think the flood of developers to Java is
> cause less by a desire to portability in favor of an easier to use tool.
>
The "simplicity" will come back and bite you one day.
Garbage collection is Ok for dinky applets or programs
which just do something and exit. For programs which
are run for days/w s or programs which need to handle
a lot of resources (not just RAM) it falls flat on its
face. Just try allocating a milion objects in Java
*before* you run your pretty little garbage collection
benchmarks. Watch the program grind to a halt as the
garbage collector starts to kick in and scan all those
objects two or three times per second.
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
| |
| Nick Landsberg 2004-03-29, 6:51 pm |
| fungus wrote:
>
> Garbage collection is Ok for dinky applets or programs
> which just do something and exit. For programs which
> are run for days/ws or programs which need to handle
> a lot of resources (not just RAM) it falls flat on its
> face. Just try allocating a milion objects in Java
> *before* you run your pretty little garbage collection
> benchmarks. Watch the program grind to a halt as the
> garbage collector starts to kick in and scan all those
> objects two or three times per second.
>
>
In principle, I agree. Howevere, the "art" of
garbage collection has proceeded to the point
that it will kick in way before a million objects
are allocated.
I will say that a "garbage collection" style of
architecture is not an option for an application
which has strict, consitent response time requiements.
e.g. "Delay (latency) in responding to this query
shall not exceed 300 milliseconds 95% of the time."
Now, what happens if the GC kicks in every minute
and hogs the CPU for 300 ms. or more?
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
| |
| fungus 2004-03-29, 11:32 pm |
| Nick Landsberg wrote:
> fungus wrote:
>
>
>
> In principle, I agree. Howevere, the "art" of
> garbage collection has proceeded to the point
> that it will kick in way before a million objects
> are allocated.
>
Yes of course, it's just an example. The point is that
garbage collection is expensive, no matter what people
say. As usual, microbenchmarks demonstrate nothing.
> I will say that a "garbage collection" style of
> architecture is not an option for an application
> which has strict, consitent response time requiements.
>
In my experience, garbage collection has very non-linear
performance. With a million objects in memory then every
little temporary string/object can potentially be *very*
expensive. Languages with explicit creation/release
of resources have a much more linear response. C++ can
also create temporary objects on the stack and these are
completely free in terms of memory allocation overhead.
I don't think this problem will go away any time soon.
People think garbage collection will make their lives
easier but in a Java project I worked on we spent a
lot of time trying to write code to avoid temporary
objects, to recycle objects, and to make the garbage
collector's life as easy as possible. In the end we
probably spent more time doing this than we would
have done writing manual allocation/release in C++
and we *still* had a program which chugged enough
to be annoying.
The other problem, ie. knowing _when_ things like files
will be closed, is even worse in a garbage collected
system. Yes, you can call fclose() by hand (or was it
called "finalize()", I can never remember...) but when
you add exceptions to the mix then you end up enclosing
everything in try...finally blocks. This is fine, except
that you have write that same try...finally code every
single time you want to use a file (or whatever...)
Your code ends up littered with the things, there's
try...finally clauses _all over_ the place, and every
one is a potential bug. Hellooo! What's going on here?
Garbage collection was supposed to make my life easier,
not harder.
The original poster said "it's a pain to wrap every
resource up as class". I say that try...finally is a
*much* bigger PITA. In C++ I write the allocate/release
code *just once* in the object constructor/destructor
then I just use stack-allocted objects or auto_ptr
to manage things. Everything just works, even when I
start throwing exceptions, and I didn't have to read
your documentation to find out how to do it properly
for each object in your library. C++ stack unwinding
is a powerful tool, don't forget it.
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
| |
|
| Nick Landsberg wrote:
> fungus wrote:
>
>
>
> In principle, I agree. Howevere, the "art" of
> garbage collection has proceeded to the point
> that it will kick in way before a million objects
> are allocated.
>
> I will say that a "garbage collection" style of
> architecture is not an option for an application
> which has strict, consitent response time requiements.
>
> e.g. "Delay (latency) in responding to this query
> shall not exceed 300 milliseconds 95% of the time."
>
> Now, what happens if the GC kicks in every minute
> and hogs the CPU for 300 ms. or more?
You can arrange for that to never happen.
For performance-critical stuff, GC is probably not an idea choice. But
GC has come a lot further than that. Firstly you have parallel
collection, which does not introduce latencies, but it is not so
efficient. Then you have incremental GC, so you don't do your GC all in
one go, you do it in little bites of a few hundred objects, perhaps that
would amount to a few microseconds each time.
Finally, you can also disable garbage-collection completely if you are
in the middle of a time-critical operation, and also force GC at a
particular time if you have just become idle, or manually request it to
be done incrementally, for example in an idle loop.
GC now has a performance overhead of just a few percent. For that cost,
I think the benefits outweigh the costs in many circumstances.
| |
| fungus 2004-03-30, 8:36 am |
| Calum wrote:
>
> GC now has a performance overhead of just a few percent.
Prove it...
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
| |
| Calum 2004-03-30, 10:48 am |
| fungus wrote:
> Calum wrote:
>
>
>
> Prove it...
1) "A good garbage collector will have an overhead of 5% to 15%" page
307, B. Meyer, Object-Oriented Software Construction, 2nd Ed, 1997
2) http://www.hpl.hp.com/personal/Hans_Boehm/gc/
"Performance of the nonincremental collector is typically competitive
with malloc/free implementations. Both space and time overhead are
likely to be only slightly higher for programs written for malloc/free"
"If the collector is used in a multithreaded environment and configured
for thread-local allocation, it may in some cases significantly
outperform malloc/free allocation in time."
3) Detlefs, Dosser & Zorn, "Memory Allocation Costs in Large C and C++
programs" ftp://ftp.cs.colorado.edu/pub/techr...-CS-665-93.ps.Z
| |
| fungus 2004-03-30, 1:37 pm |
| Calum wrote:
>
>
>
> 1) ...
>
> 2) ...
>
> 3) ...
Yeah, yeah. Microbenchmarks and academic papers prove
nothing in the real world.
All those papers deal with ideal cases. In the real
world there's two fatal flaws with garbage collectors.
It took me a month of real experience to figure this
out but in the end they are the reason why I gave up
on them.
1) Garbage collectors are very conservative about
expanding the heap. When you start getting near the
limits they spend more time scanning and (mostly
uselessly) trying to free memory than they spend
executing your code.
Yes, many runtimes allow you to specify initial
heap size from the command line but how you're
supposed to guess the amount of memory needed is
a mystery. Trail and error seems to be the only
way. Besides, you can hardly ask the average user
to start doing this just to run your program.
The reason they are so conservative is:
2) Virtual memory. As soon as you start paging
memory then a garbage collection system is *DEAD*
performance-wise. Just forget it.
All those papers conveniently seem to ignore:
1) The amount of fiddling and tuning of memory
allocations you can do with the average C++
implementations. Memory pooling, organising
data in memory to maximize paging performance,
etc. When your program starts to be used with real
world data a little bit of performance tuning will
usually make a mockery of those papers you cite.
2) Most (if not all) C++ temporary objects are created
on the stack in and are therefore *free*.
Finally, let me put it to you this way:
Garbage collectors are nothing new. I can personally
remember using one back in the 1970s.
If they're so good then how come nobody's using them?
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
| |
|
| fungus wrote:
> Calum wrote:
>
>
>
> Yeah, yeah. Microbenchmarks and academic papers prove
> nothing in the real world.
>
> All those papers deal with ideal cases.
Did you read them?
1) and 2) aren't papers - they are just the sources I have read which
have formed my world-view on the performance of GC. I'm not a
researcher or developer of GC systems so you can just take it up with
the authors.
3) Uses a suite of real programs - why would they bother to concoct a
benchmark when they can just analyse real programs??
> In the real
> world there's two fatal flaws with garbage collectors.
> It took me a month of real experience to figure this
> out but in the end they are the reason why I gave up
> on them.
>
> 1) Garbage collectors are very conservative about
> expanding the heap. When you start getting near the
> limits they spend more time scanning and (mostly
> uselessly) trying to free memory than they spend
> executing your code.
>
> Yes, many runtimes allow you to specify initial
> heap size from the command line but how you're
> supposed to guess the amount of memory needed is
> a mystery. Trail and error seems to be the only
> way. Besides, you can hardly ask the average user
> to start doing this just to run your program.
>
> The reason they are so conservative is:
>
> 2) Virtual memory. As soon as you start paging
> memory then a garbage collection system is *DEAD*
> performance-wise. Just forget it.
>
> All those papers conveniently seem to ignore:
>
> 1) The amount of fiddling and tuning of memory
> allocations you can do with the average C++
> implementations. Memory pooling, organising
> data in memory to maximize paging performance,
You can do this with malloc? I don't think so - I think you have as
much if not more flexibility tuning your GC. If you add a GC to C++,
such as __gc keyword in C++.net, or using the Boehm-Demers-Weiser GC for
C++, you have both worlds.
> etc. When your program starts to be used with real
> world data a little bit of performance tuning will
> usually make a mockery of those papers you cite.
> 2) Most (if not all) C++ temporary objects are created
> on the stack in and are therefore *free*.
That's a very good point. Actually, if you are using the STL etc, you
normally don't need to worry about cleaning up your memory. My language
of choice is C++ without a garbage collector. There are also a load of
other approaches to memory management - owned/auto pointers, strong/weak
pointers etc which also obviate the need for a full GC. And some STL
allocators can accept memory-hints to localise data for
cache-performance, which you can't do in most other languages.
> Finally, let me put it to you this way:
> Garbage collectors are nothing new. I can personally
> remember using one back in the 1970s.
Of course - but if that's your most recent experience, then as I said,
the deficiencies of early garbage-collectors have been mostly addressed.
> If they're so good then how come nobody's using them?
"Nobody" is stating it strongly. Every Java and Microsoft .net
programmer is using a garbage collector. The performance of these
languages is now snapping at the heels of C.
It's very easy, and rational, to be prejudiced against Java or GC
because they initially had poor performance.
| |
| fungus 2004-03-31, 10:43 am |
| Calum wrote:
> fungus wrote:
>
>
>
> Did you read them?
>
> 1) and 2) aren't papers - they are just the sources I have read which
> have formed my world-view on the performance of GC. I'm not a
> researcher or developer of GC systems so you can just take it up with
> the authors.
>
> 3) Uses a suite of real programs - why would they bother to concoct a
> benchmark when they can just analyse real programs??
>
>
>
> You can do this with malloc?
Who said anything about malloc? I mean things like
inserting a tweaked "operator new[]" for heavily used
objects. You can then allocate memory in big blocks.
> And some STL allocators can accept memory-hints to localise
> data for cache-performance, which you can't do in most other
> languages.
>
That's the sort of thing I mean...not many languages
allow you to do this sort of thing. Will, technically
you could do it with plain malloc() but you have to
build it in from day one. C++ lets you retrofit it
in the final tuning stages when you have real data
sets to work with.
>
>
> Of course - but if that's your most recent experience, then as I said,
> the deficiencies of early garbage-collectors have been mostly addressed.
>
No...I did quite a lot of Java a couple of years ago.
> "Nobody" is stating it strongly. Every Java and Microsoft .net
> programmer is using a garbage collector. The performance of these
> languages is now snapping at the heels of C.
>
Execution performance, yes, I agree with you.
That's why Java got past the initial testing phase for
us. It took a month before we realized the fatal flaws,
ie. (1) The JVM was very inept at expanding the heap when
needed, and (2) When you run out of RAM you're dead because
the garbage collector wants to continuously scan the entire
heap whether it's in active use or not.
> It's very easy, and rational, to be prejudiced against
> Java or GC because they initially had poor performance.
I think we gave it a fair crack of the whip, enough to
find the deal-breaking flaws.
If GC fits your needs, fine. I have no problem with that,
just be aware of the issues.
One thing I have a problem with is people saying a GC
makes your life easire. I don't believe it does unless
you have a total disregard for system resources. This
mentality is ok in small programs, not big ones.
C++ memory management isn't hard if you do it right.
When get the hang of auto_ptr, reference counting, etc.
you hardly ever need to write destructors to free up RAM.
You do need them closing files, releasing resources, etc.,
but not to free up RAM. The compiler does that for you.
--
<\___/> "To err is human, to moo bovine."
/ O O \
\_____/ FTB. For email, remove my socks.
|
|
|
|
|