[rust-dev] Misc questions and ideas

Patrick Walton pwalton at mozilla.com
Sun Dec 23 13:45:49 PST 2012


On 12/23/12 4:25 PM, Michael Neumann wrote:
> What is the big advantage of having a tracing GC over ref counting?
> With GC we'd get rid of the extra indirection and extra operations
> during aliasing, so it's basically a performance issue, right?

Yes, and we might also be able to allow temporary parallel access to 
GC'd data for pure functions only. If we can root the data in one task 
then we can potentially temporarily operate on @ data in parallel. 
Unfortunately that's hard to do for reference counted data, because our 
reference counts are not thread-safe for performance reasons.

> Actually I was thinking of sth like in Ruby:
>
>    Array.new(size=10) {|i| i % 2}
>
> gives:
>
>    [0, 1, 0, 1, 0, 1, 0, 1...]

Use `vec::from_fn`. For example:

     rusti> do vec::from_fn(10) |i| { i % 2 }
     ~[0, 1, 0, 1, 0, 1, 0, 1, 0, 1]

> Is this an issue the LLVM developers are working on?

It's more of a Rust-specific thing. `rustc` should be providing more 
hints to LLVM so that it does the right thing. I think that, to a first 
approximation, any higher-order function in Rust would benefit from 
`always_inline` or at least `inlinehint`.

LLVM's built-in inlining heuristics are more tuned to C++; I don't think 
that's likely to change, given upstream LLVM's goals. Maybe if C++11 
uses more higher-order functions. In any case, this should be something 
fixable in `rustc` itself; I don't think LLVM will need to change much 
if any.

> Yes, I think sth with copy in the name would be less surprising. Ok,
> unwrap makes sense. Or maybe get() and get_copy()?

Yeah, `get_copy` sounds reasonable to me.

> So a "const" function (in terms of C++ ;-) would always take a &str
> pointer? Makes absolute sense to me.

Yes. You can temporarily "borrow" a ~str as immutable.

> Ideally there would be an operator, as writing .append() all the time is
> quite tedious.

I think `+=` will have this signature:

     trait AddAssign<Rhs,Result> {
         fn add_assign(&mut self, other: &Rhs) -> Result;
     }

Which would allow += to work as you suggest.

> Hm, this is interesting. Is there somewhere a simple example how to use
> #[auto_encode] and what my msgpack library needs to implement to work
> with it?

Unfortunately I'm not an expert on `auto_encode`. Erick Tryzelaar, Brian 
Anderson, or Graydon may know better.

> I see. So it would be possible to write a syntax extension called for
> example iter_fields!(struct_Type) which could be used to generate i.e.
> custom serializers. But that would be probably similar to #auto_encode,
> just that it could be more user-defined.

Well, you'd need to write it on the struct definition, so that it has 
access to the struct contents (as syntax extensions run before 
typechecking).

Actually, #[auto_encode] is a syntax extension itself, as some syntax 
extensions can be written using #[] "attribute" notation. This should 
eventually extend to user-defined syntax extensions as well.

Patrick



More information about the Rust-dev mailing list