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

261–270 of 402 posts

Re: Is Rust faster than C?

#261

Post by aw1621107 »

lionkor wrote: post #143

To answer the headline: No. Rust is not faster than C. C isn't faster than Rust either. What is fast is writing code with zero abstractions or zero cost abstractions, and if you can't do that (because writing assembly sucks), get as close as possible. Each layer you pile on adds abstraction. I've never had issues optimizing and profiling C code -- the tooling is excellent and the optimizations make sense. Get into Ru…

> If you want a stupid fast interpreter in C, you do computed goto, write a comment explaining why its not, in fact, cursed, and you're done.

Bit of an aside, but these days it might be worth experimenting with tail call interpreters coupled with `musttail` annotations. CPython saw performance improvements over their computed goto interpreters with this method, for example [0].

[0]: https://lwn.net/Articles/1010905/

Re: Is Rust faster than C?

#262

Post by stevefan1999 »

Yes, in general Rust is faster than C, I would argue, because there are some problems the hinders C performance such as strict aliasing and volatile data simply doesn't exist in Rust, and immutable const propagation and const evaluation works too.

Re: Is Rust faster than C?

#263

Post by kevincox »

stevefan1999 wrote: post #262

Yes, in general Rust is faster than C, I would argue, because there are some problems the hinders C performance such as strict aliasing and volatile data simply doesn't exist in Rust, and immutable const propagation and const evaluation works too.

Yes, the same way is that Fortran is faster than C due to stricter aliasing rules.

But in practice C, Rust and Fortran are not really distinguishable on their own in larger projects. In larger projects things like data structures and libraries are going to dominate over slightly different compiler optimizations. This is usually Rust's `std` vs `libc` type stuff or whatever foundational libraries you pull in.

For most practical Rust, C, C++, Fortran and Zig have about the same performance. Then there is a notable jump to things like Go, C# and Java.

Re: Is Rust faster than C?

#264

Post by estebank »

dwattttt wrote: post #259
kibwen wrote: post #250

Earlier quoted context omitted.

There's no Rust codebase that takes hours to compile cold unless 1) you're compiling a massive codebase in release mode with LTO enabled, in which case, you've asked for it, 2) you've ported Doom to the type system, or 3) you're compiling on a netbook.

I'm curious if this is tracked or observed somewhere; crater runs are a huge source of information, metrics about the compilation time of crates would be quite interesting.

I know some large orgs have this data for internal projects.

This page gives a very loose idea of how we're doing over time: https://perf.rust-lang.org/dashboard.html

Re: Is Rust faster than C?

#265

Post by jasonjmcghee »

pornel wrote: post #236
jasonjmcghee wrote: post #158

Earlier quoted context omitted.

> Rust programmers may as well sprinkle threads all over the place regardless whether that's a 16x improvement or 1.5x improvement What about energy use and contention?

Usually it's a benefit for energy usage anyway. CPUs are most energy efficient sitting idle doing nothing, so finishing work sooner in wall-clock time usually helps despite overheads. Energy usage is most affected by high clock frequencies, and CPUs will boost clocks for single-threaded code. Threads waiting on cache misses let CPU use hyperthreading, which is actually energy efficient (you get context switching in h…

Thanks

Re: Is Rust faster than C?

#266

Post by josephg »

dwattttt wrote: post #254
OptionOfT wrote: post #206

Earlier quoted context omitted.

Unless you use `dyn`, all code is monomorphized, and that code on its own will get optimized. This does come with code-bloat. So the Rust std sometimes exposes a generic function (which gets monomorphized), but internally passes it off to a non-generic function. This to avoid that the underlying code gets monomorphized. https://github.com/rust-lang/rust/blob/8c52f735abd1af9a73941...

> This does come with code-bloat. So the Rust std sometimes exposes a generic function (which gets monomorphized), but internally passes it off to a non-generic function. There's no free lunch here. Reducing the amount of code that's monomorphised reduces the code emitted & improves compile times, but it reduces the scope of the code that's exposed to the input type, which reduces optimisation opportunities.

Yes. But I like that rust gives you the option.

In C, the only way to write a monomorphized hash table or array list involves horribly ugly macros that are difficult to write and debug. Rust does monomorphization by default, but you can also use &dyn trait for vtable-like behaviour if you prefer.

Re: Is Rust faster than C?

#267

Post by josephg »

arghwhat wrote: post #112
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…

To be honest, I think a lot of the justification here is just a difference in standard library and ease of use. I wouldn't consider there to be any notable effort in making thread build on target platforms in C relative to normal effort levels in C, but it's objectively more work than `std::thread::spawn(move || { ... });`. Despite benefits, I don't actually think the memory safety really plays a role in the usage ra…

> To be honest, I think a lot of the justification here is just a difference in standard library and ease of use.

I really liked this article by Bryan Cantrill from 2018:

https://bcantrill.dtrace.org/2018/09/28/the-relative-perform...

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.

This isn't evidence Rust is faster than C. I mean, you could just backport that btreemap to C and get exactly the same performance in C code. At the limit, I think both languages perform basically the same.

But most people aren't going to do that.

If we're comparing normal rust to normal C - whatever that means - then I think rust takes the win here. Even Bryan Cantrill - one of the best C programmers you're likely to ever run into - isn't using a particularly well optimized hash table implementation in his C code. The quality of the standard tools matters.

When we talk about C, we're really talking about an ecosystem of practice. And in that ecosystem, having a better standard library will make the average program better.

Re: Is Rust faster than C?

#268

Post by josephg »

ndesaulniers wrote: post #242
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…

> For instance, in C, qsort() takes a function pointer for the comparison function, in Rust and C++, the standard library sorting functions are templated on the comparison function. That's more of a critique of the standard libraries than the languages themselves. If someone were writing C and cared, they could provide their own implementation of sort such that the callback could be inlined (LLVM can inline indirect…

> That's more of a critique of the standard libraries than the languages themselves.

But we're right to criticise the standard libraries. If the average programmer uses standard libraries, then the average program will be affected (positively and negatively) by its performance and quirks.

Re: Is Rust faster than C?

#269

Post by kawogi »

ratmice wrote: post #91

I feel like another optimization that rust code can exploit is uninhabited types. When combined with generics and sum types these can lead to entire branches being unreachable at the type level. Like Option or Result , rust hasn't stablized !, but you can declare them other ways such as an empty enum with no variants.

In your specific example `std::convert::Infallible` can be used: https://doc.rust-lang.org/std/convert/enum.Infallible.html

Re: Is Rust faster than C?

#270

Post by josephg »

tick_tock_tick wrote: post #249
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…

You're qsort example is basically the same reason people say C++ is faster than Rust. C++ templates are still a lot more powerful than Rusts systems but that's getting closer and closer every day.

It is?? Can you give some examples of high performance stuff you can do using C++'s template system that you can't do in rust?
Post reply on HN