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

281–290 of 402 posts

Re: Is Rust faster than C?

#281

Post by oconnor663 »

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…

> Despite benefits, I don't actually think the memory safety really plays a role in the usage rate of parallelism.

I can see what you mean with explicit things like thread::spawn, but I think Tokio is a major exception. Multithreaded by default seems like it would be an insane choice without all the safety machinery. But we have the machinery, so instead most of the async ecosystem is automatically multithreaded, and it's mostly fine. (The biggest problems seem to be the Send bounds, i.e. the machinery again.) Cargo test being multithreaded by default is another big one.

Re: Is Rust faster than C?

#282

Post by esjeon »

Theoretically, C is likely faster than Rust only by an unnoticeably small margin. Still, this is unavoidable because Rust works with abstraction that (1) adds overhead per-se albeit tiny (2) forces overhead in the design level.

Practically, that little margin can be removed thru a series of engineering, as both are proper system-level programming languages, which offer tight control over the generated machine code. That is, this whole discussion is basically pointless if we mix in engineering factors.

We better talk about overall engineering costs, and personally I think Rust would not overshoot C easily, mainly due to the limitations that Rust puts on the higher level designs.

Re: Is Rust faster than C?

#283

Post by cyberax »

pjmlp wrote: post #178
torginus wrote: post #118

Earlier quoted context omitted.

A lot of C++ devs advocate for simple replacements for the STL that do not rely too much on zero-cost abstractions. That way you can have small binaries, fast compiles, and make a fast-debug kinda build where you only turn on a few optimizations. That way you can get most of the speed of the Release version, with a fairly good chance of getting usable debug info. A huge issue with C++ debug builds is the resulting ex…

Unless one uses VC++, which can debug release builds. Similar capabilities could be made available in other compilers.

You can debug release builds with gcc/clang just fine. They don't generate debug information by default, but you can always request it ("-O3 -g" is a perfectly fine combination of flags).

Re: Is Rust faster than C?

#284

Post by josephg »

mandw wrote: post #277
josephg wrote: post #267

Earlier quoted context omitted.

> 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 co…

The only real question I have with this is did the program have to have any specific performance metric? I could write a small utility in python that would be completely acceptable for use but at the same time be 15x slower than an implementation in another language. So you do you compare code across languages that were not written for performance given one may have some set of functions that happens to favour one la…

Honestly I'm not quite sure what point you're making.

> If he needed his app to be 30% faster he would have made it so

Would he have? Improving performance by 30% usually isn't so easy. Especially not in a codebase which (according to Cantrill) was pretty well optimized already.

The performance boost came to him as a surprise. As I remember the story, he had already made the C code pretty fast and didn't realise his C hash table implementation could be improved that much. The fact rust gave him a better map implementation out of the box is great, because it means he didn't need to be clever enough to figure those optimizations out himself.

Its not an apples-to-apples comparison. But I don't think comparing the world's fastest C code to the world's fastest rust code is a good comparison either, since most programmers don't write code like that. Its usually incidental, low effort performance differences that make a programming language "fast" in the real world. Like a good btree implementation just shipping with the language.

Re: Is Rust faster than C?

#285

Post by kouteiheika »

dmitrygr wrote: post #274
kouteiheika wrote: post #97

Earlier quoted context omitted.

Yes. All `&mut` references in Rust are equivalent to C's `restrict` qualified pointers. In the past I measured a ~15% real world performance improvement in one of my projects due to this (rustc has/had a flag where you can turn this on/off; it was disabled by default for quite some time due to codegen bugs in LLVM).

Do you not use restrict in your normal everyday C code that you write? I use it in my normal C code.

I used to use it, but very rarely, since it's instant UB if you get it wrong. In tiny codebases which you can hold in your head it's probably practical to sprinkle it everywhere, but in anything bigger it's quite risky.

Nevertheless, I don't write normal everyday C code anymore since Rust has pretty much made it completely obsolete for the type of software I write.

Re: Is Rust faster than C?

#286

Post by jandrewrogers »

josephg wrote: post #270
tick_tock_tick wrote: post #249

Earlier quoted context omitted.

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?

They are likely referring to the scope of fine-grained specialization and compile-time codegen that is possible in modern C++ via template metaprogramming. Some types of complex optimizations common in C++ are not really expressible in Rust because the generics and compile-time facilities are significantly more limited.

As with C, there is nothing preventing anyone from writing all of that generated code by hand. It is just far more work and much less maintainable than e.g. using C++20. In practice, few people have the time or patience to generate this code manually so it doesn't get written.

Effective optimization at scale is difficult without strong metaprogramming capabilities. This is an area of real strength for C++ compared to other systems languages.

Re: Is Rust faster than C?

#287

Post by oguz-ismail2 »

steveklabnik wrote: post #203
jarjoura wrote: post #200

Earlier quoted context omitted.

Wouldn't C++ and Rust eventually call down into those same libc functions? I guess for your example, qsort() it is optional, and you can chose another implementation of that. Though I tend to find that both standard libraries tend to just delegate those lowest level calls to the posix API.

Rust doesn't call into libc for sort, it has its own implementation in the standard library.

Obviously. How about more complex things like multi-threading APIs though? Can the Rust compiler determine that the subject program doesn't need TLS and produce a binary that doesn't set it up at all, for example?

Re: Is Rust faster than C?

#288

Post by josephg »

jandrewrogers wrote: post #286
josephg wrote: post #270

Earlier quoted context omitted.

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?

They are likely referring to the scope of fine-grained specialization and compile-time codegen that is possible in modern C++ via template metaprogramming. Some types of complex optimizations common in C++ are not really expressible in Rust because the generics and compile-time facilities are significantly more limited. As with C, there is nothing preventing anyone from writing all of that generated code by hand. It…

Again, can you provide an example or two? Its hard to agree or disagree without an example.

I think all C++ wild template stuff can be done via proc macros. Eg, in rust you can add #[derive(Serialize, Deserialize)] to have a highly performant JSON parser & serializer. And thats just lovely. But I might be wrong? And maybe its ugly? Its hard to tell without real examples.

Re: Is Rust faster than C?

#289

Post by PPanther »

tcfhgj wrote: post #123
groundzeros2015 wrote: post #120

Earlier quoted context omitted.

Yes it can used to reduce latency of a particular task. Did you read my points about when it’s not helpful? Are people making user facing apps in rust with GUIs?

> Are people making user facing apps in rust with GUIs? yes

I made this with egui and typo: https://github.com/PJaros/menu_pdf

Works under Linux and Windows.

Re: Is Rust faster than C?

#290

Post by mjevans »

josephg wrote: post #284
mandw wrote: post #277

Earlier quoted context omitted.

The only real question I have with this is did the program have to have any specific performance metric? I could write a small utility in python that would be completely acceptable for use but at the same time be 15x slower than an implementation in another language. So you do you compare code across languages that were not written for performance given one may have some set of functions that happens to favour one la…

Honestly I'm not quite sure what point you're making. > If he needed his app to be 30% faster he would have made it so Would he have? Improving performance by 30% usually isn't so easy. Especially not in a codebase which (according to Cantrill) was pretty well optimized already. The performance boost came to him as a surprise. As I remember the story, he had already made the C code pretty fast and didn't realise his…

What I think it illustrates more is how much classic languages could gain by having a serious overhaul of their standard library and maybe even a rebrand if that's the expected baseline of a conformant implementation.
Post reply on HN