Sean Kelly wrote:
> I think another issue is that garbage collection *can* cause a noticeable stutter in user applications which pay no attention to memory management, and it's easy for someone to point at that hitch and proclaim that garbage collection itself is slow.  People seem to like the straw man argument for some reason.

You know it's a straw man when they also say that malloc/free or C++ new/delete have predictable latency. They don't. People who write code that *requires* predictable latency preallocate all their data.

BCS wrote:
> How much does the runtime, generated code and Phobos depend on the GC?
> Does it try to optimize out allocations or delete things it can?
> For example, does this preform one allocation or several?

DMD isn't very good at eliminating unnecessary temporaries. This isn't a defect in D, but in DMD. DMC++ is pretty good at eliminating unnecessary temporaries, not because C++ is better, but because I put a lot of effort into that aspect (for example, mine was the first to do the "named return value" optimization).

Sean Kelly wrote:
>  but D can
> really do everything C++ can here, unless you absolutely insist on having user-defined data types that are indistinguishable from built-in types.

C++ is not capable of having user-defined types indistinguishable from built-in ones.

BCS wrote:
> How much does the runtime, generated code and Phobos depend on the GC?
> Does it try to optimize out allocations or delete things it can?
> For example, does this preform one allocation or several?
> 
> char[] foo = "abc", bar = "baz";
> char[] ret = foo ~ bar ~ foo;

Only one IIRC. There's a function called _d_arraycatn in the runtime that accepts an element size and a variable number of arrays, allocates size * (total length) and starts copying. That should be the one invoked for a concatenation like the above.

> // ret.length = 9;
> // ret[0..3] = foo;
> // ret[3..6] = bar;
> // ret[6..9] = foo;
> 
> and would these temporaries get deleted (or maybe not even created)?
> 
> if((foo ~ bar)[4]=='g') go();
> 
> //auto __tmp = foo ~ bar
> //if(__tmp[4] == 'g') go();
> //delete __tmp;
> 
> or
> 
> //if( (foo.length>4 && foo[4]=='g') || bar[4-foo.length]=='g') go();

I don't think these get deleted[1], nor do I expect creating these is avoided. Could be wrong about this one though, you'd have to check the compiler output to be sure[2]. Well, that or wait until Walter or someone who has checked for you answers ;).

[1]: before the next GC cycle, that is.
[2]: Don't forget to turn on optimizations, might make a difference here.

Serg Kovrov wrote:

Maybe you should take a look at this:

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=dlang&l ang2=gpp

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=dlang&l ang2=java

and also try to test some programs for yourself.

I also can say that recently there was a discussion on RSDN (Russian software developers forum) about string splitting performance and D std.string's split routine was the fastest and beat C++/boost.split 20x :

http://rsdn.ru/forum/Message.aspx?mid=2126270&only=1

