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

61–70 of 402 posts

Re: Is Rust faster than C?

#61

Post by steveklabnik »

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.

Re: Is Rust faster than C?

#62

Post by renox »

OskarS wrote: post #51

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

>signed integer overflow being UB would count for C/C++

Then, I raise you to Zig which has unsigned integer overflow being UB.

Re: Is Rust faster than C?

#63

Post by pron »

xnorswap wrote: post #56
pron wrote: post #30

Earlier quoted context omitted.

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?

It's probably in the same ballpark. To me, the contenders for "the fastest language" include Java, C#, and Go and not many more.

Re: Is Rust faster than C?

#64

Post by esrauch »

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?

People do have cold Rust compiles that can push up into measured in hours. Large crates often take design choices that are more compile time friendly shape.

Note that C++ also has almost as large problem with compile times with large build fanouts including on templates, and it's not always realistic for incremental builds to solve either especially time burnt on linking, e.g. I believe Chromium development often uses a mode with .dlls dynamic linking instead of what they release which is all static linked exactly to speed up incremental development. The "fast" case is C not C++.

Re: Is Rust faster than C?

#65

Post by voidUpdate »

philipallstar wrote: post #36
voidUpdate wrote: post #7

Depends what you're doing with it... You can make any language you want slower than another language by using it badly

This is like saying that no car is faster than any other because it depends what gear you drive it in

That's true as well. Language speed depends on how you use it

Re: Is Rust faster than C?

#66

Post by swiftcoder »

justin66 wrote: post #22
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…

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

Purely by the numbers, an "average programmer" is much more likely to use Javascript, Python, or Java. The native languages have been a bit of a niche field since the late 90's (i.e. heavily slanted towards OS, embedded, and gamedev folks)

Re: Is Rust faster than C?

#67

Post by dana321 »

OskarS wrote: post #51

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

Rust has linker optimizations that can make it faster in some cases

Re: Is Rust faster than C?

#68

Post by bluGill »

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.

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 easier. It is highly likely that those restrictions are part of what made this possible. Given infinite resources (which you never have) a C++ implementation could be faster because it has better shared data concepts - but those same shared data concepts make it extremely hard to reason about multi-threaded code and so humanly you might not be able to make it work.

Re: Is Rust faster than C?

#69

Post by AnimalMuppet »

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…

I think there's a third question, but I don't know quite how to phrase it. Maybe "how real-world fast is the language?" or "how fast is the language in the hands of someone who isn't obsessively thinking about speed?"

That is, most of the time, most of the users aren't thinking about how to squeeze the last tenth of a percent of speed out of it. They aren't thinking about speed at all. They're thinking about writing code that works at all, and that hopefully doesn't crash too often. How fast is the language for them? Does it nudge them toward faster code, or slower? Are the default, idiomatic ways of writing things the fast way, or the slow way?

Re: Is Rust faster than C?

#70

Post by bluGill »

bigfishrunning wrote: post #33
steveklabnik wrote: post #12

Earlier quoted context omitted.

That’s not how I would summarize what I wrote, for what it’s worth. My summary would be “the question is malformed, you need to first state what the boundaries are for comparison before you can make any conclusions.” I think this is an interesting thing to discuss because many people assume that the answer to “is x faster than C?” to be “no” for all values of X.

> many people assume that the answer to “is x faster than C?” to be “no” for all values of X. This is because C does so little for you -- bounds checking must be done explicitly for instance, like you mention in the article, so C is "faster" unless you work around rust's bounds checking. It reminds me of some West Virginia residents I know who are very proud of how low their taxes are -- the roads are falling apart,…

In the real world the difference is rarely significant assuming great programmings implement great algorithms. However those two assumptions are rarely true.
Post reply on HN