Is Rust stack-efficient yet?
arewestackefficientyet.com
Is Rust stack-efficient yet?
1–10 of 111 posts
Re: Is Rust stack-efficient yet?
#2Apparently not: ERR_CONNECTION_TIMED_OUT
Re: Is Rust stack-efficient yet?
#3I don’t understand the point of this. Is there a trade off in being stack efficient and speed?
Re: Is Rust stack-efficient yet?
#4Apparently not: ERR_CONNECTION_TIMED_OUT
Seems to be up now. For me at least.
Re: Is Rust stack-efficient yet?
#5It would be more informative if the stack metrics were paired with heap metrics. You can trivially avoid stack to stack copies by allocating on the heap and passing pointers / references. But that is often actually slower, because heap allocation is more costly than copying data within the stack.
Re: Is Rust stack-efficient yet?
#6I don’t understand the point of this. Is there a trade off in being stack efficient and speed?
The main goal is removing replacing pointless stack-to-stack copies with simply mutating in-place on the stack correctly in the first place.
Due to some mix of:
* Rust code relying more on copies than C++ (for esample, harder to make something uninitialized and fill it in)
* LLVM missing optimizations that rust relies on heavier than C++
* No real guarantees around RVO / NRVO
Rust code often will put something on the stack, and then just instantly copy it somewhere else on the stack, even in optimized code. I've observed this happening sometimes pretty blatantly myself.
Re: Is Rust stack-efficient yet?
#7I don’t understand the point of this. Is there a trade off in being stack efficient and speed?
FTA:
> Why do we care about stack memory moves?
> Memory moves to the stack frequently represent wasted computation. For the most part, they're CPU cycles that are spent shuffling data from one place to another instead of performing useful work. Stack-to-stack memory moves in particular are very likely to represent pure overhead; non-stack-to-stack memory moves are sometimes genuinely useful and necessary but frequently also represent waste.
Re: Is Rust stack-efficient yet?
#8[deleted]
Re: Is Rust stack-efficient yet?
#9I've run into frustrating stack overflows in seemingly trivial non-recursive code, so I appreciate this effort!
I wonder if it might be simpler to track stack sizes statically instead of using runtime instrumentation. What I mean is, for example on x86_64, the function prologue has a stack reservation in the form of `sub rbp, 0x168`. So we can easily tell that the function uses 0x168 bytes of stack space. Just add those numbers up for every function in a crate, and you have a score. Track that number over time for a set of common crates.
Re: Is Rust stack-efficient yet?
#10I don’t understand the point of this. Is there a trade off in being stack efficient and speed?
"Memory moves to the stack frequently represent wasted computation. For the most part, they're CPU cycles that are spent shuffling data from one place to another instead of performing useful work. Stack-to-stack memory moves in particular are very likely to represent pure overhead; non-stack-to-stack memory moves are sometimes genuinely useful and necessary but frequently also represent waste."
It's essentially a critique that the optimizer is missing opportunities.