(it's in Russian but you can easily recognize the numbers)

(some src code also here: http://rsdn.ru/forum/Message.aspx?mid=2113456&only=1)


--------------------------------------------------------------------------------

As D is a superset of C so you can still stick to structs and malloc/free and you can overload new/delete as well.

And you can even allocate on the stack (syntax is horrible, though - perhaps to
discourage this).

-- 
AKhropov

Sean Kelly wrote:
> Kyle Furlong wrote:
>>
>> That said, isnt one able to disable the GC through std.gc.disable() or some such call? What exactly does it do, now that I think about it? 
> 
> When memory is allocated from the GC it first looks to see if it has any available internally.  If it can't find any it runs a collection and looks again.  If it still can't find any then it obtains more memory from the OS and uses a portion of that for the allocation.  Setting gc.disable() prevents the collection run from occurring so the GC will simply obtain more memory from the OS when it runs out.  The reason behind this is that collections can take a long time, and performance-critical sections of code don't necessarily want to wait for a collection to occur just because they called 'new'.  So they'll either disable and re-enable the GC around critical sections of code or they'll simply keep the GC disabled and manually collect during idle periods using gc.fullCollect().
> 
>> Perhaps, for cases such as this, it would be helpful for there to be a page on digitalmars.com/d/ which lists the language features that are gc supported such that any prospective developers of the OP's bent can easily avoid the allocations and memory waste they dont want to invoke.
> 
> Now that memory is not freed when string.length is set to zero it's quite possible to avoid most reallocations simply by preallocating in buffers before using them (ie. set length to some large number and then 

I did not know that had been changed.. Is that now part of the language 'spec' somewhere as well?

I'm betting this has been discussed or at least proposed, but here goes again; let's get an array.reserve at least for native arrays (that could be implemented as {arr.length = nnn; arr.length = 0;}). That way it would make for less of a hack than re/setting the length, and also codify it as part of the language.

> back to zero).  However, some operations will still cause an allocation, such as appending to a slice.
> 
> 
> Sean

Sean Kelly wrote:
> Walter Bright wrote:
>>
>> Then I began to think about why C++ was so complicated. I eventually began to realize it's because of explicit memory management. Have a gc, and suddenly you can make a language with even greater power that is much, much simpler.
> 
> After using D for a bit, I came to the same conclusion.  That isn't to say you can completely forget about the cost of reallocations or data ownership, but having a GC simplifies the things that should be simple, without creating additional complexity elsewhere.
> 
>> For one example, you cannot do array slices in C++ without considerable agony. In D, they are easy as pie.
> 
> True enough.  I have a slice class I use in C++ for specialized purposes (a compiler, for example), but dealing with the memory ownership issues are just too much of a headache for apps where data doesn't have such a predictable lifetime.
> 
>> P.S. It *is* true (before D) that gc based languages are slower than C/C++. The conventional wisdom says that this is caused by the gc. This simply is not true, the slowness is usually caused by lack of expressiveness in the language (Java) or dynamic typing (Python, Javascript, etc.).
> 
> I think another issue is that garbage collection *can* cause a noticeable stutter in user applications which pay no attention to memory management, and it's easy for someone to point at that hitch and 

It's called "The path of least resistance" <g> When even a good programmer who knows better is in a hurry (and when are they not? ;)), they'll abuse the heck out of the heap because it's more expedient, and the end result still makes it past QC. Pretty soon you have this largely sub-optimal program made up of many small, somewhat sub-optimal pieces.

D though at least gives us 'delete' as well as some control over the GC.

As an aside, academia moving away from explicit memory managed languages in their curriculum's is probably producing quite a few programmers who know very little about memory management and how it can effect performance.

> proclaim that garbage collection itself is slow.  People seem to like the straw man argument for some reason.
> 
> 
> Sean

>>As an aside, academia moving away from explicit memory managed languages in
their curriculum's is
probably producing quite a few programmers who know very little about memory
management and how it
can effect performance.

Interesting -- I just read this on the same day as noticing that Cambridge has ditched Java from its course and put C++ back there -- make of that what you will!

Dave wrote:
> 
> As an aside, academia moving away from explicit memory managed languages in their curriculum's is probably producing quite a few programmers who know very little about memory management and how it can effect performance.

Yup.  This is one of my major complaints about using Java in place of C++ as a teaching language.  Sure, it allows the focus to be on the algorithm instead of all the peripheral aspects, but the result is students who aren't aware of the peripheral aspects.  The cost of virtual methods is another issue.  I'd rather students suffer through a bit of additional complexity and end up not needing the additional experience they've gained than be ignorant of the issues.


Sean

Charles Fox wrote:
>>> As an aside, academia moving away from explicit memory managed languages in
> their curriculum's is
> probably producing quite a few programmers who know very little about memory
> management and how it
> can effect performance.
> 
> Interesting -- I just read this on the same day as noticing that Cambridge has
> ditched Java from its course and put C++ back there -- make of that what you will!

According to Bjarne, this is happening at a few schools.  He said it's the result of pressure from the industry, which has a high demand for students who know C++.


Sean