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

51–60 of 402 posts

Re: Is Rust faster than C?

#51

Post by OskarS »

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 integer overflow being UB would count for C/C++ (in general: all the UB in C/C++ not present in Rust is there for performance reasons).

Another thing I thought of in Rust and C++s favor is generics. 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. This means it's much easier for the compiler to specialize the sorting function, inline the comparisons and optimize around it. I don't know if C compilers specialize qsort() based on comparison function this way. They might, but it's certainly a lot more to ask of the compiler, and I would argue there are probably many cases like this where C++ and Rust can outperform C because of their much more powerful facilities for specialization.

Re: Is Rust faster than C?

#52

Post by esrauch »

greener_grass wrote: post #32
cardanome wrote: post #27

Earlier quoted context omitted.

For release builds yes. For debug builds slow compile times kill productivity.

If you are not willing to make this trade then how much of a priority was run-time performance, really?

It's never the case that only one thing is important.

In the extreme, you surely wouldn't accept a 1 day or even 1 week build time for example? It seems like that could be possible and not hypothetical for a 1 week build since a system could fuzz over candidate compilation, and run load tests and do PGO and deliver something better. But even if runtime performance was so important that you had such a system, it's obvious you wouldn't ever have developer cycles that take a week to compile.

Build time also even does matter for release: if you have a critical bug in production and need to ship the fix, a 1 hour build time can still lose you a lot here. Release build time doesn't matter until it does.

Re: Is Rust faster than C?

#53

Post by embedding-shape »

treyd wrote: post #16
embedding-shape wrote: post #11

Earlier quoted context omitted.

It's a tradeoff though, as I think traits makes the Rust build times grow really quickly. I don't know the exact characteristics of it, also I think they speed it up compared to how it used to be, but I do remember that you'll get noticeable build slowdowns the more you use traits, especially "complicated" ones.

Code is typically run many more times than it's compiled, so this is a perfectly good tradeoff to make.

Absolutely, was not trying to claim otherwise. But since we're engineers (at least I like to see myself as one), it's worth always keeping in mind that almost everything comes with tradeoffs, even traits :)

Someone down the line might be wondering why suddenly their Rust builds take 4x the time after merging something, and just maybe remembering this offhand comment will make them find the issue faster :)

Re: Is Rust faster than C?

#54

Post by mid-kid »

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 particular implementation may have, and the language may have properties that make it difficult to make a fast implementation (of those specific properties/features) given the constraints of our current computer architectures. Even then, there's usually too many variables to make a generalized statement, and the question often presumes that performance is measured as total cpu time.

Re: Is Rust faster than C?

#55

Post by steveklabnik »

torben-friis wrote: post #48
cardanome wrote: post #27

Earlier quoted context omitted.

For release builds yes. For debug builds slow compile times kill productivity.

Doesn’t rust have incremental builds to speed up debug compilation? How slow are we talking here?

Rust does have incremental rebuilds, yes.

Folks have worked tirelessly to improve the speed of the Rust compiler, and it's gotten significantly faster over time. However, there are also language-level reasons why it can take longer to compile than other languages, though the initial guess of "because of the safety checks" is not one of them, those are quite fast.

> How slow are we talking here?

It really depends on a large number of factors. I think saying "roughly like C++" isn't totally unfair, though again, it really depends.

Re: Is Rust faster than C?

#56

Post by xnorswap »

pron wrote: post #30
justin66 wrote: post #22

Earlier quoted context omitted.

These are the languages an "average programmer" would use. What language are you thinking of?

I may be biased, but I think that if you have a budget that's reasonable in the industry for some project size and includes not only the initial development but also maintenance and evolution over the software's lifetime, especially when it's not small (say over 200KLOC), and you want to choose the language that would give you the fastest outcome, you will not get a faster program than if you chose Java. To get a fas…

Do you think C# / .NET doesn't stack up in terms of budget, or not stack up in terms of runtime speed?

Re: Is Rust faster than C?

#57

Post by oguz-ismail2 »

IshKebab wrote: post #50

I think the only reasonable way to interpret this question is "is Rust written by reasonably competent Rust developer spending a reasonable amount of time faster/slower than an equally competent C developer spending the same amount of time". I don't think a language should count as "fast" if it takes an expert or an inordinate amount of time to get good performance, because most code won't have that. So on those grou…

So assembly is the slowest language?

Re: Is Rust faster than C?

#58

Post by jillesvangurp »

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 context for optimizing than the C compiler is maybe not as controversial as the notion that language X is better/faster than language Y. Ultimately, producing fast/optimal code in C kind of is the whole point of C. And there aren't really any hacks you can do in C that you can't do in Rust, or vice versa. So, it would be hard to make the case that Rust is slower than C or the other way around.

However, there have been a few rewrites of popular unix tools in Rust that benchmark a bit faster than their C equivalents. Could those be optimized in C. Probably; but they just haven't. But there is a case there of arguing that maybe Rust code is a bit easier to make fast than C code.

Re: Is Rust faster than C?

#59

Post by sgeisenh »

bluGill wrote: post #46
kibwen wrote: post #38

I like to say that there are two primary factors when we talk about how "fast" a language is: 1. What costs does the language actively inject into a program? 2. What optimizations does the language facilitate? Most of the time, it's sufficient to just think about the first point. C and Rust are faster than Python and Javascript because the dynamic nature of the latter two requires implementations to inject runtime ch…

Is Javascript significantly slower? It is extremely common in the real world and so a lot of effort has gone into optimizing it - v8 is very good. Yes C and Rust enable more optimizations: they will be slightly faster, but javascript has had a lot of effort put into making it run fast.

Yes, for most real-world examples JavaScript is significantly slower; JIT isn’t free and can be very sensitive to small code changes, you also have to consider the garbage collector.

Speed is also not the only metric, Rust and C enable much better control over memory usage. In general, it is easier to write a memory-efficient program in Rust or C than it is in JS.

Re: Is Rust faster than C?

#60

Post by Avicebron »

pron wrote: post #43
DoctorOW wrote: post #29

Earlier quoted context omitted.

> 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 I'd say most people use this definition, with the caveat that there's no official "average programmer", and everyone has different standards.

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