It's... complicated.

There's a lot of subtle nuances, each giving a chance to the optimizer to work better for Rust or C++, so it really depends whether the optimizer manages to seize the opportunities, and depending on which it seizes it may advantage one language or another.

Also, beyond the optimizer, there's also code. Rust generally provides more stringent guarantees, which the developer may take advantage of, whereas in C++ this would be dangerous, or outright wrong.

Aggressive use of references

As you pointed out, Rust applications can be structured quite differently from C++ applications, and that's not apples-to-oranges then... or is it?

Unless the goal of a C++ application is pure performance -- and even then -- there is generally a fair amount of defensive programming in C++: the language does not provide many guarantees, leaving ample opportunities to shoot yourself in the foot. After debugging that n-th data-race, or that n-th use-after-free, a developer will decide that enough is enough, and that there's no point going fast if doing so result in incorrect results, and just introduce a little overhead to make an API safer. This results in greater quality, easier maintenance, ... and all it cost was performance.

In Rust, there's much less tension between correctness and performance. The compiler will happily point out any instance of data-race or use-after-free, no worries.

And as a result, Rust software that vies for high-performance will aggressively lean on the compiler:

• No defensive copies, just use a &T!

• No lock, just use a &mut T!

While technically possible in C or C++, in practice such widespread use would result in too many human errors -- so you don't see it.

Destructive moves

I just spotted a SO question yesterday (since deleted), which linked to https://godbolt.org/z/rbsnYrxK8 . Observe how lean the generated assembly is for Rust, and how dreadful it is for C++!

Destructive, bitwise, moves are a godsend for both developers and optimizers:

• Developer: moves are guaranteed noexcept, move of arrays can be accomplished with a single memcpy, realloc works! This makes writing collections so much easier. Lean written code: less for the optimizer to go through.

• Optimizer: memcpy is often a built-in! The compiler understand exactly what's going on, much more easily at least that with the bizarre pointer manipulations going on in self-referential std::string (SSO).

The end result is that Vec, String, etc... are much leaner in Rust than in C++, and, well, you can see the effects in the above link.

Aliasing & Immutability

C++ has little concept of aliasing or immutability. In many instances, const is just a fancy declaration of intention which can just be cast away.

In Rust, however, there's a guarantee that the content pointed to by &T will not be modified under you feet. Or conversely, that nobody else can access the content pointed to by &mut T.

This allows some optimizations, though perhaps less in "business logic" code (many branches, scattered reads/writes) than in "scientific" code (matrixes, large arrays, etc...).

Bounds Checking & Unsafe

Bounds checking does, indeed, add some potential overhead... but a correct application is bounds checked, regardless of the language, and defensive coding will introduce bounds checks even if the language/library does not enforce it.

The effect of bounds checking is also highly dependent on code pattern. A single access is unlikely to have any effect; where bounds checking really is problematic is when it hampers optimizations -- such as loop vectorization, hoisting, etc... -- and if that happens there's always the unsafe hatch in Rust.

And that unsafe hatch matters in general, because any overhead that Rust safety may add can be avoided by using unsafe in the cases where it really matters -- that one hot loop.

As a result:

• Rust offers high-performance because it's safe by default.

• Rust safety checks can be disabled when they cost performance.

It's all upsides.