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