Is Rust faster than C? • Hacker News Board

Re: Is Rust faster than C?

#151

Post by taminka » Wed, Jan 14, 2026, 3:36 PM UTC

steveklabnik wrote: post #23

taminka wrote: post #4

struct field alignment/padding isn't part of the C spec iirc (at least not in the way mentioned in the article), but it's almost always done that way, which is important for having a stable abi also, if performance is critical to you, profile stuff and compare outputted assembly, more often than not you'll find that llvm just outputs the same thing in both cases

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

Re: Is Rust faster than C?

#152

Post by allreduce » Wed, Jan 14, 2026, 3:36 PM UTC

groundzeros2015 wrote: post #120

NetMageSCW wrote: post #116

Earlier quoted context omitted.

Multithreading can made an application more responsive and more performant to the end user. If multithreading causes an end user to have to wait less, the code is more performant.

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?

Usually it does not reduce latency but increases throughput.

Multithreading is an invaluable tool when actually using your computer to crunch numbers (scientific computing, rendering, ...).

Re: Is Rust faster than C?

#153

Post by steveklabnik » Wed, Jan 14, 2026, 3:39 PM UTC

nurettin wrote: post #144

gpderetta wrote: post #131

Earlier quoted context omitted.

Then again, often #pragma omp for is a very low mental-overhead way to speed up code.

Yes! gcc/omp in general solved a lot of the problems which are conveniently left out in the article. The we have the anecdotal "They failed firefox layout in C++ twice then did it in Rust" < to this I sigh in chrome.

The Rust version of this is "turn .iter() into .par_iter()."

It's also true that for both, it's not always as easy as "just make the for loop parallel." Stylo is significantly more complex than that.

> to this I sigh in chrome.

I'm actually a Chrome user. Does Chrome do what Stylo does? I didn't think it did, but I also haven't really paid attention to the internals of any browsers in the last few years.

Re: Is Rust faster than C?

#154

Post by gf000 » Wed, Jan 14, 2026, 3:43 PM UTC

jillesvangurp wrote: post #58

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…

It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more co…

> It's compilers and compiler optimizations that make code run fast

Well, then in many cases we are talking about LLVM vs LLVM.

> Ultimately, producing fast/optimal code in C kind of is the whole point of C

Mostly a nitpick, but I'm not convinced that's true. The performance queen has been traditionally C++. In C projects it's not rare to see very suboptimal design choices mandated by the language's very low expressivity (e.g. no multi-threading, sticking to an easier data structure, etc).

Re: Is Rust faster than C?

#155

Post by gf000 » Wed, Jan 14, 2026, 3:44 PM UTC

Avicebron wrote: post #60

pron wrote: post #43

Earlier quoted context omitted.

Right, but if we assume that programmers' compensation is statistically correlated with their skill, then we can drop "average" and just talk about budget.

That seems like a wild assumption to make.

Statistically? I don't think it's that wild.

If you prefer it, salaries correlate with years of experience, and the latter surely correlates with skills, right?

(No, this doesn't mean that every 10 years XP dev is better than a 3 years XP one, but it's definitely a strong correlation)

Re: Is Rust faster than C?

#156

Post by bfrog » Wed, Jan 14, 2026, 3:46 PM UTC

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).

C++ you either use templates or classes and virtuals. In either case the caller doesn't get to decide.

Re: Is Rust faster than C?

#157

Post by jkarneges » Wed, Jan 14, 2026, 3:47 PM UTC

> Some people have reported that, thanks to Rust’s checks, they are more willing to write code that’s a bit more dangerous than in the equivalent C (or C++)

I rewrote a C project in Rust some years ago, and in the Rust version I included many optimizations that I probably wouldn't have in C code, thanks to the ability to do them "fearlessly". The end result was so much more performant I had to double check I didn't leave something out!

Re: Is Rust faster than C?

#158

Post by jasonjmcghee » Wed, Jan 14, 2026, 3:48 PM UTC

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…

> 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?

Re: Is Rust faster than C?

#159

Post by jibal » Wed, Jan 14, 2026, 3:50 PM UTC

steveklabnik wrote: post #61

mid-kid wrote: post #54

I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer. I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people. A particular language doesn't have a "speed", a par…

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).

Re: Is Rust faster than C?

#160

Post by HarHarVeryFunny » Wed, Jan 14, 2026, 3:52 PM UTC

gpderetta wrote: post #137

HarHarVeryFunny wrote: post #92

In general "Is programming language X faster than Y" is a meaningless question. It mostly comes down to specific implementations - specific compilers, interpreters, etc. The only case where one language is likely to be inherently faster than another is when the other language is so high level or abstracted away from the processors it is going to run on that an optimizing compiler is going to have a hard time bridging…

Language design still has a huge impact on which optimizations are practically implementable. The Mythical Sufficiently Smart Compiler is, in fact, still mythical.

Sure, but not all compilers are created equal and are going to go to the same lengths of analysis to discover optimization opportunities, or to have the same quality of code generation for that matter.

It might be interesting to compare LLVM generated code (at same/maximum optimization level) for Rust vs C, which would remove optimizer LOE as a factor and more isolate difficulties/opportunities caused by the respective languages.