Random points from a D n00b CTO

Manu via Digitalmars-d digitalmars-d at puremagic.com
Sun Jul 13 23:13:28 PDT 2014


On 14 July 2014 14:47, uri via Digitalmars-d <digitalmars-d at puremagic.com>
wrote:

> On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:
>
>>
>> - I was *very* disappointed that using base library locks you into GC vs
>> ref. counting.
>> Separate, I like how Objective C has NSObject for GC purpose(I'd love a
>> framework that is just ref counting), but there should be dual libs and
>> base should not be GC.
>>
>
> This topic was bashed to death. There were compelling arguments
> from both sides, but in the end no one pushing for ARC could
> produce evidence that it was better than GC.
>

Andrei himself pushed such evidence in an interesting case study that
explored a high-end ARC implementation. It compared impressively with 'the
fastest GC's' (or some description very close to that). D's GC is certainly
not among those in comparison, which suggested the paper's tech would
probably be a win for D no matter how you look at it.

And the counter evidence is overwhelming. As many times as I've asked the
experts for comment, I've still *NEVER* heard anybody disagree that D's GC
will probably remain really bad for the indefinite future. Even the ones
that are strongly in favour of GC; nobody seems to know how to do it, and
many have said it's probably impossible.
Even if it was theoretically possible, that only solves one of numerous
problems... Nobody has ever addressed the low-available-memory argument
I've put forward a number of times, which is the standard operating
environment of most embedded computers.

So, I don't feel like there was any such conclusion as you suggest.
Personally, I just became horribly apathetic and gave up. My general
participation and motivation in this community has declined significantly
as a result.

I'm among the minority that REALLY care about this, and it's clear (and
it's been made clear) that if I'm not prepared to work on it myself, then
it won't move forward.
That's fine, and it's perfectly reasonable. But I'm not in the least bit
interested in working on GC technology myself - I'm not an expert, and it's
not a field that interests me, thus I decided to desist participating in
discussions.

Currently there's a big push to remove hidden GC allocs from
> Phobos, starting with @nogc.
>
> std.allocators is just around the corner as well, which will
> provide a solid framework to build better allocation strategies.


We're yet to see how to use the allocators API to specify a replacement
default allocator used by the languages intrinsic allocations, which makes
it rather less exciting.
Anyone can invent an allocator interface, but designing it such that it can
be used to configure the languages implicit allocations is much more
complex. I'm concerned that Andrei's allocator interface doesn't actually
address this... At least, I haven't seen any discussion about how it will.
That said, I'm not trying to down-play the importance of a standard
allocator API, and Andrei's development is very important and appreciated,
but I am yet to find out how it actually addresses any of my real concerns
relating to allocation.

As I see it, I have zero concern about allocations I control. I am entirely
concerned with intrinsic/implicit allocations that I don't, and may
potentially (likely) originate from within 3rd party libraries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140714/929a99f0/attachment.html>


More information about the Digitalmars-d mailing list