[smitherfield]

Rust is an interesting language, although I haven't really had the time to really sit down and play with it (just switched jobs to become a mobile developer while knowing no Swift/Obj-C and not much Java, so I've got my hands full for at least a few weeks).

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++. It was slightly beating C++ for a couple days, although just recently C++ took its biggest lead in a while[0]; I think they upgraded the GCC version they were using.

Anyway, I'm very curious whether it ultimately turns out that, as advertised, Rust's performance characteristics really are as good or better than C++'s[1].

[0] http://benchmarksgame.alioth.debian.org/u64q/which-programs-...

[1] The "Benchmarks Game" site very fairly specifies the algorithm that must be used for each benchmark — many of them say data must be operated on sequentially, so IMO Rust is getting a bit of an unfair advantage if the compiler is able to be particularly aggressive at autovectorizing it.

OTOH that is a nice real-world speedup, and anything else that's implemented with LLVM or GCC also has access to that optimization, so YMMV.

[sargas]

> Anyway, I'm very curious whether it ultimately turns out that, as advertised, Rust's performance characteristics really are as good or better than C++'s[1].

From my limited experience, Rust's performance is comparable to C++ throughout, with the added safety guarantees that Rust is known for.

[valarauca1]

Currently if Rust under performs C/C++ by a significant margin it's treated as a bug.

(The number crunching on benchmark game is done with SIMD which Rust is working on)

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

[igouy]

>> many of them say data must be operated on sequentially

I don't think so.