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.
4) If the cost of atomic ref counts are still too high, perhaps all allocations should be task-local unless you explicitly tag it as being shared (with task-local data not being allowed over channels)? This seems conceptually simple and impossible to mess up. You tag shared data in some special way and only for that data you pay the extra cost of more expensive ref-counting. If you forget to tag something as shared, then you'll get a compile-time error when you try to send it to another task. Note that you're still sharing data here, so you support the scenario in 1), you're just not incurring the cost for everything. I'd prefer if this wasn't necessary (i.e. if refcount operations could be statically or dynamically elided often enough that any immutable data can be sent over a channel), but you could always make the "shared" keyword a no-op in the future if that materializes.
I've thought about such things (a sort of "shared box" operator, perhaps), but I'm unsure as to what the precise semantics would be. It would also complicate what's already a very complicated type system :( Note that right now (AIUI) you can still share reference counted data among green threads.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
