
Rust for C++ programmers – part 5: borrowed references - AndrewDucker
http://featherweightmusings.blogspot.co.uk/2014/05/rust-for-c-programmers-part-5-borrowed.html
======
eq-
I wonder if there's a (simple syntactical) way to unlink the constness of
unique pointers and their targets. It's not a huge obstruction, but seems like
an unnecessary restriction not found in the near-equivalent C++ construction.

~~~
pcwalton
Yes, you can do it, with Cell and RefCell, though the former is restricted to
POD types and the latter comes with some minor runtime overhead.

Inherited mutability is not an unnecessary restriction from the point of view
of memory safety. It's critical to Rust's ability to prevent iterator
invalidation and related bugs at compile time. The fact that C++ doesn't do it
is the source of many of its memory safety problems, such as dangling
references and iterator invalidation.

~~~
Peaker
I was a bit surprised by the reverse:

    
    
      let x = 5
      let mut y = &x
    

If I understood correctly, x is immutable, but can still be mutated via (*y)?

~~~
pcwalton
No, that results in an error. Mutability doesn't inherit through references
(`&`).

------
ExpiredLink
This 'ownership semantics' of pointers in Rust is just the wrong kind of
abstraction. At least for a language nascent in 2014 AD.

~~~
general_failure
Not sure why you are being downvoted. I agree with you, the whole thing seems
archaic. Downvoters care to comment on why this is relevant to a modern
programming language and try to convince us (and not the other way around)?
Give me a good example of why I should care. Performance? Do you have numbers?

~~~
pcwalton
If you mean "do you have numbers as to why you might not want GC in all
scenarios", yes.
[http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf](http://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf)

~~~
pkolaczk
Generally I agree that you don't want GC in all scenarios, but the paper you
cite has several flaws which makes its conclusions very far from truth.

1\. It is based on non-production JVM and does _not_ use the same algorithms
that are used in production level VMs. There is a huge performance difference
between any GC from 1990s and modern generational GC used in production-level
VMs.

2\. Some part of the experiment involved simulation. You must be very careful
with extrapolating simulation results onto real world. Actually someone on the
Internet rerun one of the same experiment using non-simulated VM and got
totally different results, but now I can't find that blog post :(

3\. It compares GC to "ideal" manual memory management, ignoring the fact that
manual memory management is not free either. Things like heap fragmentation or
computational cost of running allocation/deallocation code do exist and may
cause also some real problems. The costs lie elsewhere, but that doesn't mean
they don't exist.

My experience with large applications is completely different than the
conclusion of the paper. Unless you're doing something completely crazy like
generating several GBs of garbage per second, modern generational GCs overhead
is typically very small (<5%) with only 20-50% more memory than the live set
size, not 3-5x as the paper claims.

The biggest pain not solved completely are pauses, but researchers are
actively working on it and things are getting much better.

~~~
pcwalton
> 3\. It compares GC to "ideal" manual memory management, ignoring the fact
> that manual memory management is not free either. Things like heap
> fragmentation or computational cost of running allocation/deallocation code
> do exist and may cause also some real problems. The costs lie elsewhere, but
> that doesn't mean they don't exist.

No, it doesn't; it uses malloc and free, counting the costs of allocation and
deallocation using a traditional memory allocator. (In fact, if anything,
that's unfair to traditional memory allocators, as high-performance code will
often use things like bump-allocating arenas which significantly outperform
malloc and free. It also uses dlmalloc, which is outpaced by jemalloc/tcmalloc
these days, although if the benchmarks are not multithreaded the difference
will be small.)

Heap fragmentation exists in GC systems as well, and fragmentation in modern
allocators like jemalloc is very small.

~~~
pkolaczk
Ok, point taken, however their cost analysis is based on "simulated cycles",
which is extremely simplified. With modern CPUs doing caching, prefetching,
out-of-order execution I seriously doubt its accurate. malloc/free have
typically a tendency to scatter objects around the whole heap, while
compacting GCs allocate from a contiguous region - so a properly designed
research experiment would take that into account. Hans Boehm did experiments
on real programs and found that using compacting GCs actually speeded up some
programs because of better cache friendliness.

As for heap fragmentation - it does not exist in some GC systems, like G1 or
C4. And fragmentation is also extremely workload dependent - it might be "very
small" for most cases and for some might be as much as 5x (Firefox struggled a
lot from this).

