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

Is Rust faster than C?

steveklabnik.com

Post reply on HN
Print view View original

341–350 of 402 posts

Re: Is Rust faster than C?

#341

Post by josephg »

johnisgood wrote: post #328
Lorkki wrote: post #326

Earlier quoted context omitted.

> library quality and algorithm choice And especially having performant and actively maintained default choices built in. With C, as described in the post you responded to, you'll typically end up building a personal collection of dusty old libraries that work well enough for most of the time.

I think Rust projects will accumulate their own cruft over time, they are just younger. And the Rust ecosystem's churn (constant breakage, edition migrations, dependency hell in Cargo.lock) creates its own class of problems. Either way, I would like to reiterate that the comparison is flawed at a more fundamental level because hash tables and B-trees are different data structures with different performance characteri…

> the Rust ecosystem's churn (constant breakage, edition migrations, dependency hell in Cargo.lock) creates its own class of problems.

What churn? Rust hasn't broken compatibility since 1.0, over a decade ago. These days it feels like rust changes slower than C and C++.

> Either way, I would like to reiterate that the comparison is flawed at a more fundamental level because hash tables and B-trees are different data structures with different performance characteristics. O(1) average lookup vs O(log n) with cache-friendly ordered traversal. These are not interchangeable.

They're mostly interchangeable when used as a map! In rust code, in most cases you can just replace HashMap with BTreeMap. In practice, O(log n) and O(1) are very similar bounds owing to how slowly log(n) grows with respect to n. Cache locality often matters much more than a O(log n) factor in your algorithm.

If you read the actual article, you'll see that Cantrill benchmarked his library using rust's b-tree and hash table implementation. Both maps outperformed his C based hash table implementation.

> Neither tells you anything about Rust vs C.

It tells you rust's standard library has a faster hash map implementation than Bryan Cantrill. If you need a hash table, you're almost certainly better off using rust than rolling your own in C.

Re: Is Rust faster than C?

#342

Post by pornel »

beng-nl wrote: post #314
OskarS wrote: post #51

I think personally the answer is "basically no", Rust, C and C++ are all the same kind of low-level languages with the same kind of compiler backends and optimizations, any performance thing you could do in one you can basically do in the other two. However, in the spirit of the question: someone mentioned the stricter aliasing rules, that one does come to mind on Rust's side over C/C++. On the other hand, signed int…

This is a tangent, because it clearly didn’t pan out, but I had hope for rust having an edge when I learned about how all objects are known to be immutable or not. This means all the mutable objects can be held together, as well as the immutable, and we’d have more efficient use of the cache: memory writes to mutable objects share the cache with other mutable objects, not immutable Objects, and the bandwidth isn’t wa…

Rust doesn't have immutable memory, only access restrictions. An exclusive owner of an object can always mutate it, or can lend temporary read-only access to it. So the same memory may flip between exclusive-write and shared-read back and forth.

It's an interesting optimization, but not something that could be done directly.

Re: Is Rust faster than C?

#343

Post by unrealhoang »

dwattttt wrote: post #337
jltsiren wrote: post #323

Earlier quoted context omitted.

Concurrency is easy by default. The hard part is when you are trying to be clever. You write concurrent code in Rust pretty much in the same way as you would write it in OpenMP, but with some extra syntax. Rust catches some mistakes automatically, but it also forces you to do some extra work. For example, you often have to wrap shared data in Arc when you convert single-threaded code to use multiple threads. And some…

> For example, you can't get mutable references to items in a shared container by thread id or loop iteration. This would be a good candidate for a specialised container that internally used unsafe. Well, thread id at least; since the user of an API doesn't provide it, you could mark the API safe, since you wouldn't have to worry about incorrect inputs. Loop iteration would be an input to the API, so you'd mark the A…

There’s split_at_mut to avoid writing unsafe yourself in this case.

Re: Is Rust faster than C?

#344

Post by arghwhat »

simonask wrote: post #319
usrnm wrote: post #308

Earlier quoted context omitted.

> Multithreaded by default seems like it would be an insane choice without all the safety machinery You're describing golang, and somehow it's fine. Bugs are possible, but not super common

Isn't that "somehow" super attributable to the fact that Go is garbage collected? Garbage collection is the one other known way to achieve memory safety.

Not really, especially as garbage collection doesn't achieve memory safety. Safety-wise, it only helps avoid UAF due to lifecycle errors.

