Perhaps smitherfield actually was talking about the overall relative performance of "Rust [programs] on that Benchmarks Game site".
To say something about whether Rust-the-language-implementation was building faster executables wouldn't we compare the same Rust programs built with different Rust versions (not compare Rust programs against Java or C++ programs).
Match-up measurements of the same programs, from the 1st June 2015 and 1st June 2016 data files, like this:
elapsed secs program id
4.013 => 3.780 binarytrees #1
15.449 => 16.650 fannkuchredux #2
5.204 => 5.588 fasta #1
0.070 => 0.067 meteor #1
0.050 => 0.044 meteor #2
24.630 => 24.068 nbody #1
1.733 => 1.743 pidigits #1
436.686 => 288.131 threadring #1
>> artificial
Perhaps you wish to draw our attention to the question of "ecological validity"?
http://benchmarksgame.alioth.debian.org/why-measure-toy-benc...
http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...
>> It's just that a few dedicated people decided to try to win the benchmarks game strictly for PR purposes [0]. <<
Perhaps you should check if the programs mentioned in that blog post are actually shown on the benchmarks game website :-)
(Also check if those tasks contribute to the summary comparisons and charts.)
Re:Path to Rust – A practical introduction
by steveklabnik on Wednesday June 01, 2016 @09:11PM
(#11819642)
In general, safe code should t always be slower than unsafe; as said below, if stuff is slower, it's a bug. The relationship is more complex than unsafe == faster.
To be clear, Rust-the-language has not sped up significantly in the past year. It's just that a few dedicated people decided to try to win the benchmarks game strictly for PR purposes [0].
Chances are, for very algo-heavy (i.e. unrealistic) workloads, there are two ways to write it in Rust - fast and safe or very fast and unsafe. (e.g. one can disable bounds checking and get maybe a 2% speedup).
All this really serves to show is how artificial the benchmarks are.
[0] https://llogiq.github.io/2015/10/03/fast.html