Sandro, thanks for posting those links [3,4]. I have to agree with you, this is the most promising abstraction for structuring fine grained parallelism I have seen to date.
I'm suspicious or may be very hard to keep the overhead near their observed 5% for less trivial data-structures, bit it is worth a shot! On Sep 30, 2013 5:07 AM, "William ML Leslie" <[email protected]> wrote: > Nevertheless, what Carmack seems to be describing is GC (with card > tables, I guess). I don't think so. I think he is describing a two-revision GC integrated version of [3], where the indirection cost is removed by replacing their COW and version lookup with a full copy integrated with the GC relocate. [3] http://research.microsoft.com/apps/pubs/default.aspx?id=132619 [4] http://research.microsoft.com/apps/pubs/default.aspx?id=150180 > He wants more control, but like many, doesn't > quite seem to grasp what that control needs to be. That is not what I see. I see a very specific desire to synchronize GC sweeps with frame rendering - letting standard gc handle lifetime. (No static lifetime analysis) However, I suspect [3] may be dramatically more efficient, capable, and flexible ... Just so long as GC stop the world is sufficiently minimized.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
