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

131–140 of 146 posts

Re: Performance of Rust Language [pdf]

#131

Post by pjmlp »

jstimpfle wrote: post #126
pjmlp wrote: post #124

Earlier quoted context omitted.

To use the developers own words, > Necessary to bootstrap GCC. GCC 5.4 or newer has sufficient support for used C++14 features. > Versions of GCC prior to 15 allow bootstrapping with an ISO C++11 compiler, versions prior to 10.5 allow bootstrapping with an ISO C++98 compiler, and versions prior to 4.8 allow bootstrapping with an ISO C89 compiler. > If you need to build an intermediate version of GCC in order to boots…

Why are you unable to get my point? I understand that GCC doesn't compile with plain C compiler anymore. A lot of my own code doesn't! I'm saying that most of features like templates, constexpr, reflection etc. don't scale well to serious use, as a broad statement. I fully acknowledge this is not a black and white situation. But I encourage you to look at actual pedestrian code, it's mostly not abstracted fluffy magi…

Because I am having this conversation with C folks since comp.lang.c and com.lang.c.moderated days.

C++ was perfectly usable already within the constraints of DR/MS-DOS 5.0 powered PC hardware with Borland compilers, instead of plain old C.

Fluffy features power the AI revolution infrastructure.

Re: Performance of Rust Language [pdf]

#132

Post by yogthos »

scns wrote: post #117
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

oh didn't know about this one, will have to try

Re: Performance of Rust Language [pdf]

#133

Post by postflopclarity »

wolvesechoes wrote: post #125
nsajko wrote: post #58

Earlier quoted context omitted.

Julia is another contender. Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++. Even without accounting for Julia's metaprogramming features, the compile-time expressiveness is top-notch. It shares some of the same drawbacks as C++, though. The language is extremely powerful, so while it is easy to write performant code, it is also easy for non experts to write very suboptim…

> Julia code can be as performant as C++ code, but Julia code may be even more elegant than C++ But not at the same time

depends on the workload. many are elegant and fast. some require a bit of clunkiness to wring out the last drops of performance

Re: Performance of Rust Language [pdf]

#134

Post by culebron21 »

jarym wrote: post #48

I've been doing more and more Rust. Even with sscache the compile times are not great so for any moderately sized codebase that requires frequent rebuilds I don't know how everyone else is doing it

I split into subcrates and also reduce the number of proc macros (e.g. got rid of Serde).

Re: Performance of Rust Language [pdf]

#135

Post by culebron21 »

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…

I had similar problems. Compilation got 10x faster once I split one crate into workspace with crates inside. The checks are only done on the compiled one. Then, I got rid of serde, because its derive macros are heavy and add some seconds of hickup (other serialization frameworks based on proc macros are slow too: rkyv, musli).

Re: Performance of Rust Language [pdf]

#136

Post by mswphd »

yogthos wrote: post #83
DauntingPear7 wrote: post #77

Earlier quoted context omitted.

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.

for context: in rust the "translation unit" is a crate (in C++, each source file is its own translation unit). So you only get parallelism across crates when compiling in rust. When you have a single-crate project, this means that

1. you get parallelism across all your dependencies, but

2. your (final) crate is serial.

Splitting your crate can therefore get you parallelism back in step 2, which can be a (compilation) perf win. You can also get a caching benefit when there aren't changes, but even absent that you can get wins.

It can come at the cost of runtime performance though, as rust won't (by default) do things like inline across translation units iirc. You can get back some of this perf back via various tricks (for example link-time optimization).

Looks like the rust performance book has some writing on these tradeoffs. I haven't read these articles, but the table of contents on the left seems reasonable enough.

https://nnethercote.github.io/perf-book/build-configuration....

Again I haven't read that (so I'm assuming it says the following), but you can get "best of both worlds" by configuring debug builds to not do LTO (= faster compilation speed, slower runtime), and release builds to do LTO (= faster runtime, slower compilation speed). There are also variants of LTO that make various tradeoffs you could look into.

That article also links to the `cargo-wizard` subcommand of cargo

https://github.com/Kobzol/cargo-wizard

it won't auto-split crates for you (of course), but it does seem to give you some default configurations of `cargo`, one of which configures for faster compilation speed. could be an easy way to mess around with things.

Re: Performance of Rust Language [pdf]

#137

Post by jstimpfle »

