Rust is now overall faster than C in benchmarks

Post by steveklabnik » Sun, Jan 03, 2021, 8:25 PM UTC

alerighi wrote: post #51

arcticbull wrote: post #42

Earlier quoted context omitted.

Rust can be faster than C because in general C compilers have to assume that pointers to memory locations can overlap (unless you mark them __restrict). Rust forbids aliasing pointers. This opens up a whole world of optimizations in the Rust compiler. Broadly speaking this is why Rust can genuinely be faster than C. Same is true in FORTRAN, for what it's worth.

Well you are saying that even in C you can use the restrict keyword to tell the compiler that 2 memory locations can overlap. Of course is in the hand of the programmer to tell the compiler to do so. I don't think there is a fair comparison between Rust and C: C is just an higher level assembler, if the programmer knows what he's doing he can use the hardware 100% of its potential. That is the reason why C is still u…

Post by steveklabnik » Sun, Jan 03, 2021, 8:26 PM UTC

arcticbull wrote: post #69

alerighi wrote: post #51

Earlier quoted context omitted.

Well you are saying that even in C you can use the restrict keyword to tell the compiler that 2 memory locations can overlap. Of course is in the hand of the programmer to tell the compiler to do so. I don't think there is a fair comparison between Rust and C: C is just an higher level assembler, if the programmer knows what he's doing he can use the hardware 100% of its potential. That is the reason why C is still u…

I think you'd be hard pressed to find more than a handful of usual C programmers, even in embedded, who know what the __restrict keyword does, let alone are rigorous in its application.

Post by pornel » Sun, Jan 03, 2021, 8:30 PM UTC

stabbles wrote: post #53

Svetlitski wrote: post #49

Once LLVM fixes some bugs with `noalias`, at which point Rust will begin using it again in more circumstances [1], I'd expect to see Rust get even faster in these benchmarks, given that the Rust compiler knows much more about which pointers do/do-not alias than most other programming languages [2] and the myriad optimizations this knowledge allows. [1] https://github.com/rust-lang/rust/issues/54878#issuecomment-... […

I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.

Post by jeffbee » Sun, Jan 03, 2021, 8:32 PM UTC

vitus wrote: post #74

jeffbee wrote: post #63

Earlier quoted context omitted.

Speaking generally and about no specific program, you should expect C++ to be faster than C. C++ has more ways for the programmer to communicate with the compiler.

At the same time, a lot of those mechanics involve additional overhead (e.g. vtable lookups for dynamic dispatch per inheritance). But yes, some of these do provide hints for the compiler, e.g. constexpr, ownership semantics per unique_ptr. There's nothing stopping a human from writing equivalent C, so my suspicion is that the performance gap is primarily due to the benchmark implementation.

Post by djeiasbsbo » Sun, Jan 03, 2021, 8:35 PM UTC

steveklabnik wrote: post #66

mlyle wrote: post #47

Earlier quoted context omitted.

A big part of why binaries are "big" is dynamic linking and external symbols. That Rust hello world is just hand-crafted to never be linkable to anything else at runtime and invoke a system call with a buffer. This isn't really how we'd like to do most things.

Interestingly enough, I would say that dynamic linking makes binaries smaller, that code no longer lives in the binary, but another place instead.