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.
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
