Hacker News new | ask | show | jobs
by bjourne 3662 days ago
> 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.
2 comments
igouy 3662 days ago
>> 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.)
link
Manishearth 3662 days ago
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)

link