<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 1 February 2014 16:26, Adam Wilson <span dir="ltr"><<a href="mailto:flyboynw@gmail.com" target="_blank">flyboynw@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, 31 Jan 2014 21:29:04 -0800, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 26 December 2012 00:48, Sven Over <<a href="mailto:dlang@svenover.de" target="_blank">dlang@svenover.de</a>> wrote:<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 std.typecons.RefCounted!T<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
core.memory.GC.disable();<br>
<br>
</blockquote>
<br>
Wow. That was easy.<br>
<br>
I see, D's claim of being a multi-paradigm language is not false.<br>
</blockquote>
<br>
<br></div><div class="im">
It's not a realistic suggestion. Everything you want to link uses the GC,<br>
and the language its self also uses the GC. Unless you write software in<br>
complete isolation and forego many valuable features, it's not a solution.<br>
<br>
<br></div><div class="im">
 Phobos does rely on the GC to some extent. Most algorithms and ranges do<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
not though.<br>
<br>
</blockquote>
<br>
Running (library) code that was written with GC in mind and turning GC off<br>
doesn't sound ideal.<br>
<br>
But maybe this allows me to familiarise myself more with D. Who knows,<br>
maybe I can learn to stop worrying and love garbage collection.<br>
<br>
Thanks for your help!<br>
<br>
</blockquote>
<br></div><div class="im">
I've been trying to learn to love the GC for as long as I've been around<br>
here. I really wanted to break that mental barrier, but it hasn't happened.<br>
In fact, I am more than ever convinced that the GC won't do. My current #1<br>
wishlist item for D is the ability to use a reference counted collector in<br>
place of the built-in GC.<br>
You're not alone :)<br>
<br>
I write realtime and memory-constrained software (console games), and for<br>
me, I think the biggest issue that can never be solved is the<br>
non-deterministic nature of the collect cycles, and the unknowable memory<br>
footprint of the application. You can't make any guarantees or predictions<br>
about the GC, which is fundamentally incompatible with realtime software.<br>
Language-level ARC would probably do quite nicely for the miscellaneous<br>
allocations. Obviously, bulk allocations are still usually best handled in<br>
a context sensitive manner; ie, regions/pools/freelists/<u></u>whatever, but the<br>
convenience of the GC paradigm does offer some interesting and massively<br>
time-saving features to D.<br>
Everyone will always refer you to RefCounted, which mangles your types and<br>
pollutes your code, but aside from that, for ARC to be useful, it needs to<br>
be supported at the language-level, such that the language/optimiser is<br>
able to optimise out redundant incref/decref calls, and also that it is<br>
compatible with immutable (you can't manage a refcount if the object is<br>
immutable).<br>
</div></blockquote>
<br>
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.<br>

<br>
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.</blockquote><div><br></div><div>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.</div>
<div>A GC heap by nature expects you to have lots of memory, and also lots of FREE memory.</div><div><br></div><div>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.</div>
</div></div></div>