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.

-- 
Sebastian Sylvan
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to