3 ms·

I don’t fundamentally disagree with your points but I do want to point out that in Rust, you have far less recount traffic than in a language that uses referenc

I don’t fundamentally disagree with your points but I do want to point out that in Rust, you have far less recount traffic than in a language that uses reference counting as a GC strategy, because you only increment and decrement on new owners, and not on every access. You can take a regular old &T to the interior of an Rc<T> at any time.

consteval 2y ago
I didn't know this, that's pretty cool. Definitely more manual than what Swift is trying to do with RC elision since you have to then deal with runtimes, but also, I'd imagine much more performant due to a finer-grained nature.
- steveklabnik 2y ago
  Yes, and beyond that, you also have the Rc<T> vs Arc<T> split, so if you're not doing multi-threaded, it's not even an atomic increment/decrement. That said, this is just my intuition here, I've never seen a good benchmark trying to do the comparison, so I don't want to over sell it either. But a lot of times, it's like, "okay I have four threads so I need the refcount to go to four" and then it's just using normal references to actually use the value inside.
  - vlovich123 2y ago
    I’ve done thorough benchmarking of Rc and Arc. Rc is cheap to the point of free unless it frees - it’s literally just an addition or subtraction with no data dependency in the path. Your CPU can do > 6 billion of these per second on a 6Ghz CPU (if I recall correctly you could do 3 per clock cycle in a micro benchmark due to out-of-order but at a minimum you should be able to do 1 per cycle). Arc is quite expensive, particularly on x86 because of its memory model. You can maybe do a few million of them per second. But as you said, you shouldn’t be incrementing ownership once you’ve sent it to a new thread and instead using references directly or using something Rc-like to track the lifetime (i.e. when the current thread’s Rc count hits 0, release your Arc reference).

consteval 2y ago

I didn't know this, that's pretty cool. Definitely more manual than what Swift is trying to do with RC elision since you have to then deal with runtimes, but also, I'd imagine much more performant due to a finer-grained nature.

steveklabnik 2y ago
Yes, and beyond that, you also have the Rc<T> vs Arc<T> split, so if you're not doing multi-threaded, it's not even an atomic increment/decrement. That said, this is just my intuition here, I've never seen a good benchmark trying to do the comparison, so I don't want to over sell it either. But a lot of times, it's like, "okay I have four threads so I need the refcount to go to four" and then it's just using normal references to actually use the value inside.
- vlovich123 2y ago
  I’ve done thorough benchmarking of Rc and Arc. Rc is cheap to the point of free unless it frees - it’s literally just an addition or subtraction with no data dependency in the path. Your CPU can do > 6 billion of these per second on a 6Ghz CPU (if I recall correctly you could do 3 per clock cycle in a micro benchmark due to out-of-order but at a minimum you should be able to do 1 per cycle). Arc is quite expensive, particularly on x86 because of its memory model. You can maybe do a few million of them per second. But as you said, you shouldn’t be incrementing ownership once you’ve sent it to a new thread and instead using references directly or using something Rc-like to track the lifetime (i.e. when the current thread’s Rc count hits 0, release your Arc reference).