shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, September 13, 2015 16:58:21 Ola Fosheim Grøstad via Digitalmars-d-learn wrote:
> On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
> wrote:
> > the GC heavily. And the reality of the matter is that the vast
> > majority of programs will have _no_ problems with using the GC
> > so long as they don't use it heavily. Programming like you're
> > in Java and allocating everything on the heap will kill
> > performance, but idiomatic D code doesn't do that, and Phobos
> > doesn't do that. Far too many programmers freak out at the
> > thought of D even having a GC and overreact thinking that they
> > have to root it out completely, when there really is no need
> > to. Plenty of folks how written highly performant code in D
> > using the GC. You just have to avoid doing a lot of allocating
> > and make sure you track down unwanted allocations when you have
> > a performance problem.
>
> I don't understand this argument. Even if the GC heap only
> contains a single live object, you still have to scan ALL memory
> that contains pointers.

> So how does programming like you do in Java affect anything
> related to the GC?
>
> Or are you saying that finalization is taking up most of the time?

Only the stack and the GC heap get scanned unless you tell the GC about
memory that was allocated by malloc or some other mechanism. malloced memory
won't be scanned by default. So, if you're using the GC minimally and coding
in a way that doesn't involve needing to tell the GC about a bunch of
malloced memory, then the GC won't have all that much to scan. And while the
amount of memory that the GC has to scan does affect the speed of a
collection, in general, the less memory that's been allocated by the GC, the
faster a collection is.

Idiomatic D code uses the stack heavily and allocates very little on the GC
heap. Classes are used only rarely, and ranges are generally preferred over
arrays, so idiomatic D code ends up with structs on the stack rather than
classes on the heap, and the number of allocations required for arrays goes
down considerably. So, there simply isn't all that much garbage to collect,
and memory isn't being constantly allocated, so it's a lot rarer that a
collection needs to be run in order to get more memory.

So, the big win is simply not allocating much on the GC heap, whether it's
because it's allocated on the malloced heap or because it's on the stack.
The result of that is that even if a collection isn't super fast,
collections are actually relatively rare. So, for a _lot_ of idiomatic D
code, collections simply won't be happening often, and as long as you don't
have realtime constraints, then having an occasional collection occur that's
a bit longer than desirable isn't necessarily a problem - though we
definitely do want to improve the GC so that collections are faster and thus
less likely to cause performance problems (and work has been done recently
on that; Martin Nowak was supposed to give a talk on it at dconf this year,
but he missed his flight).

So, while the fact that D's GC is less than stellar is certainly a problem,
and we would definitely like to improve that, the idioms that D code
typically uses seriously reduce the number of performance problems that we
get.

- Jonathan M Davis