I started to look into D very recently. I would like to know the following, if you guys are so nice to help me:

1. What is the performance of D's GC, what trade-offs where done in design , and if a in-deep primer on efficient usage and gotchas of the current implementation exists.

2. GC is never good enough. What are the current plans in this area for D. In general, please point me to the place where current work on D is done.

3. I need to be able to run with GC totally disabled sometimes. In the light of this:
   - are there any features of core language which depend on garbage collection ? (i.e unbound arrays, strings ..)
   - are there any features from standard library which depend on active garbage collection?
   - Please point me to a list where there is an exhaustive enumeration of which language features *and* library features requires GC active. Looking at standard library docs I did not seen markings which identify clearly and unequivocally what requires GC active and what not.

4. Is Andrei Alexandrescu's book from 2009 on D still actual, or the language evolution made it obsolete ?

With thanks.

On 21/12/2017 10:49 AM, Dan Partelly wrote:
> 
> I started to look into D very recently. I would like to know the following, if you guys are so nice to help me:
> 
> 1. What is the performance of D's GC, what trade-offs where done in design , and if a in-deep primer on efficient usage and gotchas of the current implementation exists.
> 
> 2. GC is never good enough. What are the current plans in this area for D. In general, please point me to the place where current work on D is done.

Ref counting isn't perfect but it is good enough. Scope attribute still needs more work but again may work in some cases.

> 3. I need to be able to run with GC totally disabled sometimes. In the light of this:

https://dlang.org/phobos/core_memory.html#.GC.disable

import core.memory : GC;
GC.disable;

That will disable the GC to attempt to collect (you can ask it to later on or renewable at your pleasure).

But bare in mind, the GC will only ever try to collect when you allocate memory.

>     - are there any features of core language which depend on garbage collection ? (i.e unbound arrays, strings ..)

Yes, lambdas, new, .length changing and that includes ~=.

>     - are there any features from standard library which depend on active garbage collection?

Available lots.
Enabled, I highly doubt that part.



Just remember, you can quite easily call into C and allocate memory the hard way of malloc.

int[] data = (cast(int*)malloc(int.sizeof * 8))[0 .. 8];
free(data.ptr);

Of course, preallocating and using buffers is always the best approach, doesn't matter if it was allocated by the GC or not.

On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
>
> I started to look into D very recently. I would like to know the following, if you guys are so nice to help me:
>
> 1. What is the performance of D's GC, what trade-offs where done in design , and if a in-deep primer on efficient usage and gotchas of the current implementation exists.
>
> 2. GC is never good enough. What are the current plans in this area for D. In general, please point me to the place where current work on D is done.
>
> 3. I need to be able to run with GC totally disabled sometimes. In the light of this:
>    - are there any features of core language which depend on garbage collection ? (i.e unbound arrays, strings ..)
>    - are there any features from standard library which depend on active garbage collection?
>    - Please point me to a list where there is an exhaustive enumeration of which language features *and* library features requires GC active. Looking at standard library docs I did not seen markings which identify clearly and unequivocally what requires GC active and what not.
>


I redirect your questions 1-3 to the excellent GC series: https://dlang.org/blog/the-gc-series

> 4. Is Andrei Alexandrescu's book from 2009 on D still actual, or the language evolution made it obsolete ?
>
> With thanks.

A few things changed, but not that much. Imho it's still an excellent book to learn D as Andrei explains the reasoning behind D's design decisions and you get a look behind the scenes.

On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
>
> I started to look into D very recently. I would like to know the following, if you guys are so nice to help me:
>
> 1. What is the performance of D's GC, what trade-offs where done in design , and if a in-deep primer on efficient usage and gotchas of the current implementation exists.

I've never independently measured it myself, so I can't say.

> 2. GC is never good enough. What are the current plans in this area for D.

The -betterC feature come to mind.  Walter is trying to convert the DMD compiler's backend to D (It's still written in C-like C++; only the frontend is in D).  For reasons I don't quite understand, he wants to use -betterC and RAII:  https://github.com/dlang/dmd/pull/7421#issuecomment-350874126

But the GC isn't required.  D is an extraordinarily powerful language with which you can work around just about any limitation.

https://wiki.dlang.org/Memory_Management
https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread

> In general, please point me to the place where current work on D is done.

Work on the D programming language is done primarily in 3 different repositories:
DMD (reference compiler) - https://github.com/dlang/dmd
DRuntime (language runtime library) - https://github.com/dlang/druntime
Phobos (standard library) - https://github.com/dlang/phobos

> 3. I need to be able to run with GC totally disabled sometimes. In the light of this:
>    - are there any features of core language which depend on garbage collection ? (i.e unbound arrays, strings ..)

Yes, Exceptions, classes, dynamic arrays, and associative arrays come to mind.  But, keep in mind that there are always ways to word around this.

>    - are there any features from standard library which depend on active garbage collection?

I'm not a big user of the standard library, but I believe most features of the standard library require the GC.

>    - Please point me to a list where there is an exhaustive enumeration of which language features *and* library features requires GC active. Looking at standard library docs I did not seen markings which identify clearly and unequivocally what requires GC active and what not.

