5 ms·

If a value returned from a function actually moves or not is currently up for Rust to optimize. It's not something you can depend on. About the refcounts: sinc

If a value returned from a function actually moves or not is currently up for Rust to optimize. It's not something you can depend on. About the refcounts: since the counting is explicit (calls to clone()) they at least in my experience don't really show up. Most of the refcounted objects I deal with bump the refcounts once when some task spawns and decrements it when it ends. I have yet to see refcounts to change in hot code paths. //EDIT for your edit: > Edit: Forgot about handles. Ugh. Completely unacceptable when you want to grow your tree data structure and you have to do a realloc and basically copy every node. Sure, but that's not my point anyways. At any point you can fall down to writing unsafe code and building a safe abstraction on top of it. This is to help developers not run into walls. I don't think that handles are the best thing invented but I don't think "well you can't do that in Rust until we some time in the future" and not provide an alternative is a particularly good suggestion.

gmueckl 9y ago
But if they do... oh boy, what fun can be had by spamming ooeratins on the same memory location from multiple cores! If this isn't thrilling enough, try doing that with atomic operationsto be extra thread safe. I had some really fun experiences with this in C++. The best one was a factor 100 slowdown by activating compiler optimizations.
berkut 9y ago
Are Rust ref-counts atomic? (I'd assume so). Atomic ref-counts can actually have a surprising amount of overhead in many multithreaded scenarios, so much so that going back to raw pointers over shared pointers in C++ for some use cases of passing pointers around can provide a huge win.
- the_mitsuhiko 9y ago
  Arc<T> is atomic, Rc<T> is not.
- therein 9y ago
  There is Rc and Arc, the latter being atomic. If you want to pass them between threads, you'll want an Arc, and in fact you will want an Arc<Mutex<Data>> so your data becomes: let data = Arc::new(Mutex::new(Data::new())); And if you want a mutable static global that's accessed across threads, you'll need something like: lazy_static! { // 0 -> None // 1 -> Circles // 2 -> Bezier static ref DRAW_ON_TOUCH: Arc<Mutex<u32>> = Arc::new(Mutex::new(0)); } I love Rust but it is making easy things harder than they need to be.
  - gmueckl 9y ago
    Hm, this distinction between non-atomic and atomic ref counting sounds like a scat-gun sized footgun waiting to go off when it is least expected. Is there any protection for non-atomic ref counting in a multithreaded environment in Rust?
    - the_mitsuhiko 9y ago
      > Is there any protection for non-atomic ref counting in a multithreaded environment in Rust? Yes. It errors at compile time (`std::rc::Rc<i32>` cannot be sent between threads safely)
    - pcwalton 9y ago
      > Is there any protection for non-atomic ref counting in a multithreaded environment in Rust? Of course. Rust is memory safe. The compiler will prevent you from sharing non-thread-safe reference counted objects between threads. This is a significant advantage over C++, where the compiler offers no such protection and so the typical solution is just to use atomic reference counting (shared_ptr) everywhere.
      - gmueckl 9y ago
        So are you claiming that the exact same solution is good in rust and bad in C++?
        9y ago
- quickben 9y ago
  Imagine your example in a singleton pattern scenario. It would be quite a performance hit.
- pcwalton 9y ago
  > Are Rust ref-counts atomic? (I'd assume so). No, not unless the object is actually shared among multiple threads.

gmueckl 9y ago

But if they do... oh boy, what fun can be had by spamming ooeratins on the same memory location from multiple cores! If this isn't thrilling enough, try doing that with atomic operationsto be extra thread safe. I had some really fun experiences with this in C++. The best one was a factor 100 slowdown by activating compiler optimizations.

berkut 9y ago

Are Rust ref-counts atomic? (I'd assume so). Atomic ref-counts can actually have a surprising amount of overhead in many multithreaded scenarios, so much so that going back to raw pointers over shared pointers in C++ for some use cases of passing pointers around can provide a huge win.

the_mitsuhiko 9y ago
Arc<T> is atomic, Rc<T> is not.
therein 9y ago
There is Rc and Arc, the latter being atomic. If you want to pass them between threads, you'll want an Arc, and in fact you will want an Arc<Mutex<Data>> so your data becomes: let data = Arc::new(Mutex::new(Data::new())); And if you want a mutable static global that's accessed across threads, you'll need something like: lazy_static! { // 0 -> None // 1 -> Circles // 2 -> Bezier static ref DRAW_ON_TOUCH: Arc<Mutex<u32>> = Arc::new(Mutex::new(0)); } I love Rust but it is making easy things harder than they need to be.
- gmueckl 9y ago
  Hm, this distinction between non-atomic and atomic ref counting sounds like a scat-gun sized footgun waiting to go off when it is least expected. Is there any protection for non-atomic ref counting in a multithreaded environment in Rust?
  - the_mitsuhiko 9y ago
    > Is there any protection for non-atomic ref counting in a multithreaded environment in Rust? Yes. It errors at compile time (`std::rc::Rc<i32>` cannot be sent between threads safely)
  - pcwalton 9y ago
    > Is there any protection for non-atomic ref counting in a multithreaded environment in Rust? Of course. Rust is memory safe. The compiler will prevent you from sharing non-thread-safe reference counted objects between threads. This is a significant advantage over C++, where the compiler offers no such protection and so the typical solution is just to use atomic reference counting (shared_ptr) everywhere.
    - gmueckl 9y ago
      So are you claiming that the exact same solution is good in rust and bad in C++?
      - 9y ago
quickben 9y ago
Imagine your example in a singleton pattern scenario. It would be quite a performance hit.
pcwalton 9y ago
> Are Rust ref-counts atomic? (I'd assume so). No, not unless the object is actually shared among multiple threads.