Why is Rust slightly slower than C?
github.com
Why is Rust slightly slower than C?
1–10 of 251 posts
Re: Why is Rust slightly slower than C?
#2I 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.
Re: Why is Rust slightly slower than C?
#3I'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?
Re: Why is Rust slightly slower than C?
#4I 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.
>I wonder if some of the bounds checks could be eliminated by using iterators instead of loops
It can and often is. Don't use [] to index into data if you can afford not to. Anecdotally, rustc is also much better at generating SIMD-friendly code with iterators than idiomatic C/C++, but that depends largely on what you're doing.
Re: Why is Rust slightly slower than C?
#5I 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]
Re: Why is Rust slightly slower than C?
#6> Our Rust driver is a few percent slower than our C driver
Please qualify the title: it's not generally the case.
Re: Why is Rust slightly slower than C?
#7I'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.
Re: Why is Rust slightly slower than C?
#8I'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?
Re: Why is Rust slightly slower than C?
#9Re: Why is Rust slightly slower than C?
#10I'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?
We can see in this specific case there was better cache locality and more data was served from the L1 and L2 cache with a drop in L3 cache misses (no hits, because it didn’t have to look in L3 for anything).
6 cycles for bounds checks that the branch predictor never had to rewind on is nothing in comparison to saving a couple trips to L3.