ur right I never thought of that, I bet all them game devs never
thought of it either, they so dumb. I bet they never tried to
use a GC, what fools! Endless graphs of traced objects, oh yes
oh yes! It only runs when I allocate, oh what a fool I've been,
please castigate me harder!
Adam pls tell me more of this c# and that amazing gc it sounds
so good
On Monday, 3 February 2014 at 21:42:59 UTC, Shammah Chancellor
wrote:
On 2014-02-01 07:35:44 +0000, Manu said:
On 1 February 2014 16:26, Adam Wilson <flybo...@gmail.com>
wrote:
On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkey...@gmail.com>
wrote:
On 26 December 2012 00:48, Sven Over <dl...@svenover.de> wrote:
std.typecons.RefCounted!T
core.memory.GC.disable();
Wow. That was easy.
I see, D's claim of being a multi-paradigm language is not
false.
It's not a realistic suggestion. Everything you want to link
uses the GC,
and the language its self also uses the GC. Unless you write
software in
complete isolation and forego many valuable features, it's not
a solution.
Phobos does rely on the GC to some extent. Most algorithms
and ranges do
not though.
Running (library) code that was written with GC in mind and
turning GC off
doesn't sound ideal.
But maybe this allows me to familiarise myself more with D.
Who knows,
maybe I can learn to stop worrying and love garbage collection.
Thanks for your help!
I've been trying to learn to love the GC for as long as I've
been around
here. I really wanted to break that mental barrier, but it
hasn't happened.
In fact, I am more than ever convinced that the GC won't do.
My current #1
wishlist item for D is the ability to use a reference counted
collector in
place of the built-in GC.
You're not alone :)
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.
Language-level ARC would probably do quite nicely for the
miscellaneous
allocations. Obviously, bulk allocations are still usually
best handled in
a context sensitive manner; ie,
regions/pools/freelists/whatever, but the
convenience of the GC paradigm does offer some interesting and
massively
time-saving features to D.
Everyone will always refer you to RefCounted, which mangles
your types and
pollutes your code, but aside from that, for ARC to be useful,
it needs to
be supported at the language-level, such that the
language/optimiser is
able to optimise out redundant incref/decref calls, and also
that it is
compatible with immutable (you can't manage a refcount if the
object is
immutable).
The problem isn't GC's per se. But D's horribly naive
implementation, games are written on GC languages now all the
time (Unity/.NET). And let's be honest, games are kind of a
speciality, games do things most programs will never do.
You might want to read the GC Handbook. GC's aren't bad, but
most, like the D GC, are just to simplistic for common usage
today.
Maybe a sufficiently advanced GC could address the performance
non-determinism to an acceptable level, but you're still left
with the memory non-determinism, and the conundrum that when
your heap approaches full (which is _always_ on a games
console), the GC has to work harder and harder, and more often
to try and keep the tiny little bit of overhead available.
A GC heap by nature expects you to have lots of memory, and
also lots of FREE memory.
No serious console game I'm aware of has ever been written in
a language with a GC. Casual games, or games that don't
attempt to raise the bar may get away with it, but that's not
the industry I work in.
You can always force the GC to run between cycles in your game,
and
turn off automatic sweeps. This is how most games operate
nowadays.
It's also probably possible to create a drop-in replacement for
the GC
to do something else. I could see if being *VERY* useful to
make the
GC take a compile-time parameter to select which GC engine is
used.
