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

211–220 of 402 posts

Re: Is Rust faster than C?

#211

Post by sfink »

NetMageSCW wrote: post #114

That article did not contribute anything to the answer of the question quoted.

It did not contribute to a yes/no answer, which is good, because it is not answerable with "yes" or "no", and the article points that out and explains why. So I would disagree; it does contribute to answering the question, in the form of spelling out why it is unanswerable.

Compare:

"Have you stopped beating your wife yet?"

"I do not beat my wife."

The response contributes to the answer, even if it brings you no closer to "yes" or "no".

Re: Is Rust faster than C?

#212

Post by steveklabnik »

groundzeros2015 wrote: post #199
tcfhgj wrote: post #132

Earlier quoted context omitted.

https://system76.com/cosmic https://helix-editor.com/ https://zed.dev/

What do you think are good use cases for multi threading in these editors?

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

Re: Is Rust faster than C?

#213

Post by sfink »

classified wrote: post #40

> Mozilla tried to parallelize Firefox’s style layout twice in C++, and both times the project failed. The multithreading was too tricky to get right. That is a damn good reason to choose Rust over C++, even if the Rust implementation of the "same" thing should be a bit slower.

It's a good reason to choose Rust over C++ for that application, and others that share its characteristics. (Or, more to the point of the article, it's a good reason to declare that Rust is faster than C++ for that application.)

It doesn't provide a lot of evidence in either direction for the rest of the vast space of potential programs.

(Knowing C++ fairly well and Rust not very well, I have Opinions, but they are not very well-informed opinions. They roughly boil down to: Rust is generally better for most programs, largely due to cargo not Rust, but C++ is better for more exploratory programming where you're going to be frequently reworking things as you go. Small changes ripple out across the codebase much more with Rust than C++ in my [limited] experience, and as a result the percentage of programming time spent fixing things up is substantially higher with Rust.)

Re: Is Rust faster than C?

#214

Post by MrJohz »

fauigerzigerk wrote: post #193
MrJohz wrote: post #165

Earlier quoted context omitted.

According to [1], the most important factor for the power consumption of code is how long the code takes to run. Code that spreads over multiple cores is generally more power efficient than code that runs sequentially, because the power consumption of multiple cores grows less than linearly (that is, it requires less than twice as much power to run two cores as it does one core). Therefore if parallelising code reduc…

>Therefore if parallelising code reduces the runtime of that code, it is almost always more energy efficient to do so Only if it leads to better utilisation. But in the scenario that the parent comment suggests, it does not lead to better utilisation as all cores are constantly busy processing requests. Throughput as well as CPU time across cores remains largely the same regardless of whether or not you paralellise i…

That's true, which is why I added the caveat that this is only true if parallelising reduces the overall runtime - if you can get in more requests per second through parallelisation. And the flip side of that is that if you're able to perfectly utilise all cores then you're already running everything in parallel.

That said, I suspect it's a rare case where you really do have perfect core utilisation.

Re: Is Rust faster than C?

#215

Post by sfink »

Huh. I expected two main advantages on Rust's side: usable multithreading (as mentioned) and stack allocation. For the latter, the ownership model makes it possible to stack-allocate things that you wouldn't dare put on the stack in either C or C++, thus saving malloc and free time as well as second-order effects from avoiding fragmentation.

Does Rust not do this for subtle reasons that I'm missing, or does it just not matter as much as I'd expect it to?

Re: Is Rust faster than C?

#216

Post by steveklabnik »

sfink wrote: post #215

Huh. I expected two main advantages on Rust's side: usable multithreading (as mentioned) and stack allocation. For the latter, the ownership model makes it possible to stack-allocate things that you wouldn't dare put on the stack in either C or C++, thus saving malloc and free time as well as second-order effects from avoiding fragmentation. Does Rust not do this for subtle reasons that I'm missing, or does it just n…

Both of those things are important, sure. I wanted this post to be talking about the higher level conceptual question, and then using interesting examples to tease out various aspects of that discussion, more than "here's what I think are the biggest differences between the two."

I think these two things are also things people would argue about a lot. It's hard to talk about them in a concrete sense of things, rather than just "I feel like code usually does X".

Re: Is Rust faster than C?

#217

Post by steveklabnik »

alkonaut wrote: post #169

Aren't there any scenarios where a C compiler (without assistance by the developer) must be defensive about aliasing, in a way that the Rust compiler must not be? I guess you could argue that C would reach the same speed because noalias is part of C as well. But I'd say that the interesting competition is for how fast idiomatic and "hand-optimized" (no unrolling, no aliasing hints etc) code is. Comparing programming…

Yes. Your point about noalias (the keyword is 'restrict' in C, noalias is the LLVM IR annotation) is right.

What I will say is that the fact that Rust uses this so much, and had to turn it off because of all the bugs it shook out, at least implies that it's not used very much in real-world C code. I don't know how to more scientifically analyze that, though.

Re: Is Rust faster than C?

#218

Post by Maxatar »

bsaul wrote: post #162
nicoburns wrote: post #18

Earlier quoted context omitted.

Right, but almost all APIs in Rust use something like fn foo(bar: impl BarTrait) and AFAIK it isn't possible to write that in C (though C++ does allow this kind of thing).

how do apis typically manage to actually « use » the « bar » of your example, such as storing it somewhere, without enforcing some kind of constraints ?

If you need to store the value then you have no choice but to take in a dyn trait.

Re: Is Rust faster than C?

#219

Post by sfink »

steveklabnik wrote: post #216
sfink wrote: post #215

Huh. I expected two main advantages on Rust's side: usable multithreading (as mentioned) and stack allocation. For the latter, the ownership model makes it possible to stack-allocate things that you wouldn't dare put on the stack in either C or C++, thus saving malloc and free time as well as second-order effects from avoiding fragmentation. Does Rust not do this for subtle reasons that I'm missing, or does it just n…

Both of those things are important, sure. I wanted this post to be talking about the higher level conceptual question, and then using interesting examples to tease out various aspects of that discussion, more than "here's what I think are the biggest differences between the two." I think these two things are also things people would argue about a lot. It's hard to talk about them in a concrete sense of things, rather…

Right, sorry, I didn't mean to imply that you should have covered stack allocation in your post. I think your post covers the right material to make its point.

This is more of a side comment about a different question, perhaps "ok fine, but then what are the language differences that could be performance-relevant for one language or the other, even if (as you say) they don't lead to a yes/no answer for your original question?"

Re: Is Rust faster than C?

#220

Post by steveklabnik »

Maxatar wrote: post #218
bsaul wrote: post #162

Earlier quoted context omitted.

how do apis typically manage to actually « use » the « bar » of your example, such as storing it somewhere, without enforcing some kind of constraints ?

If you need to store the value then you have no choice but to take in a dyn trait.

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.
Post reply on HN