[adwhit]

> I've been watching Rust on that Benchmarks Game site for a while — it's been interesting to see it go from worse than Java a year or so ago to competitive with C++

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

[igouy]

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

:and then note that the measurements were made on different OS versions, probably with different LLVM versions.

[igouy]

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

[igouy]

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

[steveklabnik]

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.