[valarauca1]

This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has.

On non-SIMD tasks Rust/C are neck and neck https://benchmarksgame.alioth.debian.org/u64q/rust.html

You're just cherry picking benchmarks. In the cases you care about raw number crunching power you'll likely be using a GPU not SIMD instructions as CPU's are roughly 3-4 orders of magnitude slower then GPU's at pure number crunching tasks.

Not that SIMD isn't important as it's instructions also cover things like AES, SHA1/2, Random numbers, Cache pre-loading/evacuation, memory fences, and fast loading paths. But so few programmers worry about these things you are really hitting a niche market.

[quickben]

GPUs aren't panacea. Such generalizations are wrong and will have you rearchitecture approaches after GPU io bottlenecks.

[valarauca1]

>GPUs aren't panacea. Such generalizations are wrong

This is true. But if you are doing hard number crunching you are using a GPU once you exhaust what a CPU can do. And most the time before you even touch SIMD as it's only a 4-8x speed up, while a GPU is 1000-10,000x.

>will have you rearchitecture approaches after GPU io bottlenecks.

90% of these are caused by bad software. Either using legacy API's. Or by writing code that forces GPU's to talk to processor more often then is necessary.

PCIe bandwidth is ~7.88GB/s [1] on modern Intel Chips (post 3xxx series). Compute GPU's often offer >10GB of on-board RAM. With last generations flag ships over a staggering 32GB of on-board RAM.

And if you are hitting a wall with GPU compute/IO limits, CPU SIMD instructions aren't going to help you in the slightest.

[1] http://www.tested.com/tech/457440-theoretical-vs-actual-band...

[tbirdz]

It's not the bandwidth that's the problem, it's the latency. Many problems need more control flow and branching, and that is better done on the CPU. If you need to make decisions and take the previous iterations output as an input, then the overhead of transferring the data back and forth from cpu to gpu outweighs the benefit of the gpu speed.

GPUs are good if you have an independent data parallel algorithm you are using to transform large blocks of floating point data. For other uses, CPU is better.

[bjourne]

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has.

Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clang 3.6.2/gcc 5.2.1 vs Rust 1.9.0 since language performance is very implementation dependent.

> On non-SIMD tasks Rust/C are neck and neck https://benchmarksgame.alioth.debian.org/u64q/rust.html

In 5 of 10 benchmarks, C is twice as fast as Rust. In one of the benchmarks where it is neck and neck, like pidigits (https://benchmarksgame.alioth.debian.org/u64q/performance.ph...) it appears to be so because both the C and the Rust variant are wrapping libgmp. GMP is written in C.

[valarauca1]

>In 5 of 10 benchmarks, C is twice as fast as Rust

fannkuch-redux why? SIMD

fasta-redux why? SIMD

spectral-norm why? SIMD

reverse-complement why? SIMD

N-Body why? Oh you guessed it SIMD

Seriously read the source code. Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why. All 5 of these tests boil down to raw FLOPS. Which C/C++ having access to SIMD instructions wins at.

The fact that Rust/C performance difference works out to just the ability to emit vector instructions says a lot about everything else in Rust. The fact that Rust can dereference, pass variables on the stack, call functions, and make decisions as fast as C renders your core point completely moot.

You are just being incredibly pedantic for no reason. And your argument holds no water. Everything Rust does is identical to C except one barely used corner case. They use the exact same model for computation, they both live in the Cee-LangVM. Post compilation they are functionally identical (except Rust makes stack manipulation easier).

Does any of that make sense to you?

:.:.:

Also Rust/C both calling the GMP without a time difference is a good thing. The Rust->C FFI is literally non-existent in practice. Dipping into C code from Rust (and vice versa) has no penalty. The same can't be said for HUNDREDS of languages.

[bjourne]

Rust is also slower in binarytrees, regexdna and fasta. SSE is not one "barely used corner case" because huge amounts of performance critical code takes advantage of it.

Edit: To explain why I don't believe you when you say that "Post compilation they are functionally identical [in performance]" is because if it were so, you would just transliterate the C solutions to the Rust equivalents and it would run as fast as C. Since that hasn't been done and is trivial to do, my conclusion is that it doesn't lead to the same performance.

[burntsushi]

Did you know Rust was quite a bit faster than C in regexdna merely a few months ago? It didn't get slower because of Rust. The algorithms employed are radically different. My hope is that the regex library has already regained performance, but until the benchmark game is updated (which is on us, not the benchmark game maintainer), I suppose we'll have to suffer the pedants!

Or perhaps, you might look at single threaded performance and wonder, maybe there is something more interesting going on than a naive surface analysis of C vs. Rust! :-) https://benchmarksgame.alioth.debian.org/u64/rust.php

