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

71–80 of 251 posts

Re: Why is Rust slightly slower than C?

#71

Post by jadbox »

andolanra wrote: post #57
maxk42 wrote: post #44

The two biggest factors involved are (1) Runtime. Even though C has "no" runtime, there is some runtime overhead: Variable allocation / de-allocation and alignment. Function invocation / call stack setup. Et cetera. I don't know enough about Rust to understand what its exact "runtime" is like, but I'd bet it's not exactly like C. (Rust is strongly-typed, is it not? Does it do run-time type-checking?) Exception handli…

Others have pointed out that Rust's type-checking is all done at compile time. Rust also does not have exception handling. To be more specific: errors in Rust are either propagated by function return values (usually in the form of `Result` or `Option` types) which do not require any kind of runtime support, or by panicking, which unwinds the stack for clearing-up of resources and then halts the running thread. (Panic…

AFAIK, some Rust types are checked at runtime. For example, RefCell:

"Because RefCell allows mutable borrows checked at runtime, you can mutate the value inside the RefCell even when the RefCell is immutable."

*source https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (like RefCell).

Re: Why is Rust slightly slower than C?

#72

Post by ridiculous_fish »

hcs wrote: post #5
gameswithgo wrote: post #2

I wonder if some of the bounds checks could be eliminated by using iterators instead of loops? It is common when coming from C to Rust to sometimes avoid complicated iterators because you imagine it can't be fast, so you use a loop, but usually the iterator really is faster. And I believe the checked math can be eliminated just by explicitly stating you want to use unchecked math. It doesn't require unsafe to do so.

Integer overflow checks are disabled by default in release builds, the author noted they were explicitly enabled in this project for additional safety. (This is just for the normal operators, if you use e.g. checked_add() or wrapping_add() then you can be explicit about what behavior you want.) [edit: oops, the overflow checks were only enabled for a separate test, see note from the author below]

It's worth observing that signed integer overflow is undefined in C but defined in Rust, which can impose an additional cost.

C: https://godbolt.org/z/CDha8-

Rust: https://godbolt.org/z/DlN3uf

Re: Why is Rust slightly slower than C?

#73

Post by lallysingh »

tom_mellior wrote: post #15

Looking at performance counter data is good, but I would have liked to see a real validation of the hypothesis that bounds checking is to blame for the extra branches and instructions. That is, modify the Rust compiler to not emit bounds checks (or maybe there is even a flag for this?) and look at performance and counters. I would imagine that this would bring the data for Rust to pretty much the same as C. But other…

Is there a disassembly to compare? I'd rather just check.

Re: Why is Rust slightly slower than C?

#74

Post by userbinator »

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?

In general, the effect of bloat is not visible in benchmarks like these where the goal is to run something small many many times, with ample memory available, and as little else on the system adding noise to the results as possible. It's the same reason you see "Java is faster than C" benchmark results, yet everyone knows how the former actually performs in practice.

The effects of larger memory usage don't become obvious until other applications start contending for it and/or swapping happens, and it's conveniently also something that is not as easily blamed on one application "being slow", which is why it doesn't receive nearly as much attention as it should.

Re: Why is Rust slightly slower than C?

#75

Post by ncmncm »

C is the wrong language to compare to. More precisely, Rust should be able to beat C, routinely. Presumably it will, when it gets more optimizer attention. With any luck, that improvement can go into LLVM proper, and speed up many other languages besides.

Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume any pointer-to-const might be use to write through. Because alias analysis is ironclad, copies can be elided even if some function borrows a reference to the copy.

At a larger scale, improved abstraction tools mean more powerful libraries may be written and used, that would be unavailable to the C coder.

It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task.

This is why articles about other languages comparing them to some fraction of C performance are amusing. C is a low bar. If you can't beat C, you are Doing It Wrong. In Rust's case, that would be "still doing it wrong"; we may assume fixing this is on the schedule, after various "getting it right" and "compiling faster" goals are met.

Re: Why is Rust slightly slower than C?

#76

Post by codesushi42 »

ncmncm wrote: post #75

C is the wrong language to compare to. More precisely, Rust should be able to beat C, routinely. Presumably it will, when it gets more optimizer attention. With any luck, that improvement can go into LLVM proper, and speed up many other languages besides. Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume an…

It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task.

That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++ when compared to C.

Rust has optimization issues of its own apparently.

C isn't a low bar. It is the benchmark.

Re: Why is Rust slightly slower than C?

#77

Post by freejulian85 »

ncmncm wrote: post #75

C is the wrong language to compare to. More precisely, Rust should be able to beat C, routinely. Presumably it will, when it gets more optimizer attention. With any luck, that improvement can go into LLVM proper, and speed up many other languages besides. Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume an…

I didn’t realize it was possible to be so wrong.

Re: Why is Rust slightly slower than C?

#78

Post by pknopf »

jadbox wrote: post #71
andolanra wrote: post #57

Earlier quoted context omitted.

Others have pointed out that Rust's type-checking is all done at compile time. Rust also does not have exception handling. To be more specific: errors in Rust are either propagated by function return values (usually in the form of `Result` or `Option` types) which do not require any kind of runtime support, or by panicking, which unwinds the stack for clearing-up of resources and then halts the running thread. (Panic…

AFAIK, some Rust types are checked at runtime. For example, RefCell: "Because RefCell allows mutable borrows checked at runtime, you can mutate the value inside the RefCell even when the RefCell is immutable." *source https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (l…

That isn't "type checking", that is just a guard to prevent simultaneous writes to the same data.

Re: Why is Rust slightly slower than C?

#79

Post by jeremyjh »

codesushi42 wrote: post #76
ncmncm wrote: post #75

C is the wrong language to compare to. More precisely, Rust should be able to beat C, routinely. Presumably it will, when it gets more optimizer attention. With any luck, that improvement can go into LLVM proper, and speed up many other languages besides. Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume an…

It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task. That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++…

Is there really a performance cost from RAII? Presumably whatever a destructor has to do to release resources, C code would also have to do.

Re: Why is Rust slightly slower than C?

#80

Post by jadbox »

pknopf wrote: post #78
jadbox wrote: post #71

Earlier quoted context omitted.

AFAIK, some Rust types are checked at runtime. For example, RefCell: "Because RefCell allows mutable borrows checked at runtime, you can mutate the value inside the RefCell even when the RefCell is immutable." *source https://doc.rust-lang.org/book/ch15-05-interior-mutability.h... EDIT: Sorry, I don't mean 'runtime type checks' are slowing down Rust, but rather that Rust performs more general runtime safety checks (l…

That isn't "type checking", that is just a guard to prevent simultaneous writes to the same data.

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).
Post reply on HN