And even more important than current benchmark numbers is that the language is explicitly designed to be optimizable, and takes the idea of "zero-cost abstractions" seriously. I can count on two fingers the number of places where we impose dynamic checks by default in the name of safety, and one of those can be unsafely turned off and the other can be safely disabled with proper code structuring.
(Theoretically we can also leverage Rust's ownership rules to automatically generate aliasing information. When implemented this should be an across-the-board speed boost for all Rust code in existence, in a way that C and C++ compilers can only dream of.)
The underlying compiler backend would use the same alias optimization pass for both Rust and C. Rust's advantages here are that all Rust code is automatically eligible for such optimization without the programmer having to do any work at all, and whereas a programmer can get `restrict` usage wrong (or alternately fail to have the confidence that a given pointer is truly unaliasable), the Rust compiler has perfect information.
To be fair, there are also optimizations that C can do that Rust can't, often resulting from C's undefined behavior.
Rust's type system enforces a great deal more invariants in terms of lifetimes, ownership and mutability than C, which enforces virtually nothing. This should therefore give the compiler far more room make optimizations without the fear of changing the semantics of the program. So in the future safe, idiomatic Rust code should be able approach the performance of highly optimized C code, without having to drop resort to unsafe code (note of course that C is implicitly unsafe).
(Theoretically we can also leverage Rust's ownership rules to automatically generate aliasing information. When implemented this should be an across-the-board speed boost for all Rust code in existence, in a way that C and C++ compilers can only dream of.)