And by the way, transliterating a regex library isn't trivial. I invite you to transliterate Tcl's regex library. Let me know how that goes. ;-) So I think your reasoning is specious at best.

[igouy]

> It didn't get slower because of Rust.

Do you mean the program became relatively slower because of changes you've made to the regex crate?

Wasn't the program relatively faster because you wrote the regex crate to use Aho-Corasick for the matches required by the regex-dna task?

[burntsushi]

> Do you mean the program became relatively slower because of changes you've made to the regex crate?

Yes. The underlying reasoning is complex. When the regex crate got a lazy DFA (similar to the one used by RE2), the vast majority of regexes got significantly faster. Some got slower. This one in particular from regex-dna:

    >[^\n]*\n|\n

Before the lazy DFA, compile time analysis would notice that all matches either start with `>` or `\n` and do a fast prefix scan for them. Each match of `>` or `\n` represents a candidate for a match. Candidates were then verified using something similar to the Thompson NFA, which is generally pretty slow, but the prefix scanning reduced the amount of work required considerably.

Once the lazy DFA was added, the prefix scanning was still used, but the lazy DFA was used to verify candidates. It's faster in general by a lot, but, the lazy DFA requires two scans of the candidate: one to find the end position and another to find the start position. That extra scan made processing this regex (on the regex-dna input) slightly slower.

I've since fixed some of this by reducing a lot of the match overhead of the lazy DFA, so my hope is that it's back to par, but I haven't done any rigorous benchmarking to verify that.

> Wasn't the program relatively faster because you wrote the regex crate to use Aho-Corasick for the matches required by the regex-dna task?

Aho-Corasick is principally useful for the second phase of regex-dna, e.g., the regexes that look like `ag[act]gtaaa|tttac[agt]ct`. (In the last phase, all the regexes are just single byte literals, so neither Aho-Corasick nor the regex engine should ever be used.) Performance here should stay the same.

On that note, I have a new nightly-only algorithm called Teddy that uses SIMD[1] (which replaces the use of Aho-Corasick for those regexes) and is a bit faster. I got the algorithm from the Hyperscan[2] project, which also does extensive literal analysis to speed up regexes.

To clarify, this optimization is generally useful because a lot of regexes in the wild have prefix literals. Even something like `(?i:foo)\s+bar` can benefit from it, since `(?i:foo)` expands to FOO, FOo, FoO, Foo, fOO, fOo, foO, foo, which can of course be used with Aho-Corasick (and also my new SIMD algorithm).

One also must wonder how well a C program using PCRE2's JIT would fair on the benchmarks game. From my experience, it would probably be near the top. It's quite fast!

[1] - https://github.com/rust-lang-nursery/regex/blob/master/src/s...

[2] - https://github.com/01org/hyperscan

[igouy]

Please don't point people to u64 -- it's no longer updated. (Note the rustc version.)

[Manishearth]

Slower by a tiny amount, and still faster than other C implementations. It's within the error box.

Also iirc there are improvements to those benchmarks in the pipeline, idk what happened to them (Veedrac and llogiq had something in mind).

Sure, you could hand-translate C in many cases (not regex), but that would be far from idiomatic. Most of the rust solutions try to still look Rust-y.

Regarding sse, if you care about performance and sse use a nightly compiler. That option exists. Rust nightly is still Rust.

[valarauca1]

You can also just bundle Rust w/ LLVM and have it JIT compile your application on start up which'll yield huge performance gains too.

But people may get salty about binary image size.

[igouy]

>> Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why.

Because the benchmarks game shows some programs to be faster, and you agree those programs actually would be faster? :-)

>> All 5 of these tests boil down to raw FLOPS.

Where exactly are the floating-point operations in fannkuch-redux Rust #2 program ?

Where exactly are the floating-point operations in reverse-complement ?

("Seriously read the source code" ?)

[igouy]

>> fannkuch-redux why? SIMD

Look how many other programs, written in various languages, are shown ahead of the fannkuch-redux Rust #2 program.

Maybe you can write a better Rust fannkuch-redux program (even without SIMD).

[Rusky]

Nightly Rust is also "currently released and available," and a significant part of the ecosystem can take advantage of it.

Besides, the vast majority of the work to close the gap between C and Rust in the benchmark game was from people optimizing the benchmarked programs, not from any language or compiler changes. There is no inherent 2x slowdown in any meaningful sense.

[valarauca1]

The inherent 2x slow down just works out to `__m128` vs `f64`. C can double Rust's FLOP thought-put.

The fact function calls, if statements, passing variables to functions is identical speed to C is lost on the parent poster. These core points prove the Rust/C are equal speed.