DIP60: @nogc attribute

[via Digitalmars-d]

On Saturday, 19 April 2014 at 13:34:13 UTC, Michel Fortin wrote:
> Yet, ARC-managed pointers are a huge success in Objective-C. I 
> think the trick is to not bother people with various pointer 
> types in regular code.

But you have to take the following into account:

1. Objective-C has a separate type for RC objects (although you 
have a toll-free bridge for some of CF).

2. Objective-C started out with inefficient manual RC, then 
required some restrictions on that when introducing ARC that 
removed some overhead, so the ARC overhead is less noticable.

ARC isn't trivial to implement:

http://clang.llvm.org/docs/AutomaticReferenceCounting.html

> D thrives with raw pointers only because its GC implementation 
> happens to manage raw pointers. That's a brillant idea that 
> makes things simpler, but this also compromises performance at 
> other levels. I don't think there is a way out of that 
> performance issue keeping raw pointers the default, even though 
> I'd like to be proven wrong.

Depends on how you look at it. GC does not really have a horrible 
performance issue, it has a terrible latency issue.

If you can put everything that is latency sensitive into separate 
units then having background collection isn't all that bad. That 
is ok if you only read from the GC heap in the real time and 
write into non-GC buffers in real time (or have a backdoor into 
the GC heap during collection).

If you can establish isolates of some sort (with multiple 
threads), then you can segment GC and reduce latency.

If you take a graph that is 100% immutable, then you can 
GC-handle that graph as a single object. So, if you get semantics 
for "freezing" graphs (conversion to immutable) then you probably 
can cut down on collection time too. As the gap between memory 
bus speed and memory capacity increases, then more an more memory 
will stay "mostly untouched". There is obviously opportunities 
for optimizing a GC for that, but you need the right semantics. 
Semantics beyond const-types.

Surely, you can have both GC, and acceptable performance. I agree 
with Paulo Pinto on that point. But not with C-like semantics.