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

11–20 of 146 posts

Re: Performance of Rust Language [pdf]

#11

Post by loeg »

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…

C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().

Re: Performance of Rust Language [pdf]

#12

Post by aw1621107 »

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…

> 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 invariants are lost during compilation

Not sure if I'm just out of the loop, but I'm having a hard time following this line of reasoning. Why is a public and/or stable contract needed to carry high-level semantics from HIR to MIR? Neither seems necessary to me; from what I understand HIR and MIR are rustc-internal so public contracts shouldn't matter, and the lack of stability means the Rust devs aren't precluded by backwards compatibility from modifying the IRs to add the ability to carry such invariants.

Re: Performance of Rust Language [pdf]

#13

Post by fithisux »

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…

You can write C style C++ and enjoy the same benefits.

In Twitter a user explained me that it is common in embedded space.

You do not need the OOP, RTTI, exceptions.

Like C with most use cases of preprocessor replaced by generic programming.

Re: Performance of Rust Language [pdf]

#14

Post by CrazyboyQCD »

afdbcreid wrote: post #8
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 overhead of bounds checking varies a lot. In the common case it's negligible (few percents), but in some cases, depending on what you build, it can go up to even 20%. And if it prevents autovectorization it can cost even more. There are techniques to minimize the perf loss, though (safely), and of course you can use unsafe code. If you do it smartly, in the vast majority of cases bound checks do not matter (in fa…

[dead]

Re: Performance of Rust Language [pdf]

#15

Post by afdbcreid »

loeg wrote: post #11
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…

C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().

I explicitly acknowledged that:

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

But in fact, if speed is a concern to you, even in C you will use "templated" sorting (via macros or code generation).

Re: Performance of Rust Language [pdf]

#16

Post by afdbcreid »

fithisux wrote: post #13
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…

You can write C style C++ and enjoy the same benefits. In Twitter a user explained me that it is common in embedded space. You do not need the OOP, RTTI, exceptions. Like C with most use cases of preprocessor replaced by generic programming.

So? How is that an argument that C++ is more performant than C? It's only an argument that it's not less performant.

Re: Performance of Rust Language [pdf]

#17

Post by smallstepforman »

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…

c++ uses rich type system to avoid aliasing when it can, as well as template meta programming.

Eg: delete_scene(void *arg) vs delete_scene(T *arg)

Re: Performance of Rust Language [pdf]

#18

Post by encodedrose »

marcosdumay wrote: post #3
encodedrose wrote: post #2

If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?

That's on the typical performance for bounds checking in C too. But no, "memory safety" includes most of the things discussed on the slides, and those number are for bounds checking only.

Ah, I was using GH's webui instead of downloading to view the PDF and it stopped loading at slide#47...rereading it now paints a much better picture. Thanks!

Re: Performance of Rust Language [pdf]

#19

Post by jandrewrogers »

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…

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 difficult to generalize in C. This allows you to get some degree of “auto-vectorization” where the compiler can’t see it because it works at the wrong level of abstraction.

With sufficiently heroic efforts you can write C that matches the performance of C++. I’m not arguing that. Virtually no one writes C to that standard, including myself when I was writing high-performance C because the effort was too high, so it is a bit of a strawman.

It is the difference between theory and practice. All code bases have a finite budget. C++ can do a lot more optimization in the same budget as C.

Re: Performance of Rust Language [pdf]

#20

Post by 20k »

afdbcreid wrote: post #15
loeg wrote: post #11

Earlier quoted context omitted.

C++ you get templated generic algorithms that in practice no one really does with C because macros suck too much. So in C typically you'd have a runtime generic routine that doesn't inline. A classic example here is qsort() vs std::sort().

I explicitly acknowledged that: > 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. But in fact, if speed is a concern to you, even in C you will use "templated" sorting (via macros or code generation).

The problem is that the implementation burden with C is so high, that people tend not to do it even in relatively performance constrained situations
Post reply on HN