Smart pointers instead of GC?

[woh]

  please this GC handbook sound good, can u post it? A queue uses 
more memory than not a queue? Fuk I did not know, I so dumb. Live 
longer more memory used, what///.


  Tuesday, 4 February 2014 at 02:33:50 UTC, Adam Wilson wrote:
> On Mon, 03 Feb 2014 18:14:36 -0800, Ola Fosheim Grøstad 
> <ola.fosheim.grostad+dlang at gmail.com> wrote:
>
>> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>>> 1. RC imposes a time overhead on mutators in order to 
>>> manipulate the counter.
>>
>> Usually you just do a retain() when your thread attain 
>> ownership (at the root of the call tree). If you use embedded 
>> counters you most likely want the data in the cache anyway, 
>> but the cacheline is made dirty. So it cost you a write back. 
>> That affects reads of small objects more than writes.
>>
>> (The C++ implementation does not use embedded counters.)
>>
>
> There are many more ways to modify the count than a thread.
>
>>> 2. Both the counter manipulation and pointer load/store 
>>> operations MUST be atomic to prevent races.
>>
>> Not with transactional memory. You revert to locking, and you 
>> probably want that kind of synchronization anyway if you run 
>> multi threaded.
>>
>
> Transactional memory incurs a massive perf penalty beyond even 
> what a lock would. You might be able to do better than a lock 
> with Intel's TSX, but that is brand new, available on Haswells 
> only, and even then only the high-end models. I doubt you'll be 
> able to sell TM-ARC to perf conscience users as the perf will 
> most likely be much worse than a GC for the next decade.