4 ms·

"Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety." If it is freeing every

"Rust achieves both of these features without runtime costs (garbage collection or reference counting), and without sacrificing safety." If it is freeing everything at the scope boundary it is incurring a huge runtime cost relative to garbage collected languages. GC scales with the number of live objects during GC while this scheme scales with the number of allocated objects. It is far more predictable than GC but I don't believe that it isn't more expensive.

wycats 12y ago
I'm a little bit confused. Every object that gets allocated has to be freed at some point. That cost is the same no matter how the memory is managed. Are you talking about an additional cost beyond "freeing memory that was allocated"?
- krig 12y ago
  It sounds like they are talking about a semi-space collector, which I can imagine might in theory be faster than scoped allocation since allocation is a simple pointer bump (just like stack allocation) but when garbage collecting you only have to traverse the live set. However, semi-space collectors can't collect non-memory resources without additional metadata, and they have a memory overhead of at least 2x the maximum live set. I have a hard time imagining even a semispace collector outperforming stack allocation. Of course if your program is short-lived you can just allocate a sufficiently large heap, pointer bump the whole way and free all non-memory resources on program termination, which ought to be cheaper (but probably not that much in practice due to cache effects).
  - wycats 12y ago
    In Rust, you often use stack allocation, which, as you pointed out, is much more efficient. There's some heap allocation in Rust, but in my experience it's actually a minority of all allocations. Rust also has an Arena library (http://doc.rust-lang.org/0.11.0/arena/index.html http://doc.rust-lang.org/0.11.0/arena/index.html), which can be used for cases where you know that you have enough memory for a given operation and are willing to throw out the entire thing when the operation (or program ;) ) is done.
    - spullara 12y ago
      Arena allocation has similar efficiencies as GC.
      - pcwalton 12y ago
        Except for not having the mark phase (also not having to copy). The mark phase can take a lot of time.
    - eddyb 12y ago
      That link is outdated, see http://doc.rust-lang.org/arena/ http://doc.rust-lang.org/arena/.
- viraptor 12y ago
  Not necessarily the same. For example for arena allocation, you can drop lots of related objects at the same time. If you don't have to run destructors on them, the cost will be much lower than any other way of managing them.
masklinn 12y ago
> It is far more predictable than GC but I don't believe that it isn't more expensive. A GC has to determine liveness of objects, so it has to traverse the object graph (or at least the most recent generation if the GC is generational) to know which objects are still alive and which aren't. That's what "GC scaling" refers to. Then it still has to deallocate dead objects, and pay the same deallocation cost as scope-bound free.
- spullara 12y ago
  It doesn't have to deallocate dead objects. That is sort of the point of most collectors.
  - pcwalton 12y ago
    All GCs have to deallocate objects. It may be very cheap to do so, for example when you have a semispace collector and no finalizers, but switching the spaces is still a form of deallocation. Production-quality GCs don't use semispace for everything because of the huge memory use overhead, and all practical GC'd languages I know of need finalizers in some form.
    - spullara 12y ago
      Finalizers are certainly the exception rather than the rule for objects. Deallocation to me represents some action taken for a particular object and scales with the number of objects deallocated. Semi-space copying collectors do not have this property. I think we only disagree on the semantics of "deallocation" — which is why I specified my argument in terms of how things scale. Similarly compacting collectors like Java's CMS also have this scaling property without semi-spaces.
  - silon5 12y ago
    But it has to scan/mark all the objects, not just the the unused ones. This has large overhead in big-mem apps. Not to mention that usually this forces the whole app into RAM (makes swap useless) and also potentialy drains cpu caches. And to amortize this it often has more memory overhead (up to 2x) than typical fragmentation in a manually managed app.
Ericson2314 12y ago
I use and love Rust, but I must admit this is true. GC has some advantages over the current options. Fear not however as post 1.0, optional GC will be most likely added to Rust. See https://github.com/rust-lang/rfcs/pull/244 https://github.com/rust-lang/rfcs/pull/244.
pcwalton 12y ago
In general, idiomatic Rust puts most objects that would be in a semispace nursery on the stack instead, which has all the advantages of a semispace collector, plus improved locality and the lack of a mark phase. The lifetime system means that the traditional limitations of escape analysis (higher order functions, separately compiled functions, virtual functions, returning objects on the stack) largely don't apply.
- spullara 12y ago
  If you can get all the objects for a full request on the stack, that would be pretty great. Is that true for the current HTTP servers / frameworks written in Rust?
  - pcwalton 12y ago
    I don't do a lot of server Web development in Rust, but I see no reason why it wouldn't be possible, at least for common cases with small vector optimization.

wycats 12y ago

I'm a little bit confused. Every object that gets allocated has to be freed at some point. That cost is the same no matter how the memory is managed. Are you talking about an additional cost beyond "freeing memory that was allocated"?

krig 12y ago
It sounds like they are talking about a semi-space collector, which I can imagine might in theory be faster than scoped allocation since allocation is a simple pointer bump (just like stack allocation) but when garbage collecting you only have to traverse the live set. However, semi-space collectors can't collect non-memory resources without additional metadata, and they have a memory overhead of at least 2x the maximum live set. I have a hard time imagining even a semispace collector outperforming stack allocation. Of course if your program is short-lived you can just allocate a sufficiently large heap, pointer bump the whole way and free all non-memory resources on program termination, which ought to be cheaper (but probably not that much in practice due to cache effects).
- wycats 12y ago
  In Rust, you often use stack allocation, which, as you pointed out, is much more efficient. There's some heap allocation in Rust, but in my experience it's actually a minority of all allocations. Rust also has an Arena library (http://doc.rust-lang.org/0.11.0/arena/index.html http://doc.rust-lang.org/0.11.0/arena/index.html), which can be used for cases where you know that you have enough memory for a given operation and are willing to throw out the entire thing when the operation (or program ;) ) is done.
  - spullara 12y ago
    Arena allocation has similar efficiencies as GC.
    - pcwalton 12y ago
      Except for not having the mark phase (also not having to copy). The mark phase can take a lot of time.
  - eddyb 12y ago
    That link is outdated, see http://doc.rust-lang.org/arena/ http://doc.rust-lang.org/arena/.
viraptor 12y ago
Not necessarily the same. For example for arena allocation, you can drop lots of related objects at the same time. If you don't have to run destructors on them, the cost will be much lower than any other way of managing them.

masklinn 12y ago

> It is far more predictable than GC but I don't believe that it isn't more expensive. A GC has to determine liveness of objects, so it has to traverse the object graph (or at least the most recent generation if the GC is generational) to know which objects are still alive and which aren't. That's what "GC scaling" refers to. Then it still has to deallocate dead objects, and pay the same deallocation cost as scope-bound free.

spullara 12y ago
It doesn't have to deallocate dead objects. That is sort of the point of most collectors.
- pcwalton 12y ago
  All GCs have to deallocate objects. It may be very cheap to do so, for example when you have a semispace collector and no finalizers, but switching the spaces is still a form of deallocation. Production-quality GCs don't use semispace for everything because of the huge memory use overhead, and all practical GC'd languages I know of need finalizers in some form.
  - spullara 12y ago
    Finalizers are certainly the exception rather than the rule for objects. Deallocation to me represents some action taken for a particular object and scales with the number of objects deallocated. Semi-space copying collectors do not have this property. I think we only disagree on the semantics of "deallocation" — which is why I specified my argument in terms of how things scale. Similarly compacting collectors like Java's CMS also have this scaling property without semi-spaces.
- silon5 12y ago
  But it has to scan/mark all the objects, not just the the unused ones. This has large overhead in big-mem apps. Not to mention that usually this forces the whole app into RAM (makes swap useless) and also potentialy drains cpu caches. And to amortize this it often has more memory overhead (up to 2x) than typical fragmentation in a manually managed app.

Ericson2314 12y ago

I use and love Rust, but I must admit this is true. GC has some advantages over the current options. Fear not however as post 1.0, optional GC will be most likely added to Rust. See https://github.com/rust-lang/rfcs/pull/244 https://github.com/rust-lang/rfcs/pull/244.

pcwalton 12y ago

In general, idiomatic Rust puts most objects that would be in a semispace nursery on the stack instead, which has all the advantages of a semispace collector, plus improved locality and the lack of a mark phase. The lifetime system means that the traditional limitations of escape analysis (higher order functions, separately compiled functions, virtual functions, returning objects on the stack) largely don't apply.

spullara 12y ago
If you can get all the objects for a full request on the stack, that would be pretty great. Is that true for the current HTTP servers / frameworks written in Rust?
- pcwalton 12y ago
  I don't do a lot of server Web development in Rust, but I see no reason why it wouldn't be possible, at least for common cases with small vector optimization.