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

161–170 of 402 posts

Re: Is Rust faster than C?

#161

Post by shmolyneaux »

While people can nitpick, the article is pretty clear that there isn't a single answer. Everything depends on how you constrain the problem. How much experience does the developer have? What time constraints are there? Is it idiomatic code? How maintainable is the code? You can write C with Rust-like safety checks or Rust with C-like unsafety.

When you can directly write assembly with either, comparing performance requires having some constraints.

For what it's worth, I think coding agents could provide a reasonable approximation of what "average" code looks like for a given language. If we benchmark that we'd have some indication of what the typical performance looks like for a given language.

Re: Is Rust faster than C?

#162

Post by bsaul »

nicoburns wrote: post #18
K0nserv wrote: post #10

Earlier quoted context omitted.

> In c the callers isn’t choosing typically. The author of some library or api decides this for you. Tbf this applies to Rust too. If the author writes fn foo(bar: Box ) they have forced the caller into dynamic dispatch. Had they written fn foo(bar: impl BarTrait) the choice would've remained open to the caller

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 ?

Re: Is Rust faster than C?

#163

Post by bluGill »

steveklabnik wrote: post #73
bluGill wrote: post #68

Earlier quoted context omitted.

Only if it is repeatable. We have no information on what they learned in the two failed attempts - it is likely that they learned from the failures and started other architectural changes that enabled the final one to work. As such we cannot say anything about this. Rust does have some interesting features, which restrict what you are allowed to do and thus make some things impossible but in turn make other things ea…

We do have some information: https://youtu.be/Y6SSTRr2mFU?t=361 (linked with the specific timestamp) In short, the previous two attempts were done by completely different groups of different people, a few years apart. Your direct question about if direct wisdom from these two attempts was shared, either between them, or used by Stylo, isn't specifically discussed though. > a C++ implementation could be faster because…

> What concepts are those?

Data can be modified by any thread that wants to. It is up to you to ensure that modifications work correctly without race conditions. In rust you can't do this (unsafe aside), the borrow checker enforces data access patterns that can't be proved correct.

Again let me be clear: the things rust doesn't allow are hard to get correct.

Re: Is Rust faster than C?

#164

Post by steveklabnik »

taminka wrote: post #151
steveklabnik wrote: post #23

Earlier quoted context omitted.

Here's the draft of C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf See "6.7.3.2 Structure and union specifiers", paragraph 16 & 17: > Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type. > Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in…

so they're ordered, which i didn't dispute, but alignment is implementation defined, so it could be aligned to the biggest field (like in the article), or packed in whatever (sequential) order the particular platform demands, which was my initial point

Ah, sorry, you're right I forgot about alignment. Yes, alignment is implementation defined, paragraph 16:

> Each non-bit-field member of a structure or union object is aligned in an implementation-defined manner appropriate to its type.

But, I still don't think that what you've said is true. This is because alignment isn't decided per-object, but per type. That bit is covered more fully in 6.2.8 Alignment of objects.

You also have to be able to take a pointer to a (non-bitfield) member, and those pointers must be aligned. This is also why __attribute__((packed)) and such are non-standard extensions.

Then again: I have not passed the C specification lawyer bar, so it is possible that I am wrong here. I'm just an armchair lawyer. :)

(but for padding, yes, that's correct.)

Re: Is Rust faster than C?

#165

Post by MrJohz »

groundzeros2015 wrote: post #110
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…

Multithreading does not make code more efficient. It still takes the same amount of work and power (slightly more). On a backend system where you already have multiple processes using various cores (databases, web servers, etc) it usually doesn’t make sense as a performance tool. And on an embedded device you want to save power so it also rarely makes sense.

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 reduces the runtime of that code, it is almost always more energy efficient to do so. Obviously if this is important in a particular context, it's probably worth measuring it in that context (e.g. embedded devices), but I suspect this is true more often than it isn't true.

[1]: https://arxiv.org/abs/2410.05460

Re: Is Rust faster than C?

#166

Post by torginus »

pron wrote: post #14

The question is what do we mean by "a fast language"? We could mean it to be how fast the fastest code that a performance expert in that language, with no resource constraints, could write. Or, we can restrict it to "idiomatic" code. Or we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget (in which case probably none of the languages mentioned…

I think when designing a language, and a set of libraries for it, the designer has an idea of how code for said language should be written, what 'idiomatic' code looks like.

In that context, the designer can reason about how should code written that way should perform.

So I think this is a meaningful question for a langauge designer, which makes it a meaningful question for the users as well, when phrased like this:

'How does idiomatic code (as imagined by the language creators) perform in language X vs Y?'

Re: Is Rust faster than C?

#167

Post by steveklabnik »

shmolyneaux wrote: post #161

While people can nitpick, the article is pretty clear that there isn't a single answer. Everything depends on how you constrain the problem. How much experience does the developer have? What time constraints are there? Is it idiomatic code? How maintainable is the code? You can write C with Rust-like safety checks or Rust with C-like unsafety. When you can directly write assembly with either, comparing performance re…

Thank you.

I wrote this at a time when I was pretty anti-LLM, but I do think that you're right that there's some interesting implications of LLM usage in this space. And that's because one version of this question is "what can the average x programmer do compared to the average y programmer in the same amount of time," and I'm curious if LLMs lift all tides here, or not.

Re: Is Rust faster than C?

#168

Post by steveklabnik »

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 ?

"BarTrait" is the constraint.

This is monomorphized for every type you pass in, in short.

Re: Is Rust faster than C?

#169

Post by alkonaut »

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 languages "performance" only makes sense if comparing idiomatic code. But you could argue that noalias in C is idiomatic. But you could equally well argue that multi threading in Rust is more idiomatic than it is in C and so on. That's where it becomes interesting (and difficult) to quantify.

Re: Is Rust faster than C?

#170

Post by steveklabnik »

jibal wrote: post #159
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.

We recently had a post here where the claim being refuted was in quotes in the title, but half the comments were as if the article were making the claim, clearly indicating that people didn't read it (and don't understand how quote marks work).

Yes, this is an age old problem, for sure.

It's a good thing to keep in mind when you read the comments on any article.

Post reply on HN