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

41–50 of 402 posts

Re: Is Rust faster than C?

#41

Post by pron »

cdelsolar wrote: post #39
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…

Go?

I don't think so, but it may not be far behind. More importantly, though, I'm fairly confident it won't be Assembly, or C, or C++, or Rust, or Zig, but also not Python, or TS/JS. The candidates would most likely include Java, C#, and Go.

Re: Is Rust faster than C?

#42

Post by Karliss »

gignico wrote: post #2

The article does not mention the possible additional optimisation opportunities that arise in Rust code due to stricter aliasing rules of references. But I don’t have an example in mind. Does anyone know of an example of it happening in real code?

Not exactly real world, but real code example demonstrating strict aliasing rule in action for C++. https://godbolt.org/z/WvMb34Kea Rust should have even more opportunities of this due to restrictions it has for writable references.

There are 2 main differences between versions with and without strict aliasing. Without strict aliasing compiler can't assume that the result accumulator doesn't change during the loop and it has to repeatedly read/write it each iteration. With strict aliasing it can just read it to register, do the looping and write the result back at the end once. Second effect is that with strict aliasing enabled compiler can vectorize the loop processing 4 floats at the same time, most likely the same uncertainty of counter prevents vecotorization without strict aliasing.

If you want something slightly simpler example you can disable vectorization by adding '-fno-tree-vectorize'. With it disabled there is still difference in handling of counter.

Using restrict pointers and multiple same type input arrays it would probably be possible to make something closer to real world example.

Re: Is Rust faster than C?

#43

Post by pron »

DoctorOW wrote: post #29
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…

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

Re: Is Rust faster than C?

#46

Post by bluGill »

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.

Re: Is Rust faster than C?

#47

Post by steveklabnik »

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 like this framing a lot.

It's also interesting to think about this in terms of the "zero cost abstractions"/"zero overhead abstractions" idea, which Stroustrup wrote as "What you don't use, you don't pay for. What you do use, you couldn't hand code any better". The first sentence is about 1, and the second one is about what you're able to do with 2.

Re: Is Rust faster than C?

#48

Post by torben-friis »

cardanome wrote: post #27
treyd wrote: post #16

Earlier quoted context omitted.

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

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?

Re: Is Rust faster than C?

#49

Post by steveklabnik »

Karliss wrote: post #42
gignico wrote: post #2

The article does not mention the possible additional optimisation opportunities that arise in Rust code due to stricter aliasing rules of references. But I don’t have an example in mind. Does anyone know of an example of it happening in real code?

Not exactly real world, but real code example demonstrating strict aliasing rule in action for C++. https://godbolt.org/z/WvMb34Kea Rust should have even more opportunities of this due to restrictions it has for writable references. There are 2 main differences between versions with and without strict aliasing. Without strict aliasing compiler can't assume that the result accumulator doesn't change during the loop an…

Note that Rust does not do strict aliasing, its model is different.

Also note that C++ does not have restrict, formally speaking, though it is a common compiler extension. It's a C feature only!

Re: Is Rust faster than C?

#50

Post by IshKebab »

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 grounds I would say Rust probably is faster than C, because it makes it much much easier to use multithreading and more optimised libraries. For example a lot of C code uses linked lists because they're easy to write in C, even when a vector would be faster and more appropriate. Multithreading can just be a one line change in Rust.

Post reply on HN