Garbage collection is primarily just a way to handle non-trivial object lifecycles without manual effort. Parallelism happens to often bring non-trivial object lifecycles, but this is not a major problem in parallelism.

In plain C, the common pattern is trying to keep lifecycles trivial, and the moment this either doesn't make sense or isn't possible, you usually just add a reference count member:

    struct some_type {
        uint32_t refcnt;
        uint32_t otherfields;
    };

    struct some_type *some_type_ref(struct some_type *a) {
        a->refcnt++;
        return a;
    }

    void some_type_unref(struct some_type *a) {
        a->refcnt--;
        if (a->refcnt == 0) {
            free(a); // or some_type_destroy(a);
        }
    }
In both Go and C, all types used in concurrent code needs to be reviewed for thread-safety, and have appropriate serialization applied - in the C case, this just also includes the refcnt itself. And yes you could have UAF or leak if you don't call ref/unref correctly, but that' sunrelated to parallism - it's just everyday life in manual memory management land.

The issues with parallelism is the same in Go and C, that you might have invalid application states, whether due to missing serialization - e.g., forgetting to lock things appropriately or accidentally using types that are not thread safe at all - or due to business logic flaws (say, two threads both sleeping, waiting for the other one to trigger an event and wake it up).

Re: Is Rust faster than C?

#345

Post by steveklabnik »

johnisgood wrote: post #332
steveklabnik wrote: post #212

Earlier quoted context omitted.

"don't block the ui thread" is a pretty classic aphorism in any language.

Hmm. "Fearless concurrency" and the flagship examples are... background threads for search and not freezing the UI? That is GUI programming 101 from the Win32 era. Every Tcl/Tk app, every GTK app, every Qt app has been doing this for 25+ years. If Rust's concurrency story were genuinely revolutionary, you would expect examples like: - Lock-free data structures that are actually hard to get right - Complex parallel al…

When a basic question is asked, a basic answer is given. I didn’t say that I think that’s the coolest or most interesting answer. It’s just the most obvious, straightforward one. It’s not even about Rust!

(And also, I don’t think things like work stealing queues are relevant to editors, but maybe that’s my own ignorance.)

Re: Is Rust faster than C?

#346

Post by steveklabnik »

marcosdumay wrote: post #234
steveklabnik wrote: post #220

Earlier quoted context omitted.

Depending on exactly what you mean, this isn't correct. This syntax is the same as , and you can store that T in any other generic struct that's parametrized by BarTrait, for example.

> you can store that T in any other generic struct that's parametrized by BarTrait, for example Not really. You can store it on any struct that specializes to the same type of the value you received. If you get a pre-built struct from somewhere and try to store it there, your code won't compile.

Can you show me what you’re talking about? I don’t understand what you mean. I’ll add a code example of what I mean in a bit.

Re: Is Rust faster than C?

#347

Post by yobbo »

pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

In C, one can build data structures with pointers that would require reference counting and heap allocation in Rust. The performance would also depend on what kind of CPU/features it is compiled for.

Whether one should do it is a different question.

Re: Is Rust faster than C?

#348

Post by steveklabnik »

yobbo wrote: post #347
pornel wrote: post #76

In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…

In C, one can build data structures with pointers that would require reference counting and heap allocation in Rust. The performance would also depend on what kind of CPU/features it is compiled for. Whether one should do it is a different question.

You can use unsafe in Rust to write the exact same thing.

Re: Is Rust faster than C?

#349

Post by [deleted] »

Lorkki wrote: post #326
johnisgood wrote: post #321

Earlier quoted context omitted.

> He straight ported some C code to rust and found the rust code outperformed it by ~30% or something. The culprit ended up being that in C, he was using a hash table library he's been copy pasting between projects for years. In rust, he used BTreeMap from the standard library, which turns out to be much better optimized. Are you surprised? Rust is never inherently faster than C. When it appears faster, it boils down…

> library quality and algorithm choice And especially having performant and actively maintained default choices built in. With C, as described in the post you responded to, you'll typically end up building a personal collection of dusty old libraries that work well enough for most of the time.

[deleted]

Re: Is Rust faster than C?

#350

Post by steveklabnik »

nixpulvis wrote: post #280
steveklabnik wrote: post #61

Earlier quoted context omitted.

I will admit the title was a bit of a gamble, but thank you for taking the time to read it and I'm glad that you enjoyed it in the end.

I just want to say, I always really appreciate your writing.

Thank you! I’m gonna end up doing a lot more of it in 2026 than I did in 2025… stay tuned!
Post reply on HN