More radical ideas about gc and reference counting

[Kapps via Digitalmars-d]

On Monday, 12 May 2014 at 19:13:50 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 12 May 2014 at 18:07:51 UTC, Kapps wrote:
>> Depending on how tunable the GC is, I feel like it should be
>> possible to get away with a GC even for soft real-time programs
>> like games.
>
> Even if you manage to make it work for game clients you also 
> should make it work for low latency game servers, as code 
> sharing is an important advantage.
>
> What a game/world server requires differs a lot, but highly 
> dynamic and flexible worlds have to keep the physics to a 
> single node (or tight cluster) for a region. That means you 
> want to have as many players as possible tied to that node.
>
> In essence you want both performance, low latency, reliability, 
> and little overhead in an evolutionary context (it has to 
> support heavy modification over time).
>
> My gut feeling is that a runtime satisfying one game design 
> will not satisfy another one as long as one insists on one 
> global GC. In essence, it will never really work well. IMO, the 
> same goes for ARC since RC does not perform well with 
> multi-threading even when you use near optimal patterns and 
> strategies. If ARC is only to be used where speed does not 
> matter then you might as well use shared_ptr.

.NET allows configuring the garbage collector by specifying
workstation (concurrent, background [allow generation 0/1
collection while a generation 2 collection is going], one primary
heap and a large object heap) or server (not certain if
concurrent/background, but multiple heaps that get handled in
parallel during collections). Or in situations where you have
many processes running at once, disabling concurrent collection
to reduce context switching overhead. In reality, most people
leave the default concurrent collector, which is what I'd hope
the default for D would be, but if it was sufficiently tunable
something like vibe.d could decide to go with something more
similar to what .NET uses for servers (which ASP.NET uses by
default).

I haven't been able to find good concrete numbers online, but the
few sources I've found say that generation 0/1 collection tends
to take <1 to 2-3 milliseconds and is not run concurrently
because it's so short. This is quite sufficient for most
projects, but perhaps could be tweaked a bit more for certain
aspects like gaming, possibly even enabling concurrent collection
for generation 0/1, but I'm not sure if this works well or is
feasible. Still, the important thing is to get a good general one
to use first, like the default one .NET uses for workstation
applications.