I don't think such a list exists.  You can compile code with the @nogc attribute and the compiler emit errors if you attempt to use the GC.

The -vgc compiler option will also tell you where you have GC allocations.

> 4. Is Andrei Alexandrescu's book from 2009 on D still actual, or the language evolution made it obsolete ?

I think there is still great information in that book, and Andrei is always a fun author to read.  However, "Programming in D" is probably the best place to start - http://ddili.org/ders/d.en/index.html

Some D books are currently on sale for $5 at Packt Publishing:  http://forum.dlang.org/post/mbczecvrworfwacmzdep@forum.dlang.org

Mike

See also how dplug is implemented https://forum.dlang.org/post/hbmbztydvyfwemfnerwb@forum.dlang.org

On Thursday, December 21, 2017 12:00:17 Mike Franklin via Digitalmars-d- learn wrote:
> I'm not a big user of the standard library, but I believe most features of the standard library require the GC.

Actually, relatively little in Phobos explicitly uses the GC. There are some things that definitely do (e.g. std.array.array), but the vast majority is range-based and doesn't explicitly allocate anything. The main problem is that lambdas often result in the compiler deciding that a closure needs to be allocated to ensure that the code is @safe with regards to the stack variables that the lambda accesses. So, for a lot of stuff, if you just use stuff like static nested functions or functors instead of lambdas, you won't get any GC allocations, but there are certainly places where the library allocates where it shouldn't (e.g. one range-based function calls another with a lambda that results in an allocation), and more work needs to be done to ensure that all of the stuff like that is caught and fixed. So, if you want to avoid the GC, you do have to be careful with Phobos, and Phobos does need some improvements to remove inadvertent uses fo the GC, but relatively little in Phobs allocates memory. Most problems that someone is likely to have with the GC stem from their own code, not the standard library.

And actually, idiomatic D does tend to reduce how much your typical program allocates (e.g. lots of structs on the stack and preferring lazy ranges to arrays), which means that the GC typically has a far lower impact than many people assume that it will - though if someone is writing their code like it's Java and uses lots of classes and puts most stuff on the heap, then they're bound to have performance problems.

- Jonathan M Davis

On Thursday, 21 December 2017 at 10:49:46 UTC, Dan Partelly wrote:
>
> I started to look into D very recently. I would like to know the following, if you guys are so nice to help me:
>
> 1. What is the performance of D's GC, what trade-offs where done in design , and if a in-deep primer on efficient usage and gotchas of the current implementation exists.
>
> 2. GC is never good enough. What are the current plans in this area for D. In general, please point me to the place where current work on D is done.
>
> 3. I need to be able to run with GC totally disabled sometimes. In the light of this:
>    - are there any features of core language which depend on garbage collection ? (i.e unbound arrays, strings ..)
>    - are there any features from standard library which depend on active garbage collection?
>    - Please point me to a list where there is an exhaustive enumeration of which language features *and* library features requires GC active. Looking at standard library docs I did not seen markings which identify clearly and unequivocally what requires GC active and what not.
>
> 4. Is Andrei Alexandrescu's book from 2009 on D still actual, or the language evolution made it obsolete ?
>
> With thanks.

I make hobby/proto-type games and I've been doing it for well-over a decade at this point. Starting learning D and trying games with Allegro 5 and D the same way I used C++.

There's lots to learn. But so far it's a freaking DELIGHT to program in D compared to C++. It's so easy to reduce boilerplate, and extend code without huge swafts of boilerplate std::vector<std::vector<my_obj(1245,124512,taco())>> template code.

I'm intentionally ABUSING the GC so far by having every smoke particle (hundreds) with new ones allocate and and old ones deallocating every frame. I'm also developing on a tiny Chromebook with a Intel Celeron ~N2950 and only 2 GB of RAM (which Ubuntu eats most of).

I'm still getting 115+ FPS drawing 600 alpha-blended "cloud" bitmaps each frame, plus the smoke trails, and allocations.

There is a microstutter issue I'm diagnosing that may be related to GC. (After all, I AM intentionally abusing it so I can get a "feel" for it.) But it's not terrible. I plan to move to static pools for everything eventually but this is a viability study for D and the GC without going out of my way to disable/avoid the GC.

Merely turning on Open Broadcast Studio to capture video of my game for explanations takes more CPU time than my game.

So depending on what you want to design, I really second everyone's recommendation "don't worry about it until it's a problem." D is so adaptable that it's really easy to move away from the GC (assuming you write good code anyway).

Now, to that previous point of "don't worry about it." I absolutely get the apprehension when someone tells you that. But yeah, it's not that bad. If you do "heavy lifting" stuff with static allocations, and leave the GC for making lambdas and stuff like that super-easy to write code, it's a good combination.

As others have mentioned, you can even allocate memory that the GC has literally no idea about and will never collect.

I definitely recommend trying D. The best way for you to know if it suits YOUR requirements is really... make a test app like I'm doing. Code the way you normally do and see if the GC affects you. Absolute worst case you can port your program to C++ pretty quickly.