As just seen, much is discussed about the D GC.

It seems to be like the rotary engine: anybody who looks at the blueprints says this simply can't work, and it still does. And pretty well too, in fact.

Anybody can (and frequently does) conjure up situations where the GC "starts smoking", and still, our real-life programs seem to "just work".

Who's had a GC problem /for real/?

Georg Wrede wrote:
> As just seen, much is discussed about the D GC.
> 
> It seems to be like the rotary engine: anybody who looks at the blueprints says this simply can't work, and it still does. And pretty well too, in fact.

I always look at the schematic for a jet engine, and listen to the explanations for how it works. I never bought the explanations, to me it just looks like it isn't going to work. It looks like the flame will blow forwards just as much as blow backwards, and there will be no net thrust.

I finally took a course in college on jet engine cycle analysis, and found out the reason the flame doesn't blow forward is the compressor produces enough pressure to prevent it. That's why in order to start a jet engine, you have to spool up the compressor first with some external power source. A jet engine "compressor stall" happens when not enough air is coming in the inlet to block the flame from coming forwards, and the flame blows forward, stopping the engine.

> 
> Anybody can (and frequently does) conjure up situations where the GC "starts smoking", and still, our real-life programs seem to "just work".
> 
> Who's had a GC problem /for real/?

Georg Wrede wrote:
> Who's had a GC problem /for real/?

Resharper refactoring plugin for Visual Studio; we use it heavily for our C# development. It regularly freezes up for a minute or so at a time. That's the dotNet runtime's GC, granted, but I have a hard time believing that D's would do better.

This isn't as simple as a "GC vs not" debate; I don't think anyone (here, at least) would argue that GC is worthless. Rather there are at least three open questions:

1) When and where is GC appropriate?

2) When it is appropriate, how good is D's implementation of it?

3) When it's not appropriate, how well does D support GC-less (and possibly
allocation-less) programming?

On Mon, 20 Nov 2006 15:54:18 -0800, Walter Bright <newshound@digitalmars.com> wrote:

> Georg Wrede wrote:
>> As just seen, much is discussed about the D GC.
>>  It seems to be like the rotary engine: anybody who looks at the blueprints says this simply can't work, and it still does. And pretty well too, in fact.
>
> I always look at the schematic for a jet engine, and listen to the explanations for how it works. I never bought the explanations, to me it just looks like it isn't going to work. It looks like the flame will blow forwards just as much as blow backwards, and there will be no net thrust.
>
> I finally took a course in college on jet engine cycle analysis, and found out the reason the flame doesn't blow forward is the compressor produces enough pressure to prevent it. That's why in order to start a jet engine, you have to spool up the compressor first with some external power source. A jet engine "compressor stall" happens when not enough air is coming in the inlet to block the flame from coming forwards, and the flame blows forward, stopping the engine.
>

Hmmm... is that what a flame-out is?  I was reading up a little about Helicopter turbines. Some similarities here.

-JJR

Mike Capp wrote:
> Georg Wrede wrote:
>> Who's had a GC problem /for real/?
> 
> Resharper refactoring plugin for Visual Studio; we use it heavily for our C#
> development. It regularly freezes up for a minute or so at a time. That's the
> dotNet runtime's GC, granted, but I have a hard time believing that D's would do
> better.
> 
> This isn't as simple as a "GC vs not" debate; I don't think anyone (here, at
> least) would argue that GC is worthless. Rather there are at least three open
> questions:
> 
> 1) When and where is GC appropriate?
> 
> 2) When it is appropriate, how good is D's implementation of it?
> 
> 3) When it's not appropriate, how well does D support GC-less (and possibly
> allocation-less) programming?

1) Most everywhere in general programming
2) Good, and getting better
3) Very well

MORE QUESTIONS? :-)

Mike Capp wrote:
> Georg Wrede wrote:
>> Who's had a GC problem /for real/?
> 
> Resharper refactoring plugin for Visual Studio; we use it heavily for our C#
> development. It regularly freezes up for a minute or so at a time. That's the
> dotNet runtime's GC, granted, but I have a hard time believing that D's would do
> better.

That sounds like bad program design rather than bad GC design.  Were the app written using conventional allocation it would either be visibly slow or leak like a sieve.

> This isn't as simple as a "GC vs not" debate; I don't think anyone (here, at
> least) would argue that GC is worthless. Rather there are at least three open
> questions:
> 
> 1) When and where is GC appropriate?

