More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

On 11 May 2014 00:20, Peter Alexander via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Saturday, 10 May 2014 at 13:33:40 UTC, 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?
>
>
> It is well known that reference counting can perform poorly. The updates
> damage the cache and atomic reference counts will stall pipelines.
>
> Of course, there are things that can be done to mitigate the impact, but the
> same is true for GC.
>
> Just Google for reference counting performance.

I agree that acceptable performance for ARC requires compiler support.
What doesn't? Acceptable performance in general requires extensive
compiler support (in the form of optimisation). Why should this be
considered any differently?

D is thread-local by default. That's a blessing for RC, the
requirement for atomics will be minimal.
D also has pure, which helps a lot. Hopefully one day we'll have
'scope' fleshed out to make proper escaping guarantees in non-pure
functions too, that would really help.

There are strategies to reduce impact on the dcache.

It just seems like a much more approachable problem with actual
options available than the mythical awesome GC.

>> 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.
>
>
> Of course. In game dev a large frame time spike is worse, and more
> obvious/noticeable than a consistent and mostly predictable performance hit.

I can't think of many situations where that wouldn't be the case. What
sort of software is it not an issue to experience intermittent
freezing?
Is it shown that cumulative RC fiddling costs significantly exceed a
GC collect pass? Recall too that D has significant opportunity to
improve on ARC as implemented by other languages, and D's GC is much
worse than most, so if you considered the same competitive difference
in the context of D, how would it look then?

It's funny actually, D offers many advantages towards ARC that other
languages don't enjoy... but by contrast, D barely supports the notion
of a GC it seems, or surely we'd have had more people experimenting
with cool advanced implementations by now?