Why Rust easily optimizes out smart pointers where C++ cannot?

I think the answer is a combination of both and inlining. With Rc, the compiler can inline the reference count increment/decrements as well as the non-public function add_numbers and the surrounding code is simple enough that it can do dead code elimination as well as other optimizations to remove the unobservable behavior. If you switch to use Arc (which is a better equivalent of shared_ptr as it also does locking/unlocking), the generated code is more comparable (funnily enough, part of the code for drop in Arc is deliberately not inlined so it prevents this optimization [1]).

Also, if one makes add_numbers public, the generated code is much larger. I don't know why the compiler chooses not to inline it in this case, probably (really speculating here) because it can be called in multiple locations and the IR for the function is over the inlining budget.

[1]: https://doc.rust-lang.org/src/alloc/sync.rs.html#1088

But someone could come along in six months and make a pointer to one of those fields, which would be an alias and would simultaneously allow mutation. The C++ language allows that, and so the C++ compiler must be very careful about optimizations.

Meanwhile in Rust if someone added the same kind of reference then the compiler would force it to be immutable (trying to create a mutable reference would cause a compiler error). Mutating the field would require that some part of the code own the value, not just own an Rc with a reference to the value inside of it. In Rust you can have mutability _or_ you can have multiple aliases, but not both at the same time. Thus the Rust compiler is free to make optimizations the C++ compiler cannot.

(But you’re right about the specific program here; it’s too simple for aliasing and mutability to really matter; I was just answering the general question.)

Also, if someone passed this Rc along to another thread then they would also get a compile error. If they really need to do that then they can make the jump to the Arc type, which is thread–safe, and then the compiler will allow it. But they can never make the mistake of sending an un–thread–safe value to another thread where it will cause race conditions, data corruption, etc.

Sure, but if you need it to work with actual reference-counted pointers from external callers, how could it be simpler? The Rust version doesn't have that ability.

The best we could expect from this example is for the C++ compiler to deduce that the shared_ptr is irrelevant because the callee has internal linkage.

No, we don't.

add_numbers() doesn't need ownership of the data, so you would never give it ownership of the data. If you happen to have the data in a reference-counted type you would get the data from it (https://en.cppreference.com/w/cpp/memry/unique_ptr/get / https://en.cppreference.com/w/cpp/memory/shared_ptr/get), and pass it to add_numbers(). The data would still be guaranteed to exist because the caller of add_numbers() is going to hold a reference at least until add_numbers() returns.

In C++ and other system languages you generally do.

In general they assume object at a time compiler (in the compiler sense, not types), and different objects may come from other compilers, instances, or even languages. So they use the standard ABI.

For an internal function they don’t have to use the standard ABI as by definition all users of that function are from within the current object. In such cases compilers can optimize the calling convention. I recall that msvc at least did this - but in those cases they’re free to change anything - they can in-line and not include the function at all in the resultant object. That’s why you often see “static inline”

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

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().

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

Then, instantiate the smart pointer with a custom no-op deleter and if you use the nt typedef I mentioned above, you'll get a similar compiler output to Rust's.

e.g nt_shared_ptr<Data> x(&d, [](Data*) -> void{});

https://godbolt.org/z/d3qv4cE1v

Why call new? I work on a several hundred k code base that has a single call to new.

It is a rookie mistake to wrap the result of new into a shared_ptr. It makes two heap allocations. You should use std::make_shared. It combines both and makes only one allocation.

Well, you can somewhat simplify it:

  int add_two_numbers_smart_way(int a, int b) {
      auto x = std::make_shared<Data>(a, b);
      return add_numbers(x);
  }

But you still get what you ask the compiler to deliver. If you don't specifically ask it to count references, it won't:

  static int add_numbers(Data *p) {
      return p->a + p->b;
  }

  int add_two_numbers_smart_way(int a, int b) {
      Data x(a, b);
      return add_numbers(&x);
  }

Here's the result:

  add_two_numbers_smart_way(int, int):
          lea     eax, [rdi + rsi]
          ret

To answer the original question, it won't optimize the smart pointers away because the smart pointers are not implemented by the compiler. They are a generic construct telling the compiler to allocate memory, increase reference counter, decrease reference counter and free memory. How does it now this is not a unit test for memory allocation API or atomic operations?

A better question would be why C++ went for implementing certain things on the library level instead of the compiler level, and the answer here is probably "historical reasons" and someone's judgement call on flexibility vs performance under specific circumstances.

unique_ptr doesn't have any aliasing guarantees, unique_ptr::get() will happily hand out references to the interior pointer.

It does give you non-ambiguous ownership semantics which is a good thing but there's still plenty of ways to misuse/abuse it.

That said if you can make the aliasing guarantees(such as Rust's borrow checker does) that opens up the possibility of automatically applying restrict semantics[1] which enables further set of optimizations available to the compiler.

[1] https://en.cppreference.com/w/c/language/restrict

How is std::unique_ptr different from Rust's Box? Everything you said applies to Rust.

Also, I definitely would not call std::unique_ptr (or Box) a GC.

> That's a zero-overhead GC that is enforced at compile time.

You should check out Rust's concept of ownership. The goodness of ownership that is implemented in unique_ptr in C++ exists for every type in Rust.

>There will be not more than 1 reference to the object at any time.

Untrue:

    auto x = std::make_unique<int>(5);
    auto& y = *x; // There are now two mutable references to the object represented by x.

>That's a zero-overhead GC that is enforced at compile time.

It's not zero overhead unfortunately. Because unique_ptr is not trivially movable or trivially destructible, there are numerous optimizations that every current C++ compiler does not perform, for example being able to pass a unique_ptr in a register.

unique_ptr is reasonable given C++'s limitations, but it doesn't come close to being as good as Rust's Box, which is genuinely zero overhead and also guarantees that there's only 1 mutable reference to the object at any given time.

It's best to pass a reference to specify that the argument shall not be null. Also avoid writing static functions in C++, make use of anonymous namespaces.

    namespace {
      int add_numbers(const Data& p) {
        return p.a + p.b;
      }
    }