On Saturday, 1 February 2014 at 05:36:44 UTC, Manu wrote:
I write realtime and memory-constrained software (console
games), and for
me, I think the biggest issue that can never be solved is the
non-deterministic nature of the collect cycles, and the
unknowable memory
footprint of the application. You can't make any guarantees or
predictions
about the GC, which is fundamentally incompatible with realtime
software.
(tried to manually fix ugly linebreaks here, so apologies if it
turns out even worse.)
(Maybe this would be better posted in D.learn; if so I'll
crosspost.)
In your opinion, of how much value would deadlining be? As in,
"okay handyman, you may sweep the floor now BUT ONLY FOR 6
MILLISECONDS; whatever's left after that you'll have to take care
of next time, your pride as a professional Sweeper be damned"?
It obviously doesn't address memory footprint, but you would get
the illusion of determinism in cases similar to where
race-to-idle approaches work. Inarguably, this wouldn't apply if
the goal is to render as many frames per second as possible, such
as for non-console shooters where tearing is not a concern but
latency is very much so.
I'm very much a layman in this field, but I'm trying to soak up
as much knowledge as possible, and most of it from threads like
these. To my uneducated eyes, an ARC collector does seem like the
near-ideal solution -- assuming, as always, the code is written
with the GC in mind. But am I right in gathering that it solves
two-thirds of the problem? You don't need to scan the managed
heap, but when memory is actually freed is still
non-deterministic and may incur pauses, though not necessarily a
program-wide stop. Aye?
At the same time, Lucarella's dconf slides were very, very
attractive. I gather that allocations themselves may become
slower with a concurrent collector, but collection times in
essence become non-issues. Technically parallelism doesn't equate
to free CPU time; but that it more or less *is* assuming there is
a cores/thread to spare. Wrong?
Lastly, am I right in understanding precise collectors as
identical to the stop-the-world collector we currently have, but
with a smarter allocation scheme resulting in a smaller managed
heap to scan? With the additional bonus of less false pointers.
If so, this would seem like a good improvement to the current
implementation, with the next increment in the same direction
being a generational gc.
I would *dearly* love to have concurrency in whatever we end up
with, though. For a multi-core personal computer threads are free
lunches, or close enough so. Concurrentgate and all that jazz.
