More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

On 5/10/14, 10:03 AM, Manu via Digitalmars-d wrote:
> On 11 May 2014 02:15, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 5/10/14, 6:33 AM, Manu via Digitalmars-d wrote:
>>>
>>> On 10 May 2014 17:08, Andrei Alexandrescu via Digitalmars-d
>>> <digitalmars-d at puremagic.com> wrote:
>>>>
>>>> On 5/9/14, 11:27 PM, Manu via Digitalmars-d wrote:
>>>>>
>>>>>
>>>>> ARC overhead would have no meaningful impact on performance, GC may
>>>>> potentially freeze execution. I am certain I would never notice ARC
>>>>> overhead on a profiler, and if I did, there are very simple methods to
>>>>> shift it elsewhere in the few specific circumstances it emerges.
>>>>
>>>> This is very, very, very wrong. -- Andrei
>>>
>>>
>>> Is there any evidence to support that assertion?
>>
>>
>> Of course, and I've shown it numerous times, only for it to be blissfully
>> ignored. Probably the most recent and influential work on it is
>>
>> http://research.microsoft.com/pubs/202163/rcix-oopsla-2013.pdf
>>
>> of which FIRST sentence is "Despite some clear advantages and recent
>> advances, reference counting remains a poor cousin to high-performance
>> tracing garbage collectors." The paper reviews previous work on the matter,
>> ALL of which shows that RC is behind GC in speed, and presents (for the
>> first time in 2013) new work that brings about parity of RC with GC.
>
> I saw that paper before.

Then the right thing is to integrate it within one's worldview. It is 
difficult to reconcile your assertions and questions with the claim that 
you have read and internalized existing work on the topic.

> And I thought, if anything, it supported my
> argument in the context of D.

It doesn't seem that way to me. Your arguments so far seem to come from 
a staunch niche position that ignores factual realities and has no 
concern for the larger environment. Some of such arguments are factually 
incorrect, and just the minimal amends and qualifications are not 
sufficient.

> The next sentence goes on to list the advantages of RC (issues we have
> wrestled with, like destructors), and then goes on to say the recent
> awesome RC is within 10% of "the fastest tracing collectors".
> Are you suggesting that D's GC is among 'the fastest tracing
> collectors'? Is such a GC possible in D?

I believe it is.

> Has anyone compared D's GC against 'the fastest tracing collectors'?
> What is the difference? Does D fall within 10%?

In all likelihood, no.

> If not, then chances are, according to this paper, RC would be
> superior to the existing GC in terms of performance,

I disagree.

> as well as
> reliability/predictability/functionality (destructors that work, not
> incompatible with embedded software).

I partially agree, but this is getting rather difficult to assess. Let's 
say I'd agree it's a valid viewpoint.

> If an awesome RC is implementable in D, but an awesome GC is not, then
> I can't see that even any performance argument can remain in the
> debate. They are talking specifically about a GC-backed-RC too, to
> handle cycles, so their implementation does not come at any cost to
> safety or added complexity for users, and has the key advantage that
> people like me may have the option to disable the cycle collector and
> take manual responsibility if desired.
>
>>> I have many colleagues who work on phones. The patterns I see are that
>>> the iOS guys who use Obj-C never complain about it, and the GC guys
>>> are often struggling with it.
>>> The bias in gamedev is strongly towards iOS too, so that should be a
>>> more populous group to draw samples from.
>>
>>
>> As competent engineers we can't afford to be ignorant of the existing
>> research and practice showing a much more complex tradeoff space than a
>> black/white distinction. We also can't do the capital mistake of engineering
>> - the beauty of the part at the expense of the beauty of the whole.
>
> There is a black/white distinction though.
> It you can't make the freezing go away, it is _incompatible_ with
> certain classes of software.
> I don't care what the performance difference is when this is the case.
> If one option is incompatible and the other is not, then there is no
> tradeoff.

Of course it would be nice to have better support for reference 
counting. My understanding is that you advocate that reference counting 
would be compulsive, which would preclude the GC option.


Andrei