Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance of Rust Language [pdf]

github.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: Performance of Rust Language [pdf]

#81

Post by bluGill »

afdbcreid wrote: post #10
jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

Is C++ more performant than C? I find this hard to believe. C++ does not have any construct that cannot be replicated, or is not common, in C. The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well. If anything, Rust has the potential to be more performant than C due to its aliasing…

It is not uncommon to realize your C program is valid C++ and get a performance improvement just by building with a C++ compiler no other change. The difference is small but C++ has a stronger type system which allows the compiler a few more optimizations. Of course it is possible that resulting program no longer does what you want but actually needing weaker types is rare.

Restrict could make things go different but I've never heard someone say otherwise.

Note that we are talking about differences that are tiny here. They can be measured if you are careful but they are almost guaranteed to not be something anyone would notice if they were not measuring

Re: Performance of Rust Language [pdf]

#82

Post by pjmlp »

flohofwoe wrote: post #34
adrian_b wrote: post #24

Earlier quoted context omitted.

In C++, nobody would want or need to use virtual functions in high-performance computational applications, while in the C language structures with virtual function tables that are accessed explicitly by the programmer are in widespread use wherever suitable, for instance in many popular open-source C programs, like the Linux kernel or the debugger gdb. So the existence of virtual function tables is not a differentiat…

> while in the C language structures with virtual function tables that are accessed explicitly by the programmer are in widespread use wherever suitable, for instance in many popular open-source C programs, like the Linux kernel or the debugger gdb For dynamic dispatch there is absolutely no difference between using a jump table in C and virtual method tables in C++. If the compiler can infer the target address at co…

With the difference that in C++ you can easily generate such call table at compile time without macro soup, while having it type checked.

Even better if assuming C++26.

Re: Performance of Rust Language [pdf]

#83

Post by yogthos »

DauntingPear7 wrote: post #77
yogthos wrote: post #75

I find the real issue with Rust is the compiler performance. I decided to use it for a project, and frankly I have huge regrets now that it's grown big enough. It literally takes over a minute to compile on my M1 laptop. I just don't understand how people find this sort of thing normal. If you implement a feature, and then you want to see it in action, the feedback loop for that is insanely slow. It's incredibly jarr…

Yeah rust has issues. Have you tried splitting your project into multiple crates if possible?

I haven't tried that yet, I guess that would be an option once I get a few stable pieces that I'm not likely to be touching much.

Re: Performance of Rust Language [pdf]

#84

Post by cogman10 »

jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

> modern C++ is notably more performant than C and by implication Rust

I don't think this holds. Rust has the same facilities which C++ has. Rust's metaprogramming capabilities are now on par with C++ (they weren't always). Rust has a similar generics implementation which allows it to do what C++ does in terms of method dispatch and generation. And now Rust has pretty much the same compile time constant generation capabilities that C++ has.

I don't think there's a part of C++ which isn't in Rust at this point. The only thing potentially missing is the experience and investment using those features.

Re: Performance of Rust Language [pdf]

#85

Post by IshKebab »

gobdovan wrote: post #4

Rust is in an awkward position of being already complicated enough that adding proofs for skipping bounds checks probably will not happen for a long time, even though this kind of low-level operation is where a lot of optimisation is lost. Compounding on this, Rust is also unstable underneath, since there is no public, stable contract for carrying high-level semantics from HIR into MIR. Because these high-level invar…

The benchmarks in this talk show that the bounds checks are mostly insignificant, and actually it's the integer overflow checks that are far more costly.

Actually nm, I forgot those are disabled in release mode. Good decision I guess.

Re: Performance of Rust Language [pdf]

#86

Post by greenavocado »

jandrewrogers wrote: post #19
afdbcreid wrote: post #10

Earlier quoted context omitted.

Is C++ more performant than C? I find this hard to believe. C++ does not have any construct that cannot be replicated, or is not common, in C. The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well. If anything, Rust has the potential to be more performant than C due to its aliasing…

Modern C++ metaprogramming materially impacts performance in practice. I’ve done performance engineering for decades in both C and modern C++ and I would assert that the difference isn’t arguable. The poor applicability of auto-vectorization is another area where C++ is strong. You can transparently codegen e.g. AVX512 from intrinsics directly in C++ in contexts that would be opaque to auto-vectorization and difficul…

[flagged]

Re: Performance of Rust Language [pdf]

#87

Post by root-parent »

jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

>> The caveat is that modern C++ is notably more performant than C and by implication Rust.

Please provide proof for this outrageous statement.

Re: Performance of Rust Language [pdf]

#88

Post by [deleted] »

pjmlp wrote: post #82
flohofwoe wrote: post #34

Earlier quoted context omitted.

> while in the C language structures with virtual function tables that are accessed explicitly by the programmer are in widespread use wherever suitable, for instance in many popular open-source C programs, like the Linux kernel or the debugger gdb For dynamic dispatch there is absolutely no difference between using a jump table in C and virtual method tables in C++. If the compiler can infer the target address at co…

With the difference that in C++ you can easily generate such call table at compile time without macro soup, while having it type checked. Even better if assuming C++26.

[deleted]

Re: Performance of Rust Language [pdf]

#89

Post by peterfirefly »

gobdovan wrote: post #4

Rust is in an awkward position of being already complicated enough that adding proofs for skipping bounds checks probably will not happen for a long time, even though this kind of low-level operation is where a lot of optimisation is lost. Compounding on this, Rust is also unstable underneath, since there is no public, stable contract for carrying high-level semantics from HIR into MIR. Because these high-level invar…

You can sometimes just add asserts for the index variable(s) and have the LLVM optimizer go "hmm, I should try to prove that those are true" and then get the range checks optimized away.

Re: Performance of Rust Language [pdf]

#90

Post by mynegation »

root-parent wrote: post #87
jandrewrogers wrote: post #7

I would summarize it thusly: Rust is roughly as performant as C. This matches my experience and Rust is more ergonomic than C in many regards. The caveat is that modern C++ is notably more performant than C and by implication Rust. This also matches my experience for both C and Rust. I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require moun…

>> The caveat is that modern C++ is notably more performant than C and by implication Rust. Please provide proof for this outrageous statement.

I was also dumbfounded by this claim. The only thing I could think of were C++ monomorphic templates that will avoid the penalty of some indirection and DIY dynamic typing.
Post reply on HN