[bjourne]

From the looks of it, that Rust program spawns 20 threads and does the computations in parallel. The C program does it all in one thread and doesn't even utilize sse intrinsics. I know full well that The Computer Language Benchmarks Game isn't a perfect source for programming language speed arguments, but what you can you do.

[Manishearth]

So it's okay to claim Rust is slower than C by cherry picking SIMD benchmarks (rust can do simd btw, just not on stable), but not okay to claim c is slower than rust by cherry picking a parallelization benchmark? If you don't think that benchmark is fair, submit a parallel solution in C.

The benchmarks game is far from being even a useful source. It gives order of magnitude answers, and that's pretty much it. Using it (cherry-picked!) to back up a claim that Rust is 2x slower than C is disingenuous. "but what can you do" -- don't make absolute arguments about something using imprecise data.

Actual rust in real world programs may actually end up being faster than C (see Yehuda Katz's talk on fast_blank in rust). C often needs to be hand-optimized. Rust, with its zero cost abstractions, often doesn't need to be; a naive program in rust would probably be faster than the same in C.

Remember that fundamentally rust compiles the same way c does, and your rust code shouldn't have any more overhead. (except drop flags -- a minor cost -- which are something you might hand-implement in c anyway). We also use llvm, so we get mostly the same compiler optimizations.

[bjourne]

I wrote "what can you do" because you are supposed to use some modicum of common sense when reading the numbers on The Benchmark Game. E.g in one of the benchmarks PHP beats both C and Rust, so you need to apply common sense to understand that that result is an outlier.

I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust.

> rust code shouldn't have any more overhead.

But it appears that it have.

> We also use llvm, so we get mostly the same compiler optimizations.

That is not a guarantee for efficient code. For example, in my testing, g++ is over 50% faster than clang++ in certain template-heavy scenarios.

[nemothekid]

>I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust.

Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me.

In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fast as as language without a runtime running on LLVM?

Don't back up your claim with flawed benchmarks.

[igouy]

>> Don't back up your claim with flawed benchmarks.

:-)

" How fast is Rust? Fast! Rust is already competitive with idiomatic C and C++ in a number of benchmarks (like the Benchmarks Game and others)."

https://www.rust-lang.org/faq.html#performance

[igouy]

>> In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe…

Believe that those Rust programs gave those measurements, and those Go programs gave those measurements (when compiled and measured as described on the website in tedious detail).

It does matter how the programs are written!

Write better Rust implementations for those tasks and contribute them --

http://benchmarksgame.alioth.debian.org/play.html

[bjourne]

> Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me.

Actually, 2x is likely the lower bound of how much faster well-written C is over Rust. Rust developers have an interest in promoting their language so they will make sure their test programs runs as fast as possible. C doesn't need that kind of marketing.

For example, the Rust solutions were all updated in 2015 while the C solutions hasn't been touched since 2013.

> In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fast as as language without a runtime running on LLVM?

It doesn't run on LLVM. It takes advantage of LLVM to compile ELF executables. I said that common sense should be used.

[igouy]

>> For example, the Rust solutions were all updated in 2015 while the C solutions hasn't been touched since 2013.

Not true:

    Jun 02, 2016    revcomp.gcc-6.gcc
    Apr 13, 2016    fasta.gcc-7.gcc
    Sep 26, 2015    revcomp.gcc-5.gcc
    Oct 01, 2014    fannkuchredux.gcc-5.gcc
    Apr 27, 2014    fastaredux.gcc-5.gcc
    Apr 08, 2014    mandelbrot.gcc-9.gcc
    Jan 19, 2014    mandelbrot.gcc-7.gcc

(There may have been others that have subsequently been removed.)

[Manishearth]

Well, yeah, Rust hit stable in 2015. Its a new language, that's when those benchmarks were first written or fixed to work with the stable compiler.

Trust me, most of the C solutions there are very hand-optimized. Less than the rust ones in some cases.

While Rust may need that marketing, C folks have had years of time to play the benchmarks game. And there are many more C programmers than Rust programmers. I think enough effort is going into those C programs.

Like I said, in practice Rust code sometimes is faster than (otherwise it is as fast as) C code because it is easy to write the fast version using zero cost abstractions.

(the benchmarks game is a different realm of optimization, in day to day usage you do not spend that much effort eking out every last cycle; you write code that doesn't have major perf issues and use it)

[Rusky]

No, it does not appear that Rust has any overhead over C, except in cases that use SIMD. That is not a generally applicable result.

[Manishearth]

> some modicum of common sense when reading the numbers on The Benchmark Game

yes, this involves checking what the benchmarks are actually measuring. In this case, it is how much faster SIMD makes things. Factor that in, or rewrite the programs with SIMD in rust, and it should come out to be the same.

> But it appears that it have.

Have you not been listening? It doesn't. The speed differences you quote are due to simd. Rust has simd support, just not in a non-nightly compiler.

[igouy]

> Have you not been listening? It doesn't. The speed differences you quote are due to simd.

That should be easy to demonstrate!

Please quote the lines in the source-code of these fannkuch-redux and reverse-complement programs that show SIMD use --

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

[bjourne]

Using the nightly builds of any programming language in production is insane. That's why we call it FutureRust to differentiate it from what is production ready Rust.

That Rust might have SIMD intrinsics in the future matters little to people trying to seriously use Rust today. And in several benchmarks C handily beats Rust even without intrinsics. Such as the fannkuch-redux one where it is about 2x faster.

[Manishearth]

Don't use the latest nightly then. Use the nightly from 4 months ago that corresponds to today's stable, ensuring that it doesn't have any extra soundness patches that need backporting. Usually the case.

I don't see "several", I just see one. Most of the non-simd benchmarks have almost exactly the same numbers for Rust and C. Perhaps the Rust test for fannkuch isn't optimized yet (looks like the C one has some extra logic about how to split up the chunks, whereas Rust blindly parallelizes)? I already optimized one Rust program, I'm not going to sit and optimize every benchmark out there -- we have tons of counterexamples of fast benchmarks already. It seems like you won't agree as long as one nonoptimized benchmark exists. In that case, good day to you. I'm done here.

[frankmcsherry]

Yeah, given that the CPU load for the C lines are listed as

    100% 95% 95% 95%

on a quadcore, I'm going to say "not one thread".

Edit: to be helpful, rather than just obnoxious, (<3) the C version uses open mp pragmas, so it looks single-threaded.

[tatterdemalion]

You're right - for microbenchmarks, the difference between Rust and C is going to be in how the solution is implemented, because the languages have such similar performance characteristics. This is why your original comment that Rust is not as performant as C is quite silly. You look rather hypocritical turning around and pointing it out when someone links to a microbenchmark on which Rust outperforms C.

[dikaiosune]

Both examples are cherry-picked, is the point. Neither is particularly helpful in representing the whole story.

That said, Rust makes it ridiculously easy to use parallelism if a task can support it, which is a strong advantage in its favor.

[xyience]

> but what you can you do.

Not make sweeping generalizations based on one benchmark you didn't write?

[kbenson]

Well, if you are familiar enough with the languages in question, you can look for what appear to be submissions that appear to use mostly idiomatic expressions of the language. Alternatively, if you are more interested in maximum possible performance, you can confirm both are making use of advanced techniques for quicker execution, but that's probably much harder to judge.