shared array?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, September 13, 2015 16:53:18 ponce via Digitalmars-d-learn wrote:
> On Sunday, 13 September 2015 at 15:35:07 UTC, Jonathan M Davis
> wrote:
> > But the idea that your average D program is going to run into
> > problems with the GC while using Phobos is just plain wrong.
> > The folks who need to care are the rare folks who need extreme
> > enough performance that they can't afford for the GC to _ever_
> > stop the world.
>
> Even in that case not all threads need to be real-time and you
> can do threads without GC.
>
> Honestly I think only people using microcontrollers or really
> constrained environments and don't have the memory have that
> problem.
>
> I suspect preciously few of the GC haters actually have those
> requirements or misrepresents the ways to avoid GC-related
> problems.
>
> Same arguments but there is a solution for everything:
>
> "Don't want memory overhead" => minimize heap usage, use -vgc /
> -profile=gc
> "Don't want pauses" => unregister thread + @nogc
> "Want shorter pauses" => minimize heap usage, use -vgc /
> -profile=gc
> "Want determinism" => ways to do that
>
> GC is basically ok for anything soft-realtime, where you already
> spend a lot of time to go fast enough. And if you want
> hard-realtime, well you wouldn't want malloc either.
>
> It's a non-problem.

There _are_ some programs that simply cannot afford a stop-the-world GC.
For instance, this has come up in discussions on games where a certain
framerate needs to be maintained. Even a 100 ms stop would be way too much
for them. In fact, it came up with the concurrent GC that was presented at
dconf 2013 that it would likely have to be guaranteed to stop the world for
less than 10 ms (or something in that range anyway) to be acceptable for
such environments. So, it _is_ a problem for some folks.

That being said, it is _not_ a problem for most folks, and the folks who
have those sorts of performance requirements frequently can't even use
malloc after the program has gotten past its startup phase. So, many of them
would simply be allocating up front and then only reusing existing memory
for the rest of the program's run, whether that memory was GC-allocated or
malloced. For instance, as I understand it, Warp used the GC, but it
allocated everything up front and didn't allocate once it got going, so the
GC wasn't a performance problem for it at all, and it's _very_ fast.

But there are other solutions such as having the critical threads not use
the GC (as you mentioned) which make it so that you can use the GC in parts
of your program while still avoiding its performance costs in the critical
portions.

Regardless, idiomatic D involves a lot more stack allocations than you often
get even in C++, so GC usage tends to be low in programs that use idiomatic
D, and there are ways to work around the cases where the GC actually turns
out to be a bottleneck. And for the most part, the folks who are freaking
out about the GC and insisting that it's simply evil and shouldn't exist and
losing out on some great stuff. And even with more lazy ranges in Phobos and
more consistent @nogc usage, I suspect that many of them will continue to
complain about Phobos using the GC even though it uses it pretty minimally.

- Jonathan M Davis