On Sat, Dec 18, 2010 at 5:41 PM, Sebastian Sylvan < [email protected]> wrote:
> > > On Sat, Dec 18, 2010 at 5:32 PM, Patrick Walton <[email protected]>wrote: > >> On 12/18/2010 09:03 AM, Sebastian Sylvan wrote: >> >>> 3) The cost of reference counting in a multi-core scenario is a concern. >>> Rust already limits the number of reference operations using aliases, >>> which presumably gets rid of a lot of the cost. Is Rust wedded to the >>> idea of having accrate refcounts at all times? As far as I can tell, >>> modern ref-counting algorithms seem to be about on par with modern GC >>> algorithms for performance (just barely) even in the context of >>> multithreading, but they achieve this feat through deferred ref-counting >>> and things like that. Should Rust not do that instead? I kind of think >>> refcounts may be the way forward in the future, because the cost of >>> GC'ing in a ref-count system is proportional to the amount of actual >>> garbage, rather than being proportional to the size of the heap, but it >>> seems like the consensus on this issue in the literature is that >>> refcounts are only performant when they're not being constantly kept up >>> to date. Am I wrong? >>> >> >> So my thinking lately is that, instead of DRC (which is essentially a form >> of garbage collection) we should have some sort of safe unique_ptr/auto_ptr >> work-alike. The details haven't been fully ironed out, but I think it's >> going to be important for performance. The end result is that reference >> counting would only be used where you really need it; i.e. roughly where >> you'd use shared_ptr in C++ right now, except that unique pointers would >> work in the standard data structures, eliminating that common C++ pain >> point. > > > If you use non-deferred reference counting it seems like there are still > optimizations that can be done. I just found this linked from an article on > LtU: http://www.hpl.hp.com/personal/Pramod_Joisha/Publications/vee08.pdf > Perhaps there are more things that can be done on the language level to > support these kinds of optimizations. > Sorry, meant to link this one too (which has the actual optimizations): http://www.hpl.hp.com/personal/Pramod_Joisha/Publications/ismm06.pdf <http://www.hpl.hp.com/personal/Pramod_Joisha/Publications/ismm06.pdf> -- Sebastian Sylvan
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
