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

131–140 of 251 posts

Re: Why is Rust slightly slower than C?

#131

Post by masklinn »

eximius wrote: post #11
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?

Unless/until a lot more is written in Rust... not much. It uses slightly more base RAM to load the binary. Some of the bloat is things that in C programs would be dynamically linked in - it isn't that Rust is doing more, it's that C gets to share a lot of stuff and Rust has to bring it's own.

> It uses slightly more base RAM to load the binary.

It's mostly vmem until / unless the data actually gets used though, no?

Re: Why is Rust slightly slower than C?

#132

Post by kzrdude »

013a wrote: post #42
fluffything wrote: post #24

Because C is slower than C. That is, they are compiling C with GCC, but Rust uses LLVM as a backend. Compiling their C code with clang reveals that it is also slightly slower than the C code compiled by GCC, but not faster than Rust. The actual conclusion here is that the GCC toolchain is slightly faster than the LLVM toolchain for this particular use case, but that isn't really news - it happens all the time. If one…

Yeah, their initial explanation is that its the "safety features", but I was under the impression that literally everything related to rust's safety happens at compile time. Their big selling point is the "zero cost abstractions".

It's never claimed that every abstraction in Rust is zero cost. Just that these are often possible.

Re: Why is Rust slightly slower than C?

#133

Post by sharpneli »

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…

”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.

Re: Why is Rust slightly slower than C?

#134

Post by tom_mellior »

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

Can you point us to a concrete benchmark to illustrate this?

Re: Why is Rust slightly slower than C?

#135

Post by kzrdude »

ncmncm wrote: post #129
xigency wrote: post #107

Earlier quoted context omitted.

Is there an element of runtime correctness and safety as well? Are we comparing programs that have proper bounds checking to ones that don't?

One hopes that the optimizer has arranged to check the bounds at the start of the loop, and not in it. Apparently Rust's doesn't, yet, but it seems usually to happen to overlap the checking it does with other stalls, so it might not usually matter much.

The actual bounds checking instructions are often negligible in terms of overhead, but it can inflict damage by inhibiting other optimizations and loop optimizations, like reduction or vectorization.

Re: Why is Rust slightly slower than C?

#136

Post by masklinn »

andrepd wrote: post #83

Newbie to rust, but surely there must be a way to disable bounds checking in rust, right?? Like C++ std::vector has operator() (bounds checked) and operator[] (pointer dereference, unsafe), or other languages have get/unsafe_get (ocaml), surely rust has a way to disable bounds checking as well (or disables it for optimised builds)

> Newbie to rust, but surely there must be a way to disable bounds checking in rust, right??

There's an unsafe method to not do bounds-checking, keeping in mind that indexing outside the collection is UB. It's usually a better idea to e.g. use iterators, or try and nudge the optimiser towards removing the bounds checks.

> disables it for optimised builds

A compiler flag to add UBs to a valid (though not correct) program is not considered a great idea by the rust team.

Re: Why is Rust slightly slower than C?

#137

Post by jzoch »

jnordwick wrote: post #117
steveklabnik wrote: post #102

Earlier quoted context omitted.

You're mis-understanding what "you don't pay for what you don't use" means. It means that a program that does not contain [] in it does not include code for []. There's no "mandatory runtime" code for []. It doesn't mean you can use [] in some special way and somehow get less code. And even if we were talking about your understanding, I don't see why get_unchecked would be disqualified. unsafe is a part of the langua…

I know, the meaning of "zero cost abstraction" is really "zero cost to not use the abstraction." But that's like saying if you don't use rust you don't pay for it. Just because there is the unsafe escape hatch in the language, you don't get to label the language as zero cost abstraction. Because practically speaking there is a lot more runtime cost to rust than people will tell you. Many langauges (almost anything wi…

What languages dont have a runtime? Even C has one (albeit a very small one). Nobody labels Rust the language as a zero cost abstraction (thatd be silly - there is a cost to learning it!). Rather, they try to provide zero cost abstractions. A great example is that there are no green threads in rust because they consciously removed them as they penalized rust performance regardless of whether said people used green threads or not.

Re: Why is Rust slightly slower than C?

#138

Post by masklinn »

didibus wrote: post #69

Would be nice to also see why Java is slower than C# and Go.

https://www.reddit.com/r/programming/comments/d2pku3/a_highs...

> We are at ~20 bytes of allocation per forwarded packet in Java.

C# and Go have much better facilities to avoid heap allocations.

Re: Why is Rust slightly slower than C?

#139

Post by celrod »

steveklabnik wrote: post #26
sh1mmer wrote: post #21

Earlier quoted context omitted.

I'm curious if there is a discussion thread on that design choice.

I’m not 100% sure if there’s a source exactly, but we don’t like safety and correctness to depend on what flags you pass or do not pass. We don’t offer a fast-math flag either for similar reasons. The odd one out is overflow, and that’s only because it’s well defined (a “program error”) and not UB to overflow in Rust. This gets checked in debug but not currently release, though the spec allows for it.

What do you think of Julia's macro-based approach? That is, there are `@inbounds` and `@fastmath` macros that turn off bounds checking/enable fast-math flags in the following expression. `@fastmath` works simply by swapping functions (eg `+`) with versions (eg, `Base.FastMath.add_fast`) that have the appropriate llvm flags. When testing Julia libraries, all `@inbounds` are ignored (ie, it'll emit bounds checks anyway).

I assume it's already possible for a user to similarly implement `inbounds!` and `fastmath!` macros in Rust to substitute `[]` for `.get_unchecked()`, etc. (I haven't checked if there are already crates.) But it sounds like it should be easy enough for folks to check performance sensitive regions this way (in particular, loops that may need these flags to vectorize).

Re: Why is Rust slightly slower than C?

#140

Post by ncmncm »

kzrdude wrote: post #135
ncmncm wrote: post #129

Earlier quoted context omitted.

One hopes that the optimizer has arranged to check the bounds at the start of the loop, and not in it. Apparently Rust's doesn't, yet, but it seems usually to happen to overlap the checking it does with other stalls, so it might not usually matter much.

The actual bounds checking instructions are often negligible in terms of overhead, but it can inflict damage by inhibiting other optimizations and loop optimizations, like reduction or vectorization.

Low-hanging fruit. But there are still bigger fish to fry.

Lower-hanging bigger fish?

Rust isn't mature yet. Give it ten years. It will either exceed C performance, or fade away. It's still too early to say which.

Post reply on HN