Hacker News Reader

Comment by yongjik | Hacker News Reader

I don't know Rust, but the documentation seems to say std::rc is single-thread reference counted pointers? C++'s shared_ptr is multithreaded, so it naturally incurs much higher overhead. (In fact I think most C++ documents would discourage using shard_ptr unless you have to.)

Haven't used much C++ recently, so I don't know if the standard library has a good single-thread implementation these days, but it's not "too hard" to roll your own if performance is critical - it may not be as good as just two instructions, but it should be much leaner than shared_ptr.

View on HN

Indeed. Switching the Rust example to Arc gives code that's more similar to the C++ implementation: https://godbolt.org/z/Eoh7Pz6oh

why do you x.clone()? it isn't in the C++, and that shaves off a few instructions ;)

I think that there is implicit clone() in C++ code because when we pass a shared_ptr to a function, its reference count gets incremented (and decremented later) and it would be unfair if we used move instead of clone in Rust.

If you don't, the Rust version will be moving the Arc, but the C++ version will be copying the shared_ptr. To make both versions comparable, you must either use Arc::clone on Rust, or use std::move on C++.

Indeed! Rust fails to notice that Arc cannot be accessed from different thread and makes unnecessary locked increment/decrement in add_two_numbers_smart_way().

Your observation of the resulting output is correct, but not your conclusion about how it got there is not. The compiler doesn’t try to verify that the Arc is actually necessary, because there’s no point in optimizing the rare case where someone used an Arc but failed to Send it to another thread. The common case is that the author knows they won’t be sending it to another thread and so they use an Rc, or they know that they will so they use an Arc.

The C++ language standard folks had to make a different choice. For historical reasons the C++ compiler is not able to prevent the program author from misusing a non–thread–safe smart pointer by sending it to another thread, so all smart pointers are required to be thread–safe. The compiler may try to optimize away the extra locking, and it may or may not succeed in any given program. It may not be able to prove that it is safe to do so even when you as the author know that it will be.

Incidentally, every Rust program comes with a free test runner which is multithreaded; it runs multiple tests in parallel. This trips people up from time to time because the compiler will insist that certain types be thread–safe (tagged with the Send trait, in Rust) even though the author is not actually using any threads.

Does the test runner actually pass any user-values between test threads?

Not on its own. It’s basically “hey take these functions, each is a test, run them on multiple threads” and that’s it, nothing fancier.

Right. It just affects other decisions about the language, like the type of static items. In a purely single–threaded program it would be ok if statics weren’t Sync, but it would be a lot of work for the compiler to verify that. And since every program needs tests anyway, it might as well always require them to be Sync and then it doesn’t have to check.

Totally.

I take a slightly different view in the statics thing; like a static means you want something to be available across threads. So by using a static, you’re opening yourself to that possibility. If you want something global to a thread, use thread local storage, and Rust will allow you to use stuff that’s not okay if multiple threads were involved. It’s about expressing your intent correctly.

TIL thread local storage!

When I mentioned Send above, I meant Sync. I mix those two up more often in the evenings.

This looks like a bug to me, the fact that Arc is thread safe shouldn't matter with the removing the allocation here.

I opened a bug about this on the rust repo. [1]

[1] https://github.com/rust-lang/rust/issues/97751

Reply on news.ycombinator.com