Smart pointers instead of GC?

[Manu]

On 1 February 2014 16:26, Adam Wilson <flyboynw at gmail.com> wrote:

> On Fri, 31 Jan 2014 21:29:04 -0800, Manu <turkeyman at gmail.com> wrote:
>
>  On 26 December 2012 00:48, Sven Over <dlang at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140201/1eb7c010/attachment-0001.html>