4 ms·

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

by adwhit 10y ago

> 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 https://llogiq.github.io/2015/10/03/fast.html

steveklabnik 10y ago
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.
igouy 10y ago
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 10y ago
>> artificial Perhaps you wish to draw our attention to the question of "ecological validity"? http://benchmarksgame.alioth.debian.org/why-measure-toy-benchmark-programs.html http://benchmarksgame.alioth.debian.org/why-measure-toy-benc... http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html#ultimate-benchmark http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...
igouy 10y ago
>> 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.)

by adwhit 10y ago

steveklabnik 10y ago

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.

igouy 10y ago

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 10y ago

>> artificial Perhaps you wish to draw our attention to the question of "ecological validity"? http://benchmarksgame.alioth.debian.org/why-measure-toy-benchmark-programs.html http://benchmarksgame.alioth.debian.org/why-measure-toy-benc... http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html#ultimate-benchmark http://benchmarksgame.alioth.debian.org/dont-jump-to-conclus...

igouy 10y ago

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