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

111–120 of 146 posts

Re: Performance of Rust Language [pdf]

#111

Post by pjmlp »

mynegation wrote: post #90
root-parent wrote: post #87

Earlier quoted context omitted.

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

And compile time programming, meaning that you can prepare some algorithms and data structures at compile time, at the expense of executable size.

Compile time reflection will make this even easier.

Re: Performance of Rust Language [pdf]

#112

Post by pjmlp »

api wrote: post #98
root-parent wrote: post #87

Earlier quoted context omitted.

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

I think they may be talking about math algorithm heavy code, where C++'s looser almost-just-a-substitution generics system (really "templates" not even quite generics) can be used to create abstractions that compile everything down to inlined maximally performant code. This type of code tends to be hard to maintain though. AFAIK you can get there in Rust but it's a little more cumbersome. You have to implement a lot…

> This type of code tends to be hard to maintain though

Depends on which C++ version one needs to support, in C++20 and later, it is relatively maintainable with concepts, constexpre, and reflection.

Re: Performance of Rust Language [pdf]

#113

Post by pjmlp »

afdbcreid wrote: post #16
fithisux wrote: post #13

Earlier quoted context omitted.

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.

Because you can write C like code, while taking advantage of templates, compile time code execution, and eventually static reflection, that prepare work ahead of time, while at the same time giving more information to optimiser passes.

Re: Performance of Rust Language [pdf]

#114

Post by jstimpfle »

pjmlp wrote: post #112
api wrote: post #98

Earlier quoted context omitted.

I think they may be talking about math algorithm heavy code, where C++'s looser almost-just-a-substitution generics system (really "templates" not even quite generics) can be used to create abstractions that compile everything down to inlined maximally performant code. This type of code tends to be hard to maintain though. AFAIK you can get there in Rust but it's a little more cumbersome. You have to implement a lot…

> This type of code tends to be hard to maintain though Depends on which C++ version one needs to support, in C++20 and later, it is relatively maintainable with concepts, constexpre, and reflection.

I think they're all ideas that are relatively obvious intuitive responses to the problem, and yet they may only incrase complexity tbh. For example, constexpr can be used relatively independent of template programming even, yet where they can be used practically before it becomes an unmaintainable mess of boilerplate are the most trivial cases, almost those which you could have hacked in with macros. TBF I think if you need serious metaprogramming, just compile and run a program at compile time.

Reflection has always been a mess no matter which implementation or language I've used. Fine for scripting languages, unusable for anything serious complex. The data you need is never there, and the data that is there is unusable, at the wrong semantic level (programming language level not what actually your own domain model semantics).

Also I avoid templates for the same reason, they're quickly becoming unmaintainable. Yes, I've tried to make use of them many times, and I have a fair number of them in deployed software. They work without bugs, of course. But I still don't love them, they're boilerplatey hard to maintain complexity that would be better solved with the right factoring plus a tiny bit of ad-hoc boilerplate. I would like to remove many of my deployed templates if I had the time.

And yes, I even avoid std:: template containers and such. Most uses I regret later. Again, this is for systems programming. They're fine for "scripting", leetcode, business software.

Re: Performance of Rust Language [pdf]

#115

Post by pjmlp »

cogman10 wrote: post #84
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 ca…

Reflection, Rust community did a very good job driving away the person that cared to do that work, to the point he went back to C and C++ ISO comittees.

Several features on C23 were done thanks to his work.

Also compile time execution is much more rich in C++ than Rust, regardling language features and standard library that can be used at compile time.

Naturally none of the languages is standing still, and they will both improve on that regard.

Re: Performance of Rust Language [pdf]

#116

Post by pjmlp »

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…

See languages like D, Delphi, Ada, C++ (with modules/libraries, REPLs like CINT), Haskell (GHCi), OCaml (REPL) for similar complexity levels, and faster compile times.

It is a matter of tooling, eventually they will get there I guess.

Re: Performance of Rust Language [pdf]

#117

Post by scns »

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…

Have you switched to a faster linker [0] yet? Do you use sccache?

[0] https://github.com/rui314/mold

Re: Performance of Rust Language [pdf]

#118

Post by pjmlp »

jstimpfle wrote: post #114
pjmlp wrote: post #112

Earlier quoted context omitted.

> This type of code tends to be hard to maintain though Depends on which C++ version one needs to support, in C++20 and later, it is relatively maintainable with concepts, constexpre, and reflection.

I think they're all ideas that are relatively obvious intuitive responses to the problem, and yet they may only incrase complexity tbh. For example, constexpr can be used relatively independent of template programming even, yet where they can be used practically before it becomes an unmaintainable mess of boilerplate are the most trivial cases, almost those which you could have hacked in with macros. TBF I think if y…

Is writing compilers, linkers, database servers, HPC and HFT platforms, OS drivers, networking stacks at IP level, considered systems programming accordign to you, or are they plain business software?

Re: Performance of Rust Language [pdf]

#119

Post by jstimpfle »

pjmlp wrote: post #118
jstimpfle wrote: post #114

Earlier quoted context omitted.

I think they're all ideas that are relatively obvious intuitive responses to the problem, and yet they may only incrase complexity tbh. For example, constexpr can be used relatively independent of template programming even, yet where they can be used practically before it becomes an unmaintainable mess of boilerplate are the most trivial cases, almost those which you could have hacked in with macros. TBF I think if y…

Is writing compilers, linkers, database servers, HPC and HFT platforms, OS drivers, networking stacks at IP level, considered systems programming accordign to you, or are they plain business software?

I said, I avoid, I don't love, I was talking about preference. And I'll state: Most of these are written mostly like I say. Please find serious counter-examples.

Re: Performance of Rust Language [pdf]

#120

Post by pjmlp »

jstimpfle wrote: post #119
pjmlp wrote: post #118

Earlier quoted context omitted.

Is writing compilers, linkers, database servers, HPC and HFT platforms, OS drivers, networking stacks at IP level, considered systems programming accordign to you, or are they plain business software?

I said, I avoid, I don't love, I was talking about preference. And I'll state: Most of these are written mostly like I say. Please find serious counter-examples.

A cursory glance to the ones that are publicly available shows otherwise.
Post reply on HN