4 ms·
> dynamic lifetimes What do you mean ? If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur p
by Fiahil 4y ago
> dynamic lifetimes
What do you mean ?
If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur performance hits other than a regular heap allocation.
- eptcyka 4y agoAtomic reference counting does incur a slowdown.
- Fiahil 4y agoyes, but that's not a JVM-like slowdown. It's fairly well amortised and _clearly_ not a matter of consideration when writing an app or a library. If your issue is "atomics are slowing down my app", then I assume you already milked the code to the latest micro second of performances everywhere else. This is likely not the case here and not a general advice I would give to anyone. Remember, some dev in python where concurrency is inexistent, start-up time is horrendous and performances are abysmal compared to rust. (this is exaggerated: of course you can run stuff in parallel in python)
- selfmodruntime 4y agoWhich should be incredibly negligible unless you're counting literal millions of objects. Even then, I'm suspecting that refcounting will never be in the top spots of things that slow you down.
- eptcyka 4y agoWhat I'm saying is that bumping atomic references inside a hot loop will be detrimental for performance, and since it invalidates a cache line and this can flush caches for lots of cores. It also shuts down ILP.
- insanitybit 4y agoOne really nice thing about Rust's use of Arc is that you don't need to bump atomic references in a hot loop, or much at all usually. Once you have an Arc<T> you can `as_ref()` to get a &T. So maybe you need an Arc to share something with another thread, so you clone it once. Once you're in that thread though you can go back to just using `&` and never touch the atomic again.
- moonchild 4y agoReference counting is much slower than 'garbage collection'.
- anonymous_sorry 4y agoReference for "much" slower? Surely depends on usage? The cost is also more predictable/amortised than classic garbage collection.
- scratcheee 4y agoIt's generally true to be fair, reference counting could be used for every garbage collected language (and be much simpler). The only reason they switched to more complex schemes is they're faster on average. Even smart schemes that try to remove unnecessary ref count changes will tend to underperform compared to a (well built) tracing GC. As for a reference, https://en.wikipedia.org/wiki/Tracing_garbage_collection#Performance https://en.wikipedia.org/wiki/Tracing_garbage_collection#Per... The point about predictability is totally valid though (and combined with simplicity is the reason many languages still pick ref counting).
- marcosdumay 4y agoIt's not generally true. It's true for the case when the runtime keeps track of every little memory segment.
- masklinn 4y agoThat's an issue when every object is managed. Which is not the case in an unmanaged language, you'd only refcount what you need to refcount. Furthermore Rust can also safely borrow from a refcounted pointer without the need for refcount traffic, which can be quite the performance gain for atomic refcounts (it's nigh irrelevant for non-thread-safe refcounts as those just do a local increment/decrement).
- scratcheee 4y agoTechnically yes, but if you only use it when you need it, it's often not a performance concideration. And for systems programming, the often overlooked truth is that people care far less about perfect performance than they do about control - ref counting doesn't give up control to a mysterious oracle running in the background which may or may not wreck your performance in hard to predict ways, it just pays a known cost at the time you use it based on how you're using it. (that's not to say performance is irrelevant, but it's not always the top concern, and with control you can always rewrite slow code as needed). The obvious question is "why can't we have an optional modern garbage collector built into a systems language?", and it's a good question (I remember reading there was one in rust for a while during early development, but it got removed), I think the main reason is that high quality garbage collectors are incredibly complicated, with many trade offs, and a gc that combines well with the rest of a language and various alternative memory tracking solutions is harder than most. The projects that really want one can always implement their own and choose their own tradeoffs, so there's not many use-cases where a generic language-provided one would justify the complexity of implementing it within the language.