DIP60: @nogc attribute

Manu via Digitalmars-d digitalmars-d at puremagic.com
Wed Apr 23 00:45:51 PDT 2014


On 22 April 2014 05:03, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 4/21/2014 10:57 AM, Steven Schveighoffer wrote:
>>
>> On Mon, 21 Apr 2014 13:28:24 -0400, Walter Bright
>> <newshound2 at digitalmars.com>
>> wrote:
>>
>>> On 4/21/2014 5:00 AM, Steven Schveighoffer wrote:
>>>>>
>>>>> Total replacement of GC with ARC in D will:
>>>>
>>>> This is the wrong straw-man, I'm not advocating for this at all.
>>>
>>>
>>> Many are when they advocate ARC for D.
>>
>>
>> Does that preclude you from accepting any kind of ARC for D?
>
>
> No. My objection is to pervasive ARC, i.e. all gc is replaced with ARC, and
> it all magically works.

It's not magic, it's careful engineering, and considering each problem
case one by one as they arise until it's good.


>>> 5. Numerous posters here have posited that the overhead of ARC can be
>>> eliminated with a sufficiently smart compiler (which does not exist).
>>
>>
>> You continue to speak in extremes. People are saying that the compiler can
>> eliminate most of the needless ARC increments and decrements, not all of
>> them.
>
>
> Manu, for example, suggests it is good enough to make the overhead
> insignificant. I'm skeptical.

I didn't quite say that, but let me justify that claim if you want to
put it in those words.

RC fiddling in low-frequency code is insignificant.
High-frequency code doesn't typically allocate, and is also likely to
implement a context specific solution anyway if it is truly
performance sensitive.
In the event of code where RC fiddling is found to make a significant
impact on performance, there are various tools available to address
this directly.

There's a middle-ground that might suffer compared to GC;
moderate-frequency, where code is sloppily written doing whatever it
likes without any real care, and run lots of iterations. But that's
not usually an example of performance sensitive code, it's just crappy
code run many times, and again, they have the tools to improve it
easily if they care enough to do so.

I also believe programmers will learn the performance characteristics
of ARC very quickly, and work with it effectively. The core of my
argument is that it's _possible_ to work with ARC, it's not possible
to work with GC if it is fundamentally incompatible with your
application.


>> Compilers that do this do exist.
>
>
> I can't reconcile agreeing that ARC isn't good enough to be pervasive with
> compiler technology eliminates unnecessary ARC overhead.

The most important elimination is objects being passed down a
call-tree via args. That can certainly eliminate properly.
High-frequency code always exists nearer to the leaves.
D has pure (which is definitely well employed), and 'shared' is an
explicit attribute, which allows the compiler to make way more
assumptions than O-C.

The ARC optimisations are predictable and reliable. The suggestion
that acceptable code performance relying on specific optimisation is a
concept you can't reconcile is a bit strange. Programmers rely on
optimisation all the time for acceptable performance. This is no
different.


More information about the Digitalmars-d mailing list