When the memory overhead is affordable (GCs can consume 40% more system memory for the same amount of user memory as traditional allocators). For very large applications, I think a combination approach would be most likely.  GCed memory for most of the throw-away data used during processing and malloc/free or mmap for the rest.  This is one area where D has an advantage over Java, as it has built-in support for mixed-mode allocation.  For comparison, try allocating an array larger than 1 million elements in Java--the implementation I've tried have been unable to do so (though this woulc obviously be addressed by a specialized GC).

> 2) When it is appropriate, how good is D's implementation of it?

From an implementation standpoint, I really have few complaints.  The code is fairly clean, succinct, and extensible.  As far as application-level use is concerned, that's a difficult question to answer for two reasons.  First, I think any well-written app simply won't stress a GC in ways that it wasn't meant to be stressed, so some testing almost necessarily has to create unrealistic conditions to test with.  Second, I haven't yet ported or written an app in D that has such refined allocator requirements that the nuances of a GCs performance would matter.  Perhaps someone who's written a game in D could comment on the obstacles they encountered related to garbage collector performance?

> 3) When it's not appropriate, how well does D support GC-less (and possibly
> allocation-less) programming?

Stack allocation of classes could be better, though 'scope' is a decent enough substitute if heap allocation isn't a problem.  Other than that, placement new and delete work so long as classes have new/delete statements defined, but it might be nice if these weren't required.  I'm half tempted to add these functions to Object simply to avoid this, assuming it's even possible to have virtual new/delete routines.

        new( size_t size, void* pos )
        {
            return pos;
        }

        delete( void* pos )
        {

        }


Sean

John Reimer wrote:
> Hmmm... is that what a flame-out is?  I was reading up a little about Helicopter turbines. Some similarities here.

A flame-out can be caused by that, but also by the flame literally being blown out the back.

Mike Capp wrote:
> Georg Wrede wrote:
>> Who's had a GC problem /for real/?
> 
> Resharper refactoring plugin for Visual Studio; we use it heavily for our C#
> development. It regularly freezes up for a minute or so at a time. That's the
> dotNet runtime's GC, granted, but I have a hard time believing that D's would do
> better.

Might it not be something wrong in the plug-in itself? Does it happen with all plugins or only that particular plugin?

> 
> This isn't as simple as a "GC vs not" debate; I don't think anyone (here, at
> least) would argue that GC is worthless. Rather there are at least three open
> questions:
> 
> 1) When and where is GC appropriate?
> 
> 2) When it is appropriate, how good is D's implementation of it?
> 
> 3) When it's not appropriate, how well does D support GC-less (and possibly
> allocation-less) programming?

Sean Kelly wrote:

> That sounds like bad program design rather than
> bad GC design.  Were the app written using
> conventional allocation it would either be visibly
> slow or leak like a sieve.

Probably. And I suspect the codebase we use it on is larger than usual. But then, you could offer the same retort to any reported "for real" GC problem.

[snip sensible answers to questions 1 and 2]

Re implementation, I think the concerns are that it's non-copying (which leaves doubts over whether a copying implementation would work) and that it's not type-aware (which effectively forces you to use malloc for large POD allocations, beside the false-positive issues).

> Stack allocation of classes could be better,
> though 'scope' is a decent enough substitute
> if heap allocation isn't a problem.

Yes, that's pretty much my impression. Stack allocation for 'scope' classes would be very nice, but not an absolute must have. It looks as if the gubbins required to do this manually could be templated/mixedin as a stopgap.

Thanks for the thoughtful response.

Mike

Sean Kelly wrote:
>  Second, I haven't yet ported or written an app in D that has such
> refined allocator requirements that the nuances of a GCs performance would matter.  Perhaps someone who's written a game in D could comment on the obstacles they encountered related to garbage collector performance?

Generally for a realtime 3D app you want to avoid creating and destroying things on a per-frame basis as much as possible.  If you do lots of alloc/free then performance will suffer.  It's a fact of life. That's true for either GC case or explicitly managed memory.   So for example when you make a cool particle system effect you don't allocate each particle, animate it, then destroy it.  You usually pre-allocate a fixed number of them and just reuse those over and over.

A lot of game developers also use custom allocators like dlmalloc because the platform's malloc isn't fast enough.  Writing fixed-sized custom pool allocators is also fairly common.  But that kind of thing is perfectly do-able in D too.

Basically I think the kind of games that would need custom memory management with D are probably the same kinds of games that would need it under C/C++ as well.  Poor floating point performance may be a bigger issue for fancy 3D games than GC, when it comes down to it.

--bb