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
<[email protected]> 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.
