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

21–30 of 251 posts

Re: Why is Rust slightly slower than C?

#21

Post by sh1mmer »

steveklabnik wrote: post #19
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…

> (or maybe there is even a flag for this?) We specifically do not give you a flag to control this behavior, but you can choose to call different functions to use unchecked access.

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

Re: Why is Rust slightly slower than C?

#22

Post by saagarjha »

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

LLVM is a really good backend that optimizes away a lot of it. Bounds checks, for example, usually get removed.

…when possible, of course, unless you're using one of the unsafe methods.

Re: Why is Rust slightly slower than C?

#23

Post by emmericp »

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]

No, we don't run with overflow checks by default; the overflow check performance analysis is a separate test.

Re: Why is Rust slightly slower than C?

#24

Post by fluffything »

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 want to focus this on Rust, then the downside of Rust vs C here is that C has a GCC toolchain that happens to be faster for this use case, but Rust does not.

Re: Why is Rust slightly slower than C?

#25

Post by emmericp »

viraptor wrote: post #17

I wish they included rust benchmark code so we can play around and improve it. If the issue really is the bounds checks, then there are many ways to massage Rust code to make it obvious they're not needed. But it seems you can't really play with it without running on actual hardware.

Really no point to running it without real hardware, it will perform completely differently if you don't have the MMIO accesses and DMA by the NIC in there.

We'll have a VirtIO driver soon, but that's bottlenecked by the hypervisor and not really useful for performance tests.

Re: Why is Rust slightly slower than C?

#26

Post by steveklabnik »

sh1mmer wrote: post #21
steveklabnik wrote: post #19

Earlier quoted context omitted.

> (or maybe there is even a flag for this?) We specifically do not give you a flag to control this behavior, but you can choose to call different functions to use unchecked access.

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.

Re: Why is Rust slightly slower than C?

#27

Post by emmericp »

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?

Our results probably only hold true for workloads with a low IPC. The test case is also a very limited forwarder, but real network functions also have a relatively low IPC in my experience (don't have any numbers to back up this claim, though).

Re: Why is Rust slightly slower than C?

#28

Post by muricula »

grenoire wrote: post #9
wyldfire wrote: post #8

Earlier quoted context omitted.

What bloat are you referring to specifically?

I think GP forgot to build with the release flag instead of debug.

If they built with debug there would be dramatically more load/store uops than you see in the benchmark. Debug mode builds disable optimizations and store variables back to memory after most expressions to aid debugging.

Re: Why is Rust slightly slower than C?

#29

Post by NickMar »

viraptor wrote: post #17

I wish they included rust benchmark code so we can play around and improve it. If the issue really is the bounds checks, then there are many ways to massage Rust code to make it obvious they're not needed. But it seems you can't really play with it without running on actual hardware.

They have provided the code :https://github.com/ixy-languages/ixy.rs and the benchmark script : https://github.com/ixy-languages/benchmark-scripts . I found that in the readme of the repo containing the article.
Post reply on HN