Re: GC in D and synadard library.

[Chris Katko via Digitalmars-d-learn]

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> 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.

Re: GC in D and synadard library.

[Jonathan M Davis via Digitalmars-d-learn]

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

Re: GC in D and synadard library.

[Kagamin via Digitalmars-d-learn]

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

Re: GC in D and synadard library.

[Mike Franklin via Digitalmars-d-learn]

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/mbczecvrworfwacmz...@forum.dlang.org


Mike

Re: GC in D and synadard library.

[Seb via Digitalmars-d-learn]

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.

Re: GC in D and synadard library.

[rikki cattermole via Digitalmars-d-learn]

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.