hi
why rust 1.47.0 version is faster than 1.48.0 version ?
what are you doing?
What do you mean by slow?
Slower at compiling? If so, compiling what?
Slower at running something? If so, running what?
2 Likes
when i saw this site
rust was in 1.47 version and rust was faster than c in six topics and c was faster in four but now rust is in 1.48 version and rust is faster than c in three topics and and c is faster in seven, but why?
1 Like
No idea. Too many variables.
If you are going to open a discussion with "1.47.0 version is faster than 1.48.0 version" one would expect it is something you have done that got slower. Preferably with evidence, bench marks, of Rust 1.47.0 vs 1.48.0 on that task.
I do wish the benchmarkgames site would not call gcc "c" in their table headings. Where as they have "vs clang" as if that is something other than "c".
I think the comparison of Rust vs Clang is better, seeing as they both use LLVM as the optimizers/backend/code generators.
In that table I see Rust is fastest in 2 cases, C is fastest in 2 cases, and the others are so close I´m not even going to take them into consideration.
Back in their "vs gcc table" I see Rust is fatser in 3 cases, C is faster in 2 and again 3 case are so close I´m not going to worry about them.
All in all I´m not sure your assertion is correct and it looks like Rust is doing very well.
10 Likes
Usually, when C is faster, it's one of the following cases:
goto- no-alias optimization, which Rust does currently not take advantage of
- C version has UB
The measurement info site doesn't mention how programs were compiled. Rust in particular could easily be compiled with 2 different options, one taking advantage of the native CPU capabilities and one which doesn't. There's also a small problem space, that does require unsafe to get the maximum performance out of a Rust program. I'd expect Rust versions have been written with only the std library and no unsafe. At that point, I consider being (almost) as fast as C a win for Rust.
1 Like
hey, i don't want to compare rust with other programming language
i want compare it with older versions of rust
this is a older version of rust :
you can see in binary-treest rust did that in 1.20 seconds and now in 2.37
in mandelbrot older version did that in 0.92 seconds and now in 0.99
and in k-nucloetide older version did that in 2.46 but now in 2.76
and i'm saying : why older versions of rust are faster than 1.48?
4 Likes
Looks like the poorest performing Rust example there is regex-redux. Which I find a bit problematic.
Firstly it is heavily dependent on regular expressions. It pcre2 is used in the C version, the regex crate for Rust.
Secondly the entries are parallelized, OpenMP is used with C, crossbeam for Rust.
As such we we end up bench marking external libraries rather than Rust itself. (I´m not even sure I count OpenMP as even being C anymore, the C standards say nothing about it)
hey you didn't understand what I meant.
i said i don't want to compare rust with other programming language like C,C++,...
i want to compare rust with older versions of it.
you are right.
but the same code that used in 1.48.0 is used in the older versions like 1.47.0 ,
but why 1.47.0 is faster than 1.48.0?
this is my question.
1 Like
If you are really interested, you can make your own reproduction, with timings produced by Rust 1.47 and 1.48, using the same code on the same machine, and, if there's really any statistically relevant difference (i.e. this is not a glitch in BenchmarksGame's timings), you can even trace the regression down to exact change in the compiler.
4 Likes
Yes but you made your point by linking us to a page of Rust vs C results rather than Rust vs Rust results.
1 Like
It is not. Anyone who says otherwise is misleading you.
Out of curiosity I just built the slowest performing example (vs C that is), regex-redux, with both Rust 1.47 and the current nightly. Here are the results:
$ cargo +1.47.0 build --release
Finished release [optimized] target(s) in 0.06s
$ time ./target/release/regex-redux-rust < input5000000.txt
agggtaaa|tttaccct 356
[cgt]gggtaaa|tttaccc[acg] 1250
a[act]ggtaaa|tttacc[agt]t 4252
ag[act]gtaaa|tttac[agt]ct 2894
agg[act]taaa|ttta[agt]cct 5435
aggg[acg]aaa|ttt[cgt]ccct 1537
agggt[cgt]aa|tt[acg]accct 1431
agggta[cgt]a|t[acg]taccct 1608
agggtaa[cgt]|[acg]ttaccct 2178
50833411
50000000
27388361
real 0m1.563s
user 0m1.594s
sys 0m0.328s
$ cargo +nightly build --release
$ time ./target/release/regex-redux-rust < input5000000.txt
agggtaaa|tttaccct 356
[cgt]gggtaaa|tttaccc[acg] 1250
a[act]ggtaaa|tttacc[agt]t 4252
ag[act]gtaaa|tttac[agt]ct 2894
agg[act]taaa|ttta[agt]cct 5435
aggg[acg]aaa|ttt[cgt]ccct 1537
agggt[cgt]aa|tt[acg]accct 1431
agggta[cgt]a|t[acg]taccct 1608
agggtaa[cgt]|[acg]ttaccct 2178
50833411
50000000
27388361
real 0m1.549s
user 0m1.516s
sys 0m0.406s
Such rude and crude timing has a lot of variance but those are about the fastest numbers on my 8 year old x86-64 box.
Looks the same to me.
I notice there are a lot of build errors for the different versions of several programs, mostly to do with rayon. IIUC the Benchmarks Game only takes the fastest version of each one when rendering comparisons (i.e., the fastest Rust version of regex-redux vs. the fastest gcc version of regex-redux). So maybe (for some of these programs) there was a faster Rust version that worked for 1.47 but no longer works in 1.48?
With more curiosity I compared to the regex-redux in C. My best time was:
$ gcc -pipe -Wall -O3 -fomit-frame-pointer -fopenmp regexredux.c -o regexredux -lpcre2-8
$ time ./regexredux < input5000000.txt
agggtaaa|tttaccct 356
[cgt]gggtaaa|tttaccc[acg] 1250
a[act]ggtaaa|tttacc[agt]t 4252
ag[act]gtaaa|tttac[agt]ct 2894
agg[act]taaa|ttta[agt]cct 5435
aggg[acg]aaa|ttt[cgt]ccct 1537
agggt[cgt]aa|tt[acg]accct 1431
agggta[cgt]a|t[acg]taccct 1608
agggtaa[cgt]|[acg]ttaccct 2178
50833411
50000000
27388361
real 0m1.075s
user 0m2.172s
sys 0m0.281s
Sadly Rust is 44% slower here.
But that is a lot better than the 72% slowdown that thebenchmarkgame is reporting!
It looks like the Rayon library was not fully updated correctly after the benchmarksgame site upgraded to Rust 1.48, which broke all the Rust programs that depend on Rayon. This means that some of the fastest Rust programs are not included in the Rust 1.48 benchmarks. I'm working with the developer of the site to fix this.
In other words, the Rust programs didn't get any slower, but the new comparison is using different Rust programs than the old one.
33 Likes
This has now been fixed:
14 Likes
The benchmarks game website does tell you how programs were compiled and run, for example:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-rust-5.html#log
1 Like
Was reading this thread, just commenting to say thank you.
Thanks @mbrubeck for looking into this!
1 Like
For future reference, our Perf site is a good way of keeping up with the current state of the compiler speed. We are not always getting faster, but that's the overall intent and long term trend.
6 Likes
For what it’s worth, at my company we have a Tokio based tcp server project, and we also noticed sizeable runtime performance degradation. Unfortunately I can’t pay paste a link to the the repo, but this probably isn’t an isolated incident.
Again, there was no performance degradation in the benchmarks game programs; there was only a problem in the build script that temporarily stopped some of them from building. Now that they are all compiled with Rust 1.48, they are performing just as fast as with 1.47.
4 Likes