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
On Windows? Use a dev drive.
Performance of Rust Language [pdf]
91–100 of 146 posts
Re: Performance of Rust Language [pdf]
#92I 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…
[deleted]
Re: Performance of Rust Language [pdf]
#93I 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…
There are a number of compiler performance enhancements (and correctness improvements) that are being worked on that are kind of at a chokepoint behind some other piece of work. Unfortunately it's not that easy to discern what state they're in or how quickly they're making progress.
At some point though a lot of work will be able to start advancing at once, so long as people exist to do the work.
e.g. https://rust-lang.github.io/rust-project-goals/2026/parallel...
Re: Performance of Rust Language [pdf]
#94I 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…
Last I checked (which was a while ago to be fair), LLVM machine code quality still lagged behind GCC - so things should be slightly more interesting with the GCC back end.
There were also some bugs (hence disabled optimization passes) and missed opportunities from the lack of aliasing Rust precipitates - again, not sure where those sit - and GCC will have to play catch up here (unless there are other languages that exercise this part of the backend).
Re: Performance of Rust Language [pdf]
#95I 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…
Nim also has top notch meta programming, probably more so than Zig. You can easily do loop unrolling, specialization, etc. For example Constantine, which is a constant time crypto library that outperforms C, etc. To me programming Rust feels so limiting due to lack of good compile time meta programming with types . That’s the key.
I have tried Nim meta programming (to make a tree vaguely like the one used by Zed), and the tooling support of pretty dreadful. I ran into multiple compiler crashes or simply unhelpful and confusing error messages, alongside LSP hangs.
Re: Performance of Rust Language [pdf]
#96I 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…
C++ being more performant than C is not something that I've seen in any benchmarks or personal experience.
In practice, some of the cases about specialization that was made possible with C++ constructs is also achieved by modern C compilers.
Re: Performance of Rust Language [pdf]
#97I 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…
> Rust's metaprogramming capabilities are now on par with C++ (they weren't always).
Is that really true, though? I haven't really written any Rust code, so I have no idea, but I don't think Rust has static reflection. Also, aren't const generics much more limited? I've also heard there is no template specialization and no "if constexpr". Or what about dynamic allocations in constexpr functions?
Re: Performance of Rust Language [pdf]
#98I 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 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 of operators, and for that type of code you might actually benefit from #[inline(always)] which is discouraged in normal Rust.
Re: Performance of Rust Language [pdf]
#99Earlier quoted context omitted.
> 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…
> Rust's metaprogramming capabilities are now on par with C++ (they weren't always). Is that really true, though? I haven't really written any Rust code, so I have no idea, but I don't think Rust has static reflection. Also, aren't const generics much more limited? I've also heard there is no template specialization and no "if constexpr". Or what about dynamic allocations in constexpr functions?
> I don't think Rust has static reflection.
Before C++ in fact through procedural macros. You can do everything you can do with C++ static reflection.
Now, it could be better. Proc macros require you to pull in secondary packages for parsing the token stream. But all the sorts of operations you can do via static reflection you can do via proc macros. That's how the most popular rust serialization package like serde works. It's also how some more popular database libs work like sqlx.
> Also, aren't const generics much more limited? I've also heard there is no template specialization and no "if constexpr".
Both have been added and expanded. AFAIK they are now roughly on par with what C++ const expressions can do. What they can't do, proc macros can do.
> Or what about dynamic allocations in constexpr functions?
IDK if that's possible in rust. Const expr capabilities of rust have been rapidly expanding though in the last year.
Re: Performance of Rust Language [pdf]
#100Earlier quoted context omitted.
Whoops! Although there is no public contract between HIR and MIR, the public part was not relevant here. What I wanted to highlight is that if they'd want to add proper proof machinery to eliminate low-level safety checks, they'd have to do it at: surface language, which is already complex enough; then HIR->MIR boundary with clean provenance (which I think current MIR would collapse too aggressively) and which may re…
Of course you can write the above as: a[0..32].iter_mut().for_each(|el| *el = 1) and have per-iteration bounds checks elided in Rust today.
Or as mentioned in the OP, just add at the top:
assert!(a.len() >= 32);
for i in 0..32 {
a[i] = 0;
}
for i in 0..std::cmp::min(a.len(), 32) {
a[i] = 0;
}
As for the speed comparisons with C++, the OP says at the end you tell the C++ compiler to be as strict as Rust using "-D_FORTIFY_SOURCE=3 -fsanitize=bounds,object-size" & hardened STL, then it slows to below Rust speeds for the same safety unless you use the same techniques.
It's a shame the other optimisation techniques you need to bring Rust in line with C++ aren't as easy to apply.