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

171–180 of 402 posts

Re: Is Rust faster than C?

#171

Post by pjmlp »

steveklabnik wrote: post #153
nurettin wrote: post #144

Earlier quoted context omitted.

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.

And the C++ version is add std::execution::par_unseq as parameter to the ranges algorithm.

Re: Is Rust faster than C?

#172

Post by jandrewrogers »

gf000 wrote: post #139
jandrewrogers wrote: post #128

Earlier quoted context omitted.

The main performance difference between Rust, C, and C++ is the level of effort required to achieve it. Differences in level of effort between these languages will vary with both the type of code and the context. It is an argument about economics. I can write C that is as fast as C++. This requires many times more code that takes longer to write and longer to debug. While the results may be the same, I get far better…

> I can write C that is as fast as C++ I generally agree with your take, but I don't think C is in the same league as Rust or C++. C has absolutely terrible expressivity, you can't even have proper generic data structures. And something like small string optimization that is in standard C++ is basically impossible in C - it's not an effort question, it's a question of "are you even writing code, or assembly".

Yes, it is the difference between "in theory" and "in practice". In practice, almost no one would write the C required to keep up with the expressiveness of modern C++. The difference in effort is too large to be worth even considering. It is why I stopped using C for most things.

There is a similar argument around using "unsafe" in Rust. You need to use a lot of it in some cases to maintain performance parity with C++. Achievable in theory but a code base written in this way is probably going to be a poor experience for maintainers.

Each of these languages has a "happy path" of applications where differences in expressivity will not have a material impact on the software produced. C has a tiny "happy path" compared to the other two.

Re: Is Rust faster than C?

#173

Post by pjmlp »

m-schuetz wrote: post #138
sebtron wrote: post #121

Earlier quoted context omitted.

I think this is related to the C++ standard library implementation. Using pthread in C, for example, TBB is not required. Not sure about C11 threads, but I have always thought that GLIBC just uses pthread under the hood.

I don't know the details since I'm mainly a windows dev, but when porting to linux, TBB has always been a huge pain in the ass since it's a suddenly additionally required dependency by gcc. Using C++ and std::thread.

Also clang, and in general parallel algorithms aren't available outside of platforms not supported by TBB.

C++26 will get another similar dependency, because BLAS algorithms are going to be added, but apparently the expectation is to build on top of C/Fortran BLAS battle tested implementations.

Re: Is Rust faster than C?

#174

Post by steveklabnik »

bluGill wrote: post #163
steveklabnik wrote: post #73

Earlier quoted context omitted.

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.

I mean, data races are undefined behavior in C++ the same way that they are in unsafe Rust. The languages are equivalent there.

Re: Is Rust faster than C?

#175

Post by pjmlp »

jandrewrogers wrote: post #128
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…

The main performance difference between Rust, C, and C++ is the level of effort required to achieve it. Differences in level of effort between these languages will vary with both the type of code and the context. It is an argument about economics. I can write C that is as fast as C++. This requires many times more code that takes longer to write and longer to debug. While the results may be the same, I get far better…

> I can write C that is as fast as C++.

Only if ignoring the C++ compile time execution capabilites.

Re: Is Rust faster than C?

#176

Post by michalsustr »

lionkor wrote: post #143

To answer the headline: No. Rust is not faster than C. C isn't faster than Rust either. What is fast is writing code with zero abstractions or zero cost abstractions, and if you can't do that (because writing assembly sucks), get as close as possible. Each layer you pile on adds abstraction. I've never had issues optimizing and profiling C code -- the tooling is excellent and the optimizations make sense. Get into Ru…

What are your favorite tools for profiling/optimizing C and Rust code?

Re: Is Rust faster than C?

#177

Post by bluGill »

steveklabnik wrote: post #174
bluGill wrote: post #163

Earlier quoted context omitted.

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

I mean, data races are undefined behavior in C++ the same way that they are in unsafe Rust. The languages are equivalent there.

Only if there is a data race - if there is no data race C++ lets you do it. Rust doesn't let you do things that don't have a race but cannot be proven within the context of rust to not have a data race.

Re: Is Rust faster than C?

#178

Post by pjmlp »

torginus wrote: post #118
cardanome wrote: post #27

Earlier quoted context omitted.

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

A lot of C++ devs advocate for simple replacements for the STL that do not rely too much on zero-cost abstractions. That way you can have small binaries, fast compiles, and make a fast-debug kinda build where you only turn on a few optimizations. That way you can get most of the speed of the Release version, with a fairly good chance of getting usable debug info. A huge issue with C++ debug builds is the resulting ex…

Unless one uses VC++, which can debug release builds.

Similar capabilities could be made available in other compilers.

Re: Is Rust faster than C?

#179

Post by pmarin »

pjmlp wrote: post #175
jandrewrogers wrote: post #128

Earlier quoted context omitted.

The main performance difference between Rust, C, and C++ is the level of effort required to achieve it. Differences in level of effort between these languages will vary with both the type of code and the context. It is an argument about economics. I can write C that is as fast as C++. This requires many times more code that takes longer to write and longer to debug. While the results may be the same, I get far better…

> I can write C that is as fast as C++. Only if ignoring the C++ compile time execution capabilites.

C++ compile time execution is just a gimmicky code generator, you can do it in any language.
Post reply on HN