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.
