More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

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. And I thought, if anything, it supported my
argument in the context of D.
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?

Has anyone compared D's GC against 'the fastest tracing collectors'?
What is the difference? Does D fall within 10%?
If not, then chances are, according to this paper, RC would be
superior to the existing GC in terms of performance, as well as
reliability/predictability/functionality (destructors that work, not
incompatible with embedded software).

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.

There are also technical advantages to RC too, like destructors that
work, which I find very compelling.