pjmlp wrote: post #131
jstimpfle wrote: post #126

Earlier quoted context omitted.

Why are you unable to get my point? I understand that GCC doesn't compile with plain C compiler anymore. A lot of my own code doesn't! I'm saying that most of features like templates, constexpr, reflection etc. don't scale well to serious use, as a broad statement. I fully acknowledge this is not a black and white situation. But I encourage you to look at actual pedestrian code, it's mostly not abstracted fluffy magi…

Because I am having this conversation with C folks since comp.lang.c and com.lang.c.moderated days. C++ was perfectly usable already within the constraints of DR/MS-DOS 5.0 powered PC hardware with Borland compilers, instead of plain old C. Fluffy features power the AI revolution infrastructure.

Congratulations, empty marketing speech, not reacting to what I say.

Re: Performance of Rust Language [pdf]

#138

Post by nicoburns »

gobdovan wrote: post #105
rstuart4133 wrote: post #100

Earlier quoted context omitted.

Or as mentioned in the OP, just add at the top: assert!(a.len() >= 32); for i in 0..32 { a[i] = 0; } Or: for i in 0..std::cmp::min(a.len(), 32) { a[i] = 0; } I confess I hadn't thought about the implications of any of this before reading the article. If you need to squeeze the last 10% of performance out of your code, I'd consider it required reading. As for the speed comparisons with C++, the OP says at the end you…

Both rewrites differ semantically from: for i in 0..32 { a[i] = 1; } If a.len() == 16, the indexed loop writes a[0]..a[15] and then panics at a[16]. By contrast, both assert!(a.len() >= 32); and a[0..32].iter_mut().for_each(|el| *el = 1) fail before any writes occur. The former at the explicit assertion, the latter while creating the a[0..32] subslice. That difference is observable if the panic is caught, and the pan…

That's relevant if we're talking about the compiler automatically rewriting the code, but the chances are if you're writing this code yourself that the array will always have >= 32 elements.

Re: Performance of Rust Language [pdf]

#139

Post by rstuart4133 »

gobdovan wrote: post #105
rstuart4133 wrote: post #100

Earlier quoted context omitted.

Or as mentioned in the OP, just add at the top: assert!(a.len() >= 32); for i in 0..32 { a[i] = 0; } Or: for i in 0..std::cmp::min(a.len(), 32) { a[i] = 0; } I confess I hadn't thought about the implications of any of this before reading the article. If you need to squeeze the last 10% of performance out of your code, I'd consider it required reading. As for the speed comparisons with C++, the OP says at the end you…

Both rewrites differ semantically from: for i in 0..32 { a[i] = 1; } If a.len() == 16, the indexed loop writes a[0]..a[15] and then panics at a[16]. By contrast, both assert!(a.len() >= 32); and a[0..32].iter_mut().for_each(|el| *el = 1) fail before any writes occur. The former at the explicit assertion, the latter while creating the a[0..32] subslice. That difference is observable if the panic is caught, and the pan…

> The GitHub issue discussion is directly about these concerns and discuss whether bounds checks may fail early, whether intermediate writes are observable after catch_unwind and whether panic behavior must be preserved.

No argument about the point of the issue. But this is a discussion about the relative efficiency of C, C++ and Rust. My point is there is a way in Rust to say "I don't care about observable writes, hoist the bounds check out of the loop", so that the efficiency is the same.

Admittedly, it's not part of the language definition. You're relying on intimate knowledge of how the optimiser works. In fact, you are probably pasting the code into godbolt, and looking at the assembler produced. But if you care about cycles that much, that's true for all three languages.

Re: Performance of Rust Language [pdf]

#140

Post by yogthos »

mswphd wrote: post #136
yogthos wrote: post #83

Earlier quoted context omitted.

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.

for context: in rust the "translation unit" is a crate (in C++, each source file is its own translation unit). So you only get parallelism across crates when compiling in rust. When you have a single-crate project, this means that 1. you get parallelism across all your dependencies, but 2. your (final) crate is serial. Splitting your crate can therefore get you parallelism back in step 2, which can be a (compilation)…

Thanks, that's helpful to keep in mind. Looks like you can fiddle with organizing the project in way where you can balance 1 and 2 in a reasonable way. Right now, it's definitely the second step that's killing me where assembling the crates together takes forever.
Post reply on HN