Rust is now overall faster than C in benchmarks • Hacker News Board

Re: Rust is now overall faster than C in benchmarks

#41

Post by fmntf » Sun, Jan 03, 2021, 7:39 PM UTC

steveklabnik wrote: post #40

1vuio0pswjnm7 wrote: post #38

The reasons I use C versus comparable alternatives are not limited to speed. For example, the size of the compiler toolchain, the speed of compilation and the size of the resulting executables are all factors I have to consider. I do lots of work on systems with limited resources. How does Rust compare on those points versus, say, GCC. https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna

I mean, you'll get drastically different numbers with all of those examples if you actually ask for options that produce small binaries. That the default flags don't try to make things small (across any of these toolchains) means this isn't really a fair comparison. The smallest "hello world" binary rustc has ever produced was 137 bytes. https://github.com/tormol/tiny-rust-executable

If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?

Re: Rust is now overall faster than C in benchmarks

#42

Post by arcticbull » Sun, Jan 03, 2021, 7:40 PM UTC

harporoeder wrote: post #2

I was wondering if perhaps this was actually measuring a difference between LLVM and GCC, but they also provide a set of benchmarks of C Clang vs C GCC (1) and Clang is generally slower in those test. Although there is some correlation between the ones Clang wins in C And Rust. 1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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.

Re: Rust is now overall faster than C in benchmarks

#43

Post by londons_explore » Sun, Jan 03, 2021, 7:41 PM UTC

jolux wrote: post #11

I think benchmarking C vs C++ vs Rust must only really be useful for researchers. They’re all making a similar tradeoff for performance: forcing you to consider how you use memory. Does anyone work in a field where the performance difference between these specific three platforms matters? I’m genuinely curious. Edit: also, if you could explain briefly why and what makes particular choices out of the three unsuitable,…

I do some graphics stuff. As soon as you get to "this chunk of code needs to be run for every pixel of every 4k frame at 60fps", suddenly the number of clock cycles and registers matters... Some of my platforms don't have GPU's, so it really is squeezing everything possible out of the language and compiler...

Re: Rust is now overall faster than C in benchmarks

#44

Post by shepmaster » Sun, Jan 03, 2021, 7:41 PM UTC

arcticbull wrote: post #42

harporoeder wrote: post #2

I was wondering if perhaps this was actually measuring a difference between LLVM and GCC, but they also provide a set of benchmarks of C Clang vs C GCC (1) and Clang is generally slower in those test. Although there is some correlation between the ones Clang wins in C And Rust. 1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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.

Why does the Rust compiler not optimize code assuming that two mutable references cannot alias? —https://stackoverflow.com/q/57259126/155423

Re: Rust is now overall faster than C in benchmarks

#45

Post by steveklabnik » Sun, Jan 03, 2021, 7:42 PM UTC

fmntf wrote: post #41

steveklabnik wrote: post #40

Earlier quoted context omitted.

I mean, you'll get drastically different numbers with all of those examples if you actually ask for options that produce small binaries. That the default flags don't try to make things small (across any of these toolchains) means this isn't really a fair comparison. The smallest "hello world" binary rustc has ever produced was 137 bytes. https://github.com/tormol/tiny-rust-executable

If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?

Because everything is a tradeoff. Getting the binary to be smaller means taking more compile time, because compilers have to do work to reduce the size. It is much faster to produce larger binaries.

Additionally, most compilers produce something that's useful for development and debugging by default, and that means including extra stuff for that purpose.

Re: Rust is now overall faster than C in benchmarks

#46

Post by arcticbull » Sun, Jan 03, 2021, 7:42 PM UTC

shepmaster wrote: post #44

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.

Why does the Rust compiler not optimize code assuming that two mutable references cannot alias? — https://stackoverflow.com/q/57259126/155423

Follow along here for re-enabling: https://github.com/rust-lang/rust/issues/54878

For what it's worth I did say "can be" not "is" because I wasn't sure of the current state of this feature. I was just passing on the theory.

There are certainly other potential reasons, for instance constant expressions and generics. And, of course, the prohibited undefined behavior makes other optimizations possible, and potentially better.

Re: Rust is now overall faster than C in benchmarks

#47

Post by mlyle » Sun, Jan 03, 2021, 7:44 PM UTC

fmntf wrote: post #41

steveklabnik wrote: post #40

Earlier quoted context omitted.

I mean, you'll get drastically different numbers with all of those examples if you actually ask for options that produce small binaries. That the default flags don't try to make things small (across any of these toolchains) means this isn't really a fair comparison. The smallest "hello world" binary rustc has ever produced was 137 bytes. https://github.com/tormol/tiny-rust-executable

If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?

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.

Re: Rust is now overall faster than C in benchmarks

#48

Post by arcticbull » Sun, Jan 03, 2021, 7:44 PM UTC

jandrewrogers wrote: post #23

yudlejoza wrote: post #8

When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.

C++ is faster than C now for most things because C++ enables many optimizations that are impractical in C.

Certainly constexpr haha.

Re: Rust is now overall faster than C in benchmarks

#49

Post by Svetlitski » Sun, Jan 03, 2021, 7:46 PM UTC

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

[2] https://doc.rust-lang.org/nomicon/aliasing.html

Re: Rust is now overall faster than C in benchmarks

#50

Post by _jordan » Sun, Jan 03, 2021, 8:00 PM UTC

skohan wrote: post #24

zarkov99 wrote: post #14

Earlier quoted context omitted.

Why is that? There are cases where c++ is faster than C, a typical example is qsort vs std::sort.

How does c++ manage to win here? I'm not doubting, just curious

The constexpr specifier should give C++ an advantage