Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Rust slightly slower than C?

github.com

Post reply on HN
Print view View original

161–170 of 251 posts

Re: Why is Rust slightly slower than C?

#161

Post by masklinn »

Omin wrote: post #151
sharpneli wrote: post #133

Earlier quoted context omitted.

”even though C++ suffers from the same aliasing flaws C has.” C no longer has them. Not since a standard that’s 20 years old (C99). restrict qualifier handles that. Unfortunately C++ committee has not included restrict in C++, but it is available in all major compilers as an extension.

restrict is so rarely used that optimizations based on non-aliasing data are broken in both major compilers. A fact which has bitten Rust repeatedly.

FWIW the last round was an issue with the interaction between noaliasing and loop unrolling (after inlining) as unrolling would fail to "split" the noalias between unrolled iteration, so it was not the noalias handling which was broken but the loop unrolling pass.

And my understanding's it's since been fixed in GCC.

I don't doubt for a second there will be new miscompilations discovered after that one's fixed though.

Re: Why is Rust slightly slower than C?

#162

Post by PrototypeNM1 »

pknopf wrote: post #110
jadbox wrote: post #80

Earlier quoted context omitted.

You're correct- what I had meant to say is Rust is smarter with more runtime checks over C for several cases, like RefCell. Therefor, Rust can be slower than C because of safety (but not because of type checking itself).

RefCell has an internal semaphore. It's used specifically for multi threaded scenarios. If someone is writing a multi threaded C app, they will likely be using semaphores as well. At least, they should be. Rust just enforces it. So, I wouldn't say rust is "slower" in the regard.

Iirc RefCell is marked !Sync, I thought Mutex was the multithreadong analog?

Re: Why is Rust slightly slower than C?

#163

Post by The_rationalist »

ShorsHammer wrote: post #87
The_rationalist wrote: post #12

Earlier quoted context omitted.

Source?

Anyone asking for "source" should be able to prove that they've not searched first. Because it's right there. As noted in the other comment it's in the literal documentation for rust. Low effort commenting is usually shunned here, yet the ever prevalent "source?" seems to get a free pass all the time. Really people should say: "source? Because I tried https://www.google.com/search?q=rustc+is+also+much+better+at... an…

Well I mostly agree when the first Google result answer the claim.

I've clicked on most links from your Google query and was not able to find something that prove Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++ Most of the links are about explicit SIMD, something that is off topic with the initial claim and something that c/c++ do far better (so many SIMD libs), and are also better at hybrid SIMD (SPMD, OpenMP 5,o penACC, etc).

"Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++" The author talk about auto vectorization. Firstly c/c++ supports AVX512 while rust do not (in stable at least) Secondly real world llvm/gcc dev are paid to improve c/c++ performance, rust performance improvements are only a side effect. And iterators in c++ are idiomatic and I see no reason why rust iterators would auto vectorize better than c++ ones. And c++ do not enforce bounds check (but allow it with at(), anyway bounds check are a totally useless concept because they slow down release performance and capture far less information for debugging than ASAN) So the initial claim is non obvious and I see no answer on the Google query. If nobody is able to prove it I will believe the claim is probably wrong.

Re: Why is Rust slightly slower than C?

#164

Post by The_rationalist »

viraptor wrote: post #16
The_rationalist wrote: post #12

Earlier quoted context omitted.

Source?

https://llogiq.github.io/2017/06/01/perf-pitfalls.html https://doc.rust-lang.org/1.30.0/book/second-edition/ch13-04...

I see no comparison about rust vs c++ performance in general nor about auto vectorization.

Re: Why is Rust slightly slower than C?

#165

Post by fluffything »

ynx wrote: post #114
fluffything wrote: post #34

Earlier quoted context omitted.

> We of course also compared gcc with clang/LLVM and found that clang was 0.8% slower, so it does not explain the difference entirely. I think it would be quite useful and interesting to figure out why there is still a small difference between clang and Rust. There might be some low hanging fruit in how Rust generates LLVM-IR that could be fixed.

doesn't it also use an older fork of LLVM rather than branching/rebasing off of master? That could account for losing out on optimizations.

The Rust toolchain distributed by the Rust project bundles an LLVM version that's very close to LLVM master. IIRC, this version has some patches on top to allow Rust to query some backend information, but I'm not sure if this information is still up-to-date.

Rust can, however, work with an external LLVM. When installing Rust through a package manager, e.g., on Linux, typical Linux distros like Debian, RH, Ubuntu, etc. configure Rust to use the system-wide LLVM binaries. So if you have Debian, and say LLVM 8.0 installed, you can just compare the installed clang 8.0 with the Rust version installed by the Linux distro.

That will not compare the "bleeding edge" clang vs Rust toolchains, but it would be a fair comparison of Clang vs Rust at a particular point in those toolchains lifes.

Re: Why is Rust slightly slower than C?

#166

Post by CodesInChaos »

Currently Rust doesn't make proper use of its aliasing rules because of bugs in LLVM. This can reduce performance of code by forcing unnecessary memory accesses. As an experiment you could try the `-Zmutable-noalias=yes` option, which should enable these optimizations (but exposes you to those bugs). See [masklynn's comment](https://news.ycombinator.com/item?id=20948779).

In general Rust suffers a bit because LLVM is primarily a C++ compiler backend. For example infinite loops without side-effects are UB in C++, but supposed to be well defined in Rust. This is even an issue for C, because `while(1) {}` is a valid in C but UB in C++. https://github.com/rust-lang/rust/issues/28728

Re: Why is Rust slightly slower than C?

#167

Post by rejschaap »

donio wrote: post #111
emmericp wrote: post #33

Earlier quoted context omitted.

Thank you for your thoughtful comment, recommended reading: https://news.ycombinator.com/newsguidelines.html (edit: thanks for editing your comment, we can have a civil discussion here) To answer your question: Yes, that particular benchmark was done with GCC and yes, it would have been better to use clang/LLVM for a more fair comparison. We of course also compared gcc with clang/LLVM and found that clang was 0.8% sl…

It could be argued that using the best available implementation for each is the more fair comparison.

That depends on the purpose of the comparison. But for many practical reasons you are right.

It makes this statement seem a bit dishonest though:

"Our Rust driver is a few percent slower than our C driver, why? Well, it's of course because of safety features in Rust, but can we quantify that?"

Re: Why is Rust slightly slower than C?

#168

Post by leni536 »

graycat wrote: post #150
monocasa wrote: post #98

Earlier quoted context omitted.

It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. And GCC at least (don't know about the others, not that this isn't true for them) has done this for decades at this point as well. Edit: Before that point, the targets that C tended focus on preferred these operations being in functions anyway.

> It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. As I read K&R, strcpy, etc., where there, in a library of external functions, as a convenience and optional for the user, and NOT part of the definition of the C language. Your YMMV. The situation definitely is "cheating": In K&R, strcpy is clearly, syntax, semantics, original implementation, an external…

The currently used C standards have no direct relationship with K&R and they define both the language and the standard library functions.

Re: Why is Rust slightly slower than C?

#169

Post by im3w1l »

wyldfire wrote: post #8
im3w1l wrote: post #3

I'm surprised how much bloat rusts adds and how little it affects the speed. Is there any other downside? Electricity consumption / heat? Evicting other stuff from cache?

What bloat are you referring to specifically?

I'm referring to the table in the article.
Post reply on HN