Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

51–60 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#51

Post by alerighi »

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.

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 used in all the embedded applications where you have ridiculous low power microcontrollers and you must squeeze out the best performance.

That is the difference between C and Rust to me: for each fast Rust program you are guaranteed that you can write an equivalent performant program in C (or assembly). Worst case scenario you use inline assembly in C and you get that.

Thus the contrary cannot be true for Rust: if I give you a heavily optimized C program not always you can produce an equivalent version in Rust.

Also not always these optimizations are what you want. In C you can choose the level of optimizations, and most of the time, at least on the program that I write, I choose a low level of optimization. The reason is that a lot of time performance is not the only thing that matters, but it maybe matters most the stability of the code (and a code compiler with optimizations is more likely to contain bugs) or the ability to debug (and thus the readability of the assembly output of the compiler).

Rust gives out an horrible assembly code, that is impossible to debug, or to check for correctness. You just have to hope that the compiler doesn't contains bugs. For the same reason Rust is the ideal language to write viruses, since it's difficult to reverse engineer.

Re: Rust is now overall faster than C in benchmarks

#52

Post by FartyMcFarter »

kzrdude wrote: post #6

Rust seems to be using parallelism better. In one benchmark though (fasta), C gcc is using all 4 cpus and Rust only two, and still wins. (Looking at just C gcc vs Rust) https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The C version uses OpenMP, while the Rust version doesn't.

I tried running the C code with 2 and 4 threads, wall-time and CPU time don't change much in either case which is strange (this is cygwin with gcc 10.2.0):

2 threads:

  $ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -march=ivybridge -fopenmp fasta.c -o fasta.gcc-2.gcc_run && time ./fasta.gcc-2.gcc_run 25000000 | md5sum
  fd55b9e8011c781131046b6dd87511e1 *-

  real    0m0.724s
  user    0m1.468s
  sys     0m0.108s
4 threads:

  $ /usr/bin/gcc -pipe -Wall -O3 -fomit-frame-pointer -march=ivybridge -fopenmp fasta.c -o fasta.gcc-2.gcc_run && time ./fasta.gcc-2.gcc_run 25000000 | md5sum
  fd55b9e8011c781131046b6dd87511e1 *-

  real    0m0.670s
  user    0m1.514s
  sys     0m0.046s

Re: Rust is now overall faster than C in benchmarks

#53

Post by stabbles »

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.

Re: Rust is now overall faster than C in benchmarks

#54

Post by mrec »

londons_explore wrote: post #43
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...

I'm curious, what platforms support 4K output but don't have any kind of GPU?

Re: Rust is now overall faster than C in benchmarks

#55

Post by FartyMcFarter »

nynx wrote: post #9

The fastest n-body program is written in very idiomatic rust. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

n-body in C compiled by clang runs just as fast as Rust apparently:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Rust is now overall faster than C in benchmarks

#56

Post by pjmlp »

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…

People think C is an high level Assembler, that was only true on PDP-11, 8 and 16 bit CPUs.

Also in C you cannot retrofit restrict in existing programs, specially they depend on existing binary libraries.

Re: Rust is now overall faster than C in benchmarks

#57

Post by pjmlp »

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?

Just like C compilers, it is a matter of use case, and compiling for size has tradeoffs regarding execution speed.

Re: Rust is now overall faster than C in benchmarks

#59

Post by guenthert »

coldtea wrote: post #37
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.

> I know I can safely ignore such benchmark. C++ makes certain intentions clear to the compiler in ways that C doesn't, which makes certain optimizations possible.

That has always been the case, but it appears that the GNU compiler finally makes good on that promise. Kudos to all involved!

Re: Rust is now overall faster than C in benchmarks

#60

Post by vvanders »

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.

Have you ever used restrict in anger?

I've done it when we really needed that performance for an inner loop(particle system). It can be a real bastard to keep the non-alias constraint held constant in a large, multi-person codebase and the error cases are really gnarly to chase down.

Compare that to Rust which has this knowledge built in since it naturally falls out of the ownership model.

Post reply on HN