The "no gc" crowd

[Michel Fortin]

On 2013-10-09 21:40:11 +0000, Walter Bright <newshound2 at digitalmars.com> said:

> On 10/9/2013 2:10 PM, Michel Fortin wrote:
>> That's no different from the GC having to ignore those pointers when it does a
>> scan. Just check it was allocated within the reference counted allocator memory
>> pool, and if so adjust the block's reference counter, else ignore. There's a
>> small performance cost, but it's probably small compared to an atomic
>> increment/decrement.
> 
> When passing any dynamic array to a function, or most any assignment, 
> the compiler must insert:
> 
>     (is pointer into gc) && (update ref count)
> 
> This is costly, because:
> 
> 1. the gc pools may be fragmented, i.e. interleaved with malloc'd 
> blocks, meaning an arbitrary number of checks for "is pointer into gc". 
> I suspect on 64 bit machines one might be able to reserve in advance a 
> large enough range of addresses to accommodate any realistic eventual 
> gc size, making the check cost 3 instructions, but I don't know how 
> portable such a scheme may be between operating systems.

I know it is. The GC already pays that cost when it scans. We're just 
moving that cost elsewhere.


> 2. the "update ref count" is likely a function call, which trashes the 
> contents of many registers, leading to poor code performance even if 
> that function is never called (because the compiler must assume it is 
> called, and the registers trashed)

In my opinion, the "is pointer into gc" check would be part of the 
functions. It wouldn't change things much because this is the most 
likely case and your registers are going to be trashed anyway (and it 
makes the code smaller at the call site, better for caching).

There's no question that assigning to a pointer will be slower. The 
interesting question how much of that lost performance do you get back 
later by not having the GC stop the world?


> Considering that we are trying to appeal to the performance oriented 
> community, these are serious drawbacks. Recall that array slicing 
> performance has been a BIG WIN for several D users.

Performance means different things for different people. Slicing 
performance is great, but GC pauses very bad in some cases. You can't 
choose to have one without having the other. It all depends on what you 
want to do.

In an ideal world, we'd be able to choose between using a GC or using 
ARC when building our program. A compiler flag could do the trick. But 
that becomes messy when libraries (static and dynamic) get involved as 
they all have to agree on the same codegen to work together. Adding 
something to mangling that would cause link errors in case of mismatch 
might be good enough to prevent accidents though.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca